From: Sven Schnelle <svens@linux.ibm.com>
To: Stefan Haberland <sth@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.vom>
Subject: Re: [PATCH] s390/stp: Drop CLOCK_SYNC_STP
Date: Wed, 09 Sep 2026 14:29:07 +0200 [thread overview]
Message-ID: <yt9d4ifyvca4.fsf@linux.ibm.com> (raw)
In-Reply-To: <cffc6734-19c8-439d-a55b-79bdedd54eab@linux.ibm.com>
Stefan Haberland <sth@linux.ibm.com> writes:
> Am 14.08.26 um 09:34 schrieb sashiko-bot@kernel.org:
>> [Severity: High]
>> Could this change cause a boot hang on systems with XRC-capable DASDs
>> but no active STP network?
>>
>> Because stp_online is initialized to true, if the machine supports the
>> STP facility but is not connected to a usable STP time source, time
>> synchronization won't occur and stp_online will remain true.
>>
>> With stp_online remaining true, get_phys_clock() will continuously fall
>> through and return -EAGAIN, rather than safely returning -EACCES as it
>> did prior to this patch.
>>
>> The DASD driver ignores -EACCES but propagates -EAGAIN:
>>
>> drivers/s390/block/dasd_eckd.c:set_timestamp() {
>> ...
>> if ((rc && !private->rdc_data.facilities.XRC_supported) ||
>> rc == -EOPNOTSUPP || rc == -EACCES)
>> return 0;
>> ...
>> }
>>
>> If -EAGAIN is propagated up, will the block layer endlessly retry the I/O,
>> resulting in a complete hang during boot?
>>
>
> From what I see, Sashiko is right. This will break how the DASD driver
> actually checks if the clock is enabled and in sync.
>
> The DASD driver relies on -EACCES to know that the clock exists but STP
> sync is not online/applicable which in turn will skip it, whereas
> -EAGAIN means the clock does exist but is not in sync yet and we should
> wait and retry, which in turn leads to endless loop of request never
> being built because we never get a valid timestamp.
>
> So I guess we will still need a third bit to differentiate those states.
If I understood the code correctly, it would only block until STP is in
sync, so this is expected behaviour - looking at z/VM documentation (especially
the XRC_OPTional flag), DASD I/O should be blocked until time is in
sync.
I think the correct way would be to add a patch on top that adds the
XRC_OPTional parameter to either block DASD I/O when STP is in unsynchronized
state (current behaviour) or just omits the timestamp when XRC_OPTional
is set.
next prev parent reply other threads:[~2026-09-09 12:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 7:22 [PATCH] s390/stp: Drop CLOCK_SYNC_STP Sven Schnelle
2026-08-14 7:34 ` sashiko-bot
2026-09-03 12:10 ` Stefan Haberland
2026-09-09 12:29 ` Sven Schnelle [this message]
2026-09-09 13:07 ` Stefan Haberland
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=yt9d4ifyvca4.fsf@linux.ibm.com \
--to=svens@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.vom \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sth@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.