Hi
On 29.10.2020 8.03, Mike Galbraith wrote:
> Greetings,
>
> Testing $subject in shiny new 5.10-rt induced a lockdep grumble, so I
> plugged it into master and booted lappy with threadirqs. When I then
> fired up my android-x86 vm toy, that kernel grumbled as well.
>
>
> [ 107.611645] =====================================================
> [ 107.611650] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
> [ 107.611656] 5.10.0.g23859ae-master #17 Tainted: G S I E
> [ 107.611660] -----------------------------------------------------
> [ 107.611666] worker/4060 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [ 107.611671] ffff90bba6d2c680 (lock#2){+.+.}-{2:2}, at: radix_tree_maybe_preload+0x8/0xb0
> [ 107.611684]
> and this task is already holding:
> [ 107.611689] ffff90ba501a8430 (&xhci->lock){..-.}-{2:2}, at: xhci_urb_enqueue+0x20a/0x6f0 [xhci_hcd]
> [ 107.611706] which would create a new lock dependency:
> [ 107.611710] (&xhci->lock){..-.}-{2:2} -> (lock#2){+.+.}-{2:2}
> [ 107.611719]
This looks like a separate locking issue related to stream ring buffer expansion and radix tree usage.
This has probably been there for a while. Can you check if this can be reproduced with 5.9 kernel?
I don't have a quick fix for this. I need to look into it more.
Anyway, this shouldn't prevent PATCH 3/3 from fixing the streams debugfs issue introduced in 5.10-rc1
-Mathias
