1. 18 7月, 2011 3 次提交
  2. 02 7月, 2011 2 次提交
    • D
      ipv6: Don't put artificial limit on routing table size. · 957c665f
      David S. Miller 提交于
      IPV6, unlike IPV4, doesn't have a routing cache.
      
      Routing table entries, as well as clones made in response
      to route lookup requests, all live in the same table.  And
      all of these things are together collected in the destination
      cache table for ipv6.
      
      This means that routing table entries count against the garbage
      collection limits, even though such entries cannot ever be reclaimed
      and are added explicitly by the administrator (rather than being
      created in response to lookups).
      
      Therefore it makes no sense to count ipv6 routing table entries
      against the GC limits.
      
      Add a DST_NOCOUNT destination cache entry flag, and skip the counting
      if it is set.  Use this flag bit in ipv6 when adding routing table
      entries.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      957c665f
    • D
      ipv6: Don't change dst->flags using assignments. · 11d53b49
      David S. Miller 提交于
      This blows away any flags already set in the entry.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d53b49
  3. 10 6月, 2011 1 次提交
    • G
      rtnetlink: Compute and store minimum ifinfo dump size · c7ac8679
      Greg Rose 提交于
      The message size allocated for rtnl ifinfo dumps was limited to
      a single page.  This is not enough for additional interface info
      available with devices that support SR-IOV and caused a bug in
      which VF info would not be displayed if more than approximately
      40 VFs were created per interface.
      
      Implement a new function pointer for the rtnl_register service that will
      calculate the amount of data required for the ifinfo dump and allocate
      enough data to satisfy the request.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c7ac8679
  4. 21 5月, 2011 1 次提交
  5. 29 4月, 2011 2 次提交
  6. 26 4月, 2011 1 次提交
    • H
      net: provide cow_metrics() methods to blackhole dst_ops · 0972ddb2
      Held Bernhard 提交于
      Since commit 62fa8a84 (net: Implement read-only protection and COW'ing
      of metrics.) the kernel throws an oops.
      
      [  101.620985] BUG: unable to handle kernel NULL pointer dereference at
                 (null)
      [  101.621050] IP: [<          (null)>]           (null)
      [  101.621084] PGD 6e53c067 PUD 3dd6a067 PMD 0
      [  101.621122] Oops: 0010 [#1] SMP
      [  101.621153] last sysfs file: /sys/devices/virtual/ppp/ppp/uevent
      [  101.621192] CPU 2
      [  101.621206] Modules linked in: l2tp_ppp pppox ppp_generic slhc
      l2tp_netlink l2tp_core deflate zlib_deflate twofish_x86_64
      twofish_common des_generic cbc ecb sha1_generic hmac af_key
      iptable_filter snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device loop
      snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec
      snd_pcm snd_timer snd i2c_i801 iTCO_wdt psmouse soundcore snd_page_alloc
      evdev uhci_hcd ehci_hcd thermal
      [  101.621552]
      [  101.621567] Pid: 5129, comm: openl2tpd Not tainted 2.6.39-rc4-Quad #3
      Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R
      [  101.621637] RIP: 0010:[<0000000000000000>]  [<          (null)>]   (null)
      [  101.621684] RSP: 0018:ffff88003ddeba60  EFLAGS: 00010202
      [  101.621716] RAX: ffff88003ddb5600 RBX: ffff88003ddb5600 RCX:
      0000000000000020
      [  101.621758] RDX: ffffffff81a69a00 RSI: ffffffff81b7ee61 RDI:
      ffff88003ddb5600
      [  101.621800] RBP: ffff8800537cd900 R08: 0000000000000000 R09:
      ffff88003ddb5600
      [  101.621840] R10: 0000000000000005 R11: 0000000000014b38 R12:
      ffff88003ddb5600
      [  101.621881] R13: ffffffff81b7e480 R14: ffffffff81b7e8b8 R15:
      ffff88003ddebad8
      [  101.621924] FS:  00007f06e4182700(0000) GS:ffff88007fd00000(0000)
      knlGS:0000000000000000
      [  101.621971] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  101.622005] CR2: 0000000000000000 CR3: 0000000045274000 CR4:
      00000000000006e0
      [  101.622046] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [  101.622087] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [  101.622129] Process openl2tpd (pid: 5129, threadinfo
      ffff88003ddea000, task ffff88003de9a280)
      [  101.622177] Stack:
      [  101.622191]  ffffffff81447efa ffff88007d3ded80 ffff88003de9a280
      ffff88007d3ded80
      [  101.622245]  0000000000000001 ffff88003ddebbb8 ffffffff8148d5a7
      0000000000000212
      [  101.622299]  ffff88003dcea000 ffff88003dcea188 ffffffff00000001
      ffffffff81b7e480
      [  101.622353] Call Trace:
      [  101.622374]  [<ffffffff81447efa>] ? ipv4_blackhole_route+0x1ba/0x210
      [  101.622415]  [<ffffffff8148d5a7>] ? xfrm_lookup+0x417/0x510
      [  101.622450]  [<ffffffff8127672a>] ? extract_buf+0x9a/0x140
      [  101.622485]  [<ffffffff8144c6a0>] ? __ip_flush_pending_frames+0x70/0x70
      [  101.622526]  [<ffffffff8146fbbf>] ? udp_sendmsg+0x62f/0x810
      [  101.622562]  [<ffffffff813f98a6>] ? sock_sendmsg+0x116/0x130
      [  101.622599]  [<ffffffff8109df58>] ? find_get_page+0x18/0x90
      [  101.622633]  [<ffffffff8109fd6a>] ? filemap_fault+0x12a/0x4b0
      [  101.622668]  [<ffffffff813fb5c4>] ? move_addr_to_kernel+0x64/0x90
      [  101.622706]  [<ffffffff81405d5a>] ? verify_iovec+0x7a/0xf0
      [  101.622739]  [<ffffffff813fc772>] ? sys_sendmsg+0x292/0x420
      [  101.622774]  [<ffffffff810b994a>] ? handle_pte_fault+0x8a/0x7c0
      [  101.622810]  [<ffffffff810b76fe>] ? __pte_alloc+0xae/0x130
      [  101.622844]  [<ffffffff810ba2f8>] ? handle_mm_fault+0x138/0x380
      [  101.622880]  [<ffffffff81024af9>] ? do_page_fault+0x189/0x410
      [  101.622915]  [<ffffffff813fbe03>] ? sys_getsockname+0xf3/0x110
      [  101.622952]  [<ffffffff81450c4d>] ? ip_setsockopt+0x4d/0xa0
      [  101.622986]  [<ffffffff813f9932>] ? sockfd_lookup_light+0x22/0x90
      [  101.623024]  [<ffffffff814b61fb>] ? system_call_fastpath+0x16/0x1b
      [  101.623060] Code:  Bad RIP value.
      [  101.623090] RIP  [<          (null)>]           (null)
      [  101.623125]  RSP <ffff88003ddeba60>
      [  101.623146] CR2: 0000000000000000
      [  101.650871] ---[ end trace ca3856a7d8e8dad4 ]---
      [  101.651011] __sk_free: optmem leakage (160 bytes) detected.
      
      The oops happens in dst_metrics_write_ptr()
      include/net/dst.h:124: return dst->ops->cow_metrics(dst, p);
      
      dst->ops->cow_metrics is NULL and causes the oops.
      
      Provide cow_metrics() methods, like we did in commit 214f45c9
      (net: provide default_advmss() methods to blackhole dst_ops)
      Signed-off-by: NHeld Bernhard <berny156@gmx.de>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0972ddb2
  7. 23 4月, 2011 1 次提交
  8. 22 4月, 2011 1 次提交
  9. 16 4月, 2011 1 次提交
  10. 23 3月, 2011 1 次提交
  11. 13 3月, 2011 2 次提交
  12. 10 3月, 2011 1 次提交
    • D
      ipv6: Don't create clones of host routes. · 7343ff31
      David S. Miller 提交于
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=29252
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=30462
      
      In commit d80bc0fd ("ipv6: Always
      clone offlink routes.") we forced the kernel to always clone offlink
      routes.
      
      The reason we do that is to make sure we never bind an inetpeer to a
      prefixed route.
      
      The logic turned on here has existed in the tree for many years,
      but was always off due to a protecting CPP define.  So perhaps
      it's no surprise that there is a logic bug here.
      
      The problem is that we canot clone a route that is already a
      host route (ie. has DST_HOST set).  Because if we do, an identical
      entry already exists in the routing tree and therefore the
      ip6_rt_ins() call is going to fail.
      
      This sets off a series of failures and high cpu usage, because when
      ip6_rt_ins() fails we loop retrying this operation a few times in
      order to handle a race between two threads trying to clone and insert
      the same host route at the same time.
      
      Fix this by simply using the route as-is when DST_HOST is set.
      
      Reported-by: slash@ac.auone-net.jp
      Reported-by: NErnst Sjöstrand <ernstp@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7343ff31
  13. 04 3月, 2011 1 次提交
  14. 02 3月, 2011 2 次提交
  15. 26 2月, 2011 2 次提交
  16. 19 2月, 2011 1 次提交
  17. 18 2月, 2011 1 次提交
  18. 11 2月, 2011 1 次提交
    • D
      inet: Create a mechanism for upward inetpeer propagation into routes. · 6431cbc2
      David S. Miller 提交于
      If we didn't have a routing cache, we would not be able to properly
      propagate certain kinds of dynamic path attributes, for example
      PMTU information and redirects.
      
      The reason is that if we didn't have a routing cache, then there would
      be no way to lookup all of the active cached routes hanging off of
      sockets, tunnels, IPSEC bundles, etc.
      
      Consider the case where we created a cached route, but no inetpeer
      entry existed and also we were not asked to pre-COW the route metrics
      and therefore did not force the creation a new inetpeer entry.
      
      If we later get a PMTU message, or a redirect, and store this
      information in a new inetpeer entry, there is no way to teach that
      cached route about the newly existing inetpeer entry.
      
      The facilities implemented here handle this problem.
      
      First we create a generation ID.  When we create a cached route of any
      kind, we remember the generation ID at the time of attachment.  Any
      time we force-create an inetpeer entry in response to new path
      information, we bump that generation ID.
      
      The dst_ops->check() callback is where the knowledge of this event
      is propagated.  If the global generation ID does not equal the one
      stored in the cached route, and the cached route has not attached
      to an inetpeer yet, we look it up and attach if one is found.  Now
      that we've updated the cached route's information, we update the
      route's generation ID too.
      
      This clears the way for implementing PMTU and redirects directly in
      the inetpeer cache.  There is absolutely no need to consult cached
      route information in order to maintain this information.
      
      At this point nothing bumps the inetpeer genids, that comes in the
      later changes which handle PMTUs and redirects using inetpeers.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6431cbc2
  19. 09 2月, 2011 1 次提交
  20. 01 2月, 2011 1 次提交
    • R
      net: Add default_mtu() methods to blackhole dst_ops · ec831ea7
      Roland Dreier 提交于
      When an IPSEC SA is still being set up, __xfrm_lookup() will return
      -EREMOTE and so ip_route_output_flow() will return a blackhole route.
      This can happen in a sndmsg call, and after d33e4553 ("net: Abstract
      default MTU metric calculation behind an accessor.") this leads to a
      crash in ip_append_data() because the blackhole dst_ops have no
      default_mtu() method and so dst_mtu() calls a NULL pointer.
      
      Fix this by adding default_mtu() methods (that simply return 0, matching
      the old behavior) to the blackhole dst_ops.
      
      The IPv4 part of this patch fixes a crash that I saw when using an IPSEC
      VPN; the IPv6 part is untested because I don't have an IPv6 VPN, but it
      looks to be needed as well.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec831ea7
  21. 28 1月, 2011 2 次提交
    • D
      net: Store ipv4/ipv6 COW'd metrics in inetpeer cache. · 06582540
      David S. Miller 提交于
      Please note that the IPSEC dst entry metrics keep using
      the generic metrics COW'ing mechanism using kmalloc/kfree.
      
      This gives the IPSEC routes an opportunity to use metrics
      which are unique to their encapsulated paths.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06582540
    • D
      ipv6: Remove route peer binding assertions. · 8f2771f2
      David S. Miller 提交于
      They are bogus.  The basic idea is that I wanted to make sure
      that prefixed routes never bind to peers.
      
      The test I used was whether RTF_CACHE was set.
      
      But first of all, the RTF_CACHE flag is set at different spots
      depending upon which ip6_rt_copy() caller you're talking about.
      
      I've validated all of the code paths, and even in the future
      where we bind peers more aggressively (for route metric COW'ing)
      we never bind to prefix'd routes, only fully specified ones.
      This even applies when addrconf or icmp6 routes are allocated.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f2771f2
  22. 27 1月, 2011 1 次提交
    • D
      net: Implement read-only protection and COW'ing of metrics. · 62fa8a84
      David S. Miller 提交于
      Routing metrics are now copy-on-write.
      
      Initially a route entry points it's metrics at a read-only location.
      If a routing table entry exists, it will point there.  Else it will
      point at the all zero metric place-holder called 'dst_default_metrics'.
      
      The writeability state of the metrics is stored in the low bits of the
      metrics pointer, we have two bits left to spare if we want to store
      more states.
      
      For the initial implementation, COW is implemented simply via kmalloc.
      However future enhancements will change this to place the writable
      metrics somewhere else, in order to increase sharing.  Very likely
      this "somewhere else" will be the inetpeer cache.
      
      Note also that this means that metrics updates may transiently fail
      if we cannot COW the metrics successfully.
      
      But even by itself, this patch should decrease memory usage and
      increase cache locality especially for routing workloads.  In those
      cases the read-only metric copies stay in place and never get written
      to.
      
      TCP workloads where metrics get updated, and those rare cases where
      PMTU triggers occur, will take a very slight performance hit.  But
      that hit will be alleviated when the long-term writable metrics
      move to a more sharable location.
      
      Since the metrics storage went from a u32 array of RTAX_MAX entries to
      what is essentially a pointer, some retooling of the dst_entry layout
      was necessary.
      
      Most importantly, we need to preserve the alignment of the reference
      count so that it doesn't share cache lines with the read-mostly state,
      as per Eric Dumazet's alignment assertion checks.
      
      The only non-trivial bit here is the move of the 'flags' member into
      the writeable cacheline.  This is OK since we are always accessing the
      flags around the same moment when we made a modification to the
      reference count.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62fa8a84
  23. 25 1月, 2011 1 次提交
  24. 19 12月, 2010 1 次提交
  25. 17 12月, 2010 1 次提交
    • A
      ipv6: delete expired route in ip6_pmtu_deliver · d3052b55
      Andrey Vagin 提交于
      The first big packets sent to a "low-MTU" client correctly
      triggers the creation of a temporary route containing the reduced MTU.
      
      But after the temporary route has expired, new ICMP6 "packet too big"
      will be sent, rt6_pmtu_discovery will find the previous EXPIRED route
      check that its mtu isn't bigger then in icmp packet and do nothing
      before the temporary route will not deleted by gc.
      
      I make the simple experiment:
      while :; do
          time ( dd if=/dev/zero bs=10K count=1 | ssh hostname dd of=/dev/null ) || break;
      done
      
      The "time" reports real 0m0.197s if a temporary route isn't expired, but
      it reports real 0m52.837s (!!!!) immediately after a temporare route has
      expired.
      Signed-off-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d3052b55
  26. 15 12月, 2010 1 次提交
  27. 14 12月, 2010 1 次提交
    • D
      net: Abstract default ADVMSS behind an accessor. · 0dbaee3b
      David S. Miller 提交于
      Make all RTAX_ADVMSS metric accesses go through a new helper function,
      dst_metric_advmss().
      
      Leave the actual default metric as "zero" in the real metric slot,
      and compute the actual default value dynamically via a new dst_ops
      AF specific callback.
      
      For stacked IPSEC routes, we use the advmss of the path which
      preserves existing behavior.
      
      Unlike ipv4/ipv6, DecNET ties the advmss to the mtu and thus updates
      advmss on pmtu updates.  This inconsistency in advmss handling
      results in more raw metric accesses than I wish we ended up with.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dbaee3b
  28. 13 12月, 2010 3 次提交
  29. 10 12月, 2010 1 次提交
    • D
      net: Abstract away all dst_entry metrics accesses. · defb3519
      David S. Miller 提交于
      Use helper functions to hide all direct accesses, especially writes,
      to dst_entry metrics values.
      
      This will allow us to:
      
      1) More easily change how the metrics are stored.
      
      2) Implement COW for metrics.
      
      In particular this will help us put metrics into the inetpeer
      cache if that is what we end up doing.  We can make the _metrics
      member a pointer instead of an array, initially have it point
      at the read-only metrics in the FIB, and then on the first set
      grab an inetpeer entry and point the _metrics member there.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      defb3519
  30. 01 12月, 2010 1 次提交