Daniel Borkmann <daniel@xxxxxxxxxxxxx> writes:
> On 8/13/20 9:52 PM, Toke Høiland-Jørgensen wrote:
>> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:
>>> On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>>>>
>>>> Turns out there were a few more instances where libbpf didn't save the
>>>> errno before writing an error message, causing errno to be overridden by
>>>> the printf() return and the error disappearing if logging is enabled.
>>>>
>>>> Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
>>>> ---
>>>
>>> Acked-by: Andrii Nakryiko <andriin@xxxxxx>
>>>
>>>> tools/lib/bpf/libbpf.c | 12 +++++++-----
>>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>>> index 0a06124f7999..fd256440e233 100644
>>>> --- a/tools/lib/bpf/libbpf.c
>>>> +++ b/tools/lib/bpf/libbpf.c
>>>> @@ -3478,10 +3478,11 @@ bpf_object__probe_global_data(struct bpf_object *obj)
>>>>
>>>> map = bpf_create_map_xattr(&map_attr);
>>>> if (map < 0) {
>>>> - cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
>>>> + ret = -errno;
>>>> + cp = libbpf_strerror_r(-ret, errmsg, sizeof(errmsg));
>>>
>>> fyi, libbpf_strerror_r() is smart enough to work with both negative
>>> and positive error numbers (it basically takes abs(err)), so no need
>>> to ensure it's positive here and below.
>>
>> Noted. Although that also means it doesn't hurt either, I suppose; so
>> not going to bother respinning this unless someone insists :)
>
> Fixed up while applying, thanks!
Great, thanks!
-Toke
