Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 17 5月, 2016 1 次提交
  3. 24 4月, 2016 6 次提交
  5. 22 4月, 2016 1 次提交
  7. 21 4月, 2016 1 次提交
  9. 20 4月, 2016 2 次提交
  11. 30 9月, 2015 1 次提交
  13. 01 4月, 2015 2 次提交
  15. 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
  17. 06 1月, 2015 1 次提交
  19. 29 10月, 2014 1 次提交
  21. 17 10月, 2014 1 次提交
  23. 29 7月, 2014 1 次提交
  25. 22 9月, 2013 1 次提交
  27. 11 9月, 2012 1 次提交
  29. 04 8月, 2012 1 次提交
  31. 02 4月, 2012 4 次提交
  33. 31 1月, 2012 1 次提交
  35. 05 11月, 2011 1 次提交
  37. 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
  39. 10 5月, 2011 1 次提交
  41. 01 2月, 2011 1 次提交
  43. 17 11月, 2010 1 次提交
  45. 05 11月, 2010 1 次提交
  47. 24 6月, 2010 1 次提交
  49. 20 3月, 2010 1 次提交
  51. 19 2月, 2010 1 次提交
  53. 25 8月, 2009 1 次提交
  55. 27 5月, 2009 1 次提交
  57. 26 3月, 2009 1 次提交
  59. 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