Re: [PATCH bpf-next v1 1/2] bpf: Fix sleepable context checks and remove in_sleepable helper

[Eduard Zingerman <eddyz87@gmail.com>]

On Thu, 2026-08-06 at 23:22 +0200, Kumar Kartikeya Dwivedi wrote:
> On Thu Aug 6, 2026 at 10:31 PM CEST, Eduard Zingerman wrote:
> > On Thu, 2026-08-06 at 18:40 +0200, Kumar Kartikeya Dwivedi wrote:
> > 
> > ...
> > 
> > > @@ -10258,7 +10253,7 @@ static inline bool in_sleepable_context(struct bpf_verifier_env *env)
> > >  	       !env->cur_state->active_preempt_locks &&
> > >  	       !env->cur_state->active_locks &&
> > >  	       !env->cur_state->active_irq_id &&
> > > -	       in_sleepable(env);
> > > +	       env->cur_state->in_sleepable;
> > >  }
> > 
> > The in_rcu_cs() and in_sleepable_context() are complementary:
> > 
> >   env->cur_state->active_rcu_locks ||       !env->cur_state->active_rcu_locks &&
> >   env->cur_state->active_preempt_locks ||   !env->cur_state->active_preempt_locks &&
> >   env->cur_state->active_locks ||           !env->cur_state->active_locks &&
> >   env->cur_state->active_irq_id ||          !env->cur_state->active_irq_id &&
> >   !env->cur_state->in_sleepable;            env->cur_state->in_sleepable;
> > 
> > Should the one be expressed through the other?
> > 
> 
> I thought about this, and I really can't decide, so I'll let others shape the
> decision. On one hand, it is true, but I am just worried we have some other way
> of disabling sleepable context in the future, for which we modify
> in_sleepable_context(), but that thing does not imply RCU CS. I don't know
> whether we will have such a case though.
> 
> We can also add a comment to revisit in_rcu_cs() and keep it in sync everytime
> in_sleepable_context() is changed though, and hopefully reviewers (human and AI)
> will be reminded to not break the relationship between both.

I'd declare in_rcu_cs() as !in_sleepable_context() and put both
functions side-by-side in the verifier.c.