[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB421114F025F27AF2BC5FA21980C80@AM0PR04MB4211.eurprd04.prod.outlook.com>
Date: Thu, 18 Jul 2019 03:08:23 +0000
From: Aisheng Dong <aisheng.dong@....com>
To: Anson Huang <anson.huang@....com>,
"a.zummo@...ertech.it" <a.zummo@...ertech.it>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH] rtc: snvs: fix possible race condition
> From: Anson Huang
> Sent: Wednesday, July 17, 2019 9:58 PM>
> Hi, Aisheng
>
> > > From: Anson.Huang@....com <Anson.Huang@....com>
> > > Sent: Tuesday, July 16, 2019 3:19 PM
> > >
> > > The RTC IRQ is requested before the struct rtc_device is allocated,
> > > this may lead to a NULL pointer dereference in IRQ handler.
> > >
> > > To fix this issue, allocating the rtc_device struct before
> > > requesting the RTC IRQ using devm_rtc_allocate_device, and use
> > > rtc_register_device to register the RTC device.
> > >
> >
> > I saw other rtc drivers did the same way as us, so this looks like a
> > common problem.
> > My question is if we can clear interrupt status before register to
> > avoid this issue as other rtc drivers?
>
> I think we can NOT predict when the IRQ will be pending, IRQ could arrive at
> any time, the most safe way is to prepare everything before
> requesting/enabling IRQ.
> There is also patch to fix similar issue:
>
I just feel like it's common issue. But seems community already did the same thing.
So:
Reviewed-by: Dong Aisheng <aisheng.dong@....com>
Regards
Aisheng
> commit 060711f5274dfc2d76a5b2cd65abf6ccbf061e40
> Author: Alexandre Belloni <alexandre.belloni@...tlin.com>
> Date: Tue Apr 30 11:32:09 2019 +0200
>
> rtc: digicolor: fix possible race condition
>
> Anson
Powered by blists - more mailing lists