Message-ID: <6b50a83e-acd7-4db3-ae9b-015ffad4f615@amazon.com>
Date: Fri, 16 Jan 2026 14:55:56 +0000
From: Nikita Kalyazin <kalyazin@...zon.com>
To: Ackerley Tng <ackerleytng@...gle.com>, "Kalyazin, Nikita"
	<kalyazin@...zon.co.uk>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "kvmarm@...ts.linux.dev"
	<kvmarm@...ts.linux.dev>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"kernel@...0n.name" <kernel@...0n.name>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, "linux-s390@...r.kernel.org"
	<linux-s390@...r.kernel.org>, "loongarch@...ts.linux.dev"
	<loongarch@...ts.linux.dev>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "corbet@....net"
	<corbet@....net>, "maz@...nel.org" <maz@...nel.org>, "oupton@...nel.org"
	<oupton@...nel.org>, "joey.gouly@....com" <joey.gouly@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>, "yuzenghui@...wei.com"
	<yuzenghui@...wei.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "luto@...nel.org"
	<luto@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>,
	"willy@...radead.org" <willy@...radead.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "david@...nel.org" <david@...nel.org>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "vbabka@...e.cz"
	<vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>, "surenb@...gle.com"
	<surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>, "ast@...nel.org"
	<ast@...nel.org>, "daniel@...earbox.net" <daniel@...earbox.net>,
	"andrii@...nel.org" <andrii@...nel.org>, "martin.lau@...ux.dev"
	<martin.lau@...ux.dev>, "eddyz87@...il.com" <eddyz87@...il.com>,
	"song@...nel.org" <song@...nel.org>, "yonghong.song@...ux.dev"
	<yonghong.song@...ux.dev>, "john.fastabend@...il.com"
	<john.fastabend@...il.com>, "kpsingh@...nel.org" <kpsingh@...nel.org>,
	"sdf@...ichev.me" <sdf@...ichev.me>, "haoluo@...gle.com" <haoluo@...gle.com>,
	"jolsa@...nel.org" <jolsa@...nel.org>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"jhubbard@...dia.com" <jhubbard@...dia.com>, "peterx@...hat.com"
	<peterx@...hat.com>, "jannh@...gle.com" <jannh@...gle.com>,
	"pfalcato@...e.de" <pfalcato@...e.de>, "shuah@...nel.org" <shuah@...nel.org>,
	"riel@...riel.com" <riel@...riel.com>, "ryan.roberts@....com"
	<ryan.roberts@....com>, "jgross@...e.com" <jgross@...e.com>,
	"yu-cheng.yu@...el.com" <yu-cheng.yu@...el.com>, "kas@...nel.org"
	<kas@...nel.org>, "coxu@...hat.com" <coxu@...hat.com>,
	"kevin.brodsky@....com" <kevin.brodsky@....com>, "maobibo@...ngson.cn"
	<maobibo@...ngson.cn>, "prsampat@....com" <prsampat@....com>,
	"mlevitsk@...hat.com" <mlevitsk@...hat.com>, "jmattson@...gle.com"
	<jmattson@...gle.com>, "jthoughton@...gle.com" <jthoughton@...gle.com>,
	"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>, "alex@...ti.fr"
	<alex@...ti.fr>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
	"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
	"chenhuacai@...nel.org" <chenhuacai@...nel.org>, "dev.jain@....com"
	<dev.jain@....com>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
	"hca@...ux.ibm.com" <hca@...ux.ibm.com>, "Jonathan.Cameron@...wei.com"
	<Jonathan.Cameron@...wei.com>, "palmer@...belt.com" <palmer@...belt.com>,
	"pjw@...nel.org" <pjw@...nel.org>, "shijie@...amperecomputing.com"
	<shijie@...amperecomputing.com>, "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
	"thuth@...hat.com" <thuth@...hat.com>, "wyihan@...gle.com"
	<wyihan@...gle.com>, "yang@...amperecomputing.com"
	<yang@...amperecomputing.com>, "vannapurve@...gle.com"
	<vannapurve@...gle.com>, "jackmanb@...gle.com" <jackmanb@...gle.com>,
	"aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>, "patrick.roy@...ux.dev"
	<patrick.roy@...ux.dev>, "Thomson, Jack" <jackabt@...zon.co.uk>, "Itazuri,
 Takahiro" <itazur@...zon.co.uk>, "Manwaring, Derek" <derekmn@...zon.com>,
	"Cali, Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v9 02/13] mm/gup: drop secretmem optimization from
 gup_fast_folio_allowed



