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 0F5AFD42B85 for ; Tue, 12 Nov 2024 14:49:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91A156B00A0; Tue, 12 Nov 2024 09:49:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A19B6B00B8; Tue, 12 Nov 2024 09:49:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F3946B00C1; Tue, 12 Nov 2024 09:49:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4982B6B00A0 for ; Tue, 12 Nov 2024 09:49:14 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E7A21401D7 for ; Tue, 12 Nov 2024 14:49:13 +0000 (UTC) X-FDA: 82777724526.30.7004A15 Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) by imf04.hostedemail.com (Postfix) with ESMTP id B79F440013 for ; Tue, 12 Nov 2024 14:48:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=UXrVeWYI; spf=pass (imf04.hostedemail.com: domain of "prvs=0392ce917=roypat@amazon.co.uk" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=0392ce917=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731422897; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jmAWYVWTItYY6sYiriVLXoFyHZtABKNORDlLDv0YA8o=; b=e75CFfSTu0Ta+Lw3fKENHC4AmDd1EStMWtaOkYxetLmUCXt8+wC1JXu9sFFOllYGcexwXD Vov5hbzNodOq4U/dG64SfumbPpBoHBJNWaY9yRLavcMHR5vxfNynk5iUuSCebKbDdRlQeA 9MZxMtAU/UsxE2oUKYUux29GiHxepS4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731422897; a=rsa-sha256; cv=none; b=2N+nIJWtC6vNnu5Aq7enAHPOS3Oy5ppe6UnCVTqnAFzBDFZmRX7dhQ8OIQlxWLbQy6pqMM tMo8kp/znPRW6/BHnrLl73J7yJ33VMkZkCfZweu8dOsnNwwh94ekGMHTkZmUbHdS03b5oJ Ha8pFea2vNVmphM+YjqPcoZAQa0Twyw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=UXrVeWYI; spf=pass (imf04.hostedemail.com: domain of "prvs=0392ce917=roypat@amazon.co.uk" designates 207.171.190.10 as permitted sender) smtp.mailfrom="prvs=0392ce917=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1731422952; x=1762958952; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=jmAWYVWTItYY6sYiriVLXoFyHZtABKNORDlLDv0YA8o=; b=UXrVeWYInzuGE/UWjF5JE2ASMqWuu2B1GqdN2+KVdccPWrmiIvRdvtDP KQUIOXbCs+k38n1wQwKKf7+Gnh934HP2+T7wBs9BiGIpJr5FHgUs9VgbR SnNiFeEU8uMFNMB7bq76hx1Z2IgJfKuqIT/fhBnFHSm6E8FwtCT8Jp2iG 4=; X-IronPort-AV: E=Sophos;i="6.12,148,1728950400"; d="scan'208";a="384565955" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Nov 2024 14:49:07 +0000 Received: from EX19MTAEUB002.ant.amazon.com [10.0.10.100:13328] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.18.131:2525] with esmtp (Farcaster) id 10c75058-a729-46eb-ac89-a0cf40349664; Tue, 12 Nov 2024 14:49:05 +0000 (UTC) X-Farcaster-Flow-ID: 10c75058-a729-46eb-ac89-a0cf40349664 Received: from EX19D030EUC001.ant.amazon.com (10.252.61.228) by EX19MTAEUB002.ant.amazon.com (10.252.51.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Tue, 12 Nov 2024 14:48:58 +0000 Received: from EX19MTAUEB002.ant.amazon.com (10.252.135.47) by EX19D030EUC001.ant.amazon.com (10.252.61.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Tue, 12 Nov 2024 14:48:58 +0000 Received: from email-imr-corp-prod-pdx-all-2c-619df93b.us-west-2.amazon.com (10.124.125.2) by mail-relay.amazon.com (10.252.135.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34 via Frontend Transport; Tue, 12 Nov 2024 14:48:57 +0000 Received: from [127.0.0.1] (dev-dsk-roypat-1c-dbe2a224.eu-west-1.amazon.com [172.19.88.180]) by email-imr-corp-prod-pdx-all-2c-619df93b.us-west-2.amazon.com (Postfix) with ESMTPS id 842D1402F3; Tue, 12 Nov 2024 14:48:49 +0000 (UTC) Message-ID: Date: Tue, 12 Nov 2024 14:48:48 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 1/6] arch: introduce set_direct_map_valid_noflush() To: Vlastimil Babka , David Hildenbrand , , , , , , , , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20241030134912.515725-1-roypat@amazon.co.uk> <20241030134912.515725-2-roypat@amazon.co.uk> <440b2682-dbfb-4a5c-927c-2397413a7f9c@suse.cz> From: Patrick Roy Content-Language: en-US Autocrypt: addr=roypat@amazon.co.uk; keydata= xjMEY0UgYhYJKwYBBAHaRw8BAQdA7lj+ADr5b96qBcdINFVJSOg8RGtKthL5x77F2ABMh4PN NVBhdHJpY2sgUm95IChHaXRodWIga2V5IGFtYXpvbikgPHJveXBhdEBhbWF6b24uY28udWs+ wpMEExYKADsWIQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbAwULCQgHAgIiAgYVCgkI CwIEFgIDAQIeBwIXgAAKCRBVg4tqeAbEAmQKAQC1jMl/KT9pQHEdALF7SA1iJ9tpA5ppl1J9 AOIP7Nr9SwD/fvIWkq0QDnq69eK7HqW14CA7AToCF6NBqZ8r7ksi+QLOOARjRSBiEgorBgEE AZdVAQUBAQdAqoMhGmiXJ3DMGeXrlaDA+v/aF/ah7ARbFV4ukHyz+CkDAQgHwngEGBYKACAW IQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbDAAKCRBVg4tqeAbEAtjHAQDkh5jZRIsZ 7JMNkPMSCd5PuSy0/Gdx8LGgsxxPMZwePgEAn5Tnh4fVbf00esnoK588bYQgJBioXtuXhtom 8hlxFQM= In-Reply-To: <440b2682-dbfb-4a5c-927c-2397413a7f9c@suse.cz> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Stat-Signature: yjtu7kb34xu15pmrzhscacgahzsf8fga X-Rspam-User: X-Rspamd-Queue-Id: B79F440013 X-Rspamd-Server: rspam02 X-HE-Tag: 1731422898-947128 X-HE-Meta: U2FsdGVkX1+xnm+qlWIFUguJwkN/wTOUUmGbVm58oRpm0bLC3dwi3KNXln7J5eRb5URoI3EkeYu8f04ZGuZxaWfu32L2Iv65EcztJ0kTTCxHzeuwqVbINfHKT54ybjkJy0lHRh8Z2ZZK3qBCTinI7ZRM8l1wYA4mUVPwMay9o54XRtH+HwJV7bu8nePkhUqys86qP3Dt70MF4YVHUGPAym4IgR7+kTdJ0q6Y5NTXsBX77aGLHRFikBfuuDLwrpc6S4LBQwHr0P+qUxz/Y/O00wW5D3IZ0bmOXh4zbwffQD9ge/rq0+0orXfmm52vhykWr/zovKoV/a5MbofRVWfbN6rHd4dsWsr+zf1rJ0hn+9k8DdAaMR3a7s4k1IGSMeOdZ2w9kYvvl85VApQVibtPpNu95KfJ0Il5IVZ/ecivt76g0cSHMzQlsvSF9trU9ef5Z7gtmbjlyQopT1SXsWccu/sds7ckZjhiRMY4DJkEySNh1k5ER38cF8mhOqvxhE6+XIzn9aCHcJYQFkCPxTtmvvYuAeW4Ygc4geKxws4x33jzL4n7Vt0U7sT7o0Ipb6Srvtwdv3hNGLD5hK63bHWmMoyJUCJDW2OhrAIKb1C0HX1EolQameN8Cr5/pPsb4T8kyAcIT6kGHO7evYmrYRZcEQ6Lo13Dag02Lg0UUqhmK+SiACg6DaxP/3XaXzUthcTysFf4bXOcdCalpHI7AKxsJo69uMHiLxRcl5HmyNFrEAleaMRosu21jzwz8ZxosyxWf9dLtOZyCFHFbzX0+Un50aDCJ4ri/ODrdACZzuW1wnGQkln9fybmTjZRcTvb8fIEAJtsC8r4m8pobcQa+DXUQ3TxIuzMBAihhhl3DDL4S/FVMoZeJEZEQ+5zFlXzHiN6aBqoouxYUbIud5Ike53XVuSMO5EICvcmYwNWGZkddLdiBLS62hoMaigIorCBvLiVXx3a8ZxHbBbrPmzpN4L 4Tx0LxH6 RfQqe+w8k9mpfd1w5TSNgCgJWYKjvCtiKM/y6FnTGjfiU+6X0BRmxyZOjCyeR61av68+Mq6YtDX5TgOba9wtiUcYPBkoSbq8qRUjQTXcGuW5apQjJ4EuZHwDo3z+riOFAhSrZX/U1qqWd6KvA1zCltU/2aGQGTAGSnfgcxiVlANvLROtIZ98VYwKbC582PbrVLzfGk0NMkdwibgTggfgtt2MLGkOEmdLhDTDbk9bpgHfX93sKE4PAEROvm1IrZh2272PfGyM3GVTO6gJfNZ6cE4eR1A+ZGFAyG3KO4ckP+acPFPFcTY0b+/vl850znJ74LX6w2PriJdcASbGuP+LgA5IG9xn+jALgF6NIeKNwK1rNTuU0HXRxCGp2XhHZ5GfZPoeuHmNPtoSyNb8h8MWxfFh15pXGhQGizIeMdV/BeJ9IjachlHohCrgzywcyTIsdIsrHPj6lRiJg21GK99hmfGpNVrvzEA1qCU0HxzYPbUVDw1zO5GpPCGrWpVTQqvTqobZbaopS1lRK6AH/aLzJPWKgJRA9DIQz+wTXDsdPJi2FUiQ= 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 Mon, 2024-11-11 at 12:12 +0000, Vlastimil Babka wrote: > On 10/31/24 10:57, David Hildenbrand wrote: >> On 30.10.24 14:49, Patrick Roy wrote: >>> From: "Mike Rapoport (Microsoft)" >>> >>> From: Mike Rapoport (Microsoft) >>> >>> Add an API that will allow updates of the direct/linear map for a set of >>> physically contiguous pages. >>> >>> It will be used in the following patches. >>> >>> Signed-off-by: Mike Rapoport (Microsoft) >>> Signed-off-by: Patrick Roy >> >> >> [...] >> >>> #ifdef CONFIG_DEBUG_PAGEALLOC >>> void __kernel_map_pages(struct page *page, int numpages, int enable) >>> { >>> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h >>> index e7aec20fb44f1..3030d9245f5ac 100644 >>> --- a/include/linux/set_memory.h >>> +++ b/include/linux/set_memory.h >>> @@ -34,6 +34,12 @@ static inline int set_direct_map_default_noflush(struct page *page) >>> return 0; >>> } >>> >>> +static inline int set_direct_map_valid_noflush(struct page *page, >>> + unsigned nr, bool valid) >> >> I recall that "unsigned" is frowned upon; "unsigned int". >> >>> +{ >>> + return 0; >>> +} >> >> Can we add some kernel doc for this? >> >> In particular >> >> (a) What does it mean when we return 0? That it worked? Then, this > > Seems so. > >> dummy function looks wrong. Or this it return the > > That's !CONFIG_ARCH_HAS_SET_DIRECT_MAP and other functions around do it the > same way. Looks like the current callers can only exist with the CONFIG_ > enabled in the first place. Yeah, it looks a bit weird, but these functions seem to generally return 0 if the operation is not supported. ARM specifically has if (!can_set_direct_map()) return 0; inside `set_direct_map_invalid_{noflush,default}`. Documenting this definitely cannot hurt, I'll keep it on my todo list for the next iteration :) >> number of processed entries? Then we'd have a possible "int" vs. >> "unsigned int" inconsistency. >> >> (b) What are the semantics when we fail halfway through the operation >> when processing nr > 1? Is it "all or nothing"? > > Looking at x86 implementation it seems like it can just bail out in the > middle, but then I'm not sure if it can really fail in the middle, hmm... If I understood Mike correctly when talking about this at LPC, then it can only fail if during break-up of huge mappings, it fails to allocate page tables to hold the lower-granularity mappings (which happens before any present bits are modified). Best, Patrick