linux-kernel - Re: [PATCH] i386 tsc: remove xtime_lock'ing around cpufreq notifier

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: <20070411173902.b2a9ab9d.akpm@linux-foundation.org>
Date:	Wed, 11 Apr 2007 17:39:02 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Daniel Walker <dwalker@...sta.com>, linux-kernel@...r.kernel.org,
	johnstul@...ibm.com, tglx@...utronix.de, Andi Kleen <ak@...e.de>
Subject: Re: [PATCH] i386 tsc: remove xtime_lock'ing around cpufreq notifier

On Wed, 11 Apr 2007 14:33:57 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:

> > Here is the call ordering ,
> > 
> > ktime_get()
> >  ktime_get_ts() -> read_seqretry(&xtime_lock, seq)
> >   getnstimeofday()
> >    __get_realtime_clock_ts() -> read_seqretry(&xtime_lock, seq)
> > 
> > 
> > I wonder if there is a weird case which case this to loop forever .. But
> > as said , it's just something I noticed so I don't know if it's
> > related .
> > 
> 
> hm.
> 
> Bear in mind that printk calls sched_clock() for each line of output. 
> (with the "time" kernel boot parameter).
> 
> If we're doing a read_seqretry() in sched_clock() then bascially any printk
> inside the write_seqlock() will cause a lockup.
> 
> So in fact, this explains my hang: I was debugging it with printk and I
> noticed that the printk before the write_seqlock() came out and the one
> after it did not.  Presumably if I wasn't using "time", that hang wouldn't
> have happened.
> 
> Which means that I still don't have a clue why Andi's patch is locking up
> the Vaio.
> 
> It's a bad idea to make sched_clock() this complex - we've gone and
> degraded kernel debuggability somewhat.
> 
> We have provision for fixing this: the architecture can provide its own
> printk_clock().  We should do something quick-n-dirty in printk_clock()
> which doesn't require any locks.
> 

OK, so I resurrected x86_64-mm-sched-clock-share.patch and
x86_64-mm-sched-clock64.patch.  The x86_64 box hangs on boot when using
netconsole and printk timestamps too.  Removing "time" from the kernel boot
command line prevents that.

This explains why the hang only happens with
x86_64-mm-log-reason-why-tsc-was-marked-unstable.patch applied, too: that
patch must be triggering a printk inside xtime_lock.

Does someone want to cook up a lockless printk_clock() for i386 and x86_64?

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