bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Menglong Dong <menglong8.dong@gmail.com>
To: paulmck@kernel.org
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	 Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard <eddyz87@gmail.com>,  Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	KP Singh <kpsingh@kernel.org>,
	 Stanislav Fomichev <sdf@fomichev.me>,
	Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
	 bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/7] rcu: add rcu_migrate_enable and rcu_migrate_disable
Date: Sun, 17 Aug 2025 10:01:23 +0800	[thread overview]
Message-ID: <CADxym3bkqdXScTBvQMOb-JTDZTmAqdm_m_we4Rds6W=rgByauQ@mail.gmail.com> (raw)
In-Reply-To: <eb93f12d-2232-4b7e-a7c6-71082a69f1f6@paulmck-laptop>

On Fri, Aug 15, 2025 at 11:31 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Aug 15, 2025 at 04:02:14PM +0300, Alexei Starovoitov wrote:
> > On Fri, Aug 15, 2025 at 9:18 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
> > >
> > > migrate_disable() is called to disable migration in the kernel, and it is
> > > used togather with rcu_read_lock() oftenly.
> > >
> > > However, with PREEMPT_RCU disabled, it's unnecessary, as rcu_read_lock()
> > > will disable preemption, which will also disable migration.
> > >
> > > Introduce rcu_migrate_enable() and rcu_migrate_disable(), which will do
> > > the migration enable and disable only when the rcu_read_lock() can't do
> > > it.
> > >
> > > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > > ---
> > >  include/linux/rcupdate.h | 18 ++++++++++++++++++
> > >  1 file changed, 18 insertions(+)
> > >
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 120536f4c6eb..0d9dbd90d025 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -72,6 +72,16 @@ static inline bool same_state_synchronize_rcu(unsigned long oldstate1, unsigned
> > >  void __rcu_read_lock(void);
> > >  void __rcu_read_unlock(void);
> > >
> > > +static inline void rcu_migrate_enable(void)
> > > +{
> > > +       migrate_enable();
> > > +}
> >
> > Interesting idea.
> > I think it has to be combined with rcu_read_lock(), since this api
> > makes sense only when used together.
> >
> > rcu_read_lock_dont_migrate() ?
> >
> > It will do rcu_read_lock() + migrate_disalbe() in PREEMPT_RCU
> > and rcu_read_lock() + preempt_disable() otherwise?
>
> That could easily be provided.  Or just make one, and if it starts
> having enough use cases, it could be pulled into RCU proper.

Hi, do you mean that we should start with a single
use case? In this series, I started it with the BPF
subsystem. Most of the situations are similar, which will
call rcu_read_lock+migrate_disable and run bpf prog.

>
> > Also I'm not sure we can rely on rcu_read_lock()
> > disabling preemption in all !PREEMPT_RCU cases.
> > iirc it's more nuanced than that.
>
> For once, something about RCU is non-nuanced.  But don't worry, it won't
> happen again.  ;-)
>
> In all !PREEMPT_RCU, preemption must be disabled across all RCU read-side
> critical sections in order for RCU to work correctly.

Great! I worried about this part too.

Thanks!
Menglong Dong

>
>                                                         Thanx, Paul

  reply	other threads:[~2025-08-17  2:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-15  6:18 [PATCH bpf-next 0/7] bpf: introduce and use rcu_migrate_{enable,disable} Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 1/7] rcu: add rcu_migrate_enable and rcu_migrate_disable Menglong Dong
2025-08-15 13:02   ` Alexei Starovoitov
2025-08-15 15:31     ` Paul E. McKenney
2025-08-17  2:01       ` Menglong Dong [this message]
2025-08-19 21:34         ` Paul E. McKenney
2025-08-17  1:55     ` Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 2/7] bpf: use rcu_migrate_* for bpf_cgrp_storage_free() Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 3/7] bpf: use rcu_migrate_* for bpf_inode_storage_free() Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 4/7] bpf: use rcu_migrate_* for bpf_iter_run_prog() Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 5/7] bpf: use rcu_migrate_* for bpf_task_storage_free() Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 6/7] bpf: use rcu_migrate_* for bpf_prog_run_array_cg() Menglong Dong
2025-08-15  6:18 ` [PATCH bpf-next 7/7] bpf: use rcu_migrate_* for trampoline.c Menglong Dong

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='CADxym3bkqdXScTBvQMOb-JTDZTmAqdm_m_we4Rds6W=rgByauQ@mail.gmail.com' \
    --to=menglong8.dong@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=paulmck@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).