[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b604e39a-9f0c-15b2-1460-7e0bb7e75d19@suse.com>
Date: Mon, 22 May 2023 15:22:45 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Christian Brauner <brauner@...nel.org>,
syzbot <syzbot+24d1639a31b024b125bd@...kaller.appspotmail.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, syzkaller-bugs@...glegroups.com,
viro@...iv.linux.org.uk
Subject: Re: [syzbot] [fs?] [usb?] INFO: rcu detected stall in vfs_readlink
On 22.05.23 15:01, Christian Brauner wrote:
> On Fri, May 19, 2023 at 08:18:45PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: a4422ff22142 usb: typec: qcom: Add Qualcomm PMIC Type-C dr..
>> git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10ce218e280000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=2414a945e4542ec1
>> dashboard link: https://syzkaller.appspot.com/bug?extid=24d1639a31b024b125bd
>> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137d4c06280000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17b758a1280000
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/414817142fb7/disk-a4422ff2.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/448dba0d344e/vmlinux-a4422ff2.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/d0ad9fe848e2/bzImage-a4422ff2.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+24d1639a31b024b125bd@...kaller.appspotmail.com
>>
>> imon 1-1:0.0: imon usb_rx_callback_intf0: status(-71): ignored
>> imon 5-1:0.0: imon usb_rx_callback_intf0: status(-71): ignored
>
> I have the strong suspicion that the usb drive is removed or some such
> nonsense. Doesn't seem an fs bug.
It hasn't been removed. On a real system it would likely be.
The device keeps returning only -EPROTO. As we are dealing with virtual
hardware that is fast enough to cause a livelock from the error
handling retrying the IO without delay.
Handling this nicely would need a real error handler with a workqueue
and some delays and evetually more drastic action like resetting the
device.
Regards
Oliver
Powered by blists - more mailing lists