<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 3:41 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</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">On 1/26/24 11:28, enh via Toybox wrote:<br>
> The ULONG_MAX turns into -1 here, which isn't what was intended.<br>
<br>
Ah. That one ONLY works on 32 bit. Oops.<br></blockquote><div><br></div><div>(yeah, sorry, i realized after sending my patch that my LP64 bigotry was showing again, and it might not be obvious _why_.)</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">
(I went down a research rathole trying to work out whether the spectre/meltdown<br>
mitigations that unmapped the kernel from normal userspace brought back Ingo's<br>
old 4G/4G mapping or not on 32 bit, didn't really get a useful answer, went with<br>
unsigned rather than try to read through the kernel code... and missed the obvious.)<br>
<br>
> I'll avoid the bikeshed of the least worst full fix and take half<br>
> the range which is plenty for my purposes.<br>
<br>
Neither Intel nor Arm support the full 64 bits (Intel did 5-level page tables to<br>
hit 57 bits, Arm increased page size to hit 52, and atomic limits are really<br>
starting to bite ala <a href="https://www.youtube.com/watch?v=2G4_RZo41Zw" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=2G4_RZo41Zw</a>), so signed<br>
long is probably fine for the forseeable future. :)<br></blockquote><div><br></div><div>the main users for this are working on 32-bit devices anyway, and explicitly only devices that have less than 4GiB anyway (if i've understood <a href="https://source.android.com/docs/compatibility/14/android-14-cdd#76_memory_and_storage">https://source.android.com/docs/compatibility/14/android-14-cdd#76_memory_and_storage</a> correctly).</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">
> Also fix the array indexing to not segfault.<br>
<br>
Sigh, I only ran "memeater 10k" on my laptop (in a 32 bit build). My musl-cross<br>
toolchain hasn't got ASAN wired up and hangs right after so never noticed.<br>
(Still embarassing...)<br>
<br>
Your fix is writing more than once per page. I'm adjusting stride already in the<br>
increment, the problem is size needs to be adjusted to not go off the end.<br>
(Moving adjustment to the index adds math to the loop instead of resolving it at<br>
compile time, but eh, keep that one. I fixed up your patch with vi, but actually<br>
tested the result this time. :)<br>
<br>
The _next_ problem is trying "memeater 1m" so it actually gets some nontrivial<br>
exercise, I had to sudo it to avoid:<br>
<br>
$ ./memeater 1m<br>
memeater: mlock: Cannot allocate memory<br>
<br>
With the 10k I didn't get that objection, because:<br>
<br>
$ ulimit -l<br>
64<br>
<br>
Should I make the mlock() not be the default, presumably switching to -m to<br>
enable rather than disable it? (Dunno what your android environment looks like<br>
here...)<br></blockquote><div><br></div><div>"works for me" on _my_ hosts, but i haven't actually tested on Android yet, and that's very likely to be next week at this point...</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">
Commit 1e04fb285c3c.<br></blockquote><div><br></div><div>...especially because this isn't showing in github yet :-)</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">
Rob<br>
</blockquote></div></div>