netdev
[Top] [All Lists]

Re: [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevi

To: Michael Ellerman <michael@xxxxxxxxxxxxxx>
Subject: Re: [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevice() hanging
From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 12 May 2005 21:28:57 +1000
Cc: Andrew Morton <akpm@xxxxxxxx>, Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, PPC64-dev <linuxppc64-dev@xxxxxxxxxx>
In-reply-to: <200505121809.45419.michael@ellerman.id.au>
Mail-followup-to: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>, Michael Ellerman <michael@xxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, PPC64-dev <linuxppc64-dev@xxxxxxxxxx>
References: <200505121809.45419.michael@ellerman.id.au>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Thu, May 12, 2005 at 06:09:45PM +1000, Michael Ellerman wrote:
> Hi Andrew, Jeff,
> 
> The iseries_veth driver is badly behaved in that it will keep TX packets
> hanging around forever if they're not ACK'ed and the queue never fills up.
> 
> This causes the unregister_netdevice code to wait forever when we try to take
> the device down, because there's still skbs around with references to our
> struct net_device.
> 
> There's already code to cleanup any un-ACK'ed packets in 
> veth_stop_connection()
> but it's being called after we unregister the net_device, which is too late.
> 
> The fix is to rearrange the module exit function so that we cleanup any
> outstanding skbs and then unregister the driver.
> 
> Signed-off-by: Michael Ellerman <michael@xxxxxxxxxxxxxx>

Nice catch.

Acked-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/people/dgibson

<Prev in Thread] Current Thread [Next in Thread>