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

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.

> ...