linux-kernel - Re: [PATCH v2] mm/highmem: Fix kernel-doc warnings in highmem*.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4058661.1IzOArtZ34@leap>
Date:   Tue, 19 Apr 2022 15:25:16 +0200
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Ira Weiny <ira.weiny@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Peter Collingbourne <pcc@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        linux-kernel@...r.kernel.org, outreachy@...ts.linux.dev
Subject: Re: [PATCH v2] mm/highmem: Fix kernel-doc warnings in highmem*.h

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