Re: [PATCH bpf-next v5 7/8] libbpf: Support creating light skeleton of either endianness

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

 



On Tue, Sep 3, 2024 at 12:34 AM Tony Ambardar <tony.ambardar@xxxxxxxxx> wrote:
>
> @@ -1040,10 +1121,11 @@ void bpf_gen__map_update_elem(struct bpf_gen *gen, int map_idx, void *pvalue,
>         int zero = 0;
>
>         memset(&attr, 0, attr_size);
> -       pr_debug("gen: map_update_elem: idx %d\n", map_idx);
>
>         value = add_data(gen, pvalue, value_size);
>         key = add_data(gen, &zero, sizeof(zero));
> +       pr_debug("gen: map_update_elem: idx %d, value: off %d size %d\n",
> +                map_idx, value, value_size);
>
>         /* if (map_desc[map_idx].initial_value) {
>          *    if (ctx->flags & BPF_SKEL_KERNEL)
> @@ -1068,6 +1150,8 @@ void bpf_gen__map_update_elem(struct bpf_gen *gen, int map_idx, void *pvalue,
>         emit(gen, BPF_EMIT_CALL(BPF_FUNC_probe_read_kernel));
>
>         map_update_attr = add_data(gen, &attr, attr_size);
> +       pr_debug("gen: map_update_elem: attr: off %d size %d\n",
> +                map_update_attr, attr_size);
>         move_blob2blob(gen, attr_field(map_update_attr, map_fd), 4,
>                        blob_fd_array_off(gen, map_idx));
>         emit_rel_store(gen, attr_field(map_update_attr, key), key);

I don't see the point of two pr_debug("gen: map_update_elem...
just a few lines from each other.

Other than that:
Acked-by: Alexei Starovoitov <ast@xxxxxxxxxx>





[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