[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <700c5a5f-3128-4671-99aa-827ca73f5cdf@kernel.org>
Date: Mon, 20 Oct 2025 11:04:26 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Brendan Jackman <jackmanb@...gle.com>, David Hildenbrand <david@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johannes Weiner <hannes@...xchg.org>, Julia Lawall <Julia.Lawall@...ia.fr>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Michal Hocko
<mhocko@...e.com>, Suren Baghdasaryan <surenb@...gle.com>,
Zi Yan <ziy@...dia.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *
On 20. 10. 25, 10:54, Vlastimil Babka wrote:
>>> Most of them shouldn't be using get_free_pages() at all, they should be
>>> using kmalloc().
>
> Changing to kmalloc() would have to be careful, what if the callers rely on
> doing e.g. get_page() later. It would however be useful to dintinguish "I
> want a page-sized buffer" (note that it's guaranteed to be aligned by
> kmalloc() these days, which it wasn't in 2015) from "I really want a page".
> But many of the latter cases maybe want a struct page then and are using
> alloc_pages()?
FTR, tty appears NOT to need any of the specialties, so k*alloc()
conversion looks sensible to me... OK, I can re-revisit that and do the
work, but give me some time :). (Which means 1/3 from this series won't
be needed.)
thanks,
--
js
suse labs
Powered by blists - more mailing lists