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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox