Re: [PATCH 10/13] s390/qdio_setup: Use kzalloc() for QDIO buffers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Replacing get_zeroed_page() with kzalloc() breaks the strict 256-byte hardware alignment requirement for QDIO SBALs when memory debugging is enabled.
--

commit cef648048ee4dbd28b972a034767786968da0d5a
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>

s390/qdio_setup: Use kzalloc() for QDIO buffers

This commit replaces the use of get_zeroed_page() and free_page() with
kzalloc() and kfree() for allocating and freeing QDIO buffers.

Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com

> diff --git a/drivers/s390/cio/qdio_setup.c b/drivers/s390/cio/qdio_setup.c
> --- a/drivers/s390/cio/qdio_setup.c
> +++ b/drivers/s390/cio/qdio_setup.c

[ ... ]

> @@ -49,7 +49,7 @@ int qdio_alloc_buffers(struct qdio_buffer **buf, unsigned int count)
>  	int pos;
>  
>  	for (pos = 0; pos < count; pos += QBUFF_PER_PAGE) {
> -		buf[pos] = (void *) get_zeroed_page(GFP_KERNEL);
> +		buf[pos] = kzalloc(PAGE_SIZE, GFP_KERNEL);

[Severity: High]
Does this kzalloc() change break the 256-byte hardware alignment requirement
for QDIO SBALs?

The s390 QDIO hardware requires struct qdio_buffer to be strictly 256-byte
aligned.

While get_zeroed_page() guarantees page alignment, using kzalloc() with
PAGE_SIZE will fall into the kmalloc-4096 cache. If a memory debugging
feature like CONFIG_SLUB_DEBUG is enabled, the SLUB allocator adds a left
redzone before the object.

On s390, this redzone shifts the payload address by ARCH_KMALLOC_MINALIGN
(8 bytes). This shifts the address so the returned pointer is no longer
256-byte aligned, which can cause device probe failures or system crashes
when the misaligned address is rejected by the channel subsystem.

>  		if (!buf[pos]) {
>  			qdio_free_buffers(buf, count);
>  			return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-s390-cio-ready-v1-0-ca7f39806234@kernel.org?part=10