linux-kernel - Re: [GIT PULL] printk: Support for full dynticks mode

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: <20130204200459.f2a0a1cc.akpm@linux-foundation.org>
Date:	Mon, 4 Feb 2013 20:04:59 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] printk: Support for full dynticks mode

On Mon, 04 Feb 2013 21:42:02 -0500 Steven Rostedt <rostedt@...dmis.org> wrote:

> On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> 
> > I don't think so.  Conceptually printk() should be "inner" to the
> > scheduler and shouldn't call into sched things at all.  The (afaik
> > sole) exception to that was the klogd wakeup.
> > 
> > Traditionally the deadlock happened when calling printk() with
> > tasklist_lock (now q->lock) held.  printk() would call wake_up(klogd)
> > and wake_up() tries to take tasklist_lock and boom.  Moving the
> > wake_up() out to the tick "thread" fixed that.
> > 
> > Maybe there were other deadlock scenarios, dunno.  That knowledge
> > appears to be disappearing into the mists of time :(
> 
> Even without the printk irq_work the current printk method uses a
> delayed wakeup anyway.
> 
> The wake_up_klogd() sets PRINTK_PENDING_WAKEUP, and the wakeup happens
> at time of the tick. I don't see where there is a deadlock.
>
> ...
>
> Do we really even need that printk_sched()?

3ccf3e8306156a282 ("printk/sched: Introduce special printk_sched() for
those awkward moments") was added _after_ wake_up_klogd() was switched
to using the printk_pending->printk_tick() thing.  So presumably there
were deadlocks other than around wake_up_klogd().

The printk_pending->printk_tick() thing was added by b845b517b5e
("printk: robustify printk"), four years earlier in 2008.  It says
"Avoid deadlocks against rq->lock and xtime_lock...".

So what deadlocks was the March 2012 3ccf3e830 ("printk/sched:
Introduce special printk_sched() for those awkward moments") supposed
to fix?  grr.  I searched my lkml archives for March 2012 and few
preceding months, but couldn't find any additional info.

> I added a printk in __sched_setscheduler() where the run queue lock is held,
> and booted that with full lockdep debugging enabled. No deadlock is
> detected.

Well, you'd need to enable various printk options to get full coverage.
For example, that xtime_lock deadlock would only have occurred when
timestamping is enabled.

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