1. 06 Jan, 2009 7 commits
  2. 05 Jan, 2009 14 commits
  3. 04 Jan, 2009 2 commits
  4. 02 Jan, 2009 1 commit
  5. 31 Dec, 2008 2 commits
  6. 30 Dec, 2008 8 commits
  7. 26 Dec, 2008 6 commits
    • Herbert Xu's avatar
      gro: Fix potential use after free · 0da2afd5
      Herbert Xu authored
      
      The initial skb may have been freed after napi_gro_complete in
      napi_gro_receive if it was merged into an existing packet.  Thus
      we cannot check same_flow (which indicates whether it was merged)
      after calling napi_gro_complete.
      
      This patch fixes this by saving the same_flow status before the
      call to napi_gro_complete.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0da2afd5
    • Peter P Waskiewicz Jr's avatar
      net: Init NAPI dev_list on napi_del · d7b06636
      Peter P Waskiewicz Jr authored
      
      The recent GRO patches introduced the NAPI removal of devices in
      free_netdev.  For drivers that can change the number of queues during
      driver operation, the NAPI infrastructure doesn't allow the freeing and
      re-addition of NAPI entities without reloading the driver.
      
      This change reinitializes the dev_list in each NAPI struct on delete,
      instead of just deleting it (and assigning the list pointers to POISON).
      Drivers that wish to remove/re-add NAPI will need to re-initialize the
      netdev napi_list after removing all NAPI instances, before re-adding NAPI
      devices again.
      Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7b06636
    • Herbert Xu's avatar
      ipsec: Remove useless ret variable · f2712fd0
      Herbert Xu authored
      
      This patch removes a useless ret variable from the IPv4 ESP/UDP
      decapsulation code.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2712fd0
    • Julia Lawall's avatar
      net/appletalk: Remove redundant test · 88a44e51
      Julia Lawall authored
      atif is tested for being NULL twice, with the same effect in each case.  I
      have kept the second test, as it seems to fit well with the comment above it.
      
      A simplified version of the semantic patch that makes this change is as
      follows: (http://www.emn.fr/x-info/coccinelle/
      
      )
      
      // <smpl>
      @r exists@
      local idexpression x;
      expression E;
      position p1,p2;
      @@
      
      if (x@p1 == NULL || ...) { ... when forall
         return ...; }
      ... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      // another path to the test that is not through p1?
      @s exists@
      local idexpression r.x;
      position r.p1,r.p2;
      @@
      
      ... when != x@p1
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      @fix depends on !s@
      position r.p1,r.p2;
      expression x,E;
      statement S1,S2;
      @@
      
      (
      - if ((x@p2 != NULL) || ...)
        S1
      |
      - if ((x@p2 == NULL) && ...) S1
      |
      - BUG_ON(x@p2 == NULL);
      )
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <julia@diku.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88a44e51
    • Herbert Xu's avatar
      tcp: Always set urgent pointer if it's beyond snd_nxt · 64ff3b93
      Herbert Xu authored
      
      Our TCP stack does not set the urgent flag if the urgent pointer
      does not fit in 16 bits, i.e., if it is more than 64K from the
      sequence number of a packet.
      
      This behaviour is different from the BSDs, and clearly contradicts
      the purpose of urgent mode, which is to send the notification
      (though not necessarily the associated data) as soon as possible.
      Our current behaviour may in fact delay the urgent notification
      indefinitely if the receiver window does not open up.
      
      Simply matching BSD however may break legacy applications which
      incorrectly rely on the out-of-band delivery of urgent data, and
      conversely the in-band delivery of non-urgent data.
      
      Alexey Kuznetsov suggested a safe solution of following BSD only
      if the urgent pointer itself has not yet been transmitted.  This
      way we guarantee that when the remote end sees the packet with
      non-urgent data marked as urgent due to wrap-around we would have
      advanced the urgent pointer beyond, either to the actual urgent
      data or to an as-yet untransmitted packet.
      
      The only potential downside is that applications on the remote
      end may see multiple SIGURG notifications.  However, this would
      occur anyway with other TCP stacks.  More importantly, the outcome
      of such a duplicate notification is likely to be harmless since
      the signal itself does not carry any information other than the
      fact that we're in urgent mode.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64ff3b93
    • Wei Yongjun's avatar
      sctp: Add validity check for SCTP_PARTIAL_DELIVERY_POINT socket option · 8510b937
      Wei Yongjun authored
      
      The latest ietf socket extensions API draft said:
      
        8.1.21.  Set or Get the SCTP Partial Delivery Point
      
          Note also that the call will fail if the user attempts to set
          this value larger than the socket receive buffer size.
      
      This patch add this validity check for SCTP_PARTIAL_DELIVERY_POINT
      socket option.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8510b937