From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ira Weiny <ira.weiny@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Peter Collingbourne <pcc@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mike Rapoport <rppt@linux.ibm.com>,
linux-kernel@vger.kernel.org, outreachy@lists.linux.dev
Subject: Re: [PATCH v2] mm/highmem: Fix kernel-doc warnings in highmem*.h
Date: Tue, 19 Apr 2022 15:25:16 +0200 [thread overview]
Message-ID: <4058661.1IzOArtZ34@leap> (raw)
In-Reply-To: <Yl6unkluUEeRZBbB@casper.infradead.org>
On martedì 19 aprile 2022 14:44:14 CEST Matthew Wilcox wrote:
> On Mon, Apr 18, 2022 at 07:56:38PM +0200, Fabio M. De Francesco wrote:
> > +/**
> > + * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic()
> > + * @__addr: Virtual address to be unmapped
> > + *
> > + * Counterpart to kmap_atomic().
>
> I don't think this is a terribly useful paragraph?
I agree but let me remind you that this patch is _only_ about fixing
kernel-doc warnings. This warning was simply fixed by moving kdoc comment
from highmem.h to highmem-internal.h (which is the file where the
definition of kunmap_atomic() resides) and merging the text with few lines
that already were in highmem-internal.h.
Furthermore, I've already had an "Acked-by:" tag from Mike Rapoport. I
suppose that if I changed the paragraph here I could not forward his ack to
the next version.
> > + * Effectively a wrapper around kunmap_local() which additionally
undoes
> > + * the side effects of kmap_atomic(), i.e. reenabling pagefaults and
> > + * preemption. Prevent people trying to call kunmap_atomic() as if it
> > + * were kunmap() because kunmap_atomic() should get the return value
of
> > + * kmap_atomic(), not its argument which is a pointer to struct page.
>
> I'd rather this were useful advice to the caller than documentation of
> how it works. How about:
>
> * Unmap an address previously mapped by kmap_atomic(). 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 kmap_atomic().
> * The compiler will warn you if you pass the page.
A change like this should go to a separate patch and indeed I'll send it
ASAP. Probably, when I'll rework this text in a separate patch, I'll also
copy-paste the paragraph you wrote as-is (too easy!).
However, since the rework of the text in paragraph can only be applied on
top of this patch, I'm not sure if I should either (1) make a series with
two patches or (2) make a separate patch with a warning to Maintainers that
the changes in the new patch can only be applied on top of this patch.
Actually, I don't yet know how the Community wants tasks like these to be
carried out. Any suggestion?
Thanks for your review and for suggesting a better suited text for the next
patch.
Fabio M. De Francesco
next prev parent reply other threads:[~2022-04-19 13:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 17:56 [PATCH v2] mm/highmem: Fix kernel-doc warnings in highmem*.h Fabio M. De Francesco
2022-04-19 12:44 ` Matthew Wilcox
2022-04-19 13:25 ` Fabio M. De Francesco [this message]
2022-04-19 14:52 ` Ira Weiny
2022-04-19 15:09 ` Fabio M. De Francesco
2022-04-19 17:13 ` Fabio M. De Francesco
2022-04-21 17:50 ` 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=4058661.1IzOArtZ34@leap \
--to=fmdefrancesco@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=outreachy@lists.linux.dev \
--cc=pcc@google.com \
--cc=rppt@linux.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.