linux-kernel - Re: [ANNOUNCE] v4.4.3-rt9

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: <alpine.DEB.2.11.1602291538590.3638@nanos>
Date:	Mon, 29 Feb 2016 16:00:18 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Sebastian Sewior <bigeasy@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [ANNOUNCE] v4.4.3-rt9

On Mon, 29 Feb 2016, Mike Galbraith wrote:

> On Mon, 2016-02-29 at 13:46 +0100, Thomas Gleixner wrote:
> > Dear RT folks!
> > 
> > I'm pleased to announce the v4.4.3-rt9 patch set. v4.4.2-rt7 and v4.4.3-rt8
> > are non-announced updates to incorporate the linux-4.4.y stable tree.
> > 
> > There is one change caused by the 4.4.3 update:
> > 
> >   The relaxed handling of dump_stack() on RT has been dropped as there is
> >   actually a potential deadlock lurking around the corner. See: commit
> >   d7ce36924344 upstream. This does not effect the other facilities which
> >   gather stack traces.
> 
> Hrm.  I had rolled that dropped bit forward as below.  I was given
> cause to do a very large pile of ltp oom4 testing (rt kernels will
> livelock due to waitqueue workers waiting for kthreadd to get memory to
> spawn a kworker thread, while stuck kworker holds manager mutex, unless
> workers are run as rt tasks to keep us from getting that depleted in
> the first place), which gives it oodles of exercise, and all _seemed_
> well.  Only seemed?

Well, it will work nicely as long as you don't trigger a back trace in hard
irq context. Hmm?

Thanks,

	tglx