All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <llong@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rt-devel@lists.linux.dev
Cc: 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: Mon, 18 Aug 2025 14:06:39 -0400	[thread overview]
Message-ID: <db8defe4-14bf-4060-803f-e8b09a941d42@redhat.com> (raw)
In-Reply-To: <20250815093858.930751-3-bigeasy@linutronix.de>

On 8/15/25 5:38 AM, Sebastian Andrzej Siewior wrote:
> local_lock_nested_bh() is used within networking where applicable.
> Document why it is used and how it behaves.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>   Documentation/locking/locktypes.rst | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst
> 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.

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
>   =============================


  reply	other threads:[~2025-08-18 18:06 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 [this message]
2025-08-19 10:00     ` Sebastian Andrzej Siewior
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=db8defe4-14bf-4060-803f-e8b09a941d42@redhat.com \
    --to=llong@redhat.com \
    --cc=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=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.