[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YmL2EQhfQLMoU1WV@iweiny-desk3>
Date: Fri, 22 Apr 2022 11:38:09 -0700
From: Ira Weiny <ira.weiny@...el.com>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Will Deacon <will@...nel.org>,
Peter Collingbourne <pcc@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-doc@...r.kernel.org, outreachy@...ts.linux.dev,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 3/4] Documentation/vm: Remove "Using kmap-atomic" from
highmem.rst.
On Thu, Apr 21, 2022 at 08:01:59PM +0200, Fabio M. De Francesco wrote:
> The use of kmap_atomic() is deprecated in favor of kmap_local_page().
I'm not sure deprecated is the right word. And I think the fact that this
documentation is stale is a better reason for the patch as is.
This series should end up indicating the desire to stop growing kmap() and
kmap_atomic() call sites and that their deprecation is on the horizon. I've
not read the text in patch 4/4 yet.
> For
> this reason the "Using kmap_atomic" section in highmem.rst is obsolete and
> unnecessary.
A lot of the text is obsolete (and redundant) but the example code might be
useful.
Why not move the example and relevant bits into the kdoc for kmap_atomic()
which is then automatically picked up via patch 2/4.
Ira
>
> Therefore, just remove it.
>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ira Weiny <ira.weiny@...el.com>
> Cc: Matthew Wilcox <willy@...radead.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@...il.com>
> ---
> 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 mappings:
> It may be assumed that k[un]map_atomic() won't fail.
>
>
> -Using kmap_atomic
> -=================
> -
> -When and where to use kmap_atomic() is straightforward. It is used 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 = find_get_page(mapping, offset);
> -
> - /* Gain access to the contents of that page. */
> - void *vaddr = 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 = kmap_atomic(page1);
> - vaddr2 = kmap_atomic(page2);
> -
> - memcpy(vaddr1, vaddr2, PAGE_SIZE);
> -
> - kunmap_atomic(vaddr2);
> - kunmap_atomic(vaddr1);
> -
> -
> Cost of Temporary Mappings
> ==========================
>
> --
> 2.34.1
>
Powered by blists - more mailing lists