Re: Invalid wait context in qman_update_cgr()

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Thu, Mar 23, 2023 at 05:41:04PM -0400, Sean Anderson wrote:
> Well, it's either this or switch to another function like
> smp_call_function which calls its callback in softirq/threaded hardirq
> context.

Okay.

> > 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.

> > [   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?