Re: [syzbot] [mm?] [input?] [usb?] INFO: rcu detected stall in brk (2)

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

 



+Alan re: USB stalls

On Thu, Oct 31, 2024 at 09:41:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
>
> Reported-by: syzbot+7402e6c8042635c93ead@xxxxxxxxxxxxxxxxxxxxxxxxx
> Tested-by: syzbot+7402e6c8042635c93ead@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> Tested on:
>
> commit:         cffcc47b mm/mlock: set the correct prev on failure
> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/ mm-hotfixes-unstable
> console output: https://syzkaller.appspot.com/x/log.txt?x=1304a630580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6648774f7c39d413
> dashboard link: https://syzkaller.appspot.com/bug?extid=7402e6c8042635c93ead
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>
> Note: no patches were applied.
> Note: testing is done by a robot and is best-effort only.

OK this seems likely to be intermittant (and unrelated to what's in
mm-unstable-fixes honestly) and does make me wonder if the fix referenced
in [0] really has sorted things out? Or whether it has perhaps help
mitigate the issue but not sufficiently in conjunction with debug things
that slow things down.

Because we keep getting these reports, that mysteriously don't occur if we
re-run (or hit other code paths), they seem to hit somewhat arbitrary parts
of mm, and because CONFIG_DEBUG_VM_MAPLE_TREE is set we spend a _long_ time
in mm validating trees (this config option is REALLY REALLY heavy-handed).

I note we also set CONFIG_KCOV and CONFIG_KCOV_INSTRUMENT_ALL which isn't
going to make anything quicker if the USB gets laggy.

I'm not sure if there's a human who can help tweak the config for these
hardware-centric tests at Google? At least tweaking the RCU stall time
anyway?

In any case this continues not to look likely to be an actual mm issue as
far as I can see.

In [0] we were stalled in a validate call which would align with the idea
that perhaps we were just dealing with a very very big tree and getting
slow down that way.

Cheers, Lorenzo

[0]:https://lore.kernel.org/all/967f3aa0-447a-4121-b80b-299c926a33f5@xxxxxxxxxxxxxxxxxxx/




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux