All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>
Subject: [PATCH v3 0/7] Introduce local_lock()
Date: Wed, 27 May 2020 22:11:12 +0200	[thread overview]
Message-ID: <20200527201119.1692513-1-bigeasy@linutronix.de> (raw)

This is v3 of the local_lock() series. The v2 can be found at 

   https://lore.kernel.org/lkml/20200524215739.551568-1-bigeasy@linutronix.de/

v2…v3:
  - Use `local_lock_t' instead of `struct local_lock' because it is
    tiny data structure in general (similar to spinlock_t). Use also
    consistent file names `local_lock.h'.

  - Export the data structure in radix-tree so that the `lock' member
    can be accessed externally. The common case of 'local_unlock()' (no
    lockdep, no preemption) will then be optimized away. Otherwise
    `idr_preload_end()' will be a function containing only a return
    opcode.

  - Reorganize the struct member names in mm/swap and connector/cn_proc.

  - Make the `lock' member comes before the member that it aims to
    protect.

  - Two hunks from patch #6 appeared under mysteries circumstances in
    patch #7. They have been moved back to patch #6.
    Also applied comments to patch #7 as suggested by Ingo.

v1…v2:
  - Remove static initializer so a local_lock is not used a single
    per-CPU variable but a as a member of an existing structure, that is
    used per-CPU.

  - Use LD_WAIT_CONFIG as wait-type in the dep_map.

  - Expect a pointer like value as argument (same as this_cpu_ptr()).

  - Drop the SRCU patch. A different sollution is worked on.

  - Drop the zswap patch. That code part will be reworked.


preempt_disable() and local_irq_disable/save() are in principle per CPU big
kernel locks. This has several downsides:

  - The protection scope is unknown

  - Violation of protection rules is hard to detect by instrumentation

  - For PREEMPT_RT such sections, unless in low level critical code, can
    violate the preemptability constraints.

To address this PREEMPT_RT introduced the concept of local_locks which are
strictly per CPU.

The lock operations map to preempt_disable(), local_irq_disable/save() and
the enabling counterparts on non RT enabled kernels.

If lockdep is enabled local locks gain a lock map which tracks the usage
context. This will catch cases where an area is protected by
preempt_disable() but the access also happens from interrupt context. local
locks have identified quite a few such issues over the years, the most
recent example is:

  b7d5dc21072cd ("random: add a spinlock_t to struct batched_entropy")

Aside of the lockdep coverage this also improves code readability as it
precisely annotates the protection scope.

PREEMPT_RT substitutes these local locks with 'sleeping' spinlocks to
protect such sections while maintaining preemtability and CPU locality.

The followin series introduces the infrastructure including
documentation and provides a couple of examples how they are used to
adjust code to be RT ready.

Sebastian


             reply	other threads:[~2020-05-27 20:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 20:11 Sebastian Andrzej Siewior [this message]
2020-05-27 20:11 ` [PATCH v3 1/7] locking: Introduce local_lock() Sebastian Andrzej Siewior
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2020-05-27 20:11 ` [PATCH v3 2/7] radix-tree: Use local_lock for protection Sebastian Andrzej Siewior
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Sebastian Andrzej Siewior
2020-05-27 20:11 ` [PATCH v3 3/7] mm/swap: " Sebastian Andrzej Siewior
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Ingo Molnar
2020-05-27 20:11 ` [PATCH v3 4/7] squashfs: make use of local lock in multi_cpu decompressor Sebastian Andrzej Siewior
2020-06-01  9:52   ` [tip: locking/core] squashfs: Make " tip-bot2 for Julia Cartwright
2020-05-27 20:11 ` [PATCH v3 5/7] connector/cn_proc: Protect send_msg() with a local lock Sebastian Andrzej Siewior
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Mike Galbraith
2020-05-27 20:11 ` [PATCH v3 6/7] zram: Allocate struct zcomp_strm as per-CPU memory Sebastian Andrzej Siewior
2020-05-29 20:51   ` Minchan Kim
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Sebastian Andrzej Siewior
2020-05-27 20:11 ` [PATCH v3 7/7] zram: Use local lock to protect per-CPU data Sebastian Andrzej Siewior
2020-05-29 20:57   ` Minchan Kim
2020-06-01  9:52   ` [tip: locking/core] " tip-bot2 for Mike Galbraith
2020-10-19  1:52   ` [PATCH v3 7/7] " Yu Zhao
2020-10-19  2:33     ` Hugh Dickins
2020-10-19  2:33       ` Hugh Dickins
2020-10-19  2:46     ` Mike Galbraith
2020-10-19  2:46       ` Mike Galbraith

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=20200527201119.1692513-1-bigeasy@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    --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 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.