[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090922124041.62abee25@i1501.lan.towertech.it>
Date: Tue, 22 Sep 2009 12:40:41 +0200
From: Alessandro Zummo <alessandro.zummo@...ertech.it>
To: Herton Ronaldo Krzesinski <herton@...driva.com.br>
Cc: linux-kernel@...r.kernel.org, David Brownell <david-b@...bell.net>,
rtc-linux@...glegroups.com
Subject: Re: rtc_cmos oops in cmos_rtc_ioctl
On Mon, 21 Sep 2009 15:53:38 -0300
Herton Ronaldo Krzesinski <herton@...driva.com.br> wrote:
> The problem here is the rtc char device being created early and acessible before
> rtc_cmos does dev_set_drvdata(dev, &cmos_rtc), so dev_get_drvdata in
> cmos_rtc_ioctl can return null, like in this example where hwclock is run right
> after char device creation that triggers the udev rule:
> ACTION=="add", SUBSYSTEM=="rtc", RUN+="/sbin/hwclock --hctosys --rtc=/dev/%k"
> And makes the oops possible, in this case hwclock looks to open and close the
> device fast enough.
right. the best option would be to use the new irq api that was
introduced after the creation of rtc_cmos (and thus remove the whole
ioctl routine).
[...]
> But I saw another issue: looks it could be possible that as cmos_rtc_ioctl
> (ioctl) can be run before rtc_device_register returns, the following call chain
> could happen in current code:
> cmos_rtc_ioctl->cmos_irq_{en,dis}able->cmos_checkintr->rtc_update_irq
> rtc_update_irq uses cmos->rtc, which is set only at return of
> rtc_device_register, and here we may have another problem... is it
> possible?
this shouldn't happen, irqs are enabled only after everything
has been setup to handle them.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists