From nobody Tue Jan 27 00:10:02 2026 Received: from fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com [3.75.33.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0D35347BC6; Mon, 26 Jan 2026 16:47:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=3.75.33.185 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769446049; cv=none; b=B5yKpRpZ+yHfji7ssDKrqp8vSc45dSXyFB5aDFs8miEKMjrSNWOoBT/AXNk4MkDG4ubR6DUQMNMZNsc72gMbQno0qmfImNs6JfyL3fGs6Bw6kTTNJm6sbe0rzy958HCR9RUszUG6JKqa0lP5sXAbEDcFfwYpJZXWFhFWla4XLS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769446049; c=relaxed/simple; bh=9TObX7tiC7VZqU3WbcdNCXdCs2JppBenzFSq+tte7Ak=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=gwkhj269DYpsvFLoNciLIsAg2sSSHvjhtLJEGH/x1GkJDY6H7yvSlFLatk4/2L58pTotneesgWFdRbAfj8xvix9wksKhFi7WnQQjXlb/kpLykfbk0IjZ3yFrpAGHAsc6QgIiu69prsW/d/wChFr6Ysj3fFc7i+ZEqwyw0c7qB/Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.co.uk; spf=pass smtp.mailfrom=amazon.co.uk; dkim=pass (2048-bit key) header.d=amazon.co.uk header.i=@amazon.co.uk header.b=PyI6S0PU; arc=none smtp.client-ip=3.75.33.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.co.uk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.co.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.co.uk header.i=@amazon.co.uk header.b="PyI6S0PU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazoncorp2; t=1769446046; x=1800982046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4FHpHY6AJ0hg5Jwwtw1W2IN5LouOY5p8WzE+ejVhd1U=; b=PyI6S0PUKEQkYf+noiFACf3aLXZ2kfzNraV9B67yBhlDqQ+oFsmBdA3B x7SK8nsTRbMdWtVq5dpM6LPhN4TsGc6vgNcMvpSXPHY6qLAM7IbEblZf1 uwFlq/6Tkw38+fGOfJ4vP56Bo4+LaVnLWa9cOxEODCaG2GlcIOsrmamrx aPibyuqDOM9Ul+Op4/68DZGsbom5GcFyecSul3WhmtEbysxzCpLgBqbU2 edkldgjrUSm6bBzvBtFXPNssZzgdCKHzFAJEczdNhq4751A2Jcu4BAv0M nunQwLosqaX9tUkCwDVrc9l84lAF0UCqyu45F4uxhctNZBxYLCJ9jlut6 Q==; X-CSE-ConnectionGUID: DMzACF5LSsKESVxEYLrHgw== X-CSE-MsgGUID: 3HCBPdKjQdySNhZmk4v6Lw== X-IronPort-AV: E=Sophos;i="6.21,255,1763424000"; d="scan'208";a="8453218" Received: from ip-10-6-6-97.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.6.97]) by internal-fra-out-007.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2026 16:47:24 +0000 Received: from EX19MTAEUA002.ant.amazon.com [54.240.197.232:7851] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.23.198:2525] with esmtp (Farcaster) id 08284e5c-c7d3-4f42-97a9-df05ddd14a97; Mon, 26 Jan 2026 16:47:23 +0000 (UTC) X-Farcaster-Flow-ID: 08284e5c-c7d3-4f42-97a9-df05ddd14a97 Received: from EX19D005EUB004.ant.amazon.com (10.252.51.126) by EX19MTAEUA002.ant.amazon.com (10.252.50.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Mon, 26 Jan 2026 16:47:23 +0000 Received: from EX19D005EUB003.ant.amazon.com (10.252.51.31) by EX19D005EUB004.ant.amazon.com (10.252.51.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.35; Mon, 26 Jan 2026 16:47:23 +0000 Received: from EX19D005EUB003.ant.amazon.com ([fe80::b825:becb:4b38:da0c]) by EX19D005EUB003.ant.amazon.com ([fe80::b825:becb:4b38:da0c%3]) with mapi id 15.02.2562.035; Mon, 26 Jan 2026 16:47:23 +0000 From: "Kalyazin, Nikita" To: "kvm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "bpf@vger.kernel.org" , "linux-kselftest@vger.kernel.org" , "kernel@xen0n.name" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "loongarch@lists.linux.dev" CC: "pbonzini@redhat.com" , "corbet@lwn.net" , "maz@kernel.org" , "oupton@kernel.org" , "joey.gouly@arm.com" , "suzuki.poulose@arm.com" , "yuzenghui@huawei.com" , "catalin.marinas@arm.com" , "will@kernel.org" , "seanjc@google.com" , "tglx@kernel.org" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "luto@kernel.org" , "peterz@infradead.org" , "willy@infradead.org" , "akpm@linux-foundation.org" , "david@kernel.org" , "lorenzo.stoakes@oracle.com" , "vbabka@suse.cz" , "rppt@kernel.org" , "surenb@google.com" , "mhocko@suse.com" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "martin.lau@linux.dev" , "eddyz87@gmail.com" , "song@kernel.org" , "yonghong.song@linux.dev" , "john.fastabend@gmail.com" , "kpsingh@kernel.org" , "sdf@fomichev.me" , "haoluo@google.com" , "jolsa@kernel.org" , "jgg@ziepe.ca" , "jhubbard@nvidia.com" , "peterx@redhat.com" , "jannh@google.com" , "pfalcato@suse.de" , "shuah@kernel.org" , "riel@surriel.com" , "ryan.roberts@arm.com" , "jgross@suse.com" , "yu-cheng.yu@intel.com" , "kas@kernel.org" , "coxu@redhat.com" , "kevin.brodsky@arm.com" , "ackerleytng@google.com" , "maobibo@loongson.cn" , "prsampat@amd.com" , "mlevitsk@redhat.com" , "jmattson@google.com" , "jthoughton@google.com" , "agordeev@linux.ibm.com" , "alex@ghiti.fr" , "aou@eecs.berkeley.edu" , "borntraeger@linux.ibm.com" , "chenhuacai@kernel.org" , "dev.jain@arm.com" , "gor@linux.ibm.com" , "hca@linux.ibm.com" , "palmer@dabbelt.com" , "pjw@kernel.org" , "shijie@os.amperecomputing.com" , "svens@linux.ibm.com" , "thuth@redhat.com" , "wyihan@google.com" , "yang@os.amperecomputing.com" , "Jonathan.Cameron@huawei.com" , "Liam.Howlett@oracle.com" , "urezki@gmail.com" , "zhengqi.arch@bytedance.com" , "gerald.schaefer@linux.ibm.com" , "jiayuan.chen@shopee.com" , "lenb@kernel.org" , "osalvador@suse.de" , "pavel@kernel.org" , "rafael@kernel.org" , "vannapurve@google.com" , "jackmanb@google.com" , "aneesh.kumar@kernel.org" , "patrick.roy@linux.dev" , "Thomson, Jack" , "Itazuri, Takahiro" , "Manwaring, Derek" , "Cali, Marco" , "Kalyazin, Nikita" Subject: [PATCH v10 03/15] mm/gup: drop secretmem optimization from gup_fast_folio_allowed Thread-Topic: [PATCH v10 03/15] mm/gup: drop secretmem optimization from gup_fast_folio_allowed Thread-Index: AQHcjuNxPEuJ1xEMVkO51n3oGxbE+g== Date: Mon, 26 Jan 2026 16:47:22 +0000 Message-ID: <20260126164445.11867-4-kalyazin@amazon.com> References: <20260126164445.11867-1-kalyazin@amazon.com> In-Reply-To: <20260126164445.11867-1-kalyazin@amazon.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Patrick Roy This drops an optimization in gup_fast_folio_allowed() where secretmem_mapping() was only called if CONFIG_SECRETMEM=3Dy. 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 Acked-by: Vlastimil Babka Acked-by: David Hildenbrand (Red Hat) Signed-off-by: Nikita Kalyazin --- 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 *foli= o, unsigned int flags) { bool reject_file_backed =3D false; struct address_space *mapping; - bool check_secretmem =3D false; unsigned long mapping_flags; =20 /* @@ -2751,14 +2750,6 @@ static bool gup_fast_folio_allowed(struct folio *fol= io, unsigned int flags) reject_file_backed =3D true; =20 /* 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 =3D true; - - if (!reject_file_backed && !check_secretmem) - return true; - if (WARN_ON_ONCE(folio_test_slab(folio))) return false; =20 @@ -2800,7 +2791,7 @@ static bool gup_fast_folio_allowed(struct folio *foli= o, 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); --=20 2.50.1