public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
@ 2024-10-11  4:31 Yongliang Gao
  2024-11-11 22:11 ` Alexandre Belloni
  0 siblings, 1 reply; 5+ messages in thread
From: Yongliang Gao @ 2024-10-11  4:31 UTC (permalink / raw)
  To: alexandre.belloni, john.stultz
  Cc: linux-rtc, linux-kernel, Yongliang Gao, Jingqun Li

From: Yongliang Gao <leonylgao@tencent.com>

If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtc_tm_to_ktime later, the result may be a very large value
(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
they will continually expire, may causing kernel softlockup.

Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
Signed-off-by: Yongliang Gao <leonylgao@tencent.com>
Acked-by: Jingqun Li <jingqunli@tencent.com>
---
 drivers/rtc/interface.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index cca650b2e0b9..aaf76406cd7d 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -904,13 +904,18 @@ void rtc_timer_do_work(struct work_struct *work)
 	struct timerqueue_node *next;
 	ktime_t now;
 	struct rtc_time tm;
+	int err;
 
 	struct rtc_device *rtc =
 		container_of(work, struct rtc_device, irqwork);
 
 	mutex_lock(&rtc->ops_lock);
 again:
-	__rtc_read_time(rtc, &tm);
+	err = __rtc_read_time(rtc, &tm);
+	if (err) {
+		mutex_unlock(&rtc->ops_lock);
+		return;
+	}
 	now = rtc_tm_to_ktime(tm);
 	while ((next = timerqueue_getnext(&rtc->timerqueue))) {
 		if (next->expires > now)
-- 
2.39.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
  2024-10-11  4:31 [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work() Yongliang Gao
@ 2024-11-11 22:11 ` Alexandre Belloni
  2024-11-20 14:32   ` Yongliang Gao
       [not found]   ` <CAJxhyqC9hYo3E=J--EYN9uYQc6_q67X4F5DSgpMFzsWrFcbw4Q@mail.gmail.com>
  0 siblings, 2 replies; 5+ messages in thread
From: Alexandre Belloni @ 2024-11-11 22:11 UTC (permalink / raw)
  To: john.stultz, Yongliang Gao
  Cc: linux-rtc, linux-kernel, Yongliang Gao, Jingqun Li

