linux-kernel - Re: [PATCH] ref_tracker: add stack_depot_save() failure handling to ref_tracker

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]

Date:   Mon, 29 May 2023 19:05:26 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ref_tracker: add stack_depot_save() failure handling to
 ref_tracker_alloc()

On Sat, 27 May 2023 20:04:11 +0900 Tetsuo Handa wrote:
> stack_depot_save() cannot accept __GFP_NOFAIL flag because
> __stack_depot_save() drops gfp flags which are not in
> GFP_KERNEL | GFP_ATOMIC | __GFP_NOWARN. Also, changing
> __stack_depot_save() to accept __GFP_NOFAIL is not possible
> because rmqueue() does not want __GFP_NOFAIL flag for
> order == DEPOT_POOL_ORDER allocation request.
> 
> Therefore, assume that stack_depot_save(GFP_KERNEL | __GFP_NOFAIL) from
> ref_tracker_alloc() can silently fail, and emit "unreliable refcount
> tracker." message.

It's probably a good idea to CC netdev@...r. I'm not sure if anyone
will pick this up from LKML. 

For the patch itself - I'm not sure it's needed, even if we don't
record the stack we'll have a tracker object and still detect the leak.
So printing the "unreliable refcount" message is not very precise. 
At least to me; Eric's opinion matters most.