Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 29 May 2023 19:05:26 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc:     Eric Dumazet <edumazet@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ref_tracker: add stack_depot_save() failure handling to
 ref_tracker_alloc()
Message-ID: <20230529190526.65d13658@kernel.org>
In-Reply-To: <5fa8dfeb-8eb6-0de0-a335-e0b4336c29e0@I-love.SAKURA.ne.jp>
References: <5fa8dfeb-8eb6-0de0-a335-e0b4336c29e0@I-love.SAKURA.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@vger. 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.