<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Laim and all,</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 27, 2021 at 12:14 AM Liam Howlett <<a href="mailto:liam.howlett@oracle.com" target="_blank">liam.howlett@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Petr Vorel <<a href="mailto:pvorel@suse.cz" target="_blank">pvorel@suse.cz</a>> [210326 06:43]:<br>
> Hi Liam, Li,<br>
> <br>
> > > This was my test platform.  I also sent it to the Travis CI which passed<br>
> > > for x86_64.  I will re-examine the accepted code to ensure the cosmetic<br>
> > > changes didn't invalidate my testing.<br>
> <br>
> > FWIK, the Travis CI does not run test case, it just compiles/builds LTP<br>
> > across<br>
> > many arches/platforms.<br>
> <br>
> Yes, while KernelCI and some enterprise / embedded distros for their kernels run<br>
> LTP testcases, the project does not run it. Cyril run some regression tests for<br>
> few most important runtests before release manually. But having a server it'd be<br>
> handy to run them.<br>
<br>
<br>
Thank you for clarification.  What is the best way to re-test my<br>
changes?  As I had said, I made a change that will not add EXEC but will<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">No best way I guess, it would be great if you can do more arches</div><div class="gmail_default" style="font-size:small">verification before patch sending, but then the maintainers would</div><div class="gmail_default" style="font-size:small">help do that also.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
still test removal of more than one VMA.  We cannot just mprotect<br>
PROT_READ|PROT_WRITE as this will allow VMA merging to occur.  My<br>
solution is to change the anon vma to just PROT_READ.  It passes in my<br>
x86_64 test but since that was the case for me regardless, I cannot say<br>
that I have fixed the issue, but I have verified that the test still<br>
does what I expect it to do.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I'm fine with just test PROT_READ. And we can take this way to fix</div><div class="gmail_default" style="font-size:small">the FAIL before the next LTP release.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But there is still a query in my mind, whether the FAIL I mentioned before</div><div class="gmail_default" style="font-size:small">is a kernel bug or just caused by preventing process Self Modiefed Code,</div><div class="gmail_default" style="font-size:small">that probably needs more investigation.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
Liam<br>
<br>
Patch below.<br>
-------------------------------------------<br>
<br>
+++ b/testcases/kernel/syscalls/brk/brk02.c<br>
@@ -36,8 +36,7 @@ void brk_down_vmas(void)<br>
                return;<br>
        }<br>
<br>
-       if (mprotect(addr - page_size, page_size,<br>
-                    PROT_READ|PROT_WRITE|PROT_EXEC)) {<br>
+       if (mprotect(addr - page_size, page_size, PROT_READ)) {<br>
                tst_res(TFAIL, "Cannot mprotect new VMA");<br>
                return;<br>
        }<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>