[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250226192835.bmehafm2rjcbq42z@offworld>
Date: Wed, 26 Feb 2025 11:28:35 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Vlastimil Babka <vbabka@...e.cz>,
Suren Baghdasaryan <surenb@...gle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Christoph Lameter <cl@...ux.com>,
David Rientjes <rientjes@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
Uladzislau Rezki <urezki@...il.com>, linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>, rcu@...r.kernel.org,
maple-tree@...ts.infradead.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Alexei Starovoitov <ast@...nel.org>
Subject: Re: [PATCH RFC v2 03/10] locking/local_lock: Introduce
localtry_lock_t
On Wed, 26 Feb 2025, Alexei Starovoitov wrote:
>On Wed, Feb 26, 2025 at 9:01???AM Davidlohr Bueso <dave@...olabs.net> wrote:
>>
>> On Fri, 14 Feb 2025, Vlastimil Babka wrote:
>>
>> >From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>> >
>> >In !PREEMPT_RT local_lock_irqsave() disables interrupts to protect
>> >critical section, but it doesn't prevent NMI, so the fully reentrant
>> >code cannot use local_lock_irqsave() for exclusive access.
>> >
>> >Introduce localtry_lock_t and localtry_lock_irqsave() that
>> >disables interrupts and sets acquired=1, so localtry_lock_irqsave()
>> >from NMI attempting to acquire the same lock will return false.
>> >
>> >In PREEMPT_RT local_lock_irqsave() maps to preemptible spin_lock().
>> >Map localtry_lock_irqsave() to preemptible spin_trylock().
>> >When in hard IRQ or NMI return false right away, since
>> >spin_trylock() is not safe due to PI issues.
>> >
>> >Note there is no need to use local_inc for acquired variable,
>> >since it's a percpu variable with strict nesting scopes.
>> >
>>
>> LGTM.
>>
>> Acked-by: Davidlohr Bueso <dave@...olabs.net>
>
>Thanks for the review.
>Do you mind if I apply your ack to the latest version of this patch?
>https://lore.kernel.org/bpf/20250222024427.30294-2-alexei.starovoitov@gmail.com/
Yes, that is fine.
Thanks,
Davidlohr
Powered by blists - more mailing lists