linux-kernel - Re: [RFC PATCH] mm: avoid clearing user movable page twice with init_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <be1a1c1b-4630-41e2-a79a-57447851017d@suse.cz>
Date: Tue, 8 Oct 2024 14:57:48 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Zi Yan <ziy@...dia.com>, David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, Alexander Potapenko <glider@...gle.com>,
 Kees Cook <keescook@...omium.org>, Andrew Morton
 <akpm@...ux-foundation.org>, "Matthew Wilcox (Oracle)"
 <willy@...radead.org>, Miaohe Lin <linmiaohe@...wei.com>,
 Kefeng Wang <wangkefeng.wang@...wei.com>, John Hubbard
 <jhubbard@...dia.com>, "Huang, Ying" <ying.huang@...el.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm: avoid clearing user movable page twice with
 init_on_alloc=1

On 10/8/24 13:52, Zi Yan wrote:
> On 8 Oct 2024, at 4:26, David Hildenbrand wrote:
> 
>>
>> I remember we discussed that in the past and that we do *not* want to sprinkle these CONFIG_INIT_ON_ALLOC_DEFAULT_ON checks all over the kernel.
>>
>> Ideally, we'd use GFP_ZERO and have the buddy just do that for us? There is the slight chance that we zero-out when we're not going to use the allocated folio, but ... that can happen either way even with the current code?
> 
> I agree that putting CONFIG_INIT_ON_ALLOC_DEFAULT_ON here is not ideal, but

Create some nice inline wrapper for the test and it will look less ugly? :)

> folio_zero_user() uses vmf->address to improve cache performance by changing
> subpage clearing order. See commit c79b57e462b5 ("mm: hugetlb: clear target
> sub-page last when clearing huge page”). If we use GFP_ZERO, we lose this
> optimization. To keep it, vmf->address will need to be passed to allocation
> code. Maybe that is acceptable?

I'd rather not change the page allocation code for this...

> Best Regards,
> Yan, Zi