[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBKBG96ufOqOHqEa@gpd3>
Date: Wed, 30 Apr 2025 21:59:23 +0200
From: Andrea Righi <arighi@...dia.com>
To: Tejun Heo <tj@...nel.org>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH sched_ext/for-6.16] sched_ext: Add RCU protection to
scx_root in DSQ iterator
On Wed, Apr 30, 2025 at 08:59:06AM -1000, Tejun Heo wrote:
> On Wed, Apr 30, 2025 at 11:09:30AM +0200, Andrea Righi wrote:
> > @@ -6907,28 +6907,39 @@ __bpf_kfunc int bpf_iter_scx_dsq_new(struct bpf_iter_scx_dsq *it, u64 dsq_id,
> > {
> > struct bpf_iter_scx_dsq_kern *kit = (void *)it;
> > struct scx_sched *sch;
> > + int ret = 0;
> >
> > BUILD_BUG_ON(sizeof(struct bpf_iter_scx_dsq_kern) >
> > sizeof(struct bpf_iter_scx_dsq));
> > BUILD_BUG_ON(__alignof__(struct bpf_iter_scx_dsq_kern) !=
> > __alignof__(struct bpf_iter_scx_dsq));
> >
> > + rcu_read_lock();
> > sch = rcu_dereference(scx_root);
>
> Can you instead try changing rcu_derefernece(scx_root) to
> rcu_derefernece_check(scx_root, rcu_read_lock_bh_held())? The warning is
> because this can be called both from rcu-locked and bh contexts and while
> grabbing rcu_read_lock() once works, telling rcu that the dereference can be
> in both contexts is more accurate here.
Yeah, that seems better, also considering that bpf_iter_scx_dsq_next() is
marked with KF_RCU_PROTECTED, so checking for rcu_read_lock_bh_held()
should cover all the possible cases.
Will test that and send a v2.
Thanks!
-Andrea
Powered by blists - more mailing lists