From: Bagas Sanjaya <bagasdotme@gmail.com>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Ira Weiny <ira.weiny@intel.com>, Mike Rapoport <rppt@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Cc: Mike Rapoport <rppt@linux.ibm.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] mm/highmem: Add notes about conversions from kmap{,_atomic}()
Date: Thu, 8 Dec 2022 11:22:37 +0700 [thread overview]
Message-ID: <Y5FmjdBNEO8aP/Ls@debian.me> (raw)
In-Reply-To: <20221207225308.8290-1-fmdefrancesco@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
On Wed, Dec 07, 2022 at 11:53:08PM +0100, Fabio M. De Francesco wrote:
> diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
> index 0f731d9196b0..59d1078f53df 100644
> --- a/Documentation/mm/highmem.rst
> +++ b/Documentation/mm/highmem.rst
> @@ -57,7 +57,8 @@ list shows them in order of preference of use.
> It can be invoked from any context (including interrupts) but the mappings
> can only be used in the context which acquired them.
>
> - This function should be preferred, where feasible, over all the others.
> + This function should always be used. kmap_atomic() and kmap() have been
> + deprecated.
"... always be used, whereas ..."
> + NOTE: Conversions to kmap_local_page() must take care to follow the mapping
> + restrictions imposed on kmap_local_page(). Furthermore, the code between
> + calls to kmap_atomic() and kunmap_atomic() may implicitly depend on the side
> + effects of atomic mappings, i.e. disabling page faults or preemption, or both.
> + In that case, explicit calls to pagefault_disable() or preempt_disable() or
> + both must be made in conjunction with the use of kmap_local_page().
> +
> <snipped>...
> + NOTE: Conversions to kmap_local_page() must take care to follow the mapping
> + restrictions imposed on kmap_local_page(). In particular, it is necessary to
> + make sure that the kernel virtual memory pointer is only valid in the thread
> + that obtained it.
> +
What about using note block to signify conversion notes above?
---- >8 ----
diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
index 59d1078f53df57..ef53eb580d4cda 100644
--- a/Documentation/mm/highmem.rst
+++ b/Documentation/mm/highmem.rst
@@ -103,12 +103,14 @@ list shows them in order of preference of use.
* kmap_atomic(). This function has been deprecated; use kmap_local_page().
- NOTE: Conversions to kmap_local_page() must take care to follow the mapping
- restrictions imposed on kmap_local_page(). Furthermore, the code between
- calls to kmap_atomic() and kunmap_atomic() may implicitly depend on the side
- effects of atomic mappings, i.e. disabling page faults or preemption, or both.
- In that case, explicit calls to pagefault_disable() or preempt_disable() or
- both must be made in conjunction with the use of kmap_local_page().
+ .. note::
+ Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). Furthermore, the code between
+ calls to kmap_atomic() and kunmap_atomic() may implicitly depend on the
+ side effects of atomic mappings, i.e. disabling page faults or preemption,
+ or both. In that case, explicit calls to pagefault_disable() or
+ preempt_disable() or both must be made in conjunction with the use of
+ kmap_local_page().
[Legacy documentation]
@@ -129,10 +131,11 @@ list shows them in order of preference of use.
* kmap(). This function has been deprecated; use kmap_local_page().
- NOTE: Conversions to kmap_local_page() must take care to follow the mapping
- restrictions imposed on kmap_local_page(). In particular, it is necessary to
- make sure that the kernel virtual memory pointer is only valid in the thread
- that obtained it.
+ .. note::
+ Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). In particular, it is necessary
+ to make sure that the kernel virtual memory pointer is only valid in the
+ thread that obtained it.
[Legacy documentation]
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-12-08 4:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 22:53 Fabio M. De Francesco
2022-12-08 4:22 ` Bagas Sanjaya [this message]
2022-12-08 20:05 ` Fabio M. De Francesco
2022-12-09 3:26 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5FmjdBNEO8aP/Ls@debian.me \
--to=bagasdotme@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=corbet@lwn.net \
--cc=fmdefrancesco@gmail.com \
--cc=ira.weiny@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox