From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EB7E7262A; Tue, 10 Feb 2026 01:20:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770686411; cv=none; b=oVQDh34F1FujBSCmCnC1eo6v6M3SD3TYhpe2HLBgG2YpDJPjCAbYTNNluRBnmZjq3vIVSDfLzAzU7ZunXbxVlLWHFlkjSjvOd2Dljz2KAPMBFxUe0r3tCbMcRqdcLn0mHslh885FgVWknO3UmBC9NHwRXn0HJV7ZWSPlktIv/C4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770686411; c=relaxed/simple; bh=KQDMo6KDE8bY9om2BIOOP4wysK63lPkaFonb63R/kcc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qtj0VcXBxq7JEfpiPk8/MwWiwkyRbgLGd6wDItO1U3ZZTcdKndBHEms4qD6UJ2a7Dnx8+/f9Et2fTOqbSi0s5m4AKau6Wl89eEUGs99wPDLD2qjMDNtD4WhebKt4STQ0kKGjjZw1iiwRAJHWAqH7G//aPoPklQA5L37qVh84+NQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=C6QebXQ6; arc=none smtp.client-ip=115.124.30.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="C6QebXQ6" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1770686406; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=cN85VGoE32TAaBeuh7trX4TvvDZc5iL4HxTbBbIYYCc=; b=C6QebXQ6fNMh2yrMD4tomXEcyMyuk52FjdP05uOIaIM8FejLaa2ZMRSL/XyBG1b3O0mxf+Z69GRFUiDRRJy/U+838tEfbWsxnE9w42Ho46agRXLnilyb4B+s0+JWGqPx0sN4NutrXRwCZGdhNtkKhqMuOOK6LZBAaxltxf2BQJo= Received: from 30.74.144.109(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wyx9JBp_1770686404 cluster:ay36) by smtp.aliyun-inc.com; Tue, 10 Feb 2026 09:20:05 +0800 Message-ID: Date: Tue, 10 Feb 2026 09:20:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm/page_alloc: clear page->private in free_pages_prepare() To: Zi Yan , "David Hildenbrand (Arm)" Cc: Mikhail Gavrilov , linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, npiggin@gmail.com, linux-kernel@vger.kernel.org, kasong@tencent.com, hughd@google.com, chrisl@kernel.org, ryncsn@gmail.com, stable@vger.kernel.org, willy@infradead.org References: <209207FE-D3A9-4BE2-8DA7-9BE38A19F387@nvidia.com> <20260207173615.146159-1-mikhail.v.gavrilov@gmail.com> <0BC1D792-80CA-4E60-AEA0-187F73BD4723@nvidia.com> <22431471-b569-4ade-9881-387debada00b@kernel.org> <91F2E741-5473-4D34-ADA1-C9E6EDCBF5E0@nvidia.com> <546b200d-5b70-4db4-99f1-f50f6a343c10@kernel.org> <3E055DAD-647A-456B-9230-4DD2574D4E8E@nvidia.com> <4a759288-baf9-4fe6-9d16-034edf6615f0@kernel.org> <72534BCC-2581-4BFA-B3BC-2CC6FF1B1E7A@nvidia.com> From: Baolin Wang In-Reply-To: <72534BCC-2581-4BFA-B3BC-2CC6FF1B1E7A@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/10/26 3:42 AM, Zi Yan wrote: > On 9 Feb 2026, at 14:39, David Hildenbrand (Arm) wrote: > >> On 2/9/26 18:44, Zi Yan wrote: >>> On 9 Feb 2026, at 12:36, David Hildenbrand (Arm) wrote: >>> >>>> On 2/9/26 17:33, Zi Yan wrote: >>>>> >>>>> >>>>> I agree. Silently fixing non zero ->private just moves the work/responsibility >>>>> from users to core mm. They could do better. :) >>>>> >>>>> We can have a patch or multiple patches to fix users do not zero ->private >>>>> when freeing a page and add the patch below. >>>> >>>> Do we know roughly which ones don't zero it out? >>> >>> So far based on [1], I found: >>> >>> 1. shmem_swapin_folio() in mm/shmem.c does not zero ->swap.val (overlapping >>> with private); After Kairui’s series [1], the shmem part looks good to me. As we no longer skip the swapcache now, we shouldn’t clear the ->swap.val of a swapcache folio if failed to swap-in. [1]https://lore.kernel.org/all/20251219195751.61328-1-ryncsn@gmail.com/T/#mcba8a32e1021dc28ce1e824c9d042dca316a30d7 >>> 2. __free_slab() in mm/slub.c does not zero ->inuse, ->objects, ->frozen >>> (overlapping with private). >>> >>> Mikhail found ttm_pool_unmap_and_free() in drivers/gpu/drm/ttm/ttm_pool.c >>> does not zero ->private, which stores page order.