On 3/24/23 08:57, Vladimir Oltean wrote:

On Thu, Mar 23, 2023 at 05:41:04PM -0400, Sean Anderson wrote:

quoted

Well, it's either this or switch to another function like
smp_call_function which calls its callback in softirq/threaded hardirq
context.

Okay.

quoted

quoted

FWIW, a straight conversion from spinlocks to raw spinlocks produces
this other stack trace. It would be good if you could take a look too.
The lockdep usage tracker is clean prior to commit 914f8b228ede ("soc:
fsl: qbman: Add CGR update function").

Presumably you mean ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate
change"), which is the first commit to introduce a user for
qman_update_cgr_safe?

Not sure what is the objection to what I said here.

The first commit introduces the function with no users. The commit I referenced
adds a user.

quoted

quoted

[   56.650501] ================================
[   56.654782] WARNING: inconsistent lock state
[   56.659063] 6.3.0-rc2-00993-gdadb180cb16f-dirty #2028 Not tainted
[   56.665170] --------------------------------
[   56.669449] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[   56.675467] swapper/2/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[   56.680625] ffff1dc165e124e0 (&portal->cgr_lock){?.+.}-{2:2}, at: qman_update_cgr+0x60/0xfc
[   56.689054] {HARDIRQ-ON-W} state was registered at:
[   56.693943]   lock_acquire+0x1e4/0x2fc
[   56.697720]   _raw_spin_lock+0x5c/0xc0

I think we just need to use raw_spin_lock_irqsave in qman_create_cgr.

Ok, could you please look at submitting some patches that fix the lockdep issues?

https://lore.kernel.org/linux-arm-kernel/20230327192841.952688-1-sean.anderson@seco.com/ (local)

--Sean