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;
Message-ID: <c17ff3ff-b3af-fea2-f75e-68cefbc90636@I-love.SAKURA.ne.jp>
Date:   Tue, 30 May 2023 18:51:32 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH] ref_tracker: add stack_depot_save() failure handling to
 ref_tracker_alloc()
Content-Language: en-US
To:     Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>
Cc:     Dmitry Vyukov <dvyukov@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        LKML <linux-kernel@vger.kernel.org>
References: <5fa8dfeb-8eb6-0de0-a335-e0b4336c29e0@I-love.SAKURA.ne.jp>
 <20230529190526.65d13658@kernel.org>
 <CANn89iLpeeJN=QA80c1wZZ0TB+ptzKN_Hq4Cf27C-URvKKbd2Q@mail.gmail.com>
From:   Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
In-Reply-To: <CANn89iLpeeJN=QA80c1wZZ0TB+ptzKN_Hq4Cf27C-URvKKbd2Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2023/05/30 16:22, Eric Dumazet wrote:
>>> Therefore, assume that stack_depot_save(GFP_KERNEL | __GFP_NOFAIL) from
>>> ref_tracker_alloc() can silently fail, and emit "unreliable refcount
>>> tracker." message.
>
> Note: I never assumed stack_depot_save() would enforce/use NOFAIL.

Hmm, I misread this function.

	if (gfp & __GFP_DIRECT_RECLAIM)
		gfp_mask |= __GFP_NOFAIL; // Or'ing to "gfp_mask" than "gfp".
	*trackerp = tracker = kzalloc(sizeof(*tracker), gfp_mask); // <= This is "gfp_mask".
	tracker->alloc_stack_handle = stack_depot_save(entries, nr_entries, gfp); // <= This is "gfp".

So, stack_depot_save(GFP_KERNEL | __GFP_NOFAIL) is not happening.

Then, question becomes whether we want tracker->alloc_stack_handle != NULL or not.
If tracker->alloc_stack_handle == NULL is still useful, this patch will be useless...