Re: [PATCH 3/6] linux: Implement mremap in C

[enh <enh@google.com>]

On Thu, Jun 6, 2024 at 12:01 PM enh <enh@google.com> wrote:
>
> On Thu, Jun 6, 2024 at 11:15 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Adhemerval Zanella via Libc-alpha:
> >
> > > Variadic function calls in syscalls.list does not work for all ABIs
> > > (for instance where the argument are passed on the stack instead of
> > > registers) and might have underlying issues depending of the variadic
> > > type (for instance if a 64-bit argument is used).
> > >
> > > Checked on x86_64-linux-gnu.
> >
> > Where exactly does this break?
> >
> > If the syscall generator cannot handle pointer arguments, we should fix
> > that.  As far as I can tell, we currently assume that the kernel can
> > handle sign-extended pointers.  I don't see any special code for
> > processing a/p/s pointers, for example.  That impacts far more than just
> > mremap.  These pointers are generally not marked as U, for which we have
> > special processing.
> >
> > Conditional varargs processing for system calls is very bad.  It causes
> > an ongoing maintenance headache, and weird application issues.  For
> > example, Linux 5.7 added MREMAP_DONTUNMAP, and it can use the address
> > argument just like MREMAP_FIXED.  But the current mremap implementation
> > always passes NULL as a system call argument.
>
> yeah, bionic and musl have this same bug, for the same reason of
> having been written before MREMAP_DONTUNMAP was added, and not having
> been updated since.

is it possible to use MREMAP_DONTUNMAP with a destination address
without also setting MREMAP_FIXED? the kernel selftests don't seem to
_test_ that case if so...

the glibc header comment also claims that MREMAP_FIXED is necessary.

> bionic and musl both have a PTRDIFF_MAX check that glibc doesn't have,
> though, so although i think using assembler instead of C would be a
> no-op for glibc, it would be an observable change for bionic and musl
> (albeit only on ILP32).
>
> > Then there's the issue where varargs functions have more stringent ABI
> > requirements than non-varargs functions, as we recently saw with prctl.
> >
> > I think we should just revert this change, to be honest.
> >
> > Thanks,
> > Florian
> >