Re: [RESEND PATCH 1/2] rtc: cmos: Disable ACPI RTC event before handling it

[Gregory Price <gourry@gourry.net>]

On Thu, Oct 15, 2026 at 05:42:19PM +0000, sashiko-bot@kernel.org wrote:
> > 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.
> 

This is a pre-existing issue.

~Gregory