From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Waiman Long <llong@redhat.com>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev, Boqun Feng <boqun.feng@gmail.com>,
Clark Williams <clrkwllms@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
John Ogness <john.ogness@linutronix.de>,
Jonathan Corbet <corbet@lwn.net>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Valentin Schneider <vschneid@redhat.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 2/3] Documentation: locking: Add local_lock_nested_bh() to locktypes
Date: Tue, 19 Aug 2025 12:00:46 +0200 [thread overview]
Message-ID: <20250819100046.ymb_o7VA@linutronix.de> (raw)
In-Reply-To: <db8defe4-14bf-4060-803f-e8b09a941d42@redhat.com>
On 2025-08-18 14:06:39 [-0400], Waiman Long wrote:
> > index 80c914f6eae7a..37b6a5670c2fa 100644
> > --- a/Documentation/locking/locktypes.rst
> > +++ b/Documentation/locking/locktypes.rst
> > @@ -204,6 +204,27 @@ per-CPU data structures on a non PREEMPT_RT kernel.
> > local_lock is not suitable to protect against preemption or interrupts on a
> > PREEMPT_RT kernel due to the PREEMPT_RT specific spinlock_t semantics.
> > +CPU local scope and bottom-half
> > +-------------------------------
> > +
> > +Per-CPU variables that are accessed only in softirq context should not rely on
> > +the assumption that this context is implicitly protected due to being
> > +non-preemptible. In a PREEMPT_RT kernel, softirq context is preemptible, and
> > +synchronizing every bottom-half-disabled section via implicit context results
> > +in an implicit per-CPU "big kernel lock."
> > +
> > +A local_lock_t together with local_lock_nested_bh() and
> > +local_unlock_nested_bh() for locking operations help to identify the locking
> > +scope.
> > +
> > +When lockdep is enabled, these functions verify that data structure access
> > +occurs within softirq context.
> > +Unlike local_lock(), local_unlock_nested_bh() does not disable preemption and
> > +does not add overhead when used without lockdep.
>
> Should it be local_lock_nested_bh()? It doesn't make sense to compare
> local_unlock_nested_bh() against local_lock(). In a PREEMPT_RT kernel,
> local_lock() disables migration but not preemption.
Yes, it should have been the lock and not the unlock part. I mention
just preemption part here because it focuses on the !RT part compared to
local_lock() and that it adds no overhead.
The PREEMPT_RT part below mentions that it behaves as a real lock so
that should be enough (not to mention the migration part (technically
migration must be already disabled so we could omit disabling migration
here but it is just a counter increment/ decrement at this point so we
don't win much by doing so)).
I made the following:
@@ -219,11 +219,11 @@ scope.
When lockdep is enabled, these functions verify that data structure access
occurs within softirq context.
-Unlike local_lock(), local_unlock_nested_bh() does not disable preemption and
+Unlike local_lock(), local_lock_nested_bh() does not disable preemption and
does not add overhead when used without lockdep.
On a PREEMPT_RT kernel, local_lock_t behaves as a real lock and
-local_unlock_nested_bh() serializes access to the data structure, which allows
+local_lock_nested_bh() serializes access to the data structure, which allows
removal of serialization via local_bh_disable().
raw_spinlock_t and spinlock_t
Good?
> Cheers,
> Longman
>
> > +
> > +On a PREEMPT_RT kernel, local_lock_t behaves as a real lock and
> > +local_unlock_nested_bh() serializes access to the data structure, which allows
> > +removal of serialization via local_bh_disable().
> > raw_spinlock_t and spinlock_t
> > =============================
Sebastian
next prev parent reply other threads:[~2025-08-19 10:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 9:38 [PATCH v2 0/3] Documentation: Add real-time bits Sebastian Andrzej Siewior
2025-08-15 9:38 ` [PATCH v2 1/3] Documentation: seqlock: Add a SPDX license identifier Sebastian Andrzej Siewior
2025-08-15 9:38 ` [PATCH v2 2/3] Documentation: locking: Add local_lock_nested_bh() to locktypes Sebastian Andrzej Siewior
2025-08-18 18:06 ` Waiman Long
2025-08-19 10:00 ` Sebastian Andrzej Siewior [this message]
2025-08-19 17:38 ` Waiman Long
2025-08-15 9:38 ` [PATCH v2 3/3] Documentation: Add real-time to core-api Sebastian Andrzej Siewior
2025-08-18 16:16 ` Jonathan Corbet
2025-08-19 8:03 ` Sebastian Andrzej Siewior
2025-08-19 13:20 ` Jonathan Corbet
2025-08-19 13:28 ` Sebastian Andrzej Siewior
2025-08-21 18:55 ` Jonathan Corbet
2025-08-22 7:08 ` Sebastian Andrzej Siewior
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=20250819100046.ymb_o7VA@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=clrkwllms@kernel.org \
--cc=corbet@lwn.net \
--cc=frederic@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=llong@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vschneid@redhat.com \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.