linux-kernel - Re: Fix preempt-rt on AT91

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: <20160118174259.GC12309@linutronix.de>
Date:	Mon, 18 Jan 2016 18:42:59 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: Fix preempt-rt on AT91

* Alexandre Belloni | 2016-01-17 03:23:13 [+0100]:

>Hi Sebastian, Thomas,
>
Hi Alexandre,

> 1/ After apply the preempt-rt patch, the kernel doesn't build anymore,
> arm-at91-pit-remove-irq-handler-when-clock-is-unused.patch is not correct
> anymore. Can you squash the following patch to solve this build issue?

I folded most of the changes and should be part of -rt3.

> 2/ This approach actually has more issues, in particular, request_irq() must
> not be calls from interrupt disabled context. That only works because
> might_sleep() is not active during early boot.
> For more information, see the following discussion:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/357607.html
>
> However, we can't remove those patches now because else we would suffer from
> another issue:
> The timer interrupt is shared with other devices, in particular the debug tty,
> the rtc dans the pmc. When using preempt-rt, those interrupts become threaded
> interrupts. But, the pit interrupt is requested with IRQF_TIMER and so has
> IRQF_NO_THREAD. If the pit interrupt is not freed at early boot, all the other
> devices will fail requesting their interrupt, for example:
>
>genirq: Flags mismatch irq 16. 00042080 (ttyS0) vs. 00015280 (at91_tick)
>atmel_usart ffffee00.serial: atmel_startup - Can't get irq

I assumed the pit is just temporary here for the bootstap. The pit irq is
removed and the system switches to the TCB clocksource which runs at a
higher rate.

> I'd say that the proper solution would still be to implement the virtual
> irqchip because this would still hit people not wanting to use the TCB as
> their clock source.

why wouldn't people not want that?
For a virtual irqchip you would need a mask/unmask register in order to
individual disable/enable the irq and you need something to figure out
which one of the three is active. You don't have all those things, do
you?

> 3/ Finally, the kernel will crash when initializing the PMC driver. This is
> solved by this series that will hopefully land in the mainline:
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390954.html

This is new, isn't it? So the series in currently in v3 and people seem
happy with it. Please poke me once with the commit ids once it is merged
on its way upstream and I will try cherry-pick them from next or so.

All in all, care to forwarded the working pieces from -RT patch set
upstream? I problem I have here is mostly that I can't the patches on
actual hardware. Disabling the PIT and running on the other clocksource
isn't that -RT specific after all :)

Sebastian