Re: [syzbot] [net?] possible deadlock in inet_shutdown

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 9, 2025 at 2:16 AM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:
>
> 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?

Sure I will send it ASAP.





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux