<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 22, 2018 at 5:24 PM, Richard Palethorpe <span dir="ltr"><<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<span class="gmail-"><br>
Cyril Hrubis <<a href="mailto:chrubis@suse.cz">chrubis@suse.cz</a>> writes:<br>
<br>
> Hi!<br>
> I've dusted off my old pxa270 PDA and tried to compare the different<br>
> implementations of the fuzzy sync library:<br>
<br>
</span>Good stuff!<br>
<div><div class="gmail-h5"><br>
><br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | test | old library | new library |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | shmctl05 | timeouts | timeouts |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | inotify09 | timeouts | exits in sampling with WARN |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | cve-2017-2671 | kernel crash | kernel crash |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | cve-2016-7117 | kernel crash | exits in sampling with WARN |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
> | cve-2014-0196 | timetous | exits in sampling with WARN |<br>
> |-----------------------------<wbr>------------------------------<wbr>--|<br>
><br>
> The shmctl05 timeouts because the remap_file_pages is too slow and we<br>
> fail to do even one iteration, it's possible that this is because we are<br>
> hitting the race as well since this is kernel 3.0.0, but I cannot say<br>
> that for sure.<br>
><br>
> The real problem is that we fail to callibrate because the machine is<br>
> too slow and we do not manage to take the minimal amount of samples<br>
> until the default timeout.<br>
><br>
> If I increase the timeout percentage to 0.5, we manage to take at least<br>
> minimal amount of samples and to trigger the cve-2016-7117 from time to<br>
> time. But it looks like the bias computation does not work reasonably<br>
> reliably there, not sure why. But looking at the latest version adding<br>
> bias no longer resets the averages, which may be the reason because the<br>
> bias seems to be more or less the same as the number minimal samples.<br>
<br>
</div></div>Sounds correct. I guess context switches take a large number of cycles<br>
on this CPU relative to x86.<br>
<span class="gmail-"><br>
><br>
> So there are a few things to consider, first one is that the default<br>
> timeout percentage could be probably increased so that we do not have to<br>
> tune the LTP_TIMEOUT_MUL even on slower processors. The downside is that<br>
> these testcase would take longer on modern harware. Maybe we can do some<br>
> simple CPU benchmarking to callibrate the timeout.<br>
<br>
</span>Perhaps the test runner or test library should tune LTP_TIMEOUT_MUL?<br>
Assuming the user allows it.<br>
<span class="gmail-"><br>
><br>
> Second thing to consider is if and how to tune the minimal amount of<br>
> samples, Maybe we can set the minimal amount of samples to be smaller<br>
> and then exit the callibration if our deviation was small enough three<br>
> times in a row. But then there is this bias that we have to take into an<br>
> account somehow.<br>
<br>
</span>I think the only way is to benchmark a selection of syscalls and then<br>
pass this data to the test somehow. Then it can calculate some<br>
reasonable time and sample limits.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Maybe we can also reduce the sampling time via remove pair->diff_ss average counting.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Looking at the pair->delay algorithm:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default"> per_spin_time = fabsf(pair->diff_ab.avg) / pair->spins_avg.avg;<br></div><div class="gmail_default"> time_delay = drand48() * (pair->diff_sa.avg + pair->diff_sb.avg) - pair->diff_sb.avg;</div><div class="gmail_default"> pair->delay += (int)(time_delay / per_spin_time);</div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">the pair->diff_ss is not in use and why we do average calculation in tst_upd_diff_stat()? On the other hand, it has overlap with pair->diff_ab in functional, we could reduce 1/4 of total sampling time if we remove it.</div></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
However I also think this is beyond the scope of this patch set because<br>
fuzzy sync tests are just one potential user of such metrics. I suspect<br>
also that it will be a big enough change to justify its own discussion<br>
and patch set.<br>
<br>
For now, if we increase the minimum time limit and samples so that<br>
cve-2016-7117 behaves sensibly on a pxa270 then we are probably covering<br>
most users. The downside is that we are wasting some time and<br>
electricity on server grade hardware, but at least the tests are being<br>
performed correctly on most hardware.<br>
<br>
--<br>
Thank you,<br>
Richard.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
-- <br>
Mailing list info: <a href="https://lists.linux.it/listinfo/ltp" rel="noreferrer" target="_blank">https://lists.linux.it/<wbr>listinfo/ltp</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div>
</div></div></div></div></div></div>