From: sashiko-bot@kernel.org
To: "Jonathan Corbet" <corbet@lwn.net>, linux-mm@kvack.org
Cc: "Shuah Khan" <skhan@linuxfoundation.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>
Subject: Re: [PATCH] docs: core-api: include documentation from linux/uaccess.h
Date: Thu, 22 Oct 2026 22:54:59 +0000 [thread overview]
Message-ID: <sashiko-outbox-182137@kernel.org> (raw)
In-Reply-To: <878q3q4qby.fsf@trenco.lwn.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] docs: core-api: kernel-doc and Sphinx warnings from linux/uaccess.h
--
commit 2999ceef858b0ddc1bc84f5c20261a45d3fb5ade
Author: Jonathan Corbet <corbet@lwn.net>
docs: core-api: include documentation from linux/uaccess.h
This commit adds a kernel-doc directive to Documentation/core-api/mm-api.rst
to include internal kernel-doc comments from include/linux/uaccess.h.
> diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst
> index c1d03a5a2a192..b8c00bc5314e1 100644
> --- a/Documentation/core-api/mm-api.rst
> +++ b/Documentation/core-api/mm-api.rst
> @@ -8,6 +8,9 @@ User Space Memory Access
> .. kernel-doc:: arch/x86/include/asm/uaccess.h
> :internal:
>
> +.. kernel-doc:: include/linux/uaccess.h
> + :internal:
> +
> .. kernel-doc:: arch/x86/lib/usercopy_32.c
> :export:
>
[Severity: Low]
Does pulling include/linux/uaccess.h into the documentation build introduce
kernel-doc and Sphinx warnings during make htmldocs?
First, in include/linux/uaccess.h, the comments above
copy_struct_from_bounce_buffer() and copy_struct_to_bounce_buffer() start
with /** without a kernel-doc identifier line:
/**
* This is like copy_struct_from_user(), but the
* src buffer was already copied into a kernel
* bounce buffer, so it will never return -EFAULT.
*/
static __always_inline __must_check int
copy_struct_from_bounce_buffer(void *dst, size_t dstsize,
const void *src, size_t srcsize)
When KernelDoc.process_name() in tools/lib/python/kdoc/kdoc_parser.py parses
these comments, it emits a warning that the comment starts with /** but is
not a valid kernel-doc comment, and omits both functions from the generated
output.
Second, the kernel-doc comments for copy_struct_from_user(),
copy_struct_to_user(), and __scoped_user_access() in include/linux/uaccess.h
include indented C code examples preceded by : or . rather than a :: literal
block marker:
* @ksize is just sizeof(*dst), and @usize should've been passed by userspace.
* The recommended usage is something like the following:
*
* SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
* {
* int err;
* struct foo karg = {};
and in __scoped_user_access():
* wrapped. See unsafe_get_user() for reference.
*
* scoped_user_rw_access(ptr, efault) {
* unsafe_get_user(rval, &ptr->rval, efault);
* unsafe_put_user(wval, &ptr->wval, efault);
* }
* return 0;
* efault:
* return -EFAULT;
Without ::, RestFormat.output_highlight() in
tools/lib/python/kdoc/kdoc_output.py does not treat these blocks as literal
code, causing Sphinx to emit unexpected unindent warnings on the closing
braces and the efault: label, as well as inline emphasis warnings on the
unescaped pointer asterisks in sizeof(*dst), sizeof(*src), and
struct foo __user *.
Finally, in __scoped_user_access(), scoped_user_read_access(),
scoped_user_write_access(), and scoped_user_rw_access() in
include/linux/uaccess.h, parameter references sit directly adjacent to
token-pasting or dereference operators:
* When the scope is left user_##@_mode##_access_end() is automatically
and:
* The size of the access starting from @usrc is determined via sizeof(*@usrc)).
RestFormat expands @param into **param**, turning these into
user_##**_mode**##_access_end() and sizeof(***usrc**)) (along with *@udst and
*@uptr), which triggers further Sphinx inline strong/emphasis markup
warnings. Should the comments in include/linux/uaccess.h be cleaned up before
including the header in Documentation/core-api/mm-api.rst?
--
Sashiko AI review · https://sashiko.dev/#/patchset/878q3q4qby.fsf@trenco.lwn.net?part=1
prev parent reply other threads:[~2026-10-22 22:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 22:54 [PATCH] docs: core-api: include documentation from linux/uaccess.h Jonathan Corbet
2026-10-21 23:03 ` Andrew Morton
2026-10-22 13:28 ` Jonathan Corbet
2026-10-22 22:54 ` sashiko-bot [this message]
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=sashiko-outbox-182137@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=linux-mm@kvack.org \
--cc=rdunlap@infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skhan@linuxfoundation.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.