Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Message-ID: <4058661.1IzOArtZ34@leap>
In-Reply-To: <Yl6unkluUEeRZBbB@casper.infradead.org>
References: <20220418175638.30018-1-fmdefrancesco@gmail.com> <Yl6unkluUEeRZBbB@casper.infradead.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

On marted=C3=AC 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().
>=20
> I don't think this is a terribly useful paragraph?

I agree but let me remind you that this patch is _only_ about fixing=20
kernel-doc warnings. This warning was simply fixed by moving kdoc comment=20
from highmem.h to highmem-internal.h (which is the file where the=20
definition of kunmap_atomic() resides) and merging the text with few lines=
=20
that already were in highmem-internal.h.

=46urthermore, I've already had an "Acked-by:" tag from Mike Rapoport. I=20
suppose that if I changed the paragraph here I could not forward his ack to=
=20
the next version.

> > + * Effectively a wrapper around kunmap_local() which additionally=20
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=20
of
> > + * kmap_atomic(), not its argument which is a pointer to struct page.
>=20
> I'd rather this were useful advice to the caller than documentation of
> how it works.  How about:
>=20
>  * 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=20
ASAP. Probably, when I'll rework this text in a separate patch, I'll also=20
copy-paste the paragraph you wrote as-is (too easy!).

However, since the rework of the text in paragraph can only be applied on=20
top of this patch, I'm not sure if I should either (1) make a series with=20
two patches or (2) make a separate patch with a warning to Maintainers that=
=20
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=20
carried out. Any suggestion?

Thanks for your review and for suggesting a better suited text for the next=
=20
patch.

=46abio M. De Francesco