netdev - Re: Invalid wait context in qman_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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?