[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1451502526.8255.48.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Wed, 30 Dec 2015 14:08:46 -0500
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: davej@...emonkey.org.uk, daniel@...earbox.net,
alexei.starovoitov@...il.com, dledford@...hat.com,
netdev@...r.kernel.org
Subject: Re: 4.4-rc7 failure report
On Wed, 2015-12-30 at 12:50 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Wed, 30 Dec 2015 11:55:25 -0500
>
> > On Wed, 2015-12-30 at 10:11 -0500, Dave Jones wrote:
> >> On Wed, Dec 30, 2015 at 10:38:56AM +0100, Daniel Borkmann wrote:
> >>
> >> > Given that this drop doesn't strictly need to be caused by filter code,
> >> > it would be nice if you could pin the location down where the packet gets
> >> > dropped exactly. Perhaps dropwatch or perf with '-e skb:kfree_skb -a -g
> >> > dhclient <iface>', etc could help to get a first overview to dig into
> >> > details then.
> >>
> >> Wild stab in the dark, but..
> >> Could this bug be another symptom fixed by http://article.gmane.org/gmane.linux.network/392885 ?
> >
> > dhclient does not use async io
>
> But the bug causes requests to "LOOK" like async I/O, right?
This is not how I understood the bug.
By having a bit set (because we lacked a clear of wq->flags), we have :
sock_wake_async()
...
case SOCK_WAKE_WAITD:
if (test_bit(SOCKWQ_ASYNC_WAITDATA, &wq->flags))
break;
So we never call kill_fasync()
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists