linux-kernel - Re: [PATCH] rtc: fix deadlock

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 23 Aug 2008 21:46:31 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Mikael Pettersson <mikpe@...uu.se>,
	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	tglx@...utronix.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] rtc: fix deadlock

Maciej W. Rozycki writes:
 > On Sat, 23 Aug 2008, Ingo Molnar wrote:
 > 
 > > > The sporadic nature of the bug means that it will probably take a 
 > > > couple of days of testing and dozens of reboots w/o problems before 
 > > > I'm confident to say that the problem's been fixed.
 > > 
 > > btw., i've seen that lockup too on a testbox - but havent been able to 
 > > track it down yet. You went further and presented the bug on a plate by 
 > > tracking it down to the loop in get_rtc_time() - so now we can both test 
 > > the fix and see whether the lockups are gone.
 > 
 >  Hmm, waiting for 20ms with interrupts disabled sounds like a bad idea --
 > a lot of system timer ticks may be lost and some devices may not be happy
 > about such a delay either (serial?).  I think your proposal only papers
 > over the actual bug and it should simply be forbidden to call this
 > function with interrupts disabled.
 > 
 >  I can see this is a part of the legacy RTC interface, so except from the
 > long delay the function itself may have a chance to work with interrupts
 > disabled.  But with the modern RTC library this is no longer true as some
 > RTC chips it supports can only be accessed with interrupts enabled,
 > because their accessor functions may sleep.  This is for example common
 > with RTC chips wired through I2C.
 > 
 >  Therefore I think to avoid propagating the design problem with places
 > calling get_rtc_time() when they eventually switch to the RTC library it
 > would be better to put:
 > 
 > BUG_ON(irqs_disabled());
 > 
 > into get_rtc_time() now and fix the callers which happen to trigger it.

On my C2D, I've only seen the lockup happen when user-space is
using hwclock to init system time (early init) or to flush system
time to the hw (end of shutdown/reboot). And the lockup is always
in hpet_rtc_interrupt. I've never ever seen the lockup while the
system is up and running normally.

So I suspect a bad interaction between the HPET RTC stuff and
the RTC user-space interface.

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