Hi,
在 2025/09/08 17:07, Eric Dumazet 写道:
On Mon, Sep 8, 2025 at 1:52 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:
Hi,
在 2025/09/06 17:16, Eric Dumazet 写道:
On Fri, Sep 5, 2025 at 1:03 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
On Fri, Sep 5, 2025 at 1:00 PM syzbot
<syzbot+e1cd6bd8493060bd701d@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Note to NBD maintainers : I held about 20 syzbot reports all pointing
to NBD accepting various sockets, I can release them if needed, if you prefer
to triage them.
I'm not NBD maintainer, just trying to understand the deadlock first.
Is this deadlock only possible for some sepecific socket types? Take
a look at the report here:
Usually issue IO will require the order:
q_usage_counter -> cmd lock -> tx lock -> sk lock
I have not seen the deadlock being reported with normal TCP sockets.
NBD sets sk->sk_allocation to GFP_NOIO | __GFP_MEMALLOC;
from __sock_xmit(), and TCP seems to respect this.
.
What aboud iscsi and nvme-tcp? and probably other drivers, where
sk_allocation is GFP_ATOMIC, do they have similar problem?
Thanks,
Kuai
