Re: [PATCH bpf-next v4] bpf: Refactor active lock management

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

 



On Fri, Nov 8, 2024 at 11:43 PM Kumar Kartikeya Dwivedi
<memxor@xxxxxxxxx> wrote:
>  struct bpf_retval_range {
> @@ -434,7 +431,7 @@ struct bpf_verifier_state {
>         u32 insn_idx;
>         u32 curframe;
>
> -       struct bpf_active_lock active_lock;
> +       int active_lock;

What about this comment from v3:
> +       bool active_lock;

In the next patch it becomes 'int',
so let's make it 'int' right away and move it to bpf_func_state
next to:
        int acquired_refs;
        struct bpf_reference_state *refs;

?

wouldn't it be cleaner to keep the count of locks in bpf_func_state
next to refs ?

acquire_lock_state() would increment it and release will dec it.

check_resource_leak() will
instead of:
env->cur_state->active_lock
do:
cur_func(env)->active_lock

so behavior is the same, but counting of locks is clean.

Since in this patch it's kinda counting locks across all frames
which is a bit odd.





[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