On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
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
On Wed, Apr 21, 2010 at 01:46:33PM +0200, Jan Kiszka wrote:
Michael S. Tsirkin wrote:
On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed.
From: Herbert Xu herb...@gondor.apana.org.au
Date: Wed, 14 Apr 2010 08:58:22 +0800
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Herbert Acked your patch, so I guess its OK, but I think it can be
dangerous.
The tun socket accounting was never designed to stop it from
On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
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
Michael S. Tsirkin wrote:
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed.
And before that, tap1 may not be able to send further packets to anyone
else on the bridge as its TX resources were blocked by tap2 -
Eric Dumazet wrote:
Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
Michael S. Tsirkin wrote:
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed.
And before that, tap1 may not be able to send
On Tue, Apr 13, 2010 at 06:40:38PM +0200, Eric Dumazet wrote:
Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
Michael S. Tsirkin wrote:
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed.
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
When a socket with inflight tx packets is closed, we dont block the
close, we only delay the socket freeing once all packets were delivered
and freed.
On Tue, Apr 13, 2010 at 10:38:06PM +0200, Eric Dumazet wrote:
Le mardi 13 avril 2010 à 23:25 +0300, Michael S. Tsirkin a écrit :
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
When a socket with
Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
Michael S. Tsirkin wrote:
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed.
And before that, tap1 may not be able to send further packets to
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
Herbert Acked your patch, so I guess its OK, but I think it can be
dangerous.
The tun socket accounting was never designed to stop it from
flooding another tun interface. It's there to stop it from
transmitting above a destination
11 matches
Mail list logo
