From: Akira Yokosawa <akiyks@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Akira Yokosawa <akiyks@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Duplicate kernel-doc comments for ksize()
Date: Mon, 7 Nov 2022 19:41:05 +0900 [thread overview]
Message-ID: <d33440f6-40cf-9747-3340-e54ffaf7afb8@gmail.com> (raw)
Hi Kees,
"make htmldocs" reports duplicate C declaration of ksize()
as follows:
/linux/Documentation/core-api/mm-api:43: ./mm/slab_common.c:1428: WARNING: Duplicate C declaration, also defined at core-api/mm-api:212.
Declaration is '.. c:function:: size_t ksize (const void *objp)'.
This is due to the kernel-doc comment for ksize() added in
include/linux/slab.h by a commit you have authored:
05a940656e1e ("slab:Introduce kmalloc_size_roundup()").
/**
* ksize - Report actual allocation size of associated object
*
* @objp: Pointer returned from a prior kmalloc()-family allocation.
*
* This should not be used for writing beyond the originally requested
* allocation size. Either use krealloc() or round up the allocation size
* with kmalloc_size_roundup() prior to allocation. If this is used to
* access beyond the originally requested allocation size, UBSAN_BOUNDS
* and/or FORTIFY_SOURCE may trip, since they only know about the
* originally allocated size via the __alloc_size attribute.
*/
There is another kernel-doc comment in mm/slab_common.c (originally
by Manfred, since v2.6.14):
/**
* ksize - get the actual amount of memory allocated for a given object
* @objp: Pointer to the object
*
* kmalloc may internally round up allocations and return more memory
* than requested. ksize() can be used to determine the actual amount of
* memory allocated. The caller may use this additional memory, even though
* a smaller amount of memory was initially specified with the kmalloc call.
* The caller must guarantee that objp points to a valid object previously
* allocated with either kmalloc() or kmem_cache_alloc(). The object
* must not be freed during the duration of the call.
*
* Return: size of the actual memory used by @objp in bytes
*/
I guess the one in slab_common.c is outdated and can be removed.
Can you please take care of it?
Thanks, Akira
next reply other threads:[~2022-11-07 10:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 10:41 Akira Yokosawa [this message]
2022-11-07 16:23 ` Vlastimil Babka
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=d33440f6-40cf-9747-3340-e54ffaf7afb8@gmail.com \
--to=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
/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