Linux RTC
 help / color / mirror / Atom feed
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

  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