On Fri, 11 Oct 2024 12:31:53 +0800, Yongliang Gao wrote:
> If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
> uninitialized data, or an illegal date/time read from the RTC hardware.
> 
> When calling rtc_tm_to_ktime later, the result may be a very large value
> (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
> they will continually expire, may causing kernel softlockup.
> 
> [...]

Applied, thanks!

[1/1] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
      https://git.kernel.org/abelloni/c/e8ba8a2bc4f6

Best regards,

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
  2024-11-11 22:11 ` Alexandre Belloni
@ 2024-11-20 14:32   ` Yongliang Gao
       [not found]   ` <CAJxhyqC9hYo3E=J--EYN9uYQc6_q67X4F5DSgpMFzsWrFcbw4Q@mail.gmail.com>
  1 sibling, 0 replies; 5+ messages in thread
From: Yongliang Gao @ 2024-11-20 14:32 UTC (permalink / raw)
  To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Yongliang Gao, Jingqun Li

Hi Alexandre Belloni,

I've noticed that the post-failure process for __rtc_read_time
requires careful handling.
1. Need to call pm_relax.
2. Potentially need to set the alarm to ensure subsequent interrupts
can process the
    expired timer? Could you give me some advice?
Should I continue to submit a fix patch or create a v2 version of the patch?

Best Regards,
Yongliang Gao

On Tue, Nov 12, 2024 at 6:11 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On Fri, 11 Oct 2024 12:31:53 +0800, Yongliang Gao wrote:
> > If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
> > uninitialized data, or an illegal date/time read from the RTC hardware.
> >
> > When calling rtc_tm_to_ktime later, the result may be a very large value
> > (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
> > they will continually expire, may causing kernel softlockup.
> >
> > [...]
>
> Applied, thanks!
>
> [1/1] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
>       https://git.kernel.org/abelloni/c/e8ba8a2bc4f6
>
> Best regards,
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
       [not found]   ` <CAJxhyqC9hYo3E=J--EYN9uYQc6_q67X4F5DSgpMFzsWrFcbw4Q@mail.gmail.com>
@ 2024-11-29 23:20     ` Alexandre Belloni
  2024-12-02  3:10       ` Yongliang Gao
  0 siblings, 1 reply; 5+ messages in thread
From: Alexandre Belloni @ 2024-11-29 23:20 UTC (permalink / raw)
  To: 高永良
  Cc: john.stultz, linux-rtc, linux-kernel, Yongliang Gao, Jingqun Li

On 20/11/2024 22:17:34+0800, 高永良 wrote:
> Hi Alexandre Belloni,
> 
> I've noticed that the post-failure process for __rtc_read_time requires
> careful handling.
> 1. Need to call pm_relax.

I had a look when taking your patch and I'm not convinced calling
pm_relax is necessary.

> 2. Potentially need to set the alarm to ensure subsequent interrupts can
> process the
>     expired timer? Could you give me some advice?

Same thing, if you are not able to read the current time, setting the
next alarm is going to fail anyway.

> Should I continue to submit a fix patch or create a v2 version of the patch?
> 
> Best Regards,
> Yongliang Gao
> 
> Alexandre Belloni <alexandre.belloni@bootlin.com> 于2024年11月12日周二 06:11写道:
> 
> > On Fri, 11 Oct 2024 12:31:53 +0800, Yongliang Gao wrote:
> > > If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
> > > uninitialized data, or an illegal date/time read from the RTC hardware.
> > >
> > > When calling rtc_tm_to_ktime later, the result may be a very large value
> > > (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
> > > they will continually expire, may causing kernel softlockup.
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/1] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
> >       https://git.kernel.org/abelloni/c/e8ba8a2bc4f6
> >
> > Best regards,
> >
> > --
> > Alexandre Belloni, co-owner and COO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
> >

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
  2024-11-29 23:20     ` Alexandre Belloni
@ 2024-12-02  3:10       ` Yongliang Gao
  0 siblings, 0 replies; 5+ messages in thread
From: Yongliang Gao @ 2024-12-02  3:10 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: john.stultz, linux-rtc, linux-kernel, Yongliang Gao, Jingqun Li

On Sat, Nov 30, 2024 at 7:20 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 20/11/2024 22:17:34+0800, 高永良 wrote:
> > Hi Alexandre Belloni,
> >
> > I've noticed that the post-failure process for __rtc_read_time requires
> > careful handling.
> > 1. Need to call pm_relax.
>
> I had a look when taking your patch and I'm not convinced calling
> pm_relax is necessary.

Before all the code of schedule_work(&rtc->irqwork),
pm_stay_awake(rtc->dev.parent) is called. There are the following 4
functions:
 - rtc_set_time
 - rtc_update_irq
 - rtc_timer_enqueue
 - rtc_timer_remove
At the end of the normal processing flow of the rtc_timer_do_work
function, pm_relax(rtc->dev.parent) is called.
So, if it fails here, pm_relax(rtc->dev.parent) should be called, right?

>
> > 2. Potentially need to set the alarm to ensure subsequent interrupts can
> > process the
> >     expired timer? Could you give me some advice?
>
> Same thing, if you are not able to read the current time, setting the
> next alarm is going to fail anyway.

OK, I won't set the next alarm if it fails here. Thanks.

>
> > Should I continue to submit a fix patch or create a v2 version of the patch?
> >
> > Best Regards,
> > Yongliang Gao
> >
> > Alexandre Belloni <alexandre.belloni@bootlin.com> 于2024年11月12日周二 06:11写道:
> >
> > > On Fri, 11 Oct 2024 12:31:53 +0800, Yongliang Gao wrote:
> > > > If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
> > > > uninitialized data, or an illegal date/time read from the RTC hardware.
> > > >
> > > > When calling rtc_tm_to_ktime later, the result may be a very large value
> > > > (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
> > > > they will continually expire, may causing kernel softlockup.
> > > >
> > > > [...]
> > >
> > > Applied, thanks!
> > >
> > > [1/1] rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
> > >       https://git.kernel.org/abelloni/c/e8ba8a2bc4f6
> > >
> > > Best regards,
> > >
> > > --
> > > Alexandre Belloni, co-owner and COO, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> > >
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-12-02  3:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-11  4:31 [PATCH] rtc: check if __rtc_read_time was successful in rtc_timer_do_work() Yongliang Gao
2024-11-11 22:11 ` Alexandre Belloni
2024-11-20 14:32   ` Yongliang Gao
     [not found]   ` <CAJxhyqC9hYo3E=J--EYN9uYQc6_q67X4F5DSgpMFzsWrFcbw4Q@mail.gmail.com>
2024-11-29 23:20     ` Alexandre Belloni
2024-12-02  3:10       ` Yongliang Gao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox