linux-kernel - Re: 2.6.31-rt11 freeze on userland start on ARM

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]

Date:	Sun, 4 Oct 2009 13:59:04 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Remy Bohmer <linux@...mer.net>
cc:	linux-rt-users <linux-rt-users@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.31-rt11 freeze on userland start on ARM

On Wed, 30 Sep 2009, Remy Bohmer wrote:
> > The serial irq cannot run in hard irq context.
> 
> Indeed most drivers cannot, but for this particular handler can you
> please explain me why?
> Maybe I am missing some new mechanism that prevents it that was not
> there on older RT-kernels (tested up-to latest 2.6.24-rt +
> 2.6.26-rt)...

Which had the same problem ....

> The atmel_serial IRQ was adapted such (I think it was mainlined in
> 2.6.25 already) to make it suitable to run in hard-irq context. (I
> know, because I did that myself)

That's fine for mainline but not for -rt.

> FWIW... it seems to run stable in hard-irq context on 2.6.31-rt with
> the patch above as well... (coincidence?)

Yes. The serial code takes locks which are converted to sleeping locks
on -RT. That's a nono.

> > 2) Make the serial driver explicitely threaded and check in the
> > hardirq handler whether the irq originated from the serial driver. If
> > yes, disable it in the serial device and return IRQ_WAKE_THREAD
> > otherwise return IRQ_NONE.
> 
> Interesting, this sounds new, and I have to dig into it to find out
> how this is supposed to work... Do you happen to have any good
> pointers for examples or doc?

drivers/net/wireless/b43/main.c in mainline

> TOL: could the generic interrupt code not check for this? It can see
> the timer interrupt handler not returning 'IRQ_HANDLED', and still see
> the interrupt being active, and know that there is a IRQ thread on the
> same line, so it can conclude itself to mask the source in the
> interrupt controller and wake the thread... Or am I wrong?

What happens if both are active at the same time ? Also masking the
interrupt line will block your timer interrupts until the threaded
handler has completed.

Thanks,

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