1. 06 2月, 2009 2 次提交
    • G
      net: fix some trailing whitespaces · fe2918b0
      Graf Yang 提交于
      Signed-off-by: NGraf Yang <graf.yang@analog.com>
      Signed-off-by: NBryan Wu <cooloney@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe2918b0
    • H
      tun: Limit amount of queued packets per device · 33dccbb0
      Herbert Xu 提交于
      Unlike a normal socket path, the tuntap device send path does
      not have any accounting.  This means that the user-space sender
      may be able to pin down arbitrary amounts of kernel memory by
      continuing to send data to an end-point that is congested.
      
      Even when this isn't an issue because of limited queueing at
      most end points, this can also be a problem because its only
      response to congestion is packet loss.  That is, when those
      local queues at the end-point fills up, the tuntap device will
      start wasting system time because it will continue to send
      data there which simply gets dropped straight away.
      
      Of course one could argue that everybody should do congestion
      control end-to-end, unfortunately there are people in this world
      still hooked on UDP, and they don't appear to be going away
      anywhere fast.  In fact, we've always helped them by performing
      accounting in our UDP code, the sole purpose of which is to
      provide congestion feedback other than through packet loss.
      
      This patch attempts to apply the same bandaid to the tuntap device.
      It creates a pseudo-socket object which is used to account our
      packets just as a normal socket does for UDP.  Of course things
      are a little complex because we're actually reinjecting traffic
      back into the stack rather than out of the stack.
      
      The stack complexities however should have been resolved by preceding
      patches.  So this one can simply start using skb_set_owner_w.
      
      For now the accounting is essentially disabled by default for
      backwards compatibility.  In particular, we set the cap to INT_MAX.
      This is so that existing applications don't get confused by the
      sudden arrival EAGAIN errors.
      
      In future we may wish (or be forced to) do this by default.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33dccbb0
  2. 05 2月, 2009 15 次提交
  3. 04 2月, 2009 23 次提交