[Toybox] [PATCH] ps: widen the VSIZE field for Android's default view.

[Rob Landley]

On 2/23/23 14:35, enh via Toybox wrote:
> On LP64 systems, address space is effectively free,

I remember when the ipv6 guys said that back in the 1990's. This is why
wikipedia[citation needed] blocks editing from the entire v6 address space.

> and the security
> folks have found a variety of ways to use large PROT_NONE regions. For
> example, Android currently spends 3GiB on the CFI shadow and 7GiB
> padding the scudo heap, meaning that even toybox cat has a VmSize around
> 10GiB. This means that the default ps output doesn't line up.

And this is why resident set size was invented.

Is there an "RSS if everything actually populated was faulted in" metric? RSS
plus swap space plus nonresident file backed pages? Hmmm... It really gets down
to "what do we WANT to be measuring here, and why"?

Sigh. SZ and VSZ are the same SLOT_vsize with different units:

    else if (which==PS_SZ) ll >>= 12;
    else if (which==PS_VSZ) ll >>= 10;

(Which implies the "ps -o help" description of SZ is wrong because that implies
it's RSS instead of VSZ. Or is the SLOT entry wrong and it SHOULD be SLOT_rss? I
tested all of this by hand at one point...)

Not digging into it right now. That said, If RSS _isn't_ the right metric, then
the next place to look would be /proc/self/smaps_rollup which I believe is newer
than this code and just... sigh. Did they add any of those new metrics to
/proc/self/stat? No of course they didn't, why would they do that...

> Arguably this should be a change to the default width (currently 7) of
> the VSZ entry in the "typos" array, but as long as desktop Linux isn't
> using its address space for security mitigations, that seemed like it
> might be too contentious.

Possibly it argues that the VSZ units should be something other than 1k, but
mostly I think it argues that VSZ has become somewhat meaningless on android?

*shrug* Applied, but this is kinda whistling past some design questions...

Rob