1. 16 May, 2016 1 commit
  2. 23 Apr, 2016 6 commits
  3. 21 Apr, 2016 1 commit
  4. 20 Apr, 2016 2 commits
  5. 19 Apr, 2016 1 commit
  6. 30 Sep, 2015 1 commit
  7. 31 Mar, 2015 2 commits
  8. 17 Jan, 2015 1 commit
    • Johannes Berg's avatar
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg authored
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      053c095a
  9. 05 Jan, 2015 1 commit
  10. 28 Oct, 2014 1 commit
  11. 16 Oct, 2014 1 commit
  12. 28 Jul, 2014 1 commit
  13. 21 Sep, 2013 1 commit
  14. 10 Sep, 2012 1 commit
  15. 03 Aug, 2012 1 commit
  16. 02 Apr, 2012 3 commits
  17. 01 Apr, 2012 1 commit
  18. 30 Jan, 2012 1 commit
  19. 04 Nov, 2011 1 commit
  20. 22 Jun, 2011 1 commit
    • Johannes Berg's avatar
      netlink: advertise incomplete dumps · 670dc283
      Johannes Berg authored
      Consider the following situation:
       * a dump that would show 8 entries, four in the first
         round, and four in the second
       * between the first and second rounds, 6 entries are
         removed
       * now the second round will not show any entry, and
         even if there is a sequence/generation counter the
         application will not know
      
      To solve this problem, add a new flag NLM_F_DUMP_INTR
      to the netlink header that indicates the dump wasn't
      consistent, this flag can also be set on the MSG_DONE
      message that terminates the dump, and as such above
      situation can be detected.
      
      To achieve this, add a sequence counter to the netlink
      callback struct. Of course, netlink code still needs
      to use this new functionality. The correct way to do
      that is to always set cb->seq when a dumpit callback
      is invoked and call nl_dump_check_consistent() for
      each new message. The core code will also call this
      function for the final MSG_DONE message.
      
      To make it usable with generic netlink, a new function
      genlmsg_nlhdr() is needed to obtain the netlink header
      from the genetlink user header.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      670dc283
  21. 10 May, 2011 1 commit
  22. 01 Feb, 2011 1 commit
  23. 16 Nov, 2010 1 commit
  24. 04 Nov, 2010 1 commit
  25. 23 Jun, 2010 1 commit
  26. 19 Mar, 2010 1 commit
  27. 18 Feb, 2010 1 commit
  28. 25 Aug, 2009 1 commit
  29. 27 May, 2009 1 commit
  30. 25 Mar, 2009 1 commit
  31. 25 Dec, 2008 1 commit
    • Vegard Nossum's avatar
      netlink: fix (theoretical) overrun in message iteration · 619e803d
      Vegard Nossum authored
      See commit 1045b03e ("netlink: fix
      overrun in attribute iteration") for a detailed explanation of why
      this patch is necessary.
      
      In short, nlmsg_next() can make "remaining" go negative, and the
      remaining >= sizeof(...) comparison will promote "remaining" to an
      unsigned type, which means that the expression will evaluate to
      true for negative numbers, even though it was not intended.
      
      I put "theoretical" in the title because I have no evidence that
      this can actually happen, but I suspect that a crafted netlink
      packet can trigger some badness.
      
      Note that the last test, which seemingly has the exact same
      problem (also true for nla_ok()), is perfectly OK, since we
      already know that remaining is positive.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      619e803d