Re: [PATCH] rtc: st-lpc: remove unnecessary check

From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Trent Piepho <tpiepho@impinj.com>
Cc: "patrice.chotard@st.com" <patrice.chotard@st.com>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] rtc: st-lpc: remove unnecessary check
Date: Wed, 1 May 2019 22:30:23 +0200	[thread overview]
Message-ID: <20190501203023.GL11339@piout.net> (raw)
In-Reply-To: <1556730703.31309.53.camel@impinj.com>

On 01/05/2019 17:11:44+0000, Trent Piepho wrote:
> > I can't believe you can possibly have more than one second between the
> > check in the core and the check in the driver, it doesn't make much
> > sense to check, even in the current state of the core.
> 
> It's certainly possible to have multiple seconds pass.  For an external
> device over SPI or I2C, one has to wait for the bus to become free. 
> And on SPI that requires the kernel thread running the bus to be 
> scheduled.  Just put in some real-time tasks and maybe a big transfer
> to a flash chip and it could be a while before that happens.
> 
> I don't think this device has that issue as I don't think it's
> external.  And ever for a device on an external bus, delays > 1 second
> are unlikely.  Possible, but unlikely.
> 
> You can also get them when Linux is running under a hypervisor, i.e. a
> Linux VM.  But also something like an NMI and ACPI BIOS.  If the Linux
> guest is not scheduled to run for while anything that is supposed to be
> based on real time, like the value returned by an RTC, will still
> advance.  It is possible that multiple seconds elapse from the guest
> CPU executing one instruction to the next.
> 
> But even ignoring that, does it require > 1 second to elapse.  Can't it
> happen when the clock ticks from one second to the next, which happens
> effectively instantly?
> 
> If the time from the check to the time when the alarm is set is 1
> microsecond, and the time this call to set the alarm is made is
> randomly done and not synchronized to the RTC, then isn't there a 1 out
> of 1 million chance (1 microsecond / 1 second), that the once per
> second clock tick will hit our 1 us window?

No, let's say you want Talarm == Tcurrent + 1, if the core check happens
right before the next second, then you necessarily end up with
Talarm == Tcurrent after the check. This means that you now have one
second before the time read in st-lpc to avoid the
alarm_secs -= now_secs; underflow.

Obviously, in that case, you are likely to miss the alarm but this is as
likely to happen with the check that is in the driver. This check
doesn't provide anything but a false sense of security.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com