From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-244.mta1.migadu.com [95.215.58.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99B8F3FCB0C for ; Mon, 17 Aug 2026 12:10:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.244 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786968661; cv=none; b=KksQDP04aa2gvVsaUd5txAp1wlX7p1vaAvlVDgilhyKSvto5ial1Q63niT4Hstw+bhEpRkCBwJAxWhT4MtBfobnM+hP+bMdW9EJ4s1ttp249MVl/8npQ0udtDIINKYkf3sVjnIZELd3+QiJ8bCNPn3XcCpyYeB6qp6JSTXsgCFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786968661; c=relaxed/simple; bh=HixNdaF24ntDEuguIuhpK7haYmS/JSSrlBPi1Y1tptI=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=tDl70I/dWI4Wzi+wgiaaKsYha9de2iX8oXDi6N+N8Jiq9A653tqH53uxAZGA9zdADxqXL/oRwUiW4vXRLl2P9dnZDCGpjjPex8CCie+DIIET1OKs3g4mRn6pkahmibypIwPfuhhzJPYquJPbTpwL4CCmdqfnjqINXxgpT30ghxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=QeEsg/dq; arc=none smtp.client-ip=95.215.58.244 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="QeEsg/dq" X-Envelope-To: loongarch@lists.linux.dev DKIM-Signature: a=rsa-sha256; bh=HixNdaF24ntDEuguIuhpK7haYmS/JSSrlBPi1Y1tptI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786968655; v=1; x=1787573455; b=QeEsg/dqo1TZKqifzrBNzsykZmrFrlTHIwqmU/NfoUZuilMqfjcwRFQWsUqqIc1hgw0/A0kg JvEop+e9FDiowsS/ZKpFBBgvwCfaYypnG3Eq7CzMxKIlFsxztHVZ7HgwayE3nz2eXd+UkW0TJqe HoN2VbcomdRbSPmB6Q4EDzfU= X-Envelope-To: loongarch@lists.linux.dev Received: from localhost (185.201.63.253) by smtp.migadu.com with ESMTPS id f0badc6dc42a8a86; Mon, 17 Aug 2026 12:10:55 +0000 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: loongarch@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 17 Aug 2026 14:10:39 +0200 Message-Id: Cc: =?utf-8?q?Adrian_Barna=C5=9B?= , "Albert Ou" , "Alexander Gordeev" , "Alexandre Ghiti" , "Andy Lutomirski" , "Borislav Petkov" , "Brendan Jackman" , "Catalin Marinas" , "Christian Borntraeger" , "Dave Hansen" , "David Hildenbrand" , "Gerald Schaefer" , "Heiko Carstens" , "Huacai Chen" , "Ingo Molnar" , "Len Brown" , "Palmer Dabbelt" , "Paul Walmsley" , "Pavel Machek" , "Peter Zijlstra" , "H. Peter Anvin" , "Rafael J. Wysocki" , "Ryan Roberts" , "Sven Schnelle" , "Thomas Gleixner" , "Uladzislau Rezki" , "Vasily Gorbik" , "WANG Xuerui" , "Will Deacon" , , , , , , , , Subject: Re: [PATCH 1/6] set_memory: add number of pages parameter to set_direct_map APIs From: "Brendan Jackman" To: "Mike Rapoport (Microsoft)" , "Andrew Morton" X-Mailer: aerc 0.21.0 References: <20260816-execmem-set-vm-perms-v0-2-v1-0-90944a3ad43f@kernel.org> <20260816-execmem-set-vm-perms-v0-2-v1-1-90944a3ad43f@kernel.org> In-Reply-To: <20260816-execmem-set-vm-perms-v0-2-v1-1-90944a3ad43f@kernel.org> On Sun Aug 16, 2026 at 12:59 PM CEST, Mike Rapoport (Microsoft) wrote: > When set_direct_map APIs were introduced by the commit d253ca0c3865 > ("x86/mm/cpa: Add set_direct_map_*() functions") the single page > parameter made sense because the initial callers (vmalloc and > hibernation) had sets of unsorted struct pages that required changes of > their mappings in the direct map. > > Since there is an increasing demand for direct map manipulation and it > is also desirable to be able to update larger physically contiguous > mappings, for example an entire large folio, extend set_direct_map APIs > to receive number of pages parameter. > > As there is still only a handful of callers, change the existing > functions directly and update all the call sites rather than adding > wrappers for single page case. > > Signed-off-by: Mike Rapoport (Microsoft) I think if we add this arg we also need to specify how the implementations are supposed to behave when they fail midway? IIUC the incumbent answer for stuff like this is: - The implementation might leave partial modifications behind when it fails. The caller needs to deal with that. - ... But, that's gonna be due to allocation failure. So the caller can just do the inverse operation in the failure path as a cleanup, and assume that inverse operation succeeds since the pagetables are already allocated up to the failure point. I guess it's worth making that a sort of explicit contract since it makes certain implementation details load-bearing, e.g. I think... - It forces the pagetable update algorithm to work in a fixed order. - it forbids us to e.g. merge PTEs into a PMD if the region might be pending such a cleanup, since it would force that cleanup to reallocate a PTE table. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7A07C5DF66 for ; Mon, 17 Aug 2026 12:11:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:To:From:Subject: Cc:Message-Id:Date:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=s5x8bgtVAcphi10pdM82ZJWw34/Wv5sCuJDcPKz/N+Y=; b=uIqM7TW9jhEtbT hc4j1VbYKGi+ykUIgtKwGwywH29hFkRIG3nfhodItyo5gJ1MP/Envpgm9iQfy04JkDUs/jZP8dySj n9wsnOKGFTMb7EI8zGUOC0XicIOUfNfm2LOUfjN7KGatsXpOytaMYd5yl1g23vL9AeiEZz/NaEm8n s8tLC9yd9FZFvcmzBZJKVS0rrrmoTupQnpAloRW7t3F3/jj4VGODXn26bYyy9wAIi554P3T3blqPZ exfD6R5tMYVOBWcVlXtgOK/hhDFmCBFRKQNgtC/HzF2lybaIvcATN4dwolQe/0IWnk30xvPkcReEa pZHsKu4g2XTscXhGv+yQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wvwBF-000000066bV-1iwF; Mon, 17 Aug 2026 12:11:05 +0000 Received: from out-245.mta0.migadu.com ([2001:41d0:1004:224b::f5] helo=mta0.migadu.com) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wvwBB-000000066aH-3Xo2 for linux-riscv@lists.infradead.org; Mon, 17 Aug 2026 12:11:04 +0000 X-Envelope-To: linux-riscv@lists.infradead.org DKIM-Signature: a=rsa-sha256; bh=HixNdaF24ntDEuguIuhpK7haYmS/JSSrlBPi1Y1tptI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786968655; v=1; x=1787573455; b=QeEsg/dqo1TZKqifzrBNzsykZmrFrlTHIwqmU/NfoUZuilMqfjcwRFQWsUqqIc1hgw0/A0kg JvEop+e9FDiowsS/ZKpFBBgvwCfaYypnG3Eq7CzMxKIlFsxztHVZ7HgwayE3nz2eXd+UkW0TJqe HoN2VbcomdRbSPmB6Q4EDzfU= X-Envelope-To: linux-riscv@lists.infradead.org Received: from localhost (185.201.63.253) by smtp.migadu.com with ESMTPS id f0badc6dc42a8a86; Mon, 17 Aug 2026 12:10:55 +0000 X-Migadu-Flow: FLOW_OUT Mime-Version: 1.0 Date: Mon, 17 Aug 2026 14:10:39 +0200 Message-Id: Cc: =?utf-8?q?Adrian_Barna=C5=9B?= , "Albert Ou" , "Alexander Gordeev" , "Alexandre Ghiti" , "Andy Lutomirski" , "Borislav Petkov" , "Brendan Jackman" , "Catalin Marinas" , "Christian Borntraeger" , "Dave Hansen" , "David Hildenbrand" , "Gerald Schaefer" , "Heiko Carstens" , "Huacai Chen" , "Ingo Molnar" , "Len Brown" , "Palmer Dabbelt" , "Paul Walmsley" , "Pavel Machek" , "Peter Zijlstra" , "H. Peter Anvin" , "Rafael J. Wysocki" , "Ryan Roberts" , "Sven Schnelle" , "Thomas Gleixner" , "Uladzislau Rezki" , "Vasily Gorbik" , "WANG Xuerui" , "Will Deacon" , , , , , , , , Subject: Re: [PATCH 1/6] set_memory: add number of pages parameter to set_direct_map APIs From: "Brendan Jackman" To: "Mike Rapoport (Microsoft)" , "Andrew Morton" X-Mailer: aerc 0.21.0 References: <20260816-execmem-set-vm-perms-v0-2-v1-0-90944a3ad43f@kernel.org> <20260816-execmem-set-vm-perms-v0-2-v1-1-90944a3ad43f@kernel.org> In-Reply-To: <20260816-execmem-set-vm-perms-v0-2-v1-1-90944a3ad43f@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260817_051102_386867_3869CCCA X-CRM114-Status: GOOD ( 14.45 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Sun Aug 16, 2026 at 12:59 PM CEST, Mike Rapoport (Microsoft) wrote: > When set_direct_map APIs were introduced by the commit d253ca0c3865 > ("x86/mm/cpa: Add set_direct_map_*() functions") the single page > parameter made sense because the initial callers (vmalloc and > hibernation) had sets of unsorted struct pages that required changes of > their mappings in the direct map. > > Since there is an increasing demand for direct map manipulation and it > is also desirable to be able to update larger physically contiguous > mappings, for example an entire large folio, extend set_direct_map APIs > to receive number of pages parameter. > > As there is still only a handful of callers, change the existing > functions directly and update all the call sites rather than adding > wrappers for single page case. > > Signed-off-by: Mike Rapoport (Microsoft) I think if we add this arg we also need to specify how the implementations are supposed to behave when they fail midway? IIUC the incumbent answer for stuff like this is: - The implementation might leave partial modifications behind when it fails. The caller needs to deal with that. - ... But, that's gonna be due to allocation failure. So the caller can just do the inverse operation in the failure path as a cleanup, and assume that inverse operation succeeds since the pagetables are already allocated up to the failure point. I guess it's worth making that a sort of explicit contract since it makes certain implementation details load-bearing, e.g. I think... - It forces the pagetable update algorithm to work in a fixed order. - it forbids us to e.g. merge PTEs into a PMD if the region might be pending such a cleanup, since it would force that cleanup to reallocate a PTE table. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv