On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 09 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> > find(1) uses ARG_MAX to compute the maximum space it can pass to
> > execve(2). This doesn't fly if userland and the kernel don't agree, as
> > noticed by some after the recent ARG_MAX bump.
> >
> > --8<--
> > ritchie /usr/src/usr.bin/find$ obj/find /usr/src/ -type f -exec true {} +
> > find: true: Argument list too long
> > find: true: Argument list too long
> > find: true: Argument list too long
> > ^C
> > -->8--
> >
> > While having the kernel and userland out of sync is not a good idea,
> > making find(1) more robust by using sysconf(3) is easy. This is what
> > xargs(1) already does.
> >
> > ok?
>
> Committed, thanks.
>
> > PS: a followup diff will take into account the space taken by the
> > environment
>
> Right now we don't account for the space used by the environment.
> We get lucky either because of the 5000 max args limit or because
> environment size usually fits in the 4096 bytes safety net.
>
> The diff below uses the same approach as xargs(1).
> While here, tweak the message in case of (unlikely) sysconf(3) failure.
You drop a bit of the comment in find, specifically the 4K stuff.
I would probably restore it.
Note that there is an explanation for the overflow in the kernel code:
MAXINTERP + MAXPATHLEN
exec does not reallocate args for scripts, but requires the extra space to
set things up.
