Re: [PATCH bpf-next v1 3/7] bpf: Consolidate RCU and preempt locks in bpf_func_state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 21 Nov 2024 at 19:09, Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Wed, 2024-11-20 at 16:53 -0800, Kumar Kartikeya Dwivedi wrote:
> > To ensure consistency in resource handling, move RCU and preemption
> > state counters to bpf_func_state, and convert all users to access them
> > through cur_func(env).
> >
> > For the sake of consistency, also compare active_locks in ressafe as a
> > quick way to eliminate iteration and entry matching if the number of
> > locks are not the same.
> >
> > OTOH, the comparison of active_preempt_locks and active_rcu_lock is
> > needed for correctness, as state exploration cannot be avoided if these
> > counters do not match, and not comparing them will lead to problems
> > since they lack an actual entry in the acquired_res array.
> >
> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> > ---
>
> This change is a bit confusing to me.
> The following is done currently:
> - in setup_func_entry() called from check_func_call():
>   copy_resource_state(callee, caller);
> - in prepare_func_exit():
>   copy_resource_state(caller, callee);
>
> So it seems that it is logical to track resources in the
> bpf_verifier_state and avoid copying.
> There is probably something I don't understand.
>

This is what we were doing all along, and you're right, it is sort of
a global entity.
But we've moved active_locks to bpf_func_state, where references reside, while
RCU and preempt lock state stays in verifier state. Either everything
should be in
cur_func, or in bpf_verifier_state. I am fine with either of them,
because it would
materially does not matter too much.

Alexei's preference has been stashing this in bpf_func_state instead in [0].
Let me know what you think.

  [0] https://lore.kernel.org/bpf/CAADnVQKxgE7=WhjNckvMDTZ5GZujPuT3Dqd+sY=pW8CWoaF9FA@xxxxxxxxxxxxxx

> [...]
>




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux