Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 30 9月, 2015 1 次提交
  3. 26 5月, 2015 3 次提交
  5. 08 4月, 2015 1 次提交
    • D
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      由 David Miller 提交于 
      On the output paths in particular, we have to sometimes deal with two
socket contexts.  First, and usually skb->sk, is the local socket that
generated the frame.

And second, is potentially the socket used to control a tunneling
socket, such as one the encapsulates using UDP.

We do not want to disassociate skb->sk when encapsulating in order
to fix this, because that would break socket memory accounting.

The most extreme case where this can cause huge problems is an
AF_PACKET socket transmitting over a vxlan device.  We hit code
paths doing checks that assume they are dealing with an ipv4
socket, but are actually operating upon the AF_PACKET one.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7026b1dd
  7. 07 4月, 2015 1 次提交
    • H
      ipv6: protect skb->sk accesses from recursive dereference inside the stack · f60e5990
      由 hannes@stressinduktion.org 提交于 
      We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.

ipv6 does not conform with this in three places:

1) ip6_fragment: we do consult ipv6_npinfo for frag_size

2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
   loop the packet back to the local socket

3) ip6_skb_dst_mtu could query the settings from the user socket and
   force a wrong MTU

Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.

Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.

Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f60e5990
  9. 16 5月, 2014 1 次提交
    • D
      ipv6: update Destination Cache entries when gateway turn into host · be7a010d
      由 Duan Jiong 提交于 
      RFC 4861 states in 7.2.5:

	The IsRouter flag in the cache entry MUST be set based on the
         Router flag in the received advertisement.  In those cases
         where the IsRouter flag changes from TRUE to FALSE as a result
         of this update, the node MUST remove that router from the
         Default Router List and update the Destination Cache entries
         for all destinations using that neighbor as a router as
         specified in Section 7.3.3.  This is needed to detect when a
         node that is used as a router stops forwarding packets due to
         being configured as a host.

Currently, when dealing with NA Message which IsRouter flag changes from
TRUE to FALSE, the kernel only removes router from the Default Router List,
and don't update the Destination Cache entries.

Now in order to update those Destination Cache entries, i introduce
function rt6_clean_tohost().
Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be7a010d
  11. 13 5月, 2014 1 次提交
  13. 15 4月, 2014 1 次提交
  15. 01 4月, 2014 1 次提交
  17. 27 2月, 2014 1 次提交
  19. 08 1月, 2014 1 次提交
  21. 02 1月, 2014 1 次提交
  23. 19 12月, 2013 1 次提交
  25. 22 10月, 2013 2 次提交
  27. 22 9月, 2013 1 次提交
  29. 01 9月, 2013 1 次提交
  31. 23 8月, 2013 1 次提交
  33. 19 1月, 2013 1 次提交
  35. 18 1月, 2013 1 次提交
  37. 16 11月, 2012 1 次提交
  39. 18 7月, 2012 1 次提交
  41. 12 7月, 2012 3 次提交
  43. 16 6月, 2012 1 次提交
    • D
      ipv6: Handle PMTU in ICMP error handlers. · 81aded24
      由 David S. Miller 提交于 
      One tricky issue on the ipv6 side vs. ipv4 is that the ICMP callouts
to handle the error pass the 32-bit info cookie in network byte order
whereas ipv4 passes it around in host byte order.

Like the ipv4 side, we have two helper functions.  One for when we
have a socket context and one for when we do not.

ip6ip6 tunnels are not handled here, because they handle PMTU events
by essentially relaying another ICMP packet-too-big message back to
the original sender.

This patch allows us to get rid of rt6_do_pmtu_disc().  It handles all
kinds of situations that simply cannot happen when we do the PMTU
update directly using a fully resolved route.

In fact, the "plen == 128" check in ip6_rt_update_pmtu() can very
likely be removed or changed into a BUG_ON() check.  We should never
have a prefixed ipv6 route when we get there.

Another piece of strange history here is that TCP and DCCP, unlike in
ipv4, never invoke the update_pmtu() method from their ICMP error
handlers.  This is incredibly astonishing since this is the context
where we have the most accurate context in which to make a PMTU
update, namely we have a fully connected socket and associated cached
socket route.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81aded24
  45. 12 6月, 2012 1 次提交
  47. 11 6月, 2012 1 次提交
  49. 09 6月, 2012 1 次提交
  51. 19 5月, 2012 1 次提交
  53. 16 4月, 2012 1 次提交
  55. 07 12月, 2011 2 次提交
  57. 05 12月, 2011 1 次提交
  59. 25 4月, 2011 1 次提交
  61. 23 4月, 2011 1 次提交
  63. 16 4月, 2011 1 次提交
  65. 23 3月, 2011 1 次提交
  67. 13 3月, 2011 1 次提交