From: sashiko-bot@kernel.org
To: "Mete Durlu" <meted@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v5] s390/diag204: Add common diag204 interface with caching
Date: Thu, 05 Nov 2026 16:04:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-199402@kernel.org> (raw)
In-Reply-To: <20261104-diag204ioctl-v5-1-87a96638d58a@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] s390/diag204: diag204_allocate_buffer() does not zero buffer as documented
--
commit 58fe47d5083de8e19767f3f73d70eeda63fea0cc
Author: Mete Durlu <meted@linux.ibm.com>
s390/diag204: Add common diag204 interface with caching
This commit introduces a shared diag204 implementation in
arch/s390/kernel/diag/diag204.c with a one-second data cache and converts
hypfs and sthyi to use it.
> diff --git a/arch/s390/kernel/diag/diag204.c b/arch/s390/kernel/diag/diag204.c
> new file mode 100644
> index 0000000000000..dc4b9df8ba925
> --- /dev/null
> +++ b/arch/s390/kernel/diag/diag204.c
[ ... ]
> +static void *__diag204_allocate_buffer(int pages)
> +{
> + return __vmalloc_node(array_size(pages, PAGE_SIZE),
> + PAGE_SIZE, GFP_KERNEL, NUMA_NO_NODE,
> + __builtin_return_address(0));
> +}
> +
> +/**
> + * diag204_allocate_buffer() - Allocate a buffer for diag204
> + *
> + * Allocate a zeroed, page aligned vmalloc'ed buffer of diag204_get_buf_size()
> + * bytes, as required by diag204. The size is determined at initialization
> + * of diag204. Must only be called if diag204_is_available() returns true.
> + *
> + * Context: Can sleep (GFP_KERNEL).
> + * Return: Pointer to the buffer on success, NULL on failure.
> + */
> +void *diag204_allocate_buffer(void)
> +{
> + return __diag204_allocate_buffer(diag204_cache_info.pages);
> +}
[ ... ]
> +/**
> + * diag204_store() - Store diag204 data
> + * @buf: Diag204 data buffer allocated using
> + * diag204_allocate_buffer() or a page aligned, zeroed buffer
> + * with a size acquired from diag204_get_buf_size().
> + * @allow_busy: Allow diag204 to return -EBUSY instead of blocking and
> + * return early when there is a concurrent updater.
> + *
> + * Diag204 queries CPU utilization data from the hypervisor. Per CPU
> + * utilization information is returned either only for the current guest
> + * or, with authorization for all guests configured.
> + *
> + * Context: diag204_store() can sleep and holds diag204_mutex to serialize
> + * diag204 cache access.
> + *
> + * Return:
> + * * 0 on success
> + * * -EOPNOTSUPP diag204 is not supported
> + * * -EINVAL if @buf is NULL
> + * * -ENOMEM if the temporary buffer could not be allocated
> + * * -EBUSY if @allow_busy is set and diag204 or a concurrent cache update
> + * is busy
> + * * -EINTR if interrupted by a signal
> + */
> +int diag204_store(void *buf, bool allow_busy)
> +{
> + int rc;
> +
> + if (!diag204_is_available())
> + return -EOPNOTSUPP;
> + if (!buf)
> + return -EINVAL;
> + rc = 0;
> + if (allow_busy) {
> + if (!mutex_trylock(&diag204_mutex))
> + return -EBUSY;
> + } else {
> + if (mutex_lock_killable(&diag204_mutex))
> + return -EINTR;
> + }
> + if (diag204_is_cache_valid())
> + goto copy;
> + rc = diag204_update_cache(allow_busy);
> + if (rc)
> + goto out;
> +copy:
> + memcpy(buf, diag204_cache_info.buf, diag204_get_buf_size());
> +out:
> + mutex_unlock(&diag204_mutex);
> + return rc;
> +}
[Severity: Low]
This isn't a bug for current in-tree callers since diag204_update_cache()
zeroes diag204_cache_info.buf with memset() and diag204_store() overwrites
the caller buffer via memcpy(), but does diag204_allocate_buffer() actually
zero the allocated memory as documented?
In arch/s390/kernel/diag/diag204.c, diag204_allocate_buffer() calls
__diag204_allocate_buffer(), which invokes __vmalloc_node() with GFP_KERNEL
and without __GFP_ZERO, returning uninitialized memory despite the
kernel-doc stating that it allocates a zeroed buffer.
Similarly, the kernel-doc for diag204_store() states that buf must be a
page-aligned, zeroed buffer, even though diag204_store() only copies from
diag204_cache_info.buf into buf via memcpy().
Should __diag204_allocate_buffer() pass GFP_KERNEL | __GFP_ZERO, or should
the kernel-doc comments on diag204_allocate_buffer() and diag204_store() be
updated to match the implementation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-diag204ioctl-v5-1-87a96638d58a@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-11-05 16:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 9:24 [PATCH v5] s390/diag204: Add common diag204 interface with caching Mete Durlu
2026-11-05 16:04 ` sashiko-bot [this message]
2026-11-05 23:06 ` Ilya Leoshkevich
2026-11-06 11:12 ` Mete Durlu
2026-11-06 15:38 ` Heiko Carstens
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-199402@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=meted@linux.ibm.com \
--cc=sashiko-reviews@lists.linux.dev \
/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