lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b387d566-e460-4cae-bddb-67abe70d9f83@gmail.com>
Date: Wed, 19 Feb 2025 23:15:24 +0800
From: Tao Chen <chen.dylane@...il.com>
To: Eduard Zingerman <eddyz87@...il.com>, ast@...nel.org,
 daniel@...earbox.net, andrii@...nel.org, haoluo@...gle.com,
 jolsa@...nel.org, qmo@...nel.org
Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libbpf: Wrap libbpf API direct err with libbpf_err

在 2025/2/19 14:34, Eduard Zingerman 写道:
> On Wed, 2025-02-19 at 14:23 +0800, Tao Chen wrote:
>> 在 2025/2/19 10:08, Eduard Zingerman 写道:
>>> On Fri, 2025-02-14 at 22:17 +0800, Tao Chen wrote:
>>>> Just wrap the direct err with libbpf_err, keep consistency
>>>> with other APIs.
>>>>
>>>> Signed-off-by: Tao Chen <chen.dylane@...il.com>
>>>> ---
>>>
>>> While at it, I've noticed two more places that need libbpf_err() calls.
>>> Could you please check the following locations:
>>>
>>> bpf_map__set_value_size:
>>>     return -EOPNOTSUPP;       tools/lib/bpf/libbpf.c:10309
>>>     return err;               tools/lib/bpf/libbpf.c:10317
>>
>> Will change it. Thanks
>>
>>>
>>> ?
>>>
>>> Other than that, I agree with changes in this patch.
>>>
>>> Acked-by: Eduard Zingerman <eddyz87@...il.com>
>>>
>>> [...]
>>>
>>
>> I use a simple script, other places may also should be added:
> 
> Yeah, makes sense :)
> 
>>
>> 9727 line: return NUL; (API:libbpf_bpf_attach_type_str)
>> 9735 line: return NULL; (API: libbpf_bpf_link_type_str)
>> 9743 line: return NULL; (API: libbpf_bpf_map_type_str)
>> 9751 line: return NULL; (API: libbpf_bpf_prog_type_str)
>> 10151 line: return NULL; (API: bpf_map__name)
> 
> Sort of makes sense for these.
> Idk, I'm fine with and without changes to these functions.
> 

Well,then I'll still keep these and won't make any modifications.

>> 10458 line: return NULL; (API: bpf_object__prev_map)
> 
> This is not an error, I think.
> 
> [...]
> 


-- 
Best Regards
Tao Chen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