linux-kernel - Re: [PATCH] v2 Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

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]

Message-ID: <4A3AC0FF.20808@nortel.com>
Date:	Thu, 18 Jun 2009 16:34:39 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Ben Hutchings <ben@...adent.org.uk>
CC:	linux-kernel@...r.kernel.org, Chris Adams <cmadams@...aay.net>,
	510478@...s.debian.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] v2 Re: Bug: Status/Summary of slashdot leap-second crash
 on new years 2008-2009

Ben Hutchings wrote:
> On Sat, 2009-01-03 at 12:01 -0600, Chris Adams wrote:
>> Once upon a time, Duane Griffin <duaneg@...da.com> said:
>>> How about instead of a switch statement, assigning the message to a
>>> variable and printing that. I.e. something like:
>> Good point.  Here's an updated version that also adds a comment to the
>> xtime_lock definition about not using printk.
>> -- 
>> Chris Adams <cmadams@...aay.net>
>> Systems and Network Administrator - HiWAAY Internet Services
>> I don't speak for anybody but myself - that's enough trouble.
>>
>>
>> From: Chris Adams <cmadams@...aay.net>
>>
>> The code to handle leap seconds printks an information message when the
>> second is inserted or deleted.  It does this while holding xtime_lock.
>> However, printk wakes up klogd, and in some cases, the scheduler tries
>> to get the current kernel time, trying to get xtime_lock (which results
>> in a deadlock).  This moved the printks outside of the lock.  It also
>> adds a comment to not use printk while holding xtime_lock.
> [...]
> 
> This patch doesn't seem to have gone anywhere.  Was this bug fixed in
> some other way or has it been forgotten?

I'm interested in this as well...the current code still issues a
printk() while holding the xtime_lock for writing.  Is this allowed or not?

In addition, is it allowed for older kernels also or is Chris Adams'
patch something that should get picked up for the 2.6.27 stable series?

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