1. 17 5月, 2016 1 次提交
  2. 24 4月, 2016 6 次提交
  3. 22 4月, 2016 1 次提交
  4. 21 4月, 2016 1 次提交
  5. 20 4月, 2016 2 次提交
  6. 30 9月, 2015 1 次提交
  7. 01 4月, 2015 2 次提交
  8. 18 1月, 2015 1 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
  9. 06 1月, 2015 1 次提交
  10. 29 10月, 2014 1 次提交
  11. 17 10月, 2014 1 次提交
  12. 29 7月, 2014 1 次提交
  13. 22 9月, 2013 1 次提交
  14. 11 9月, 2012 1 次提交
  15. 04 8月, 2012 1 次提交
  16. 02 4月, 2012 4 次提交
  17. 31 1月, 2012 1 次提交
  18. 05 11月, 2011 1 次提交
  19. 23 6月, 2011 1 次提交
    • J
      netlink: advertise incomplete dumps · 670dc283
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      670dc283
  20. 10 5月, 2011 1 次提交
  21. 01 2月, 2011 1 次提交
  22. 17 11月, 2010 1 次提交
  23. 05 11月, 2010 1 次提交
  24. 24 6月, 2010 1 次提交
  25. 20 3月, 2010 1 次提交
  26. 19 2月, 2010 1 次提交
  27. 25 8月, 2009 1 次提交
  28. 27 5月, 2009 1 次提交
  29. 26 3月, 2009 1 次提交
  30. 26 12月, 2008 1 次提交
    • V
      netlink: fix (theoretical) overrun in message iteration · 619e803d
      Vegard Nossum 提交于
      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: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      619e803d