From: Mike Rapoport <rppt@kernel.org>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: 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, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, outreachy@lists.linux.dev,
Mike Rapoport <rppt@linux.ibm.com>
Subject: Re: [PATCH 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h
Date: Fri, 22 Apr 2022 11:24:14 +0300 [thread overview]
Message-ID: <YmJmLrS3hPR6gOaw@kernel.org> (raw)
In-Reply-To: <20220421180200.16901-2-fmdefrancesco@gmail.com>
On Thu, Apr 21, 2022 at 08:01:57PM +0200, Fabio M. De Francesco wrote:
> `scripts/kernel-doc -v -none include/linux/highmem*` reports the following
> warnings:
>
> include/linux/highmem.h:160: warning: expecting prototype for kunmap_atomic(). Prototype was for nr_free_highpages() instead
> include/linux/highmem.h:204: warning: No description found for return value of 'alloc_zeroed_user_highpage_movable'
> include/linux/highmem-internal.h:256: warning: Function parameter or member '__addr' not described in 'kunmap_atomic'
> include/linux/highmem-internal.h:256: warning: Excess function parameter 'addr' description in 'kunmap_atomic'
>
> Fix these warnings by (1) moving the kernel-doc comments from highmem.h to
> highmem-internal.h (which is the file were the kunmap_atomic() macro is
> actually defined), (2) extending and merging it with the comment which was
> already in highmem-internal.h, and (3) using correct parameter names.
>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> ---
> include/linux/highmem-internal.h | 14 +++++++++++---
> include/linux/highmem.h | 15 +++------------
> 2 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-internal.h
> index a77be5630209..b099a08e29d3 100644
> --- a/include/linux/highmem-internal.h
> +++ b/include/linux/highmem-internal.h
> @@ -236,9 +236,17 @@ static inline unsigned long totalhigh_pages(void) { return 0UL; }
>
> #endif /* CONFIG_HIGHMEM */
>
> -/*
> - * Prevent people trying to call kunmap_atomic() as if it were kunmap()
> - * kunmap_atomic() should get the return value of kmap_atomic, not the page.
> +/**
> + * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic()
> + * @__addr: Virtual address to be unmapped
> + *
> + * Unmap an address previously mapped by kmap_atomic() and re-enables
Unmap ... and re-enable
or
Unmaps ... and re-enables
Other than that
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> + * pagefaults and preemption. 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 it. The compiler will warn you if you pass the page.
> */
> #define kunmap_atomic(__addr) \
> do { \
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index 39bb9b47fa9c..c3d562b5f0c1 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -37,7 +37,7 @@ static inline void *kmap(struct page *page);
>
> /**
> * kunmap - Unmap the virtual address mapped by kmap()
> - * @addr: Virtual address to be unmapped
> + * @page: Virtual address to be unmapped
> *
> * Counterpart to kmap(). A NOOP for CONFIG_HIGHMEM=n and for mappings of
> * pages in the low memory area.
> @@ -145,17 +145,6 @@ static inline void *kmap_local_folio(struct folio *folio, size_t offset);
> */
> static inline void *kmap_atomic(struct page *page);
>
> -/**
> - * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic()
> - * @addr: Virtual address to be unmapped
> - *
> - * Counterpart to kmap_atomic().
> - *
> - * Effectively a wrapper around kunmap_local() which additionally undoes
> - * the side effects of kmap_atomic(), i.e. reenabling pagefaults and
> - * preemption.
> - */
> -
> /* Highmem related interfaces for management code */
> static inline unsigned int nr_free_highpages(void);
> static inline unsigned long totalhigh_pages(void);
> @@ -191,6 +180,8 @@ static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
> * @vma: The VMA the page is to be allocated for
> * @vaddr: The virtual address the page will be inserted into
> *
> + * Returns: The allocated and zeroed HIGHMEM page
> + *
> * This function will allocate a page for a VMA that the caller knows will
> * be able to migrate in the future using move_pages() or reclaimed
> *
> --
> 2.34.1
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-04-22 8:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 18:01 [PATCH 0/4] Extend and reorganize Highmem's documentation Fabio M. De Francesco
2022-04-21 18:01 ` [PATCH 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Fabio M. De Francesco
2022-04-22 8:24 ` Mike Rapoport [this message]
2022-04-22 9:36 ` Fabio M. De Francesco
2022-04-22 10:32 ` Mike Rapoport
2022-04-22 18:08 ` Ira Weiny
2022-04-22 20:42 ` Fabio M. De Francesco
2022-04-21 18:01 ` [PATCH 2/4] Documentation/vm: Include kdocs from highmem*.h into highmem.rst Fabio M. De Francesco
2022-04-22 8:33 ` Mike Rapoport
2022-04-22 18:09 ` Ira Weiny
2022-04-21 18:01 ` [PATCH 3/4] Documentation/vm: Remove "Using kmap-atomic" from highmem.rst Fabio M. De Francesco
2022-04-22 18:38 ` Ira Weiny
2022-04-22 20:09 ` Fabio M. De Francesco
2022-04-21 18:02 ` [PATCH 4/4] Documentation/vm: Rework "Temporary Virtual Mappings" Fabio M. De Francesco
2022-04-25 0:59 ` Ira Weiny
2022-04-25 1:42 ` Fabio M. De Francesco
2022-04-25 2:05 ` Fabio M. De Francesco
2022-04-25 16:51 ` Ira Weiny
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=YmJmLrS3hPR6gOaw@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=fmdefrancesco@gmail.com \
--cc=ira.weiny@intel.com \
--cc=linux-doc@vger.kernel.org \
--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.