<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 11:20 AM Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.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"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><span class="gmail_default" style="font-size:small">...</span></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+       return !(local_var_1 < &local_var_2);<br></blockquote><div><br></div><div><div style="font-size:small">Shouldn't local_var_1 less than local_var_2 on a stack grow up arch? why we return the reverse value here?</div><br></div><div><div style="font-size:small">And the worth to say that the optimization of GCC will break this rule in the compilation. </div><div style="font-size:small"><br></div><div style="font-size:small">-O2  (ltp default gcc flag)</div><div style="font-size:small">mmap18.c:46: INFO: local_var_1 = 0x3ffd177dea0, loval_var_2 = 0x3ffd177dea4<br></div><div style="font-size:small"> -O0</div><div style="font-size:small">mmap18.c:46: INFO: local_var_1 = 0x3ffc86fe614, loval_var_2 = 0x3ffc86fe56c</div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">To avoid the compiler optimization disturbing the address order of variables, I'd</div><div class="gmail_default" style="font-size:small">suggest using only one local variable as the baseline to compare with itself new</div><div class="gmail_default" style="font-size:small">address in another recursive function calling.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Something maybe like this:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">static int check_stackgrow_up(void)<br>{<br>    char local_var;<br>    static char *addr = 0;<br><br>    if (addr == 0) {<br>        addr = &local_var;<br>        return check_stackgrow_up();<br>    }<br><br>    return ((&local_var > addr) ? 1 : 0);<br>}</div></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div style="font-size:small">--------</div><br></div><div><div style="font-size:small">Apart from that, mmap18 also gets FAIL with s390x platform like:</div><div style="font-size:small"><br></div># ./mmap1<span class="gmail_default" style="font-size:small">8</span><br>tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s<br>mmap18.c:46: INFO: local_var_1 = 0x3fff537e5d4, loval_var_2 = 0x3fff537e52c<br>mmap18.c:126: INFO: mem = 0x3ff8dd3a000, stack = 0x3ff8dd5a000<br>mmap18.c:136: FAIL: Child killed by SIGSEGV</div></div></div></blockquote><div> </div></div><div class="gmail_default" style="font-size:small">From my observation, the failure only occurs on s390x, and it could not</div><div class="gmail_default" style="font-size:small">overstride to the unmap memory area. With the following debug-code</div><div class="gmail_default" style="font-size:small">adding to run_test():</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">+       memset(stack, 1, getpagesize());<br>+       tst_res(TINFO, "write to *stack sucess");<br>+       memset(stack - getpagesize(), 1, getpagesize());<br>+       tst_res(TINFO, "write to *(stack - %d) sucess", getpagesize());<br></div><div><br></div><div><div class="gmail_default" style="font-size:small">mmap18 (on s390x) prints:</div><div class="gmail_default" style="font-size:small"><br></div><span class="gmail_default" style="font-size:small">  </span>tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s<br><span class="gmail_default" style="font-size:small">  </span>mmap18.c:137: INFO: write to *stack sucess<br><span class="gmail_default" style="font-size:small">  </span>tst_test.c:1292: BROK: Test killed by SIGSEGV!</div><div><br><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">But trying with other architectures(x86_64, aarch64), they all override</div><div class="gmail_default" style="font-size:small">the stack and write into the unmapped area.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">  tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s<br></div><div class="gmail_default" style="font-size:small">  mmap18.c:139: INFO: write to *stack sucess<br>  mmap18.c:141: INFO: write to *(stack - 65536) sucess<br>  mmap18.c:151: PASS: Stack grows in unmapped region</div></div><div><br></div><div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And the Linux Manual makes me feel confusing here, what is the correct</div><div class="gmail_default" style="font-size:small">behavior when writing the "guard" page? Can someone help explain this? </div><br></div><div><span class="gmail_default" style="font-size:small">“"”</span></div><div><span class="gmail_default" style="font-size:small">    </span>MAP_GROWSDOWN<br><span class="gmail_default" style="font-size:small">   </span><span class="gmail_default" style="font-size:small"> ...</span></div><div><span class="gmail_default" style="font-size:small">    </span>Touching an address in the "guard" page below the<span class="gmail_default" style="font-size:small"> </span>mapping will</div><div><span class="gmail_default" style="font-size:small">    </span>cause the mapping to grow by a page. This growth can be repeated</div><div><span class="gmail_default" style="font-size:small">    </span>until the mapping grows to within a page of the high end of the next</div><div><span class="gmail_default" style="font-size:small">    </span>lower<span class="gmail_default" style="font-size:small"> </span>map<span class="gmail_default">p</span>ing, at which point touching the "guard" page will result</div><div><span class="gmail_default" style="font-size:small">    </span>in a SIGSEGV signal.</div><div><div class="gmail_default" style="font-size:small">"""</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>