On 15/01/2026 21:40, Ackerley Tng wrote:
> "Kalyazin, Nikita" <kalyazin@...zon.co.uk> writes:
> 
>> From: Patrick Roy <patrick.roy@...ux.dev>
>>
>> This drops an optimization in gup_fast_folio_allowed() where
>> secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is
>> enabled by default since commit b758fe6df50d ("mm/secretmem: make it on
>> by default"), so the secretmem check did not actually end up elided in
>> most cases anymore anyway.
>>
>> This is in preparation of the generalization of handling mappings where
>> direct map entries of folios are set to not present.  Currently,
>> mappings that match this description are secretmem mappings
>> (memfd_secret()).  Later, some guest_memfd configurations will also fall
>> into this category.
>>
>> Signed-off-by: Patrick Roy <patrick.roy@...ux.dev>
>> Acked-by: Vlastimil Babka <vbabka@...e.cz>
>> Signed-off-by: Nikita Kalyazin <kalyazin@...zon.com>
>> ---
>>   mm/gup.c | 11 +----------
>>   1 file changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index 95d948c8e86c..9cad53acbc99 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -2739,7 +2739,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>   {
>>        bool reject_file_backed = false;
>>        struct address_space *mapping;
>> -     bool check_secretmem = false;
>>        unsigned long mapping_flags;
>>
>>        /*
>> @@ -2751,14 +2750,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
> 
> Copying some lines the diff didn't contain:
> 
>          /*
>           * If we aren't pinning then no problematic write can occur. A long term
>           * pin is the most egregious case so this is the one we disallow.
>           */
>          if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) ==
>              (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
> 
> If we're pinning, can we already return true here? IIUC this function
> is passed a folio that is file-backed, and the check if (!mapping) is
> just there to catch the case where the mapping got truncated.

I have to admit that I am not comfortable with removing this check, 
unless someone says it's certainly alright.

> 
> Or should we wait for the check where the mapping got truncated? If so,
> then maybe we can move this "are we pinning" check to after this check
> and remove the reject_file_backed variable?

I can indeed move the pinning check to the end to remove the variable. 
I'd do it in a separate patch.

> 
>          /*
>           * The mapping may have been truncated, in any case we cannot determine
>           * if this mapping is safe - fall back to slow path to determine how to
>           * proceed.
>           */
>          if (!mapping)
>                  return false;
> 
> 
>>                reject_file_backed = true;
>>
>>        /* We hold a folio reference, so we can safely access folio fields. */
>> -
>> -     /* secretmem folios are always order-0 folios. */
>> -     if (IS_ENABLED(CONFIG_SECRETMEM) && !folio_test_large(folio))
>> -             check_secretmem = true;
>> -
>> -     if (!reject_file_backed && !check_secretmem)
>> -             return true;
>> -
>>        if (WARN_ON_ONCE(folio_test_slab(folio)))
>>                return false;
>>
>> @@ -2800,7 +2791,7 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>         * At this point, we know the mapping is non-null and points to an
>>         * address_space object.
>>         */
>> -     if (check_secretmem && secretmem_mapping(mapping))
>> +     if (secretmem_mapping(mapping))
>>                return false;
>>        /* The only remaining allowed file system is shmem. */
>>        return !reject_file_backed || shmem_mapping(mapping);
>> --
>> 2.50.1

Powered by blists - more mailing lists