Skip to content
  1. Apr 18, 2010
  2. Apr 17, 2010
  3. Apr 16, 2010
    • David S. Miller's avatar
    • Eric Dumazet's avatar
      ip: Fix ip_dev_loopback_xmit() · e30b38c2
      Eric Dumazet authored
      
      
      Eric Paris got following trace with a linux-next kernel
      
      [   14.203970] BUG: using smp_processor_id() in preemptible [00000000]
      code: avahi-daemon/2093
      [   14.204025] caller is netif_rx+0xfa/0x110
      [   14.204035] Call Trace:
      [   14.204064]  [<ffffffff81278fe5>] debug_smp_processor_id+0x105/0x110
      [   14.204070]  [<ffffffff8142163a>] netif_rx+0xfa/0x110
      [   14.204090]  [<ffffffff8145b631>] ip_dev_loopback_xmit+0x71/0xa0
      [   14.204095]  [<ffffffff8145b892>] ip_mc_output+0x192/0x2c0
      [   14.204099]  [<ffffffff8145d610>] ip_local_out+0x20/0x30
      [   14.204105]  [<ffffffff8145d8ad>] ip_push_pending_frames+0x28d/0x3d0
      [   14.204119]  [<ffffffff8147f1cc>] udp_push_pending_frames+0x14c/0x400
      [   14.204125]  [<ffffffff814803fc>] udp_sendmsg+0x39c/0x790
      [   14.204137]  [<ffffffff814891d5>] inet_sendmsg+0x45/0x80
      [   14.204149]  [<ffffffff8140af91>] sock_sendmsg+0xf1/0x110
      [   14.204189]  [<ffffffff8140dc6c>] sys_sendmsg+0x20c/0x380
      [   14.204233]  [<ffffffff8100ad82>] system_call_fastpath+0x16/0x1b
      
      While current linux-2.6 kernel doesnt emit this warning, bug is latent
      and might cause unexpected failures.
      
      ip_dev_loopback_xmit() runs in process context, preemption enabled, so
      must call netif_rx_ni() instead of netif_rx(), to make sure that we
      process pending software interrupt.
      
      Same change for ip6_dev_loopback_xmit()
      
      Reported-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e30b38c2
  4. Apr 15, 2010
  5. Apr 14, 2010
    • Michael S. Tsirkin's avatar
      tun: orphan an skb on tx · 0110d6f2
      Michael S. Tsirkin authored
      
      
      The following situation was observed in the field:
      tap1 sends packets, tap2 does not consume them, as a result
      tap1 can not be closed. This happens because
      tun/tap devices can hang on to skbs undefinitely.
      
      As noted by Herbert, possible solutions include a timeout followed by a
      copy/change of ownership of the skb, or always copying/changing
      ownership if we're going into a hostile device.
      
      This patch implements the second approach.
      
      Note: one issue still remaining is that since skbs
      keep reference to tun socket and tun socket has a
      reference to tun device, we won't flush backlog,
      instead simply waiting for all skbs to get transmitted.
      At least this is not user-triggerable, and
      this was not reported in practice, my assumption is
      other devices besides tap complete an skb
      within finite time after it has been queued.
      
      A possible solution for the second issue
      would not to have socket reference the device,
      instead, implement dev->destructor for tun, and
      wait for all skbs to complete there, but this
      needs some thought, probably too risky for 2.6.34.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarYan Vugenfirer <yvugenfi@redhat.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0110d6f2
    • Ayaz Abdulla's avatar
      forcedeth: fix tx limit2 flag check · 5c659322
      Ayaz Abdulla authored
      
      
      This is a fix for bug 572201 @ bugs.debian.org
      
      This patch fixes the TX_LIMIT feature flag. The previous logic check
      for TX_LIMIT2 also took into account a device that only had TX_LIMIT
      set.
      
      Reported-by: default avatarStephen Mulcahu <stephen.mulcahy@deri.org>
      Reported-by: default avatarBen Huchings <ben@decadent.org.uk>
      Signed-off-by: default avatarAyaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      
      
      5c659322
  6. Apr 13, 2010
  7. Apr 11, 2010
  8. Apr 10, 2010
  9. Apr 09, 2010