linux-kernel - Re: [PATCH v3 07/11] lib/ref_tracker: remove warnings in case of allocation failure

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <00534db7-6b0e-7efa-11a1-d386e2f71a23@intel.com>
Date:   Tue, 22 Feb 2022 11:44:10 +0100
From:   Andrzej Hajda <andrzej.hajda@...el.com>
To:     Eric Dumazet <edumazet@...gle.com>
CC:     LKML <linux-kernel@...r.kernel.org>,
        <intel-gfx@...ts.freedesktop.org>,
        <dri-devel@...ts.freedesktop.org>, netdev <netdev@...r.kernel.org>,
        "Jani Nikula" <jani.nikula@...ux.intel.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Lucas De Marchi <lucas.demarchi@...el.com>,
        Chris Wilson <chris.p.wilson@...el.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "Jakub Kicinski" <kuba@...nel.org>
Subject: Re: [PATCH v3 07/11] lib/ref_tracker: remove warnings in case of
 allocation failure



On 22.02.2022 00:54, Eric Dumazet wrote:
> On Mon, Feb 21, 2022 at 3:26 PM Andrzej Hajda <andrzej.hajda@...el.com> wrote:
>> Library can handle allocation failures. To avoid allocation warnings
>> __GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
>> replaced with GFP_NOWAIT in case of stack allocation on tracker free
>> call.
>>
>> Signed-off-by: Andrzej Hajda <andrzej.hajda@...el.com>
>> ---
>>   lib/ref_tracker.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
>> index 2ef4596b6b36f..cae4498fcfd70 100644
>> --- a/lib/ref_tracker.c
>> +++ b/lib/ref_tracker.c
>> @@ -189,7 +189,7 @@ int ref_tracker_alloc(struct ref_tracker_dir *dir,
>>          unsigned long entries[REF_TRACKER_STACK_ENTRIES];
>>          struct ref_tracker *tracker;
>>          unsigned int nr_entries;
>> -       gfp_t gfp_mask = gfp;
>> +       gfp_t gfp_mask = gfp | __GFP_NOWARN;
> SGTM
>
>>          unsigned long flags;
>>
>>          WARN_ON_ONCE(dir->dead);
>> @@ -237,7 +237,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
>>                  return -EEXIST;
>>          }
>>          nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
>> -       stack_handle = stack_depot_save(entries, nr_entries, GFP_ATOMIC);
>> +       stack_handle = stack_depot_save(entries, nr_entries,
>> +                                       GFP_NOWAIT | __GFP_NOWARN);
> Last time I looked at this, __GFP_NOWARN was enforced in __stack_depot_save()

You are right, however I am not sure if we should count on unexpected 
(at least for me) and undocumented behavior.
Currently we do not need to rely on some hidden feature.

Regards
Andrzej

>
>>          spin_lock_irqsave(&dir->lock, flags);
>>          if (tracker->dead) {
>> --
>> 2.25.1
>>