1. 25 8月, 2014 1 次提交
    • I
      ipv6: White-space cleansing : Line Layouts · 67ba4152
      Ian Morris 提交于
      This patch makes no changes to the logic of the code but simply addresses
      coding style issues as detected by checkpatch.
      
      Both objdump and diff -w show no differences.
      
      A number of items are addressed in this patch:
      * Multiple spaces converted to tabs
      * Spaces before tabs removed.
      * Spaces in pointer typing cleansed (char *)foo etc.
      * Remove space after sizeof
      * Ensure spacing around comparators such as if statements.
      Signed-off-by: NIan Morris <ipm@chirality.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67ba4152
  2. 22 5月, 2014 1 次提交
  3. 17 5月, 2014 1 次提交
  4. 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
  5. 14 5月, 2014 1 次提交
    • L
      net: Use fwmark reflection in PMTU discovery. · 1b3c61dc
      Lorenzo Colitti 提交于
      Currently, routing lookups used for Path PMTU Discovery in
      absence of a socket or on unmarked sockets use a mark of 0.
      This causes PMTUD not to work when using routing based on
      netfilter fwmark mangling and fwmark ip rules, such as:
      
        iptables -j MARK --set-mark 17
        ip rule add fwmark 17 lookup 100
      
      This patch causes these route lookups to use the fwmark from the
      received ICMP error when the fwmark_reflect sysctl is enabled.
      This allows the administrator to make PMTUD work by configuring
      appropriate fwmark rules to mark the inbound ICMP packets.
      
      Black-box tested using user-mode linux by pointing different
      fwmarks at routing tables egressing on different interfaces, and
      using iptables mangling to mark packets inbound on each interface
      with the interface's fwmark. ICMPv4 and ICMPv6 PMTU discovery
      work as expected when mark reflection is enabled and fail when
      it is disabled.
      Signed-off-by: NLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b3c61dc
  6. 29 4月, 2014 1 次提交
  7. 16 4月, 2014 1 次提交
  8. 15 4月, 2014 1 次提交
  9. 01 4月, 2014 1 次提交
  10. 28 3月, 2014 1 次提交
    • M
      ipv6: do not overwrite inetpeer metrics prematurely · e5fd387a
      Michal Kubeček 提交于
      If an IPv6 host route with metrics exists, an attempt to add a
      new route for the same target with different metrics fails but
      rewrites the metrics anyway:
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1s
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1500
      RTNETLINK answers: File exists
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1.5s
      
      This is caused by all IPv6 host routes using the metrics in
      their inetpeer (or the shared default). This also holds for the
      new route created in ip6_route_add() which shares the metrics
      with the already existing route and thus ip6_route_add()
      rewrites the metrics even if the new route ends up not being
      used at all.
      
      Another problem is that old metrics in inetpeer can reappear
      unexpectedly for a new route, e.g.
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip route del fec0::1
      12sp0:~ # ip route add fec0::1 dev eth0
      12sp0:~ # ip route change fec0::1 dev eth0 hoplimit 10
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  hoplimit 10 rto_min lock 1s
      
      Resolve the first problem by moving the setting of metrics down
      into fib6_add_rt2node() to the point we are sure we are
      inserting the new route into the tree. Second problem is
      addressed by introducing new flag DST_METRICS_FORCE_OVERWRITE
      which is set for a new host route in ip6_route_add() and makes
      ipv6_cow_metrics() always overwrite the metrics in inetpeer
      (even if they are not "new"); it is reset after that.
      
      v5: use a flag in _metrics member rather than one in flags
      
      v4: fix a typo making a condition always true (thanks to Hannes
      Frederic Sowa)
      
      v3: rewritten based on David Miller's idea to move setting the
      metrics (and allocation in non-host case) down to the point we
      already know the route is to be inserted. Also rebased to
      net-next as it is quite late in the cycle.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5fd387a
  11. 07 3月, 2014 1 次提交
  12. 02 1月, 2014 2 次提交
  13. 20 12月, 2013 1 次提交
  14. 12 12月, 2013 1 次提交
    • J
      ipv6: router reachability probing · 7e980569
      Jiri Benc 提交于
      RFC 4191 states in 3.5:
      
         When a host avoids using any non-reachable router X and instead sends
         a data packet to another router Y, and the host would have used
         router X if router X were reachable, then the host SHOULD probe each
         such router X's reachability by sending a single Neighbor
         Solicitation to that router's address.  A host MUST NOT probe a
         router's reachability in the absence of useful traffic that the host
         would have sent to the router if it were reachable.  In any case,
         these probes MUST be rate-limited to no more than one per minute per
         router.
      
      Currently, when the neighbour corresponding to a router falls into
      NUD_FAILED, it's never considered again. Introduce a new rt6_nud_state
      value, RT6_NUD_FAIL_PROBE, which suggests the route should not be used but
      should be probed with a single NS. The probe is ratelimited by the existing
      code. To better distinguish meanings of the failure values, rename
      RT6_NUD_FAIL_SOFT to RT6_NUD_FAIL_DO_RR.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e980569
  15. 10 12月, 2013 1 次提交
  16. 03 12月, 2013 1 次提交
  17. 09 11月, 2013 1 次提交
  18. 06 11月, 2013 1 次提交
  19. 31 10月, 2013 1 次提交
  20. 26 10月, 2013 1 次提交
    • H
      ipv6: ip6_dst_check needs to check for expired dst_entries · e3bc10bd
      Hannes Frederic Sowa 提交于
      On receiving a packet too big icmp error we check if our current cached
      dst_entry in the socket is still valid. This validation check did not
      care about the expiration of the (cached) route.
      
      The error path I traced down:
      The socket receives a packet too big mtu notification. It still has a
      valid dst_entry and thus issues the ip6_rt_pmtu_update on this dst_entry,
      setting RTF_EXPIRE and updates the dst.expiration value (which could
      fail because of not up-to-date expiration values, see previous patch).
      
      In some seldom cases we race with a) the ip6_fib gc or b) another routing
      lookup which would result in a recreation of the cached rt6_info from its
      parent non-cached rt6_info. While copying the rt6_info we reinitialize the
      metrics store by copying it over from the parent thus invalidating the
      just installed pmtu update (both dsts use the same key to the inetpeer
      storage). The dst_entry with the just invalidated metrics data would
      just get its RTF_EXPIRES flag cleared and would continue to stay valid
      for the socket.
      
      We should have not issued the pmtu update on the already expired dst_entry
      in the first placed. By checking the expiration on the dst entry and
      doing a relookup in case it is out of date we close the race because
      we would install a new rt6_info into the fib before we issue the pmtu
      update, thus closing this race.
      
      Not reliably updating the dst.expire value was fixed by the patch "ipv6:
      reset dst.expires value when clearing expire flag".
      Reported-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
      Reported-by: NValentijn Sessink <valentyn@blub.net>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NValentijn Sessink <valentyn@blub.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3bc10bd
  21. 22 10月, 2013 2 次提交
  22. 01 10月, 2013 1 次提交
  23. 28 9月, 2013 1 次提交
  24. 06 9月, 2013 1 次提交
    • D
      ipv6:introduce function to find route for redirect · b55b76b2
      Duan Jiong 提交于
      RFC 4861 says that the IP source address of the Redirect is the
      same as the current first-hop router for the specified ICMP
      Destination Address, so the gateway should be taken into
      consideration when we find the route for redirect.
      
      There was once a check in commit
      a6279458 ("NDISC: Search over
      all possible rules on receipt of redirect.") and the check
      went away in commit b94f1c09
      ("ipv6: Use icmpv6_notify() to propagate redirect, instead of
      rt6_redirect()").
      
      The bug is only "exploitable" on layer-2 because the source
      address of the redirect is checked to be a valid link-local
      address but it makes spoofing a lot easier in the same L2
      domain nonetheless.
      
      Thanks very much for Hannes's help.
      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>
      b55b76b2
  25. 01 9月, 2013 1 次提交
  26. 23 8月, 2013 1 次提交
  27. 02 8月, 2013 2 次提交
    • M
      ipv6: update ip6_rt_last_gc every time GC is run · 49a18d86
      Michal Kubeček 提交于
      As pointed out by Eric Dumazet, net->ipv6.ip6_rt_last_gc should
      hold the last time garbage collector was run so that we should
      update it whenever fib6_run_gc() calls fib6_clean_all(), not only
      if we got there from ip6_dst_gc().
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49a18d86
    • M
      ipv6: prevent fib6_run_gc() contention · 2ac3ac8f
      Michal Kubeček 提交于
      On a high-traffic router with many processors and many IPv6 dst
      entries, soft lockup in fib6_run_gc() can occur when number of
      entries reaches gc_thresh.
      
      This happens because fib6_run_gc() uses fib6_gc_lock to allow
      only one thread to run the garbage collector but ip6_dst_gc()
      doesn't update net->ipv6.ip6_rt_last_gc until fib6_run_gc()
      returns. On a system with many entries, this can take some time
      so that in the meantime, other threads pass the tests in
      ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
      the lock. They then have to run the garbage collector one after
      another which blocks them for quite long.
      
      Resolve this by replacing special value ~0UL of expire parameter
      to fib6_run_gc() by explicit "force" parameter to choose between
      spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
      force=false if gc_thresh is reached but not max_size.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ac3ac8f
  28. 01 8月, 2013 1 次提交
  29. 25 7月, 2013 1 次提交
  30. 12 7月, 2013 1 次提交
    • H
      ipv6: fix route selection if kernel is not compiled with CONFIG_IPV6_ROUTER_PREF · afc154e9
      Hannes Frederic Sowa 提交于
      This is a follow-up patch to 3630d400
      ("ipv6: rt6_check_neigh should successfully verify neigh if no NUD
      information are available").
      
      Since the removal of rt->n in rt6_info we can end up with a dst ==
      NULL in rt6_check_neigh. In case the kernel is not compiled with
      CONFIG_IPV6_ROUTER_PREF we should also select a route with unkown
      NUD state but we must not avoid doing round robin selection on routes
      with the same target. So introduce and pass down a boolean ``do_rr'' to
      indicate when we should update rt->rr_ptr. As soon as no route is valid
      we do backtracking and do a lookup on a higher level in the fib trie.
      
      v2:
      a) Improved rt6_check_neigh logic (no need to create neighbour there)
         and documented return values.
      
      v3:
      a) Introduce enum rt6_nud_state to get rid of the magic numbers
         (thanks to David Miller).
      b) Update and shorten commit message a bit to actualy reflect
         the source.
      Reported-by: NPierre Emeriaud <petrus.lt@gmail.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      afc154e9
  31. 11 7月, 2013 1 次提交
    • H
      ipv6: in case of link failure remove route directly instead of letting it expire · 1eb4f758
      Hannes Frederic Sowa 提交于
      We could end up expiring a route which is part of an ecmp route set. Doing
      so would invalidate the rt->rt6i_nsiblings calculations and could provoke
      the following panic:
      
      [   80.144667] ------------[ cut here ]------------
      [   80.145172] kernel BUG at net/ipv6/ip6_fib.c:733!
      [   80.145172] invalid opcode: 0000 [#1] SMP
      [   80.145172] Modules linked in: 8021q nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables
      +snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer virtio_balloon snd soundcore i2c_piix4 i2c_core virtio_net virtio_blk
      [   80.145172] CPU: 1 PID: 786 Comm: ping6 Not tainted 3.10.0+ #118
      [   80.145172] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [   80.145172] task: ffff880117fa0000 ti: ffff880118770000 task.ti: ffff880118770000
      [   80.145172] RIP: 0010:[<ffffffff815f3b5d>]  [<ffffffff815f3b5d>] fib6_add+0x75d/0x830
      [   80.145172] RSP: 0018:ffff880118771798  EFLAGS: 00010202
      [   80.145172] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011350e480
      [   80.145172] RDX: ffff88011350e238 RSI: 0000000000000004 RDI: ffff88011350f738
      [   80.145172] RBP: ffff880118771848 R08: ffff880117903280 R09: 0000000000000001
      [   80.145172] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88011350f680
      [   80.145172] R13: ffff880117903280 R14: ffff880118771890 R15: ffff88011350ef90
      [   80.145172] FS:  00007f02b5127740(0000) GS:ffff88011fd00000(0000) knlGS:0000000000000000
      [   80.145172] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [   80.145172] CR2: 00007f981322a000 CR3: 00000001181b1000 CR4: 00000000000006e0
      [   80.145172] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   80.145172] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [   80.145172] Stack:
      [   80.145172]  0000000000000001 ffff880100000000 ffff880100000000 ffff880117903280
      [   80.145172]  0000000000000000 ffff880119a4cf00 0000000000000400 00000000000007fa
      [   80.145172]  0000000000000000 0000000000000000 0000000000000000 ffff88011350f680
      [   80.145172] Call Trace:
      [   80.145172]  [<ffffffff815eeceb>] ? rt6_bind_peer+0x4b/0x90
      [   80.145172]  [<ffffffff815ed985>] __ip6_ins_rt+0x45/0x70
      [   80.145172]  [<ffffffff815eee35>] ip6_ins_rt+0x35/0x40
      [   80.145172]  [<ffffffff815ef1e4>] ip6_pol_route.isra.44+0x3a4/0x4b0
      [   80.145172]  [<ffffffff815ef34a>] ip6_pol_route_output+0x2a/0x30
      [   80.145172]  [<ffffffff81616077>] fib6_rule_action+0xd7/0x210
      [   80.145172]  [<ffffffff815ef320>] ? ip6_pol_route_input+0x30/0x30
      [   80.145172]  [<ffffffff81553026>] fib_rules_lookup+0xc6/0x140
      [   80.145172]  [<ffffffff81616374>] fib6_rule_lookup+0x44/0x80
      [   80.145172]  [<ffffffff815ef320>] ? ip6_pol_route_input+0x30/0x30
      [   80.145172]  [<ffffffff815edea3>] ip6_route_output+0x73/0xb0
      [   80.145172]  [<ffffffff815dfdf3>] ip6_dst_lookup_tail+0x2c3/0x2e0
      [   80.145172]  [<ffffffff813007b1>] ? list_del+0x11/0x40
      [   80.145172]  [<ffffffff81082a4c>] ? remove_wait_queue+0x3c/0x50
      [   80.145172]  [<ffffffff815dfe4d>] ip6_dst_lookup_flow+0x3d/0xa0
      [   80.145172]  [<ffffffff815fda77>] rawv6_sendmsg+0x267/0xc20
      [   80.145172]  [<ffffffff815a8a83>] inet_sendmsg+0x63/0xb0
      [   80.145172]  [<ffffffff8128eb93>] ? selinux_socket_sendmsg+0x23/0x30
      [   80.145172]  [<ffffffff815218d6>] sock_sendmsg+0xa6/0xd0
      [   80.145172]  [<ffffffff81524a68>] SYSC_sendto+0x128/0x180
      [   80.145172]  [<ffffffff8109825c>] ? update_curr+0xec/0x170
      [   80.145172]  [<ffffffff81041d09>] ? kvm_clock_get_cycles+0x9/0x10
      [   80.145172]  [<ffffffff810afd1e>] ? __getnstimeofday+0x3e/0xd0
      [   80.145172]  [<ffffffff8152509e>] SyS_sendto+0xe/0x10
      [   80.145172]  [<ffffffff8164efd9>] system_call_fastpath+0x16/0x1b
      [   80.145172] Code: fe ff ff 41 f6 45 2a 06 0f 85 ca fe ff ff 49 8b 7e 08 4c 89 ee e8 94 ef ff ff e9 b9 fe ff ff 48 8b 82 28 05 00 00 e9 01 ff ff ff <0f> 0b 49 8b 54 24 30 0d 00 00 40 00 89 83 14 01 00 00 48 89 53
      [   80.145172] RIP  [<ffffffff815f3b5d>] fib6_add+0x75d/0x830
      [   80.145172]  RSP <ffff880118771798>
      [   80.387413] ---[ end trace 02f20b7a8b81ed95 ]---
      [   80.390154] Kernel panic - not syncing: Fatal exception in interrupt
      
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1eb4f758
  32. 04 7月, 2013 1 次提交
    • H
      ipv6: rt6_check_neigh should successfully verify neigh if no NUD information are available · 3630d400
      Hannes Frederic Sowa 提交于
      After the removal of rt->n we do not create a neighbour entry at route
      insertion time (rt6_bind_neighbour is gone). As long as no neighbour is
      created because of "useful traffic" we skip this routing entry because
      rt6_check_neigh cannot pick up a valid neighbour (neigh == NULL) and
      thus returns false.
      
      This change was introduced by commit
      887c95cc ("ipv6: Complete neighbour
      entry removal from dst_entry.")
      
      To quote RFC4191:
      "If the host has no information about the router's reachability, then
      the host assumes the router is reachable."
      
      and also:
      "A host MUST NOT probe a router's reachability in the absence of useful
      traffic that the host would have sent to the router if it were reachable."
      
      So, just assume the router is reachable and let's rt6_probe do the
      rest. We don't need to create a neighbour on route insertion time.
      
      If we don't compile with CONFIG_IPV6_ROUTER_PREF (RFC4191 support)
      a neighbour is only valid if its nud_state is NUD_VALID. I did not find
      any references that we should probe the router on route insertion time
      via the other RFCs. So skip this route in that case.
      
      v2:
      a) use IS_ENABLED instead of #ifdefs (thanks to Sergei Shtylyov)
      Reported-by: NPierre Emeriaud <petrus.lt@gmail.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3630d400
  33. 02 7月, 2013 1 次提交
  34. 13 6月, 2013 1 次提交
  35. 29 5月, 2013 2 次提交
  36. 22 3月, 2013 1 次提交