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

Message-ID: <alpine.LFD.2.00.0910051228041.2646@localhost.localdomain>
Date:	Mon, 5 Oct 2009 12:33:27 +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

B1;2005;0cOn Sun, 4 Oct 2009, Remy Bohmer wrote:

> Hi,
> 
> 2009/10/4 Thomas Gleixner <tglx@...utronix.de>:
> > 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 ....
> 
> what problem...?

The tasklet conversion happened after .24 and the hard interrupt
context receive loop has introduced quite nasty latencies in
.26. There was some other warning problem in .26 which I forgot.
 
> I will adapt the atmel-serial driver to this new irq-threading model
> and provide a patch for it, it seems cleaner and makes the tasklet
> stuff obsolete for this driver.

Great, that code really looks ugly.

> >> 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.
> 
> That is indeed true, and proves once again that shared interrupt
> handlers are really annoying, especially on -rt...
> 
> The old way we did in 2.6.24-rt + 2.6.26-rt was to adapt the handler
> to allow it to run in hard-irq context for -rt as well as mainline.
> The new way handles this differently... Since a -rt-friendly generic
> solution seems not possible, I guess before -rt ever becomes mainline
> _all_ interrupt handlers that are shared with a nodelay interrupt in
> some configuration must be adapted to the new threaded_irq model... A
> huge job...

Don't think so. ATx seems to be one of the weirder pieces of hardware :)

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/