alid and not stale with e->lock held
> >
> > Signed-off-by: Wei Yang
> > CC: Boqun Feng
> > CC: Alan Huang
> >
> > ---
> > v2:
> > * add the missing parameter *key
> > * make function return struct audit_entry
> > ---
On Tue, Feb 18, 2025 at 12:50:47AM +, Wei Yang wrote:
> This patch adjust the example code with following two purpose:
>
> * reduce the confusion on not releasing e->lock
> * emphasize e is valid and not stale with e->lock held
>
> Signed-off-by: Wei Yang
>
From: "Paul E. McKenney"
The rcu_barrier_sched(), synchronize_sched(), and synchronize_rcu_bh()
RCU API members have been gone for many years. This commit therefore
removes non-historical instances of them.
Reported-by: Joe Perches
Signed-off-by: Paul E. McKenney
Signed-off-by:
From: "Paul E. McKenney"
This commit wordsmiths the RCU_LAZY and RCU_LAZY_DEFAULT_OFF Kconfig
options' help text.
Signed-off-by: Paul E. McKenney
Signed-off-by: Boqun Feng
---
kernel/rcu/Kconfig | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff
From: "Paul E. McKenney"
This commit causes the call_srcu() kernel-doc header to reference that
of call_rcu() for detailed memory-ordering guarantees.
Signed-off-by: Paul E. McKenney
Signed-off-by: Boqun Feng
---
kernel/rcu/srcutree.c | 8 ++--
1 file changed, 6 insert
Kenney
Cc: Jonathan Corbet
Cc: Peter Zijlstra
Cc: Mark Rutland
Cc: Boqun Feng
Cc:
Signed-off-by: Boqun Feng
---
Documentation/core-api/this_cpu_ops.rst | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/Documentation/core-api/this_cpu_ops.rst
b/Document
From: "Paul E. McKenney"
This commit documents the fact that a given RCU callback function can
repost itself.
Reported-by: Jens Axboe
Signed-off-by: Paul E. McKenney
Signed-off-by: Boqun Feng
---
kernel/rcu/tree.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
di
From: "Paul E. McKenney"
Currently, stallwarn.rst does not mention the fact that timer bugs can
result in false-positive RCU CPU stall warnings. This commit therefore
adds this to the list.
Signed-off-by: Paul E. McKenney
Signed-off-by: Boqun Feng
---
Documentation/RCU/stallwa
Hi,
Please find the upcoming changes in RCU documentation for v6.15. The
changes can also be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git
docs.2025.02.04a
Regards,
Boqun
Paul E. McKenney (7):
doc: Add broken-timing possibility to stallwarn.rst
docs: Imp
From: "Paul E. McKenney"
This commit adds a description of the energy-efficiency delays that
call_rcu() can impose, along with a pointer to call_rcu_hurry() for
latency-sensitive kernel code.
Signed-off-by: Paul E. McKenney
Signed-off-by: Boqun Feng
---
kernel/rcu/tree.c | 7 +
On Mon, Feb 17, 2025 at 09:18:42AM +, Wei Yang wrote:
> On Mon, Feb 17, 2025 at 04:02:53PM +0800, Alan Huang wrote:
> >On Feb 17, 2025, at 15:41, Wei Yang wrote:
> >>
> >> On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
> >>> On Fe
On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
> On Feb 17, 2025, at 10:12, Boqun Feng wrote:
> >
> > Hi Wei,
> >
> > The change loosk good to me, thanks!
> >
> > I queued the patch for futher reviews and tests with some changes in the
> &
ld return with the lock of the entry held.
Hence fix these.
Signed-off-by: Wei Yang
Link: https://lore.kernel.org/r/20250101082306.10404-1-richard.weiy...@gmail.com
Signed-off-by: Boqun Feng
---
Documentation/RCU/listRCU.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
dif
On Wed, Oct 16, 2019 at 12:06:51PM +0200, Marco Elver wrote:
> On Wed, 16 Oct 2019 at 11:42, Boqun Feng wrote:
> >
> > Hi Marco,
> >
> > On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> > [...]
> > > --- /dev/null
> >
Hi Marco,
On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
[...]
> --- /dev/null
> +++ b/kernel/kcsan/kcsan.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * The Kernel Concurrency Sanitizer (KCSAN) infrastructure. For more info
> please
> + * see Documentati
Hi Joel,
On Tue, Aug 27, 2019 at 03:01:56PM -0400, Joel Fernandes (Google) wrote:
> During testing, it was observed that amount of memory consumed due
> kfree_rcu() batching is 300-400MB. Previously we had only a single
> head_free pointer pointing to the list of rcu_head(s) that are to be
> freed
(Copy more people)
On Wed, Apr 11, 2018 at 09:50:51PM +0800, Boqun Feng wrote:
> This patch add the documentation piece for the reasoning of deadlock
> detection related to recursive read lock. The following sections are
> added:
>
> * Explain what is a recursive read lock, an
On Sat, Apr 14, 2018 at 05:38:54PM -0700, Randy Dunlap wrote:
> Hi,
>
Hello Randy,
> Just a few typos etc. below...
>
Thanks! I fixed those typos according to your comments.
> On 04/11/2018 06:50 AM, Boqun Feng wrote:
> > Signed-off-by: Boqun Feng
> > ---
> &g
types of dependencies, and
the definition of strong paths.
* Proof for a closed strong path is both sufficient and necessary
for deadlock detections with recursive read locks involved. The
proof could also explain why we call the path "strong"
Signed-off-by:
ecursive)
new:
LOCK_* : stands for non-recursive(write lock and non-recursive
read lock)
LOCK_*_RR: stands for recursive read lock
Such a change is needed for a future improvement on recursive read
related irq inversion deadlock detection.
Signed-off-by: Boqun Feng
---
On Sat, Feb 24, 2018 at 11:53:20PM +0100, Andrea Parri wrote:
> On Thu, Feb 22, 2018 at 03:09:03PM +0800, Boqun Feng wrote:
> > As now we support recursive read lock deadlock detection, add related
> > explanation in the Documentation/lockdep/lockdep-desgin.txt:
> >
ecursive)
new:
LOCK_* : stands for non-recursive(write lock and non-recursive
read lock)
LOCK_*_RR: stands for recursive read lock
Such a change is needed for a future improvement on recursive read
related irq inversion deadlock detection.
Signed-off-by: Boqun Feng
---
Document
sumption.
* Informal proof of recursive read lock deadlock detection.
Signed-off-by: Boqun Feng
Cc: Randy Dunlap
---
Documentation/locking/lockdep-design.txt | 170 +++
1 file changed, 170 insertions(+)
diff --git a/Documentation/locking/lockdep-design.txt
b/Documentation
On Wed, Jan 24, 2018 at 05:05:49PM -0800, Randy Dunlap wrote:
> On 01/09/2018 06:38 AM, Boqun Feng wrote:
> > As now we support recursive read lock deadlock detection, add related
> > explanation in the Documentation/lockdep/lockdep-desgin.txt:
> >
> > * Definition o
sumption.
* Informal proof of recursive read lock deadlock detection.
Signed-off-by: Boqun Feng
---
Documentation/locking/lockdep-design.txt | 170 +++
1 file changed, 170 insertions(+)
diff --git a/Documentation/locking/lockdep-design.txt
b/Documentation/locking/lockdep-de
ecursive)
new:
LOCK_* : stands for non-recursive(write lock and non-recursive
read lock)
LOCK_*_RR: stands for recursive read lock
Such a change is needed for a future improvement on recursive read
related irq inversion deadlock detection.
Signed-off-by: Boqun Feng
---
Document
On Wed, Jan 03, 2018 at 03:04:36PM +0530, afzal mohammed wrote:
> Let PDF & HTML's be created out of memory-barriers Text by
> reStructuring.
>
> reStructuring done were,
> 1. Section headers modification, lower header case except start
> 2. Removal of manual index(contents section), since it now
te.
> >
> > In the future, we can either make compiler writers accept our use of
> > 'volatile', or(if that fails) find another way to provide this
> > guarantee.
> >
> > Cc: Akira Yokosawa
> > Cc: Paul E. McKenney
> > Signed-off
f READ_ONCE(), this not only
fits the conceptual semantics we have been using, but also makes the
implementation requirement more accurate.
In the future, we can either make compiler writers accept our use of
'volatile', or(if that fails) find another way to provide this
guarantee.
Cc: Ak
On Thu, Jul 20, 2017 at 04:07:14PM -0700, Paul E. McKenney wrote:
[...]
> >
> > So if I respin the patch with the extern, would you still feel reluctant?
>
> Yes, because I am not seeing how this change helps. What is this telling
> the reader that the original did not, and how does it help the
On Wed, Jul 19, 2017 at 10:47:04PM -0700, Paul E. McKenney wrote:
[...]
> > Hi Paul,
> >
> > I know the compiler could optimize atomics in very interesting ways, but
> > this case is about volatile, so I guess our case is still fine? ;-)
>
> Hello, Boqun,
>
> When I asked that question, the answ
On Wed, Jul 19, 2017 at 02:56:02PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 20, 2017 at 06:33:26AM +0900, Akira Yokosawa wrote:
> > On 2017/07/20 2:43, Paul E. McKenney wrote:
> > > On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote:
> > >> >From b798b9b631e237d285aa8699da00bfb8ced3
32 matches
Mail list logo
