linux-kernel - Re: v4.4.12-rt20 build: 0 failures 5 warnings (v4.4.12-rt20)

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] [day] [month] [year] [list]

Message-ID: <20160729152358.GC21715@linutronix.de>
Date:	Fri, 29 Jul 2016 17:23:58 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linaro-kernel@...ts.linaro.org,
	Build bot for Mark Brown <broonie@...nel.org>,
	kernel-build-reports@...ts.linaro.org,
	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: v4.4.12-rt20 build: 0 failures 5 warnings (v4.4.12-rt20)

* Arnd Bergmann | 2016-07-15 21:48:55 [+0200]:

>I also notice that your "tty: serial: 8250: don't take the trylock
>during oops" patch would apply on the pl011 driver as well.

That one. That is something I am not really sure about in the long run. On
-RT we can't try_lock() with IRQs off and that is why I removed it.
You could do the same with pl011 but you are screwed anyway because
clk_enable() will take a sleeping lock and that is a no no.

So you could stay with the try_lock because it does not solve anything.
In the long run I though about a console flag which denotes the console
as RT-IRQ save which is the case for 8250 but not for pl011 (due to
clk_enable()) so should not get on -RT into this case where it matters.

On the other hand if you oops on !RT+UP in your uart driver while
holding the lock then the try_lock will fail resulting in a lockdep
splat (because try_lock should not fail on UP). So might want take it as
a procation in that case :)

>Sure, that always works, it's just a bit ugly since the flags word
>should never be zero when it gets written back to the hardware irq
>state, at least in portable code.

yes :)

>Maybe something like the version below?

sure.

Sebastian