linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Ira Weiny <ira.weiny@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Will Deacon <will@kernel.org>,
	Peter Collingbourne <pcc@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	Jonathan Corbet <corbet@lwn.net>
Cc: Mike Rapoport <rppt@linux.ibm.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/7] Documentation/mm: Don't kmap*() pages which can't come from HIGHMEM
Date: Thu, 28 Jul 2022 16:52:45 +0200	[thread overview]
Message-ID: <7426546.EvYhyI6sBW@opensuse> (raw)
In-Reply-To: <87czdykw4j.fsf@meer.lwn.net>

On giovedì 21 luglio 2022 23:13:00 CEST Jonathan Corbet wrote:
> "Fabio M. De Francesco" <fmdefrancesco@gmail.com> writes:
> 
> > There is no need to kmap*() pages which are guaranteed to come from
> > ZONE_NORMAL (or lower). Linux has currently several call sites of
> > kmap{,_atomic,_local_page}() on pages allocated, for instance, with
> > alloc_page(GFP_NOFS) and other similar allocations.
> >
> > Therefore, add a paragraph to highmem.rst, to explain better that a
> > plain page_address() should be used for getting the address of pages
> > which cannot come from ZONE_HIGHMEM.
> >
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: Mike Rapoport <rppt@linux.ibm.com>
> > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Suggested-by: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> > ---
> >  Documentation/vm/highmem.rst | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/
highmem.rst
> > index c9887f241c6c..f266354c82ab 100644
> > --- a/Documentation/vm/highmem.rst
> > +++ b/Documentation/vm/highmem.rst
> > @@ -71,6 +71,12 @@ list shows them in order of preference of use.
> >    kmap_local_page() always returns a valid virtual address and it is 
assumed
> >    that kunmap_local() will never fail.
> >  
> > +  On CONFIG_HIGHMEM=n kernels and for low memory pages this returns 
the
> > +  virtual address of the direct mapping. Only real highmem pages are
> > +  temporarily mapped. Therefore, users should instead call a plain
> > +  page_address() for getting the address of memory pages which, 
depending
> > +  on the GFP_* flags, cannot come from ZONE_HIGHMEM.
> > +
> 
> Is this good advice?

Well... yes and no :-) 

However yours is a legit objection. 

I'm taking most of the suggestion from Ira (from an email in this same 
thread) and send the v2 of this series.

My intention was to avoid things like those I encountered when converting 
fs/btrfs:

page = alloc_page(GFP_NOFS);
kaddr = kmap(page);

Why one should kmap*() pages allocated one or two lines above with 
GFP_NOFS? 

Furthermore, since nesting kmap_local_page() / kunmap_local() is last in 
first out (LIFO), I had several problems with several un-mappings until 
David Sterba made me notice that GFP_NOFS is not OR'ed with __GFP_HIGHMEM 
and suggested to use plain page_address() instead of those unnecessary 
mappings.

However, you are right about the fact that, with most of other allocations, 
it is not so clear where and how pages are being allocated.

Thanks,

Fabio 

> First, it requires developers to worry about
> whether their pages might be in highmem, which is kind of like worrying
> about having coins in your pocket in case you need a payphone.  But it
> would also run afoul of other semantics for kmap*(), such as PKS, should
> that ever be merged:
> 
>   https://lwn.net/Articles/894531/
>
> Thanks,
> 
> jon
> 





  parent reply	other threads:[~2022-07-28 14:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 21:01 [PATCH 0/7] highmem: Extend kmap_local_page() documentation Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 1/7] highmem: Remove unneeded spaces in kmap_local_page() kdocs Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 2/7] highmem: Specify that kmap_local_page() is callable from interrupts Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 3/7] Documentation/mm: Don't kmap*() pages which can't come from HIGHMEM Fabio M. De Francesco
2022-07-21 21:13   ` Jonathan Corbet
2022-07-22  0:44     ` Ira Weiny
2022-07-28 14:52     ` Fabio M. De Francesco [this message]
2022-07-21 21:02 ` [PATCH 4/7] Documentation/mm: Avoid invalid use of addresses from kmap_local_page() Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 5/7] Documentation/mm: Prefer kmap_local_page() and avoid kmap() Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 6/7] highmem: Delete a sentence from kmap_local_page() kdocs Fabio M. De Francesco
2022-07-21 21:02 ` [PATCH 7/7] Documentation/mm: Add details about kmap_local_page() and preemption Fabio M. De Francesco

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=7426546.EvYhyI6sBW@opensuse \
    --to=fmdefrancesco@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=ira.weiny@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pcc@google.com \
    --cc=rppt@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).