[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230324125706.ettgc22v5lnu2uh5@skbuf>
Date: Fri, 24 Mar 2023 14:57:06 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Sean Anderson <sean.anderson@...o.com>
Cc: netdev@...r.kernel.org, Madalin Bucur <madalin.bucur@....com>,
Camelia Groza <camelia.groza@....com>
Subject: Re: Invalid wait context in qman_update_cgr()
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?
Powered by blists - more mailing lists