From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Zi Yan <ziy@nvidia.com>, "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>,
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
Subject: Re: [PATCH v3] mm/page_alloc: clear page->private in free_pages_prepare()
Date: Tue, 10 Feb 2026 09:20:04 +0800 [thread overview]
Message-ID: <e69270cf-dac1-448c-ace8-3f789e5cdc6e@linux.alibaba.com> (raw)
In-Reply-To: <72534BCC-2581-4BFA-B3BC-2CC6FF1B1E7A@nvidia.com>
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.
next prev parent reply other threads:[~2026-02-10 1:20 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABXGCs03XcXt5GDae7d74ynC6P6G2gLw3ZrwAYvSQ3PwP0mGXA@mail.gmail.com>
2026-02-06 17:40 ` [PATCH] mm/page_alloc: clear page->private in split_page() for tail pages Mikhail Gavrilov
2026-02-06 18:08 ` Zi Yan
2026-02-06 18:21 ` Mikhail Gavrilov
2026-02-06 18:29 ` Zi Yan
2026-02-06 18:33 ` Zi Yan
2026-02-06 19:58 ` Zi Yan
2026-02-06 20:49 ` Zi Yan
2026-02-06 22:16 ` Mikhail Gavrilov
2026-02-06 22:37 ` Mikhail Gavrilov
2026-02-06 23:06 ` Zi Yan
2026-02-07 3:28 ` Zi Yan
2026-02-07 14:25 ` Mikhail Gavrilov
2026-02-07 14:32 ` Zi Yan
2026-02-07 15:03 ` Mikhail Gavrilov
2026-02-07 15:06 ` Zi Yan
2026-02-07 15:37 ` [PATCH v2] mm/page_alloc: clear page->private in free_pages_prepare() Mikhail Gavrilov
2026-02-07 16:12 ` Zi Yan
2026-02-07 17:36 ` [PATCH v3] " Mikhail Gavrilov
2026-02-07 22:02 ` David Hildenbrand (Arm)
2026-02-07 22:08 ` David Hildenbrand (Arm)
2026-02-09 11:17 ` Vlastimil Babka
2026-02-09 15:46 ` David Hildenbrand (Arm)
2026-02-09 16:00 ` Zi Yan
2026-02-09 16:03 ` David Hildenbrand (Arm)
2026-02-09 16:05 ` Zi Yan
2026-02-09 16:06 ` David Hildenbrand (Arm)
2026-02-09 16:08 ` Zi Yan
2026-02-07 23:00 ` Zi Yan
2026-02-09 16:16 ` David Hildenbrand (Arm)
2026-02-09 16:20 ` David Hildenbrand (Arm)
2026-02-09 16:33 ` Zi Yan
2026-02-09 17:36 ` David Hildenbrand (Arm)
2026-02-09 17:44 ` Zi Yan
2026-02-09 19:39 ` David Hildenbrand (Arm)
2026-02-09 19:42 ` Zi Yan
2026-02-10 1:20 ` Baolin Wang [this message]
2026-02-10 2:12 ` Zi Yan
2026-02-10 2:25 ` Baolin Wang
2026-02-10 2:32 ` Zi Yan
2026-02-09 19:46 ` David Hildenbrand (Arm)
2026-02-09 11:11 ` [PATCH v2] " Vlastimil Babka
2026-02-06 18:24 ` [PATCH] mm/page_alloc: clear page->private in split_page() for tail pages Kairui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e69270cf-dac1-448c-ace8-3f789e5cdc6e@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jackmanb@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=npiggin@gmail.com \
--cc=ryncsn@gmail.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.