[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB3PR0402MB39164D0022E25706D2B871C7F5C90@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Date: Wed, 17 Jul 2019 13:57:45 +0000
From: Anson Huang <anson.huang@....com>
To: Aisheng Dong <aisheng.dong@....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
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:
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