[Toybox] [PATCH] memeater: fixes.

[Rob Landley]

On 1/26/24 11:28, enh via Toybox wrote:
> The ULONG_MAX turns into -1 here, which isn't what was intended.

Ah. That one ONLY works on 32 bit. Oops.

(I went down a research rathole trying to work out whether the spectre/meltdown
mitigations that unmapped the kernel from normal userspace brought back Ingo's
old 4G/4G mapping or not on 32 bit, didn't really get a useful answer, went with
unsigned rather than try to read through the kernel code... and missed the obvious.)

> I'll avoid the bikeshed of the least worst full fix and take half
> the range which is plenty for my purposes.

Neither Intel nor Arm support the full 64 bits (Intel did 5-level page tables to
hit 57 bits, Arm increased page size to hit 52, and atomic limits are really
starting to bite ala https://www.youtube.com/watch?v=2G4_RZo41Zw), so signed
long is probably fine for the forseeable future. :)

> Also fix the array indexing to not segfault.

Sigh, I only ran "memeater 10k" on my laptop (in a 32 bit build). My musl-cross
toolchain hasn't got ASAN wired up and hangs right after so never noticed.
(Still embarassing...)

Your fix is writing more than once per page. I'm adjusting stride already in the
increment, the problem is size needs to be adjusted to not go off the end.
(Moving adjustment to the index adds math to the loop instead of resolving it at
compile time, but eh, keep that one. I fixed up your patch with vi, but actually
tested the result this time. :)

The _next_ problem is trying "memeater 1m" so it actually gets some nontrivial
exercise, I had to sudo it to avoid:

$ ./memeater 1m
memeater: mlock: Cannot allocate memory

With the 10k I didn't get that objection, because:

$ ulimit -l
64

Should I make the mlock() not be the default, presumably switching to -m to
enable rather than disable it? (Dunno what your android environment looks like
here...)

Commit 1e04fb285c3c.

Rob