On Fri, Feb 21, 2025 at 06:10:02PM +0100, Marco Elver wrote:
> On Thu, Feb 20, 2025 at 05:26PM -0800, Paul E. McKenney wrote:
> [...]
> > > That's what I've tried with this patch (rcu_read_lock_bh() also
> > > acquires "RCU", on top of "RCU_BH&qu
On Fri, Feb 21, 2025 at 01:16:00AM +0100, Marco Elver wrote:
> On Thu, 20 Feb 2025 at 23:36, Paul E. McKenney wrote:
> [...]
> > Suppose that one function walks an RCU-protected list, calling some
> > function from some other subsystem on each element. Suppose that each
>
On Thu, Feb 20, 2025 at 11:11:04PM +0100, Marco Elver wrote:
> On Thu, 20 Feb 2025 at 23:00, Paul E. McKenney wrote:
> >
> > On Thu, Feb 06, 2025 at 07:10:09PM +0100, Marco Elver wrote:
> > > Improve the existing annotations to properly support Clang's capability
&g
On Thu, Feb 06, 2025 at 07:10:09PM +0100, Marco Elver wrote:
> Improve the existing annotations to properly support Clang's capability
> analysis.
>
> The old annotations distinguished between RCU, RCU_BH, and RCU_SCHED.
> However, it does not make sense to acquire rcu_read_lock_bh() after
> rcu_r
On Thu, Oct 01, 2020 at 08:07:31PM -0700, Eric Biggers wrote:
> On Thu, Sep 24, 2020 at 08:31:02PM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 24, 2020 at 07:09:08PM -0700, Eric Biggers wrote:
> > > On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> >
On Thu, Sep 24, 2020 at 07:09:08PM -0700, Eric Biggers wrote:
> On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> >
On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> > > You're missing the point here. b and c could easily be allocated by a
> > > function
> > > alloc_b() that's in a
On Tue, Sep 22, 2020 at 12:09:36PM -0700, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 11:31:00AM -0700, Paul E. McKenney wrote:
> > > Also, it's not just the p == &global_variable case. Consider:
> > >
> > > struct a { struct b *b; };
> &
On Tue, Sep 22, 2020 at 11:59:31AM -0700, Eric Biggers wrote:
> On Tue, Sep 22, 2020 at 11:42:43AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> > > On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> >
On Tue, Sep 22, 2020 at 09:51:36AM +1000, Herbert Xu wrote:
> On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> >
> > > But this reasoning could apply to any data structure that contains
> > > a spin lock, in particular ones that are dereferenced throu
On Mon, Sep 21, 2020 at 04:52:43PM -0700, Eric Biggers wrote:
> On Mon, Sep 21, 2020 at 04:26:39PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2020 at 08:11:04AM +1000, Herbert Xu wrote:
> > > On Mon, Sep 21, 2020 at 08:27:14AM -0700, Paul E. McKenney wrote:
> > >
On Tue, Sep 22, 2020 at 08:11:04AM +1000, Herbert Xu wrote:
> On Mon, Sep 21, 2020 at 08:27:14AM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 21, 2020 at 06:19:39PM +1000, Herbert Xu wrote:
> > > On Thu, Sep 17, 2020 at 09:58:02AM -0700, Eric Biggers wrote:
> > > >
On Mon, Sep 21, 2020 at 06:19:39PM +1000, Herbert Xu wrote:
> On Thu, Sep 17, 2020 at 09:58:02AM -0700, Eric Biggers wrote:
> >
> > smp_load_acquire() is obviously correct, whereas READ_ONCE() is an
> > optimization
> > that is difficult to tell whether it's correct or not. For trivial data
> > s
Commit-ID: a0076e1778c23de4a42d90fee4ecb4c21dbb5838
Gitweb: https://git.kernel.org/tip/a0076e1778c23de4a42d90fee4ecb4c21dbb5838
Author: Paul E. McKenney
AuthorDate: Mon, 5 Nov 2018 16:57:40 -0800
Committer: Paul E. McKenney
CommitDate: Tue, 27 Nov 2018 09:18:59 -0800
crypto/pcrypt
On Fri, Nov 16, 2018 at 01:56:40PM +0800, Herbert Xu wrote:
> Paul E. McKenney wrote:
> > Now that synchronize_rcu() waits for bh-disable regions of code as
> > well as RCU read-side critical sections, the synchronize_rcu_bh() in
> > pcrypt_cpumask_change_notify
Now that synchronize_rcu() waits for bh-disable regions of code as
well as RCU read-side critical sections, the synchronize_rcu_bh() in
pcrypt_cpumask_change_notify() can be replaced by synchronize_rcu().
This commit therefore makes this change.
Signed-off-by: Paul E. McKenney
Cc: Steffen
On Thu, Nov 13, 2014 at 02:24:07PM -0500, Pranith Kumar wrote:
> Recently lockless_dereference() was added which can be used in place of
> hard-coding smp_read_barrier_depends(). The following PATCH makes the change.
>
> Signed-off-by: Pranith Kumar
> ---
> drivers/crypto/caam/jr.c | 3 ---
> 1
On Thu, Nov 13, 2014 at 02:24:06PM -0500, Pranith Kumar wrote:
> Recently lockless_dereference() was added which can be used in place of
> hard-coding smp_read_barrier_depends().
>
> http://lkml.iu.edu/hypermail/linux/kernel/1410.3/04561.html
>
> The following series tries to do this.
>
> There
On Sun, Oct 07, 2012 at 07:50:12PM +0300, Kirill A. Shutemov wrote:
> On Sun, Oct 07, 2012 at 09:03:11AM -0700, Paul E. McKenney wrote:
> > On Sun, Oct 07, 2012 at 05:47:11AM +0300, Kirill A. Shutemov wrote:
> > > Hi Paul and all,
> > >
> > > With commit 7556
t;> mutex_lock(&cpu_hotplug.lock);
> >>>>>
> >>>>> Have you seen the issue before?
> >>>>
> >>>> This is a new one for me. Does the following (very lightly tested)
> >>>> p
20 matches
Mail list logo
