Linux s390 Architecture development
 help / color / mirror / Atom feed
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

  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