From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>, linux-rtc@vger.kernel.org
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [RESEND PATCH 1/2] rtc: cmos: Disable ACPI RTC event before handling it
Date: Thu, 15 Oct 2026 17:42:19 +0000 [thread overview]
Message-ID: <sashiko-outbox-173261@kernel.org> (raw)
In-Reply-To: <20261015173029.3091872-2-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rtc: cmos: TOCTOU race in ACPI RTC event toggle leads to lost alarms
--
commit 73bcc5b0dfcf900941896af4381bb8051c9589e0
Author: Gregory Price <gourry@gourry.net>
rtc: cmos: Disable ACPI RTC event before handling it
Users of RTC_UIE_ON can stop receiving update interrupts when rtc-cmos
handles alarms through ACPI. Clear and disable the current ACPI RTC event
before cmos_interrupt() schedules the work to avoid a race where the handler
undoes the worker's event enablement.
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index fa04ece151b8b..fe514b1aa3433 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -758,7 +758,9 @@ static u32 rtc_handler(void *context)
> unsigned char rtc_intr;
> unsigned long flags;
>
> -
> + /* Quiesce this event before rtc->irqwork can arm the next one. */
> + acpi_clear_event(ACPI_EVENT_RTC);
> + acpi_disable_event(ACPI_EVENT_RTC, 0);
[Severity: Medium]
Could this unconditional disablement create a race with concurrent userspace
threads setting a new alarm?
If a concurrent userspace thread calls ioctl(RTC_ALM_SET), it acquires the
necessary locks and enables the ACPI event for the newly configured alarm:
drivers/rtc/rtc-cmos.c:rtc_wake_on() {
acpi_clear_event(ACPI_EVENT_RTC);
acpi_enable_event(ACPI_EVENT_RTC, 0);
}
While the patch successfully resolves a similar race with the worker thread
by moving the disablement before cmos_interrupt(), it seems to leave the
asynchronous userspace race unhandled.
If the userspace thread enables the event after the SCI thread has been
triggered, but before the SCI thread executes acpi_disable_event() here in
rtc_handler(), will the SCI thread mistakenly disable the newly set alarm?
This could cause the newly configured alarm to be dropped, as the disablement
happens without holding locks such as rtc_lock or rtc->ops_lock.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261015173029.3091872-1-gourry@gourry.net?part=1
next prev parent reply other threads:[~2026-10-15 17:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 17:30 [RESEND PATCH 0/2] rtc: cmos: Fix ACPI RTC alarm handling Gregory Price
2026-10-15 17:30 ` [RESEND PATCH 1/2] rtc: cmos: Disable ACPI RTC event before handling it Gregory Price
2026-10-15 17:42 ` sashiko-bot [this message]
2026-10-15 21:53 ` Gregory Price
2026-10-15 17:30 ` [RESEND PATCH 2/2] rtc: cmos: Honor explicit use_acpi_alarm parameter value Gregory Price
2026-10-15 17:36 ` sashiko-bot
2026-10-15 21:54 ` Gregory Price
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-173261@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=gourry@gourry.net \
--cc=linux-rtc@vger.kernel.org \
--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