From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
bpf@vger.kernel.org, linux-mm@kvack.org, harry.yoo@oracle.com,
shakeel.butt@linux.dev, mhocko@suse.com, andrii@kernel.org,
memxor@gmail.com, akpm@linux-foundation.org,
peterz@infradead.org, rostedt@goodmis.org, hannes@cmpxchg.org,
willy@infradead.org
Subject: Re: [PATCH 3/6] locking/local_lock: Introduce local_lock_is_locked().
Date: Mon, 12 May 2025 17:23:33 +0200 [thread overview]
Message-ID: <20250512152333.Di9sTun1@linutronix.de> (raw)
In-Reply-To: <1c9bbd31-10f1-41b6-b2b9-745ab4e9e2ad@suse.cz>
On 2025-05-12 17:01:55 [+0200], Vlastimil Babka wrote:
> On 5/12/25 16:56, Sebastian Andrzej Siewior wrote:
> > On 2025-04-30 20:27:15 [-0700], Alexei Starovoitov wrote:
> >> --- a/include/linux/local_lock_internal.h
> >> +++ b/include/linux/local_lock_internal.h
> >> @@ -285,4 +288,9 @@ do { \
> >> __local_trylock(lock); \
> >> })
> >>
> >> +/* migration must be disabled before calling __local_lock_is_locked */
> >> +#include "../../kernel/locking/rtmutex_common.h"
> >> +#define __local_lock_is_locked(__lock) \
> >> + (rt_mutex_owner(&this_cpu_ptr(__lock)->lock) == current)
> >
> > So I've been looking if we really need rt_mutex_owner() or if
> > rt_mutex_base_is_locked() could do the job. Judging from the slub-free
> > case, the rt_mutex_base_is_locked() would be just fine. The alloc case
> > on the other hand probably not so much. On the other hand since we don't
> > accept allocations from hardirq or NMI the "caller == owner" case should
> > never be observed. Unless buggy & debugging and this should then also be
> > observed by lockdep. Right?
>
> AFAIU my same line of thought was debunked by Alexei here:
>
> https://lore.kernel.org/all/CAADnVQLO9YX2_0wEZshHbwXoJY2-wv3OgVGvN-hgf6mK0_ipxw@mail.gmail.com/
>
> e.g. you could have the lock and then due to kprobe or tracing in the slab
> allocator code re-enter it.
Okay. So I assumed that re-entrace is not a thing here on PREEMPT_RT but
thank you correcting.
There is a difference if the lock is locked and you try a different one
if it is possible just to avoid the contention. Otherwise fallback to
the contention case if there is no other way. The other case is to avoid
recursive locking.
> > If there is another case where recursion can be observed and need to be
> > addressed I would prefer to move the function (+define) to
> > include/linux/rtmutex.h. instead of doing this "../../ include".
> >
> >> #endif /* CONFIG_PREEMPT_RT */
Sebastian
next prev parent reply other threads:[~2025-05-12 15:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 3:27 [PATCH 0/6] mm: Reentrant kmalloc Alexei Starovoitov
2025-05-01 3:27 ` [PATCH 1/6] mm: Rename try_alloc_pages() to alloc_pages_nolock() Alexei Starovoitov
2025-05-06 8:26 ` Vlastimil Babka
2025-05-07 1:24 ` Alexei Starovoitov
2025-05-01 3:27 ` [PATCH 2/6] locking/local_lock: Expose dep_map in local_trylock_t Alexei Starovoitov
2025-05-06 12:56 ` Vlastimil Babka
2025-05-06 14:55 ` Vlastimil Babka
2025-05-07 1:25 ` Alexei Starovoitov
2025-05-12 13:26 ` Sebastian Andrzej Siewior
2025-05-12 16:46 ` Alexei Starovoitov
2025-05-01 3:27 ` [PATCH 3/6] locking/local_lock: Introduce local_lock_is_locked() Alexei Starovoitov
2025-05-06 12:59 ` Vlastimil Babka
2025-05-07 1:28 ` Alexei Starovoitov
2025-05-12 14:56 ` Sebastian Andrzej Siewior
2025-05-12 15:01 ` Vlastimil Babka
2025-05-12 15:23 ` Sebastian Andrzej Siewior [this message]
2025-05-01 3:27 ` [PATCH 4/6] locking/local_lock: Introduce local_lock_irqsave_check() Alexei Starovoitov
2025-05-07 13:02 ` Vlastimil Babka
2025-05-12 14:03 ` Sebastian Andrzej Siewior
2025-05-12 17:16 ` Alexei Starovoitov
2025-05-13 6:58 ` Vlastimil Babka
2025-05-13 21:55 ` Alexei Starovoitov
2025-05-01 3:27 ` [PATCH 5/6] mm: Allow GFP_ACCOUNT and GFP_COMP to be used in alloc_pages_nolock() Alexei Starovoitov
2025-05-06 8:55 ` Vlastimil Babka
2025-05-07 1:33 ` Alexei Starovoitov
2025-05-01 3:27 ` [PATCH 6/6] slab: Introduce kmalloc_nolock() and kfree_nolock() Alexei Starovoitov
2025-05-05 18:46 ` Shakeel Butt
2025-05-06 0:49 ` Alexei Starovoitov
2025-05-06 1:24 ` Shakeel Butt
2025-05-06 1:51 ` Alexei Starovoitov
2025-05-06 18:05 ` Shakeel Butt
2025-05-06 12:01 ` Vlastimil Babka
2025-05-07 0:31 ` Harry Yoo
2025-05-07 2:23 ` Alexei Starovoitov
2025-05-07 8:38 ` Vlastimil Babka
2025-05-07 2:20 ` Alexei Starovoitov
2025-05-07 10:44 ` Vlastimil Babka
2025-05-09 1:03 ` Harry Yoo
2025-06-24 17:13 ` SLAB_NO_CMPXCHG was:: " Alexei Starovoitov
2025-06-25 11:38 ` Harry Yoo
2025-06-26 20:03 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250512152333.Di9sTun1@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=linux-mm@kvack.org \
--cc=memxor@gmail.com \
--cc=mhocko@suse.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).