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] [day] [month] [year] [list]

Date:   Mon, 27 Mar 2023 15:33:31 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     Vladimir Oltean <vladimir.oltean@....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 3/24/23 08:57, Vladimir Oltean wrote:
> 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.

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

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

--Sean