Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[gilles.chanteperdrix@xenomai.org (Gilles Chanteperdrix)]

On Fri, Oct 02, 2015 at 05:43:52PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 02 Oct 2015 18:11:53 +0200, Gilles Chanteperdrix said:
> 
> > TRACE_IRQFLAGS is broken with the I-pipe patch. At least on ARM. The
> > visible result is LOCKDEP false positives, but there may be some
> > more subtle kernel data structures corruption due to the fact that
> > the TRACE_IRQFLAFGS code is called from the Xenomai context. The
> > principle of Xenomai is to be able to run while Linux believes
> > its interrupts are off, in the middle of its critical sections. For
> > this to be possible, the code run in this context must never touch
> > any Linux kernel data structures. Enabling TRACE_IRQFLAGS breaks
> > this assumption: Linux code which potentially accesses Linux data
> > structures gets called from the Xenomai context. The consequences
> > can be anything, such as mlock failing, though in practice we never
> > get any report about that. The usual reason for mlockall failing is
> > because the user is not root, and with default ulimit settings at
> > least, mlockall can not be called by non-root users.
> 
> Thanks for the detailed explanation - It's a refreshing change from the
> usual cargo-cult programming "It seems to break but we have no idea why,
> so just turn it off" we often see with out-of-tree patches.

Well, it also depends on what the option is, projects with small
numbers of contributors do not necessarily have the time to
investigate breakages introduced by some obscure options. lockdep is
not "some obscure option", people want to be able to enable it.

> 
> One thing jumped out at me:
> 
> > The principle of Xenomai is to be able to run while Linux believes
> > its interrupts are off, in the middle of its critical sections
> 
> Are you saying that it enables interrupts when Linux thinks they are off?

Yes, but of course if an interrupt happens for Linux during that time,
it is logged, then played back when Linux unmasks interrupts. It is
a very old principle:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.8347

The advantage of doing that is that if an interrupt happens for the
real time system, it can be handled without waiting for Linux to
unmask interrupts.

> 
> If so, all I can say is: You're a far braver man than I. :)

The alternate solution is the native preemption, implemented by the
preempt_rt patch. But we do not know yet which of the two solutions
is crazier. It seems both have strengths and weaknesses. The next
version of Xenomai, about to be released, lets the user choose his
side.

-- 
					    Gilles.
https://click-hack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151003/427f2cfe/attachment.bin