From: Mete Durlu <meted@linux.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Subject: Re: [PATCH 0/3] s390: Diag204 Rework
Date: Thu, 22 Oct 2026 09:04:56 +0200 [thread overview]
Message-ID: <eb11777b-5fd6-4bcf-9820-fbcc2f32d453@linux.ibm.com> (raw)
In-Reply-To: <20261021-diag204ioctl-v1-0-25645b97bf4e@linux.ibm.com>
On 21/10/2026 12:28, Mete Durlu wrote:
[...snip...]
> Considerations
> ========================================================================
> * At the moment diag204 size request returns a page count requirement of
> 423. That is the maximum amount of space needed currently for a CEC to
> service diag204.
> With this series at times there will be ~6Mb (1.6Mb for each; cache,
> temp, user buffer...) memory allocated for diag204 data per lpar.
>
> * With the new IOCTL interface, userspace is defaulted to the
> largest diag204 data request subcode available(from subcodes 4, 6 and
> 7 always the largest available is used as it returns more data).
> While this aligns with the existing behavior, question is, would
> there be any value in allowing users to specify which subcode to use?
> Although this also means more complicated implementation.
>
> * A new addition with the IOCTL interface are the allow_busy and
> allow_busy_wait toggles. For sure there is benefit in allowing diag204
> to return BUSY instead of waiting for longer durations when it is not
> ready at the moment. allow_busy_wait adds an interruptable polling
> loop around that, with that mechanism diag204 users from userspace can
> wait for diag204 to return from its BUSY state within the same system
> call. Obviously using only a single system call is better but diag204
> users are not performance critical atm and the same polling can be
> implemented from userspace side. This can help reduce some complexity
> on the kernel code.
>
> Changes from the earlier series;
> * Address mutex lockdep issues (Sumanth Korikkar)
> * Add permission check for IOCTL (Sumanth Korikkar)
> * Pass buffers set to 0 when calling diag (Sumanth Korikkar)
>
> ---
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
>
> Mete Durlu (3):
> s390/diag204: Introduce diag204 rework
> s390/diag204: Replace diag204 users with new implementation
> s390/diag: Add diag204 IOCTL to diag misc device
>
> arch/s390/hypfs/hypfs_diag.c | 140 ++------------
> arch/s390/hypfs/hypfs_diag.h | 4 +-
> arch/s390/hypfs/hypfs_diag_fs.c | 9 +-
> arch/s390/include/asm/diag.h | 8 +-
> arch/s390/include/uapi/asm/diag.h | 8 +
> arch/s390/kernel/diag/Makefile | 2 +-
> arch/s390/kernel/diag/diag204.c | 382 +++++++++++++++++++++++++++++++++++++
> arch/s390/kernel/diag/diag_ioctl.h | 3 +
> arch/s390/kernel/diag/diag_misc.c | 10 +
> arch/s390/kernel/sthyi.c | 28 +--
> 10 files changed, 437 insertions(+), 157 deletions(-)
I will submit a new version soon with Sashiko findings addressed.
I kindly ask to hold any comments until then.
Thank you!
prev parent reply other threads:[~2026-10-22 7:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 10:28 [PATCH 0/3] s390: Diag204 Rework Mete Durlu
2026-10-21 10:28 ` [PATCH 1/3] s390/diag204: Introduce diag204 rework Mete Durlu
2026-10-21 10:52 ` sashiko-bot
2026-10-21 10:28 ` [PATCH 2/3] s390/diag204: Replace diag204 users with new implementation Mete Durlu
2026-10-21 11:09 ` sashiko-bot
2026-10-21 10:28 ` [PATCH 3/3] s390/diag: Add diag204 IOCTL to diag misc device Mete Durlu
2026-10-21 11:13 ` sashiko-bot
2026-10-21 14:01 ` Hendrik Brueckner
2026-10-21 14:12 ` Mete Durlu
2026-10-22 7:04 ` Mete Durlu [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=eb11777b-5fd6-4bcf-9820-fbcc2f32d453@linux.ibm.com \
--to=meted@linux.ibm.com \
--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=sumanthk@linux.ibm.com \
--cc=svens@linux.ibm.com \
/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