> I still don't think this addresses the whole problem.
You're responding to one of three patches, and I said to begin with that
all together they only address part of the problem (not the OOM part).
So the import of this remark is somewhat mysterious.
I question that assertion. For a non-RLIM_INFINITY limit, there is nothing
in particular wrong with it. The kernel is free to pick its upper bound
for ARG_MAX by whatever method. I don't see anything much to object to
about the rlimit/4 method. It has no useful effect for RLIM_INFINITY and
IMHO should not try to impose any limit in that case. But that's the only
thing I see a reason to change.
I see no reason to suspect this was the "original intent". It seems most
likely to me that the original intent was 1/4th the RLIMIT_STACK size, and
just nobody thought about what that meant when RLIMIT_STACK was RLIM_INFINITY.
That's what happens now when RLIMIT_STACK is smaller, and that's what
people really care about. What you suggest would require some more
significant changes to the exec code path, touching all the binfmt modules
(though probably only binfmt_elf matters).
In the current structure of the code, the arch-dependent SET_PERSONALITY
macro used by {compat_,}binfmt_elf is the only place that knows what arch
bits to set for the new address space size. This is itself destructive,
but also runs after flush_old_exec (the point of no return). So you'd have
to reorganize things significantly, or add an entirely new arch macro tied
into struct binfmt somehow, or something like that.
This was done in commit b6a2fea by Ollie Wild <aaw@google.com>:
mm: variable length argument support
It was part of going from a fixed maximum to no fixed maximum.
The log includes:
[a.p.zijlstra@chello.nl: limit stack size]
So perhaps it was Peter who devised the rlimit/4 idea.
Thanks,
Roland
--
