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 341F5C79FA1 for ; Tue, 8 Sep 2026 11:21:22 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UwI3uzVUL92F+A1SRs5KjL41HrIrSEF0QjfdOqfQ6Oo=; b=4YClA69wzl/kEh ruBpnoM+sqDBKQY7gLoIx6Xn9XfVg0WTD0AfsqDf8rHVeJpgJ+mK5+BP/psa8EwqiMF8y6+IhQl6x KWxaCcP2IQaDbyBLiqQmeaykCMQG8FA2BxRbjgh3I7/J2M9Aur/UM2e5Fl45I0lkZvqJUPeuBe9MD TRqrqyupX5zKiHB6X10yNiBzCJn5UvbEI2y6hmvC45d+UAfdlf8OlPfURy66yerUkgjAb4WcAZKSu 4P0Oh0U+Ttq9G6dK1RhYpGDYy3kLuR41l+gtriUIQ//3wOsXRapEiBybZR1HGzrnP04o8v+VwsD3G zHqmp6fcVIaFlIgoZ7Sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3tsw-00000008sEy-09yV; Tue, 08 Sep 2026 11:21:06 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3tst-00000008sEB-49ij; Tue, 08 Sep 2026 11:21:04 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 46295404EE; Tue, 8 Sep 2026 11:21:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AB5F1F00A3A; Tue, 8 Sep 2026 11:20:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788866463; bh=IoqTyL+G5O6+fLL3cVLfgraMEyoqxgqBpPotfBdVQqw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GrB21XYOLGrBo6gxEF8O+VDQ8P6Z7IJTIEyPD1wG1Gw99Ip3jQphLMVskjjJ/q1Ia NbKynFOkclfWFGjzL/ZGOj6A9B0MpoII6bIk2IMQMeQDRYFtKMRU9tUxJ1xQ8R6XhN wy+hJ5Tgq+0qcKo/HXlbIKH3KURAlURNS462V+YZ3LJlrToDIY9DtyC4wV64/AhYYL F15CVr74IcEypm11lfsqKgyCfH6d29iy96Wyv6dN/8FLMchUrk+YzXSYPL0GlxRixZ hhPGyoW5IRAxaXfGXElFzqrAoW5JwJ8z3PYtqX0rXQUBb6XRR5zCWyXaB9s0M98V+f qbnt/MWTQnd1Q== Date: Tue, 8 Sep 2026 14:20:49 +0300 From: Mike Rapoport To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Adrian =?utf-8?Q?Barna=C5=9B?= , Albert Ou , Alexander Gordeev , Alexandre Ghiti , Andy Lutomirski , Borislav Petkov , Brendan Jackman , Catalin Marinas , Christian Borntraeger , Dave Hansen , 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 , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, loongarch@lists.linux.dev Subject: Re: [PATCH v3 1/6] set_memory: add number of pages parameter to set_direct_map APIs Message-ID: References: <20260903-execmem-set-vm-perms-v0-2-v3-0-949b64a9f755@kernel.org> <20260903-execmem-set-vm-perms-v0-2-v3-1-949b64a9f755@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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 Tue, Sep 08, 2026 at 12:38:44PM +0200, David Hildenbrand (Arm) wrote: > On 9/3/26 11:28, 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) > > --- > In general, LGTM. > > But regarding semantics, is it well defined what happens when an update fails > halfway through an operation? Just like other set_memory, it bails out in the middle if anything bad happens. > I'd assume such a case cannot currently get triggered, but there is no > documentation on what's supported and what's not. Or is there? > > Imagine someone performing an update on an area that partially spans two PMDs. > While splitting and updating the first PMD could succeed, splitting the second > PMD could fail. What would be the end result? Rollback? Does the caller have to > clean up? There is no rollback in any of set_memory implementations. It's up to the callers to cleanup the mess afterwards. > I'd appreciate if we could add proper documentation with expected semantics. I believe it's more in the scope of "arch, mm: create a generic set_memory/change_page_attr core" [1] work than this patchset. I can write (or maybe even slop ;) ) a doc about set_memory/set_direct_map, but I wouldn't want to hold this because there's not set_memory documentation. [1] https://lore.kernel.org/all/20260721-generic-set-memory-v0-1-v1-0-2c1fc62306b3@kernel.org > -- > Cheers, > > David -- Sincerely yours, Mike. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv