[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yl6unkluUEeRZBbB@casper.infradead.org>
Date: Tue, 19 Apr 2022 13:44:14 +0100
From: Matthew Wilcox <willy@...radead.org>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
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 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?
> + * 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.
Powered by blists - more mailing lists