From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9FD5C4829A for ; Tue, 13 Feb 2024 14:08:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D9FD6B0085; Tue, 13 Feb 2024 09:08:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6899F6B0098; Tue, 13 Feb 2024 09:08:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5529B6B0099; Tue, 13 Feb 2024 09:08:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4610F6B0085 for ; Tue, 13 Feb 2024 09:08:57 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E2F71160C52 for ; Tue, 13 Feb 2024 14:08:56 +0000 (UTC) X-FDA: 81786961872.04.0D8E1F8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id E558914000B for ; Tue, 13 Feb 2024 14:08:54 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=koWf2hZx; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707833335; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YHjtr+GXnOn8BIP3JJElHlWY6SaRJB9zT+dJz+7SJXI=; b=xJgiwKON3CFRRRGVoCY3598amvJzfawlKSyZ2L0xjaQhtCFcndNIHb5bva207meWd64AVD z80G+WRDTt3EVkjuGOAn3ve27fp96icHTMz4xaJ++JLdVaDMizM8/ZnCCYijcJvLQnXcsQ yrCL/fJZ5hukpXxo5pX0ZNIj9S1uygU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=koWf2hZx; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707833335; a=rsa-sha256; cv=none; b=D9zqNceYciLwMFtnB6ZWf2XCTBYLRf8nKrvcmw/LqJDBM7M1VzOQcwGCw0FsyyFYDRQbUv lTokYD9ID6dFb+3oZVQ41Lnphe6CY41SHqJclQkf3bhm1J8t0LCwkSnqy5HkVBpLeLoAsG s4ndPAAC8f4dxS1wzCwSVoOzTkkBWng= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EF2B2614C3 for ; Tue, 13 Feb 2024 14:08:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF08EC433F1 for ; Tue, 13 Feb 2024 14:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707833333; bh=TsHGewO4d1sZ/2Wke7Alzolt9Fz7V7TAkLcK4gqK7t4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=koWf2hZxawo8hiCpL71n8XZjAay/QdFoGklELgdaVkkmf9g6zXNDc15ulBWs7jdlO 3CzaiB4qaD5emYvwdpc+JtmTAkpoDNHd7EZlTy3sm6tsLqWyrp9ahoZH/GEYNj/7l/ d3Fq+5uW/cL9BIW8sESeaGJPWyrwSysDwUYze4iGEFd6E716AnCSzjhDzHutmZSF9Z ie8sqjGPAaikYZtY8g1sYgE/IF20jrmnl6ciahfmRFAieiDkJ5D2VifNU5rbwKmpjN iuYiL/A0Th4lKUMsrrBq82tuEJzl6JICJkC0CaJeOP/psV+oVHdeTGvj/3VjFIoqd3 P8L3i1sM7Sj6Q== Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5114fa38434so4824816e87.0 for ; Tue, 13 Feb 2024 06:08:53 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCV8pROknvsHGD5w8UPMkJfTTcXJiK+qK2ruRRcUdJZ8iOXh4Qa3BPcxfCyiLUErxHB1Wtc8evZmn9VQUAIhbxw6owM= X-Gm-Message-State: AOJu0YwVLNFTsBE87scUxhCAzbQto5JJDvZWQoEAct9hjYik1zKNdwOu wqiT/CDuwN3y4got2al3YiKEEm0gg/trtMaMywjiFCRSf/jSN9pMuXboqsCPEkajtlQ+I1WAjIL N4/4uawnvs6VV2D0f7fDFYCQqARA= X-Google-Smtp-Source: AGHT+IERJ2V7pHlFw7AMG1Pn749RuDSeXLXoZ89U8U4kBT5ImaY5HxngrTnEeqgTjll4w3fZWaJ2CtEbeq0i1i4Nh6M= X-Received: by 2002:ac2:46da:0:b0:511:96d0:5ae1 with SMTP id p26-20020ac246da000000b0051196d05ae1mr1799024lfo.40.1707833330972; Tue, 13 Feb 2024 06:08:50 -0800 (PST) MIME-Version: 1.0 References: <20240202080756.1453939-1-ryan.roberts@arm.com> <20240202080756.1453939-20-ryan.roberts@arm.com> <64395ae4-3a7d-45dd-8f1d-ea6b232829c5@arm.com> <41499621-482f-455b-9f68-b43ea8052557@redhat.com> <1d302d7a-50ab-4ab4-b049-75ed4a71a87d@arm.com> <99e2a92c-f2a2-4e1e-8ce2-08caae2cb7e4@redhat.com> <64b872bd-4b12-4dbd-b043-1ad11aeaa19a@redhat.com> <3de2130b-9f0f-4a11-ac06-7bf814de641c@arm.com> In-Reply-To: From: Ard Biesheuvel Date: Tue, 13 Feb 2024 15:08:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 19/25] arm64/mm: Wire up PTE_CONT for user mappings To: David Hildenbrand Cc: Ryan Roberts , Mark Rutland , Catalin Marinas , Will Deacon , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E558914000B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: jxai1d84dfdtwrwu8y6ekfih3ky4atfo X-HE-Tag: 1707833334-844812 X-HE-Meta: U2FsdGVkX19ASPSnFcQNsdWyCYDTGfCoiOmfxDXVwM/rNabzSB8B1KPj08+yP5ubGiGmmBsnWVfGAYLQCmvlCwS6FizpWv0X6p0ZzvLXZdhSvo/Wb02sc9aZRMCmHpGYl9ZFMt9jf6aHpfA9JQHPItSeupVxv3cvXLU8ka8rRQbF9cFfQ0O3ap7faU8yuQSgE7MQKhKbvTp1+wuKd42/zrEsWXGndjQsJ+NUSPoQAcJ+gSoNe5qF5GHo760Zclnkc1azPxUHD8hM73tb0gdtSkI608MjwkHjpG4Hu/hxsk8Fs6M1EJZ5CDrq+ggnBhNzNibk7GI5v9jVnw0oNmOEZ46YU9p/XtCKgOSZH/Is4L1BepcAO2ZCCXLEizlkJu6Q8rsDxa4MgnAV5YPToQXx7ZuyPSz+yM0rAN2fqoOO/6EzsIfZXKc6K0MDLclHacTyOD36tpSg397FAvbRFrGaC1Of2xVjQoGoxmYfwr3ftFqDEs0irBB0ZaCfA25kHB0/aAQ3WLFM6HSeRUUQ3O7LFJQ8HYLubWsoGzU98AUgLwa0KQjUW5EZ177awYKIhua82EkDdx3f7Mm+X/G8kdwZpf5YttLZV5jE/Qc/i80iX5HZTR/frxVQWvIwi8A8kUqTOYcHtof4PcXRahBaUdRovvEnlM7atIYU+aFEBvBjkUPIGC/9UeoT+dHZ+S5CMjzR8wAU9oJcxKIGwuJhOTX3o7kmUI+FZUgQK/RY9LKk2RPSH74HOwDyH5yt9F5cNuFoLtzdzDyK+KFWLOAFXBQ5g1oRx4FEgI3bMyRANaKCPvgMTdfQSCIKlTUjpYKGW7KcNFt2cJa/fXEQhNg3pZkVqD/Rec7YZKUZs5t4WmIbEJDhQVsml33Sbvzd0156r3RVYKAYJbBSm42cWlsOYFB6FvtoGWENZnFbDSPUO4NHqp88NaNpwCf6X5BoKf1HW7WNE6whi/oFj8xZYYd9tmB 0+0rC1E8 0KyF1DMXrAONc2spEsUzqyxljBfuk4OGY52KJZmzP5Y/1kz5wTSliCA2xCqa19V8hOg54AH6p7NiqmlcTJI90P/Rdi72O8bU4W1xTjxgvCKEL3Tmtp/Uhz1e4MVfSClCcT9S0JN3UQUkXCZdG4rGShDksi4hszG61W+E8L3sooKBQhT1QE9+uhtB7YjiJbD1asi0bE+khePlzBV+9zzJMYPHHJGSeEGXUI/j3Cb9LAcaNwnKj9ghxqD1DWmi/O767b3/Ylby6B86A6cEE7KXmvNVBN6JQF73OQbrv0CwXGD7fxfWMPYzKTxV1/laPoZez9hH3VCMVEZHJf3WWpv0Wv/CAD/gaUK0cN0wlI2UGvtECn7IK36pDX1hYuU+SaYfYToupamrD8s8wxOES0Sgh/t13SJb4I808GbJs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 13 Feb 2024 at 15:05, David Hildenbrand wrote: > > On 13.02.24 15:02, Ryan Roberts wrote: > > On 13/02/2024 13:45, David Hildenbrand wrote: > >> On 13.02.24 14:33, Ard Biesheuvel wrote: > >>> On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote: > >>>> > >>>> On 13/02/2024 13:13, David Hildenbrand wrote: ... > >>>>> Just a thought, you could have a is_efi_mm() function that abstracts all that. > >>>>> > >>>>> diff --git a/include/linux/efi.h b/include/linux/efi.h > >>>>> index c74f47711f0b..152f5fa66a2a 100644 > >>>>> --- a/include/linux/efi.h > >>>>> +++ b/include/linux/efi.h > >>>>> @@ -692,6 +692,15 @@ extern struct efi { > >>>>> > >>>>> extern struct mm_struct efi_mm; > >>>>> > >>>>> +static inline void is_efi_mm(struct mm_struct *mm) > >>>>> +{ > >>>>> +#ifdef CONFIG_EFI > >>>>> + return mm == &efi_mm; > >>>>> +#else > >>>>> + return false; > >>>>> +#endif > >>>>> +} > >>>>> + > >>>>> static inline int > >>>>> efi_guidcmp (efi_guid_t left, efi_guid_t right) > >>>>> { > >>>>> > >>>>> > >>>> > >>>> That would definitely work, but in that case, I might as well just check for it > >>>> in mm_is_user() (and personally I would change the name to mm_is_efi()): > >>>> > >>>> > >>>> static inline bool mm_is_user(struct mm_struct *mm) > >>>> { > >>>> return mm != &init_mm && !mm_is_efi(mm); > >>>> } > >>>> > >>>> Any objections? > >>>> > >>> > >>> Any reason not to use IS_ENABLED(CONFIG_EFI) in the above? The extern > >>> declaration is visible to the compiler, and any references should > >>> disappear before the linker could notice that efi_mm does not exist. > >>> > >> > >> Sure, as long as the linker is happy why not. I'll let Ryan mess with that :) > > > > I'm not sure if you are suggesting dropping the mm_is_efi() helper and just use > > IS_ENABLED(CONFIG_EFI) in mm_is_user() to guard efi_mm, or if you are suggesting > > using IS_ENABLED(CONFIG_EFI) in mm_is_efi() instead of the ifdefery? > > > > The former was what I did initially; It works great, but I didn't like that I > > was introducing a new code dependecy between efi and arm64 (nothing else outside > > of efi references efi_mm). > > > > So then concluded that it is safe to not worry about efi_mm (thanks for your > > confirmation). But then David wanted a VM_WARN check, which reintroduces the > > code dependency. So he suggested the mm_is_efi() helper to hide that... This is > > all starting to feel circular... > > I think Ard meant that inside mm_is_efi(), we could avoid the #ifdef and > simply use IS_ENABLED(). > Yes. static inline void mm_is_efi(struct mm_struct *mm) { return IS_ENABLED(CONFIG_EFI) && mm == &efi_mm; }