aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorMax Krasnyansky <maxk@qualcomm.com>2008-07-10 19:59:11 -0400
committerDavid S. Miller <davem@davemloft.net>2008-07-10 19:59:11 -0400
commite35259a95331ae4a9146cc03ab49aad641cab957 (patch)
tree703ee0018e29c07215e2bb3f3bc0b9040d2ce6fe /drivers
parentccf9b3b83d0e56fbf20c00a08b15031ce13204a7 (diff)
tun: Persistent devices can get stuck in xoff state
The scenario goes like this. App stops reading from tun/tap. TX queue gets full and driver does netif_stop_queue(). App closes fd and TX queue gets flushed as part of the cleanup. Next time the app opens tun/tap and starts reading from it but the xoff state is not cleared. We're stuck. Normally xoff state is cleared when netdev is brought up. But in the case of persistent devices this happens only during initial setup. The fix is trivial. If device is already up when an app opens it we clear xoff state and that gets things moving again. Signed-off-by: Max Krasnyansky <maxk@qualcomm.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/net/tun.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7ab94c825b5..b9018bfa0a9 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -602,6 +602,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
602 tun->attached = 1; 602 tun->attached = 1;
603 get_net(dev_net(tun->dev)); 603 get_net(dev_net(tun->dev));
604 604
605 /* Make sure persistent devices do not get stuck in
606 * xoff state.
607 */
608 if (netif_running(tun->dev))
609 netif_wake_queue(tun->dev);
610
605 strcpy(ifr->ifr_name, tun->dev->name); 611 strcpy(ifr->ifr_name, tun->dev->name);
606 return 0; 612 return 0;
607 613