linux-kernel - Re: [rtc-linux] Re: [PATCH] rtc: Make rtc_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200904240231.12906.david-b@pacbell.net>
Date:	Fri, 24 Apr 2009 02:31:12 -0700
From:	David Brownell <david-b@...bell.net>
To:	Alessandro Zummo <alessandro.zummo@...ertech.it>
Cc:	rtc-linux@...glegroups.com, Atsushi Nemoto <anemo@....ocn.ne.jp>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	hcegtvedt@...el.com, vapier@...too.org, rongkai.zhan@...driver.com,
	balajirrao@...nmoko.org, broonie@...nsource.wolfsonmicro.com
Subject: Re: [rtc-linux] Re: [PATCH] rtc: Make rtc_update_irq callable with irqs enabled

On Thursday 23 April 2009, Alessandro Zummo wrote:
> > If the spinlock is *ever* acquired with IRQs disabled,
> > it must *always* be acquired that way.
> > 
> > The typical use is ... from IRQ context, which will in
> > some cases mean IRQs disabled.  QED.
> 
>  the spinlock could be acquired with IRQs disabled,
>  with spin_lock_irq, in the alarm setup functions

I don't want to make time for a re-audit of this
spinlock's usage just now.

>  and 
>  acquired with the standard spinlock calls in the irq
>  handler.

Which "standard" call?  "spin_lock", "spin_lock_irqsave",
and "spin_lock_irq" are all standard calls.

Recall that it's not the IRQ handler that's directly
grabbing the lock; it's code called by that handler.

>  would it work?

The patch I saw -- switching rtc_update_irq() to use
spin_lock_irqsave() -- would work, but it's incomplete.
It left the doc broken, and didn't clean up the drivers
which did the real work to obey the current call spec.

It'd be much nicer if lockdep would just do the right
thing and report when IRQ handlers do stupid things,
instead of covering up that class of bugs.  But I'm told
it will not get fixed; sigh.

--
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/