Hi,
在 2025/09/08 17:40, Eric Dumazet 写道:
On Mon, Sep 8, 2025 at 2:34 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:
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?
AFAIK after this fix, iscsi was fine.
commit f4f82c52a0ead5ab363d207d06f81b967d09ffb8
Author: Eric Dumazet <edumazet@xxxxxxxxxx>
Date: Fri Sep 15 17:11:11 2023 +0000
scsi: iscsi_tcp: restrict to TCP sockets
Nothing prevents iscsi_sw_tcp_conn_bind() to receive file descriptor
pointing to non TCP socket (af_unix for example).
Return -EINVAL if this is attempted, instead of crashing the kernel.
Fixes: 7ba247138907 ("[SCSI] open-iscsi/linux-iscsi-5 Initiator:
Initiator code")
Signed-off-by: Eric Dumazet <edumazet@xxxxxxxxxx>
Cc: Lee Duncan <lduncan@xxxxxxxx>
Cc: Chris Leech <cleech@xxxxxxxxxx>
Cc: Mike Christie <michael.christie@xxxxxxxxxx>
Cc: "James E.J. Bottomley" <jejb@xxxxxxxxxxxxx>
Cc: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Cc: open-iscsi@xxxxxxxxxxxxxxxx
Cc: linux-scsi@xxxxxxxxxxxxxxx
Reviewed-by: Mike Christie <michael.christie@xxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
.
Yes, now I also agree similiar fix in nbd make sense. Perhaps can you
cook a patch?
Thanks,
Kuai
