<div dir="ltr"><div>It is a surprise for getting a reply from you, Gilles on this subject which I had posed on Xenomai forum and has been treated as if it was coming from an "idiot". </div><div><br></div><div>Knowing this is not entirely Xenomai forum, I would still like to ask if I can get hold of the patch, please? if not, hear from you in Xenomai forum.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 October 2015 at 05:11, Gilles Chanteperdrix <span dir="ltr"><<a href="mailto:gilles.chanteperdrix@xenomai.org" target="_blank">gilles.chanteperdrix@xenomai.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 02, 2015 at 09:56:39AM -0600, Jim Cromie wrote:<br>
> On Sun, Sep 27, 2015 at 8:52 AM, <<a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>> wrote:<br>
><br>
> > On Sun, 27 Sep 2015 15:08:57 +1300, vibnwis said:<br>
> ><br>
> > > Xenomai patching succeeded but when running one of is test apps,<br>
> > "latency"<br>
> > > showing<br>
> > > > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: Cannot<br>
> > > allocate<br>
> > > > > > > memory<br>
> > > And the mailing list member suggested the following<br>
> ><br>
> > Is that in dmesg, or output from the test program?<br>
> > Is there more output, or is that it?<br>
> ><br>
> > Personally, if TRACE_IRQFLAGS is causing an issue with mlock, I'd suspect<br>
> > a very buggy patch indeed. If it can't tolerate a trace function being<br>
> > turned on, there;s probably some very questionable coding in there.....<br>
> ><br>
> ><br>
><br>
> FWIW, I think Xenomai is far better smelling than your quick sniff has told<br>
> your olfactory sensors<br>
<br>
TRACE_IRQFLAGS is broken with the I-pipe patch. At least on ARM. The<br>
visible result is LOCKDEP false positives, but there may be some<br>
more subtle kernel data structures corruption due to the fact that<br>
the TRACE_IRQFLAFGS code is called from the Xenomai context. The<br>
principle of Xenomai is to be able to run while Linux believes<br>
its interrupts are off, in the middle of its critical sections. For<br>
this to be possible, the code run in this context must never touch<br>
any Linux kernel data structures. Enabling TRACE_IRQFLAGS breaks<br>
this assumption: Linux code which potentially accesses Linux data<br>
structures gets called from the Xenomai context. The consequences<br>
can be anything, such as mlock failing, though in practice we never<br>
get any report about that. The usual reason for mlockall failing is<br>
because the user is not root, and with default ulimit settings at<br>
least, mlockall can not be called by non-root users.<br>
<br>
Anyway, the reason why TRACE_IRQFLAGS is still broken is my fault:<br>
Jan has sent patches months ago, which I did not check.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Gilles.<br>
<a href="https://click-hack.org" rel="noreferrer" target="_blank">https://click-hack.org</a><br>
</font></span></blockquote></div><br></div>