From nobody Sun May 10 17:52:28 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 0EEECC433FE for ; Thu, 28 Apr 2022 21:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352280AbiD1V2X (ORCPT ); Thu, 28 Apr 2022 17:28:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346246AbiD1V2U (ORCPT ); Thu, 28 Apr 2022 17:28:20 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E649A2AC74; Thu, 28 Apr 2022 14:25:03 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id z99so6947636ede.5; Thu, 28 Apr 2022 14:25:03 -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=ppYYO/QcHXh+XwuTgyF/cB3OHqHt+JEBwYTQgvTmB4w=; b=S4w2DpJOy6Gm9MbpSPAWiXEqsxK7mI0aoRqoY49TL8lej2yqCvi+JHWEWhsLBQVeTY PEXwPd9KoiX+O+BmnuFKE1PZF7QCLsz/z3spRiPZwd2LPrHit7DeiAFsYuxDnHDWMlW3 pHjUmIA1X9hfIac19ag8aUyveCRuAs8b/6a0NmIrH+qiYCa8FMkc5kG2Rsm2cn8yi9R4 jciWKjCdlLLG0W/mI5ZkXL5YQQLjQ8JpIhT/bG5WHED4kzEBPn0zBBLIDMYkqRlt3jXj JXRyz4QMD0q8CTf2g1fvNq6O+/uHmPmOW8EDXEUMzy8UIlhLLW4YMr346zQhjvtS7qOX J2zg== 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=ppYYO/QcHXh+XwuTgyF/cB3OHqHt+JEBwYTQgvTmB4w=; b=GgRXhVkZti/CNfUc9cIrLHvq3kBQ5iReQ5m3d+7bTL5nzpFXQUqajw252139vCGIZA FDOWeDl00URIIZUoxliEuS74nxnMLO9JjToFo+VgEHv0Lo2A5xlaLQUwnPpL/u4D/mg7 tNI9X/qmwOMg2bDIjQCXTM/OPgJHOjbDjXRue+T0q0qHXR85NZ0+HxV5TXvWmkfWYUIs WyMRgUaTq3YD/yLBSBs33fn58bUOlmWcOy4zmSuwyIKF9DeIYeemdZF/9wD2Wdwh9DMZ lzqvIIK37DyqfKidqmucGZL9SlybrQLn52kCwr7vqPUtkrczsfenHmWs9/BXO3YdlIgZ IZHg== X-Gm-Message-State: AOAM531cKg8rp/SsNKsLgj8iSH05mfleb8dTX6XnmkFHE7NkE6bR9udH gPhOsYb86Fu3GBNDQJK5z7pwPlvoNJ0= X-Google-Smtp-Source: ABdhPJyCn1ofuojZO83kgw/52oDRKyEiV+0sOg0pthepaEqDl1+xumjDuiKzE4rqgXz2Feo4PrwZjQ== X-Received: by 2002:a05:6402:2753:b0:423:3895:7031 with SMTP id z19-20020a056402275300b0042338957031mr38053336edd.170.1651181102319; Thu, 28 Apr 2022 14:25:02 -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 ze12-20020a170906ef8c00b006f3ef214e68sm37147ejb.206.2022.04.28.14.25.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 14:25:01 -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, linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Mike Rapoport Subject: [PATCH v4 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Date: Thu, 28 Apr 2022 23:24:52 +0200 Message-Id: <20220428212455.892-2-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220428212455.892-1-fmdefrancesco@gmail.com> References: <20220428212455.892-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 (4) correcting a few technical inaccuracies in comments, and (5) adding a deprecation notice in kunmap_atomic() for consistency with kmap_atomic(). Cc: Ira Weiny Cc: Matthew Wilcox Cc: Mike Rapoport Cc: Sebastian Andrzej Siewior Signed-off-by: Fabio M. De Francesco Reviewed-by: Ira Weiny Reviewed-by: Sebastian Andrzej Siewior --- include/linux/highmem-internal.h | 18 +++++++++++++++--- include/linux/highmem.h | 22 ++++++++-------------- 2 files changed, 23 insertions(+), 17 deletions(-) diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-inter= nal.h index a77be5630209..a694ca95c4ed 100644 --- a/include/linux/highmem-internal.h +++ b/include/linux/highmem-internal.h @@ -236,9 +236,21 @@ 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() - dep= recated! + * @__addr: Virtual address to be unmapped + * + * Unmaps an address previously mapped by kmap_atomic() and re-enables + * pagefaults. Depending on PREEMP_RT configuration, re-enables also + * migration and preemption. Users should not count on these side effects. + * + * Mappings should be unmapped in the reverse order that they were mapped. + * See kmap_local_page() for details on nesting. + * + * @__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..f6c2d9beff2c 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: Pointer to the page which was mapped by kmap() * * Counterpart to kmap(). A NOOP for CONFIG_HIGHMEM=3Dn and for mappings of * pages in the low memory area. @@ -138,24 +138,16 @@ static inline void *kmap_local_folio(struct folio *fo= lio, size_t offset); * * Returns: The virtual address of the mapping * - * Effectively a wrapper around kmap_local_page() which disables pagefaults - * and preemption. + * In fact a wrapper around kmap_local_page() which also disables pagefaul= ts + * and, depending on PREEMPT_RT configuration, also CPU migration and + * preemption. Therefore users should not count on the latter two side eff= ects. + * + * Mappings should always be released by kunmap_atomic(). * * Do not use in new code. Use kmap_local_page() instead. */ 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 +183,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 17:52:28 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 B89DAC433F5 for ; Thu, 28 Apr 2022 21:25:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344358AbiD1V2a (ORCPT ); Thu, 28 Apr 2022 17:28:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352281AbiD1V2X (ORCPT ); Thu, 28 Apr 2022 17:28:23 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A74A2DCF; Thu, 28 Apr 2022 14:25:06 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id gh6so12089785ejb.0; Thu, 28 Apr 2022 14:25:06 -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=zRInxovmtEp5kO7w1NKMCyeNmmaZA+H9IsO8MYD/nxk=; b=KN3k7n1J89F5FoVzgUechS/8skSrFw6kWMc2q1ASXXL4KXv8dVB+FxsubPDqxVFGXE 3A/ANpJs9MTx0T4NUzDWUu6HdoEF+FtABc273Ca1TW5enA32DJ/U8omw7xy01MtlngGI lxtWTL5KgGJQcTh8VSbRtPgRwIslY1m2+Mn9EUwAUebUjUZzE98LAz3+sCc/pXr58Yqj L1mvHY6oBYsokOOels/Wm0CuusmPEyRdo/HC/pHUBVQNFrbw13GOGaBEwQ5kV+wRlmEY /347sGz/0QD6KpTP7yCOUBO/acX1rktqqNI0BbnedLlOnBviq0PfO1rJ1lWnG4PEIEKj tySQ== 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=zRInxovmtEp5kO7w1NKMCyeNmmaZA+H9IsO8MYD/nxk=; b=OamQbILlxIbX2xD4WE36L1o9bbpgidJXBZOUcIld5mpxmv90NqexDfkj0Gaw2p96QD hx8sx2TgeL5lARgFVH2Cvo7F6e2AuYVijmHCagkRNPTRC2X0eT7HVZjveTpKdWNvyOpu XmwNu5j0oaQ2UIEA3M+SYAiAbu6JyU5p3HL8Dqm/X2aPi92XMxZ9Q+kTnnxUKINjl5TM jAyeGLzzZd3OlOmBx/RzZMUKQc8TPE1ZevGnwKj4JFUkiuMtKTRxn0X5GJoZI5Z+Dj60 1sFIOKjsRLy+qYQP7ibELB3+4+477Ss5cSxTUfq7Bt7Ha8D37+DdoaEuWBj0vKuUWjVR M5Iw== X-Gm-Message-State: AOAM532E5vhuiyPFeIm66/WO+UyoD+MF7EBN/Jt96z5nhbfzZrjJ4Rff 3B+MOpqvavctTjl9s+ECthaYDOUJRtQ= X-Google-Smtp-Source: ABdhPJyps6JAZvGLNCALZ+xOu3cOWTimaZltmVZngEsBX7uAGmmNMQAy5qaL+rn1kwIdJ5q7+wXk7Q== X-Received: by 2002:a17:906:4fcb:b0:6f3:b710:9752 with SMTP id i11-20020a1709064fcb00b006f3b7109752mr14085271ejw.445.1651181104913; Thu, 28 Apr 2022 14:25:04 -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 ze12-20020a170906ef8c00b006f3ef214e68sm37147ejb.206.2022.04.28.14.25.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 14:25:03 -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, linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Jonathan Corbet , Peter Zijlstra , Thomas Gleixner , Mike Rapoport Subject: [PATCH v4 2/4] Documentation/vm: Include kdocs from highmem*.h into highmem.rst Date: Thu, 28 Apr 2022 23:24:53 +0200 Message-Id: <20220428212455.892-3-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220428212455.892-1-fmdefrancesco@gmail.com> References: <20220428212455.892-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: Matthew Wilcox Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Thomas Gleixner Suggested-by: Ira Weiny Acked-by: Mike Rapoport Reviewed-by: Ira Weiny Signed-off-by: Fabio M. De Francesco Reviewed-by: Sebastian Andrzej Siewior --- 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 17:52:28 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 6877BC433F5 for ; Thu, 28 Apr 2022 21:25:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352302AbiD1V2j (ORCPT ); Thu, 28 Apr 2022 17:28:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346246AbiD1V2Z (ORCPT ); Thu, 28 Apr 2022 17:28:25 -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 D679328E02; Thu, 28 Apr 2022 14:25:08 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id gh6so12089933ejb.0; Thu, 28 Apr 2022 14:25:08 -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=1x1kv/2gsKv5kOdZxXlxwoC/jLBT43h35UaSYyMNEo0=; b=hP7IaUTq3VQr6MTRLm48mtplWcj1hE4aDP0etWxNI5zXEF1mHnWwHHeBDrosiX9+gA v1lqA1UQd1Rc8zGMnLg3pjc6M1FdDJChmhkTOSv/CcPzvyyubWCSFbrUYfodz/mNnhWz L3yIX8iWmKb+qLTBD1SDviq1BQY2oaa1ZeuRA51ghUxrEFrOPS/r0Gus+pl9rVQ/miVz MujJAMMywglFlLvzcmpAZRzkKGB3Cl5TWE9bk3TqNa+REUJ3v808W3XN9URO3VFvCCrD kPfMzT9iujmq2ulb2mOT99RcI2ZQqCnY0LRifR6MCAsM2Vw10/3z1EOjIG1/6NVrwDCp vMow== 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=1x1kv/2gsKv5kOdZxXlxwoC/jLBT43h35UaSYyMNEo0=; b=myEttL6Jx3qs/qMjCL4RXE1hCIitoDZ45H0Wno0xB6EAEnURqOYIXoVVzcbDmXNwnX YfCP96CG+YkOjb5lx20FgkVbti81uFeGHtR4X/fpuweYSI+lF/yr0tjySiHyp7n6dSly XGtWFYK03MGQTTTPDRxAumyycc3oWQQidmTYDUWduBRK7R+w13S6Bto29GekHuRu3vHA lpSD1gY1qbXJ03q3UuOcUzYo1VFlXAet3VQNeKxEWHIz+fI+O10ZigInW5gpRtyX/qPg rxa62qtz1rEkfQJU3VW5EnZyZZ26YNNzBOEw1fdlnbK1RFKXJevw7JvtGLTssqw+8eEj b0og== X-Gm-Message-State: AOAM533CRuqNe/t/17HQhzegE8U7vybR2V53HAx1kx1FsaZhSfPHnsn3 y37qEVlaDy19KrgblVFaGR0= X-Google-Smtp-Source: ABdhPJynxAyQSQnhNPeCkGhKlNMBkNxtJ6xvuiPBpZT0sbcO6KQsyJhX5vCfoQjpVm95uTzcMNfOiA== X-Received: by 2002:a17:906:7947:b0:6da:892f:2503 with SMTP id l7-20020a170906794700b006da892f2503mr32835681ejo.710.1651181107326; Thu, 28 Apr 2022 14:25:07 -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 ze12-20020a170906ef8c00b006f3ef214e68sm37147ejb.206.2022.04.28.14.25.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 14:25:06 -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, linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Jonathan Corbet , Peter Zijlstra , Thomas Gleixner Subject: [PATCH v4 3/4] Documentation/vm: Move "Using kmap-atomic" to highmem.h Date: Thu, 28 Apr 2022 23:24:54 +0200 Message-Id: <20220428212455.892-4-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220428212455.892-1-fmdefrancesco@gmail.com> References: <20220428212455.892-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 new code is being deprecated in favor of kmap_local_page(). For this reason the "Using kmap_atomic" section in highmem.rst is obsolete and unnecessary, but it can still help developers if it were moved to kdocs in highmem.h. Therefore, move the relevant parts of this section from highmem.rst and merge them with the kdocs in highmem.h. Cc: Jonathan Corbet Cc: Matthew Wilcox Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Thomas Gleixner Suggested-by: Ira Weiny Signed-off-by: Fabio M. De Francesco Reviewed-by: Ira Weiny Reviewed-by: Sebastian Andrzej Siewior --- Documentation/vm/highmem.rst | 35 ----------------------------------- include/linux/highmem.h | 31 +++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 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 diff --git a/include/linux/highmem.h b/include/linux/highmem.h index f6c2d9beff2c..b37e8079fc40 100644 --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -145,6 +145,37 @@ static inline void *kmap_local_folio(struct folio *fol= io, size_t offset); * Mappings should always be released by kunmap_atomic(). * * Do not use in new code. Use kmap_local_page() instead. + * + * It is used in atomic context when code wants to access the contents of a + * page that might be allocated from high memory (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() + * call, 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); */ static inline void *kmap_atomic(struct page *page); =20 --=20 2.34.1 From nobody Sun May 10 17:52:28 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 DA7E8C433EF for ; Thu, 28 Apr 2022 21:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352327AbiD1V2r (ORCPT ); Thu, 28 Apr 2022 17:28:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352281AbiD1V2f (ORCPT ); Thu, 28 Apr 2022 17:28:35 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D6583121A; Thu, 28 Apr 2022 14:25:12 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id i19so11960607eja.11; Thu, 28 Apr 2022 14:25: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=fjmeDt2yw6BAdExaQDbjjx+V1POVPHBtHKYVuj5eu/o=; b=fLf+kEKk/G/GbMbYZt5wF/ids93UzRAoHIG3B8YA55Md415wTMhZ6buJEJhzPp0jxi f0LRl8xXnGjdUk8Aw5DEwshaBSBlzTyUKtcYV/vLXcbUwmw4pe/yL7gqFLGaj9k0Svj7 aLVphwY9a3V5/uhYl7a3OK0sc6CESzGHv/NiO4PtDASQuwQsnoTrHEiKMmj1bgptSYzl csr9DtT3WX7QefU+tdAt2zbdWuldi0i0wk5pF7WvzQf0pW+EEOguwnAMXyxIQtO24kyc mr7TsLofN2Bih8+HBzWmyoiDG+Je+T5T7VkbJXFQLXy1EmQwiBrHEHNWba/qJ09ETWn/ X9Xw== 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=fjmeDt2yw6BAdExaQDbjjx+V1POVPHBtHKYVuj5eu/o=; b=mJj+zWH5iZlNOyy/RXvRsKKiLSqv0twF6qFNvVIOCQVEVvpJY7I+2iNc69BUp/raGk nbuCHxxuPSSedz239dEgwGWbcQ+0Y8B5DNDroG69hwhP/54K58NEhiPHPcnkheEOCu4C TLNhDSeF+/dCaEYRhzuisbsrtsHlWlbZqe9Ji6xsB3b+mIhMAYsf5i6zNfi7ubdTzHHS zg0UsBVS4ESeKtY0+XoXb39RNWBbh1t4kWj1cxdFSyllSq8wdiZpATmSEECpAEhQSgpo sEyMovx2ZyhnS93i0ajAka0Y6Kb+z9jg5Uz9DHdHh5m34tMC4nsfFT5NGHz/6fqN8kOt zUwg== X-Gm-Message-State: AOAM531I20jAbB2XNF0QCI1mCyr8zGMMCydxFsHg4aSWZd1Yh/vv0dUJ x4xRUwcPljvz8HBtzZdpVVaHIRuq4WE= X-Google-Smtp-Source: ABdhPJyyyU/1nD7V6tY3Q4ZxnhlHdzsy3gzHd8vbn02vQxaSojptW962SPkdAPYR5crxUWUF4c4uYg== X-Received: by 2002:a17:906:478c:b0:6df:6b35:156d with SMTP id cw12-20020a170906478c00b006df6b35156dmr32858821ejc.578.1651181110717; Thu, 28 Apr 2022 14:25: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 ze12-20020a170906ef8c00b006f3ef214e68sm37147ejb.206.2022.04.28.14.25.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 14:25:08 -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, linux-doc@vger.kernel.org, outreachy@lists.linux.dev Cc: "Fabio M. De Francesco" , Jonathan Corbet , Peter Zijlstra , Thomas Gleixner Subject: [PATCH v4 4/4] Documentation/vm: Rework "Temporary Virtual Mappings" section Date: Thu, 28 Apr 2022 23:24:55 +0200 Message-Id: <20220428212455.892-5-fmdefrancesco@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220428212455.892-1-fmdefrancesco@gmail.com> References: <20220428212455.892-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: Matthew Wilcox Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Thomas Gleixner Suggested-by: Ira Weiny Signed-off-by: Fabio M. De Francesco Reviewed-by: Ira Weiny Reviewed-by: Sebastian Andrzej Siewior --- Documentation/vm/highmem.rst | 70 ++++++++++++++++++++++++++++++------ 1 file changed, 59 insertions(+), 11 deletions(-) diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index e05bf5524174..c9887f241c6c 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -50,26 +50,74 @@ 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 thread-local and CPU-local, meaning that the mapping + can only be accessed from within this thread and the thread is bound the + CPU while the mapping is active. Even if the thread is preempted (since + preemption is never disabled by the function) the CPU can not be + unplugged from the system via CPU-hotplug until the mapping is disposed. + + 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 reaso= ns. + + kmap_local_page() always returns a valid virtual address and it is assum= ed + that kunmap_local() will never fail. + + 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. See kmap_local_page() kdo= cs + (included in the "Functions" section) for details on how to manage nested + mappings. =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. Ther= efore + users should prefer kmap_local_page() instead of kmap_atomic(). =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 longer 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