On Wed, 2015-12-30 at 12:50 -0500, David Miller wrote:

From: Eric Dumazet <redacted>
Date: Wed, 30 Dec 2015 11:55:25 -0500

quoted

On Wed, 2015-12-30 at 10:11 -0500, Dave Jones wrote:

quoted

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()