[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6d0156b-5f65-9426-f27f-8a1af59bffa0@google.com>
Date: Tue, 11 Nov 2025 23:55:17 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Deepanshu Kartikey <kartikey406@...il.com>
cc: Hugh Dickins <hughd@...gle.com>, Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>, David Hildenbrand <david@...hat.com>,
Vivek Kasireddy <vivek.kasireddy@...el.com>, baolin.wang@...ux.alibaba.com,
akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
syzbot+f64019ba229e3a5c411b@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/memfd: clear hugetlb pages on allocation
On Wed, 12 Nov 2025, Deepanshu Kartikey wrote:
> Hi Hugh,
>
> Thank you for the quick review and for looping in the hugetlb maintainers!
>
> You raise good points about the approach. I chose explicit zeroing in
> memfd_alloc_folio() because hugetlb_reserve_pages() can allocate pages
> without seeing the __GFP_ZERO flag, but I'm happy to revise if the
> hugetlb maintainers prefer a different approach.
>
> I'll add the Fixes: 89c1905d9c14 tag and Cc: stable in v2.
>
> Should I send v2 now with just the tag added, or wait for feedback from
> Muchun/Oscar/David on the overall approach first?
No need for a v2 at this stage - Andrew is very much more than capable
of adding in that Fixes tag and Cc stable if he's inclined to grab your
patch for mm.git in the interim, but let's wait to hear from hugetlb
folks before finalizing (I expect they'll say __GFP_ZERO is no good).
Hugh
Powered by blists - more mailing lists