From nobody Sun May 10 22:40:21 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2C10C4332F for ; Thu, 21 Apr 2022 18:02:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391110AbiDUSFG (ORCPT ); Thu, 21 Apr 2022 14:05:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1390799AbiDUSFC (ORCPT ); Thu, 21 Apr 2022 14:05:02 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 457E44A914; Thu, 21 Apr 2022 11:02:12 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id s18so11717272ejr.0; Thu, 21 Apr 2022 11:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JB/7ga9Q6TH0mrE4s60UvEIeZRakvM8pM/E/1QVCfnw=; b=OzI8w7XL/hOdeRu/BlIhPUUAkcjzlS4wHs4wFwrOUS1RkilWZndk9ka2kVIw4YaOS+ HdXsxCnlzpLybt4R4TA1EG5IKNVBQbigStdX7Mom+ToR2DM/4Rk4wd62obNEeJiQascV te4yRPPDm0/rHZLY0P6iMpIMoKPfoccKE1xv89yGGGsqWRE5bOBf329gYjMvAXUIklqv 76CHoFC2oKYxg91WG6IieGVMbXKweCSH8vcfq7ca8Irse45E5lwsn7pZN0RsMf+7XpRa EPPsbpHyaZzHzcnSIZ4WyKahOV6zzp/h3g2PMJC6MO9AByPDs1OU/Slc4TeZWLJE/C2/ XCaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JB/7ga9Q6TH0mrE4s60UvEIeZRakvM8pM/E/1QVCfnw=; b=a5BPwBl8uxrmGQQ6SO26f1XwQC56mHqa7OecNFQ/hSI2wqF/iVLMlwsMUGsm2fW10f Qdp/YP860EWqKGd+JdBq31BvR4lRAWVy3er3iBlTEwxbrAPO/0S6ZqXLGYfaFZqU8QOT yDImGYU/PeQC0a2TfPX9Gp0te6VV5sxeQkv48Rn/2Yw+9wKg9KdkKlJXxVgSrs/eQp3I l7g34HEs5CH28nB14HPnFxhjksoA9LfQlQGYs9wIy5Pf65KaWO7F481u5R6o6KOXQSBS fNufhWspCakV6hWQYfys5F12/RHWfLbXQyDu3UFua80VQZ/P+7gfXGBZvIot58FVIdAe EZIg== X-Gm-Message-State: AOAM531XDY23jo4uchNxzepV9Rqv+R4nXVZBKSan/JPkoQ3I7qTEucDX 3IyXTPgzHF1Lvgx6jGSNAXnPWfHp2ac= X-Google-Smtp-Source: ABdhPJxN2/2vvOT4+KlkpAaB+H1hSeJuQm6eo4Gp0L7Oqc4BrVd5Vp3oARm66MGJK5pEGRA8rgMAFQ== X-Received: by 2002:a17:907:97d3:b0:6ef:f445:dd96 with SMTP id js19-20020a17090797d300b006eff445dd96mr664318ejc.416.1650564130686; Thu, 21 Apr 2022 11:02:10 -0700 (PDT) Received: from localhost.localdomain (host-79-50-86-254.retail.telecomitalia.it. [79.50.86.254]) by smtp.gmail.com with ESMTPSA id l17-20020a056402231100b0041d98ed7ad8sm11836204eda.46.2022.04.21.11.02.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 11:02:09 -0700 (PDT) From: "Fabio M. De Francesco" To: Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Mike Rapoport Subject: [PATCH 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Date: Thu, 21 Apr 2022 20:01:57 +0200 Message-Id: <20220421180200.16901-2-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220421180200.16901-1-fmdefrancesco@gmail.com> References: <20220421180200.16901-1-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" `scripts/kernel-doc -v -none include/linux/highmem*` reports the following warnings: include/linux/highmem.h:160: warning: expecting prototype for kunmap_atomic= (). Prototype was for nr_free_highpages() instead include/linux/highmem.h:204: warning: No description found for return value= of 'alloc_zeroed_user_highpage_movable' include/linux/highmem-internal.h:256: warning: Function parameter or member= '__addr' not described in 'kunmap_atomic' include/linux/highmem-internal.h:256: warning: Excess function parameter 'a= ddr' description in 'kunmap_atomic' Fix these warnings by (1) moving the kernel-doc comments from highmem.h to highmem-internal.h (which is the file were the kunmap_atomic() macro is actually defined), (2) extending and merging it with the comment which was already in highmem-internal.h, and (3) using correct parameter names. Cc: Mike Rapoport Cc: Ira Weiny Suggested-by: Matthew Wilcox Signed-off-by: Fabio M. De Francesco Acked-by: Mike Rapoport Reviewed-by: Ira Weiny --- include/linux/highmem-internal.h | 14 +++++++++++--- include/linux/highmem.h | 15 +++------------ 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-inter= nal.h index a77be5630209..b099a08e29d3 100644 --- a/include/linux/highmem-internal.h +++ b/include/linux/highmem-internal.h @@ -236,9 +236,17 @@ static inline unsigned long totalhigh_pages(void) { re= turn 0UL; } =20 #endif /* CONFIG_HIGHMEM */ =20 -/* - * Prevent people trying to call kunmap_atomic() as if it were kunmap() - * kunmap_atomic() should get the return value of kmap_atomic, not the pag= e. +/** + * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic() + * @__addr: Virtual address to be unmapped + * + * Unmap an address previously mapped by kmap_atomic() and re-enables + * pagefaults and preemption. Mappings should be unmapped in the reverse + * order that they were mapped. See kmap_local_page() for details. + * @__addr can be any address within the mapped page, so there is no need + * to subtract any offset that has been added. In contrast to kunmap(), + * this function takes the address returned from kmap_atomic(), not the + * page passed to it. The compiler will warn you if you pass the page. */ #define kunmap_atomic(__addr) \ do { \ diff --git a/include/linux/highmem.h b/include/linux/highmem.h index 39bb9b47fa9c..c3d562b5f0c1 100644 --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -37,7 +37,7 @@ static inline void *kmap(struct page *page); =20 /** * kunmap - Unmap the virtual address mapped by kmap() - * @addr: Virtual address to be unmapped + * @page: Virtual address to be unmapped * * Counterpart to kmap(). A NOOP for CONFIG_HIGHMEM=3Dn and for mappings of * pages in the low memory area. @@ -145,17 +145,6 @@ static inline void *kmap_local_folio(struct folio *fol= io, size_t offset); */ static inline void *kmap_atomic(struct page *page); =20 -/** - * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic() - * @addr: Virtual address to be unmapped - * - * Counterpart to kmap_atomic(). - * - * Effectively a wrapper around kunmap_local() which additionally undoes - * the side effects of kmap_atomic(), i.e. reenabling pagefaults and - * preemption. - */ - /* Highmem related interfaces for management code */ static inline unsigned int nr_free_highpages(void); static inline unsigned long totalhigh_pages(void); @@ -191,6 +180,8 @@ static inline void clear_user_highpage(struct page *pag= e, unsigned long vaddr) * @vma: The VMA the page is to be allocated for * @vaddr: The virtual address the page will be inserted into * + * Returns: The allocated and zeroed HIGHMEM page + * * This function will allocate a page for a VMA that the caller knows will * be able to migrate in the future using move_pages() or reclaimed * --=20 2.34.1 From nobody Sun May 10 22:40:21 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0102FC433EF for ; Thu, 21 Apr 2022 18:02:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391119AbiDUSFJ (ORCPT ); Thu, 21 Apr 2022 14:05:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1391103AbiDUSFF (ORCPT ); Thu, 21 Apr 2022 14:05:05 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50AAB4B1C0; Thu, 21 Apr 2022 11:02:15 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id i27so11590673ejd.9; Thu, 21 Apr 2022 11:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=PWSm35GKgzhZ2nsMVDxagYWw0p5o9vqwYX51NaxQrug=; b=XJsxSUUQc4rlVu1TWKgCPb23ms5Cf0+E/ldtQyI/Bnzra8P5sITAAQsvP55AunNBWu cAEefC/Y7EL6Rr54fEzFhBK7GaPER8T7/sPXZSQI8G7FPeNX6NAJImwJFqGRXZPfOTBI oTQIdm00ImB9obwuVpn0gVxYqN8faYmE4XkBubmwlicbJFI5tbcV9BOxBhicBOJTmHlE B6HDL2ajVcPSFVdRMoCAbX8fehDhEmqn2F0j/HZKUyIo/PO8V/LQtfffJTWitsTEqZm8 Ch/JUgDH5ArKBS9zSJUZbXRN+NGBvBPCym7U6KBpiwdSGwXO66fCw30evrWskKtvNk/4 Edug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PWSm35GKgzhZ2nsMVDxagYWw0p5o9vqwYX51NaxQrug=; b=v00oysfcDeitBR9RzFp37SCPoJ1yy/pZa3uJDgfHyrunmwSflY9n+nsFFzcgyjGPIV Xcy61Qw+Es/+8gKbZqkZq95OPiknjjIVV9Di8mn6f9qfQoom8SLq5df+n71kKzk25guS gt4JklMznyjQelHxS9+vBK2cLzAz/o2Ha+KO0vVt66Yd2VxJAZ7XDxuqlif2jZBEvubl qExU6cb74TMjzTC/nttU5t738XOsltaePFUmdFg0kE8iazUMxCpzLVYkzkTT6RLIxahD afM2PhjL1bGapptzw3HRa0/y0mt4Levxxe8uW+SvtXGOp7d5lrPocbSSlIVBIayRztYu 0FBw== X-Gm-Message-State: AOAM531RdeAOEkGkNtd1zfcggYwFIEoRgCO2kUpFlxudugQE1w9w3qOZ HoLMtrI+Q1hGaFMpKFZKgTM= X-Google-Smtp-Source: ABdhPJzz3okdqpk4g83+Y1lh1AY/TunHBPpCllIQOGmm8GGTU+6kn2uQoF4Jy63X4AgO3F04jvzdEA== X-Received: by 2002:a17:907:7246:b0:6ef:828d:4b49 with SMTP id ds6-20020a170907724600b006ef828d4b49mr705192ejc.172.1650564133850; Thu, 21 Apr 2022 11:02:13 -0700 (PDT) Received: from localhost.localdomain (host-79-50-86-254.retail.telecomitalia.it. [79.50.86.254]) by smtp.gmail.com with ESMTPSA id l17-20020a056402231100b0041d98ed7ad8sm11836204eda.46.2022.04.21.11.02.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 11:02:12 -0700 (PDT) From: "Fabio M. De Francesco" To: Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Thomas Gleixner , Peter Zijlstra Subject: [PATCH 2/4] Documentation/vm: Include kdocs from highmem*.h into highmem.rst Date: Thu, 21 Apr 2022 20:01:58 +0200 Message-Id: <20220421180200.16901-3-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220421180200.16901-1-fmdefrancesco@gmail.com> References: <20220421180200.16901-1-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" kernel-docs that are in include/linux/highmem.h and in include/linux/highmem-internal.h should be included in highmem.rst. Use kdocs directives to include the above-mentioned comments into highmem.rst. Cc: Jonathan Corbet Cc: Thomas Gleixner Cc: Ira Weiny Cc: Matthew Wilcox Cc: Peter Zijlstra Signed-off-by: Fabio M. De Francesco Acked-by: Mike Rapoport Reviewed-by: Ira Weiny --- Documentation/vm/highmem.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index 0f69a9fec34d..ccff08a8211d 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -145,3 +145,10 @@ The general recommendation is that you don't use more = than 8GiB on a 32-bit machine - although more might work for you and your workload, you're pretty much on your own - don't expect kernel developers to really care much if t= hings come apart. + + +Functions +=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. kernel-doc:: include/linux/highmem.h +.. kernel-doc:: include/linux/highmem-internal.h --=20 2.34.1 From nobody Sun May 10 22:40:21 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 440A6C433F5 for ; Thu, 21 Apr 2022 18:02:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391143AbiDUSFR (ORCPT ); Thu, 21 Apr 2022 14:05:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1391115AbiDUSFJ (ORCPT ); Thu, 21 Apr 2022 14:05:09 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60E784A914; Thu, 21 Apr 2022 11:02:18 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id y10so11585406ejw.8; Thu, 21 Apr 2022 11:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HmA3/73h+5LBB10zHGxV017fuflOUeGcPLWTr+e8zPI=; b=JxFESrRIt2UUIpYO6BpQfEJYWlNMou98BAoenYcLTFq13O/N0HaMuWE+53AANrJ25l LMMa2E3ZxlxPBTKAfe+XpPseTVvRPRdjFVHhnW/nH0D9hx67ybP4rvw+XlibU2dQWbFZ ayNEFeXq6fHAMPA3QMg69+E2zXekkq9IEr30pEYCXzzsixokcuZ6HYQmZSmDH6W/S/Qt vEeqwPYsNebnjtzu4hNBhLcSf4WOyNooXZbKRuDX6Ay6Xgf9RTgqpARssMLY1gZkyiWc zsjBqoZ9Hb6bb728U6ak+GmynyJ/os/7ElTN04K0x50f3qc02Piu5U4giQXd7FAr1O3S T0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HmA3/73h+5LBB10zHGxV017fuflOUeGcPLWTr+e8zPI=; b=mv0KN0b8EeBOXD1mjpdyxpRSu22llAtkJT7zTMf5BMa2p/QAt7CbgZ5vBAE32mTYs0 gWzJaAQ664pCO8YYx8lT0jpwmTpA1B2D4poU5+6rhIBzHhTLJnQV0r03PxqxPYKgPtBP I4a/W27vNUjutOWkaUkAWhfyXpC2WMcLnmX3bNcaRerb7mU18K0+flC/7+qlr5Ya3mXC Ubiy5Pbso0oSWfeG9qHovmKM/RYFyxm6hzPKVHlFTxiJ8teIVcXoec50omepIpsBZNUX OZ1o8Ly5BbzxJJtFjB2naENczEsIEKBNxKdgCqcVjDmnuQBxSllw1YFRXTvgdH0Bs4gc QmpQ== X-Gm-Message-State: AOAM532+Su2vBYwgGUI6u/ixkJ7VX8XvFg6sMa/kurNrnKbxuDuOKo24 5sbDdtACq7FmBXcuNFh9xpE= X-Google-Smtp-Source: ABdhPJyq9h4yAAyEQ3sVOf5aNXfL6p5Uwg640htvov7CuE7VFCMkHwZOIAe5oGdZuEAGRac218rGag== X-Received: by 2002:a17:907:3da8:b0:6ef:f3e8:2989 with SMTP id he40-20020a1709073da800b006eff3e82989mr637575ejc.29.1650564136966; Thu, 21 Apr 2022 11:02:16 -0700 (PDT) Received: from localhost.localdomain (host-79-50-86-254.retail.telecomitalia.it. [79.50.86.254]) by smtp.gmail.com with ESMTPSA id l17-20020a056402231100b0041d98ed7ad8sm11836204eda.46.2022.04.21.11.02.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 11:02:15 -0700 (PDT) From: "Fabio M. De Francesco" To: Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Thomas Gleixner , Peter Zijlstra Subject: [PATCH 3/4] Documentation/vm: Remove "Using kmap-atomic" from highmem.rst. Date: Thu, 21 Apr 2022 20:01:59 +0200 Message-Id: <20220421180200.16901-4-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220421180200.16901-1-fmdefrancesco@gmail.com> References: <20220421180200.16901-1-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The use of kmap_atomic() is deprecated in favor of kmap_local_page(). For this reason the "Using kmap_atomic" section in highmem.rst is obsolete and unnecessary. Therefore, just remove it. Cc: Jonathan Corbet Cc: Thomas Gleixner Cc: Ira Weiny Cc: Matthew Wilcox Cc: Peter Zijlstra Signed-off-by: Fabio M. De Francesco --- Documentation/vm/highmem.rst | 35 ----------------------------------- 1 file changed, 35 deletions(-) diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index ccff08a8211d..e05bf5524174 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -72,41 +72,6 @@ The kernel contains several ways of creating temporary m= appings: It may be assumed that k[un]map_atomic() won't fail. =20 =20 -Using kmap_atomic -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - -When and where to use kmap_atomic() is straightforward. It is used when c= ode -wants to access the contents of a page that might be allocated from high m= emory -(see __GFP_HIGHMEM), for example a page in the pagecache. The API has two -functions, and they can be used in a manner similar to the following:: - - /* Find the page of interest. */ - struct page *page =3D find_get_page(mapping, offset); - - /* Gain access to the contents of that page. */ - void *vaddr =3D kmap_atomic(page); - - /* Do something to the contents of that page. */ - memset(vaddr, 0, PAGE_SIZE); - - /* Unmap that page. */ - kunmap_atomic(vaddr); - -Note that the kunmap_atomic() call takes the result of the kmap_atomic() c= all -not the argument. - -If you need to map two pages because you want to copy from one page to -another you need to keep the kmap_atomic calls strictly nested, like:: - - vaddr1 =3D kmap_atomic(page1); - vaddr2 =3D kmap_atomic(page2); - - memcpy(vaddr1, vaddr2, PAGE_SIZE); - - kunmap_atomic(vaddr2); - kunmap_atomic(vaddr1); - - Cost of Temporary Mappings =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =20 --=20 2.34.1 From nobody Sun May 10 22:40:22 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A722C433EF for ; Thu, 21 Apr 2022 18:02:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1391147AbiDUSF0 (ORCPT ); Thu, 21 Apr 2022 14:05:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1391130AbiDUSFN (ORCPT ); Thu, 21 Apr 2022 14:05:13 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D0564B1DE; Thu, 21 Apr 2022 11:02:21 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id u15so11560716ejf.11; Thu, 21 Apr 2022 11:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=a6ZmwFanJZuh7hQqz3LVbwr1p4KwEMnE7IqhDHbu+tA=; b=WQkj196SEjCOm5X1GFd5opNyYrB5ISoL5QCp3zcZ4yG0SHgB7UKcBFt7pk76U2OtPU +Ve58ZPZqJmVLzICA+f/cnKOvcfY/w5tV4ffzw3Qja6gBgVs/y+RzREkPUa4Y3xsmFbA 3Je4Dkv/zCVMsTbR4+e2pYNkLBajXcdoM/FMM5Q+mt5Ts7Yfs2LoBBwxQbeaYSlUO+o2 L/EGCoZIiqV+yiIOC3doM2oX8GC93aQ1io1l7PE3rqtxJd6HIp0xaT7N257ByOGQ5b07 T6b1k8onjIXT3G9OxRiw0g3fI5pr8KMPaleq644o0uSnCkBIAdvXXVt5hGGGBzx7VcXK 0u6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=a6ZmwFanJZuh7hQqz3LVbwr1p4KwEMnE7IqhDHbu+tA=; b=YH6qED0tzZePi/AJRNQhlz4YynHkXoDk+18nLzzpbTPP5TERw51SxyRv9D5J5Tk0YB wzjKbzF9ysa/MFrkAzyhcg9LxrANduNHMGwdbQ2x8TWsXX3lYrV6cLJWBbK444UmVP9/ 5uPYf3NP+4+unrOHTQlZP/7KaXiNP1EiWTV3yRwppVhFVg3ek4q7yZX817q6OQIo/Qzo lMWhmdO43oDJP/9RAE2OrbFYtTC013Twjete+IRt7cNthdgmbZqZlEIuBxvQnIOmHAAm gkxWCXUR+Dzkdscdyd2FrKlnJDgw0Q2XcVzbBHazGvH00wTFjz/VTvlaz0m1XDfHJVJ9 ivKQ== X-Gm-Message-State: AOAM533AFO5NG+5GX+PV43iGTihkm/PmFXR7/13TM5YxhFGU3YX30dgX 17Gqi+stgeeFVH4zYugrr7Y= X-Google-Smtp-Source: ABdhPJyLVNzKlRNdicrjeKkwsfZkoOjRLHIkNCSVnaOxJCJcfpFsnLT/eGP2v0fC33Y/ojSFUEB1Pg== X-Received: by 2002:a17:907:7d88:b0:6f0:29ea:cbfe with SMTP id oz8-20020a1709077d8800b006f029eacbfemr640244ejc.704.1650564140059; Thu, 21 Apr 2022 11:02:20 -0700 (PDT) Received: from localhost.localdomain (host-79-50-86-254.retail.telecomitalia.it. [79.50.86.254]) by smtp.gmail.com with ESMTPSA id l17-20020a056402231100b0041d98ed7ad8sm11836204eda.46.2022.04.21.11.02.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 11:02:18 -0700 (PDT) From: "Fabio M. De Francesco" To: Ira Weiny , Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Thomas Gleixner , Peter Zijlstra Subject: [PATCH 4/4] Documentation/vm: Rework "Temporary Virtual Mappings" Date: Thu, 21 Apr 2022 20:02:00 +0200 Message-Id: <20220421180200.16901-5-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220421180200.16901-1-fmdefrancesco@gmail.com> References: <20220421180200.16901-1-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Extend and rework the "Temporary Virtual Mappings" section of the highmem.r= st documentation. Despite the local kmaps were introduced by Thomas Gleixner in October 2020, documentation was still missing information about them. These additions rely largely on Gleixner's patches, Jonathan Corbet's LWN articles, comments by Ira Weiny and Matthew Wilcox, and in-code comments from ./include/linux/highmem.h. 1) Add a paragraph to document kmap_local_page(). 2) Reorder the list of functions by decreasing order of preference of use. 3) Rework part of the kmap() entry in list. Cc: Jonathan Corbet Cc: Thomas Gleixner Cc: Ira Weiny Cc: Matthew Wilcox Cc: Peter Zijlstra Signed-off-by: Fabio M. De Francesco --- Documentation/vm/highmem.rst | 71 ++++++++++++++++++++++++++++++------ 1 file changed, 60 insertions(+), 11 deletions(-) diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index e05bf5524174..960f61e7a552 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -50,26 +50,75 @@ space when they use mm context tags. Temporary Virtual Mappings =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =20 -The kernel contains several ways of creating temporary mappings: +The kernel contains several ways of creating temporary mappings. The follo= wing +list shows them in order of preference of use. =20 -* vmap(). This can be used to make a long duration mapping of multiple - physical pages into a contiguous virtual space. It needs global - synchronization to unmap. +* kmap_local_page(). This function is used to require short term mappings. + It can be invoked from any context (including interrupts) but the mappin= gs + can only be used in the context which acquired them. + + This function should be preferred, where feasible, over all the others. =20 -* kmap(). This permits a short duration mapping of a single page. It nee= ds - global synchronization, but is amortized somewhat. It is also prone to - deadlocks when using in a nested fashion, and so it is not recommended f= or - new code. + These mappings are per thread, CPU local (i.e., migration from one CPU to + another is disabled - this is why they are called "local"), but they don= 't + disable preemption. It's valid to take pagefaults in a local kmap region, + unless the context in which the local mapping is acquired does not allow + it for other reasons. + + It is assumed that kmap_local_page() always returns the virtual address + of the mapping, therefore they won't ever fail. + + If a task holding local kmaps is preempted, the maps are removed on cont= ext + switch and restored when the task comes back on the CPU. As the maps are + strictly CPU local, it is guaranteed that the task stays on the CPU and + that the CPU cannot be unplugged until the local kmaps are released. + + Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a cer= tain + extent (up to KMAP_TYPE_NR) but their invocations have to be strictly or= dered + because the map implementation is stack based. =20 * kmap_atomic(). This permits a very short duration mapping of a single page. Since the mapping is restricted to the CPU that issued it, it performs well, but the issuing task is therefore required to stay on that CPU until it has finished, lest some other task displace its mappings. =20 - kmap_atomic() may also be used by interrupt contexts, since it is does n= ot - sleep and the caller may not sleep until after kunmap_atomic() is called. + kmap_atomic() may also be used by interrupt contexts, since it does not + sleep and the callers too may not sleep until after kunmap_atomic() is + called. + + Each call of kmap_atomic() in the kernel creates a non-preemptible secti= on + and disable pagefaults. This could be a source of unwanted latency, so it + should be only used if it is absolutely required, otherwise kmap_local_p= age() + should be used where it is feasible. =20 - It may be assumed that k[un]map_atomic() won't fail. + It is assumed that k[un]map_atomic() won't fail. + +* kmap(). This should be used to make short duration mapping of a single + page with no restrictions on preemption or migration. It comes with an + overhead as mapping space is restricted and protected by a global lock + for synchronization. When mapping is no more needed, the address that + the page was mapped to must be released with kunmap(). + + Mapping changes must be propagated across all the CPUs. kmap() also + requires global TLB invalidation when the kmap's pool wraps and it might + block when the mapping space is fully utilized until a slot becomes + available. Therefore, kmap() is only callable from preemptible context. + + All the above work is necessary if a mapping must last for a relatively + long time but the bulk of high-memory mappings in the kernel are + short-lived and only used in one place. This means that the cost of + kmap() is mostly wasted in such cases. kmap() was not intended for long + term mappings but it has morphed in that direction and its use is + strongly discouraged in newer code and the set of the preceding functions + should be preferred. + + On 64-bit systems, calls to kmap_local_page(), kmap_atomic() and kmap() = have + no real work to do because a 64-bit address space is more than sufficien= t to + address all the physical memory whose pages are permanently mapped. + +* vmap(). This can be used to make a long duration mapping of multiple + physical pages into a contiguous virtual space. It needs global + synchronization to unmap. =20 =20 Cost of Temporary Mappings --=20 2.34.1