All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Zi Yan <ziy@nvidia.com>
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: Mon, 9 Feb 2026 17:16:22 +0100	[thread overview]
Message-ID: <bc0b6d03-4309-463d-a112-aae57cee335d@kernel.org> (raw)
In-Reply-To: <0BC1D792-80CA-4E60-AEA0-187F73BD4723@nvidia.com>

>> I recall that freeing pages with page->private set was allowed. Although
>> I once wondered whether we should actually change that.
> 
> But if that is allowed, we can end up with tail page's private non zero,
> because that free page can merge with a lower PFN buddy and its ->private
> is not reset. See __free_one_page().

Right. Or someone could use page->private on tail pages and free non-zero ->private that way.

[...]

> 
> For the issue reported by Mikhail[2], the page comes from vmalloc(), so it will not be split.
> For other cases, a page/folio needs to be compound to be splittable and prep_compound_tail()
> sets all tail page's private to 0. So that check is not that useful.

Thanks.

> 
> And the issue we are handling here is non compound high order page allocation. No one is
> clearing ->private for all pages right now.

Right.

> 
> OK, I think we want to decide whether it is OK to have a page with set ->private at
> page free time.

Right. And whether it is okay to have any tail->private be non-zero.

> If no, we can get this patch in and add a VM_WARN_ON_ONCE(page->private)
> to catch all violators. If yes, we can use Mikhail's original patch, zeroing ->private
> in split_page() and add a comment on ->private:
> 
> 1. for compound page allocation, prep_compound_tail() is responsible for resetting ->private;
> 2. for non compound high order page allocation, split_page() is responsible for resetting ->private.

Ideally, I guess, we would minimize the clearing of the ->private fields.

If we could guarantee that *any* pages in the buddy have ->private clear, maybe
prep_compound_tail() could stop clearing it (and check instead).

So similar to what Vlasta said, maybe we want to (not check but actually clear):


diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e4104973e22f..4960a36145fe 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1410,6 +1410,7 @@ __always_inline bool free_pages_prepare(struct page *page,
                                 }
                         }
                         (page + i)->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
+                       set_page_private(page + i, 0);
                 }
         }
         if (folio_test_anon(folio)) {


And the try removing any other unnecessary clearing (like in prep_compound_tail()).


-- 
Cheers,

David


  reply	other threads:[~2026-02-09 16:16 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) [this message]
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
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=bc0b6d03-4309-463d-a112-aae57cee335d@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chrisl@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.