svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux

[Edward Tomasz Napierała]

On 0629T1242, Kyle Evans wrote:
> On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> >
> > Hey Kyle,
> >
> > On Mon, Jun 29, 2020 at 03:09:14AM +0000, Kyle Evans wrote:
> > > Author: kevans
> > > Date: Mon Jun 29 03:09:14 2020
> > > New Revision: 362769
> > > URL: https://svnweb.freebsd.org/changeset/base/362769
> > >
> > > Log:
> > >   linuxolator: implement memfd_create syscall
> > >
> > >   This effectively mirrors our libc implementation, but with minor fudging --
> > >   name needs to be copied in from userspace, so we just copy it straight into
> > >   stack-allocated memfd_name into the correct position rather than allocating
> > >   memory that needs to be cleaned up.
> > >
> > >   The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have
> > >   also been implemented now that we support them.
> > >
> > >   Note that this implementation is still not quite at feature parity w.r.t.
> > >   the actual Linux version; some caveats, from my foggy memory:
> > >
> > >   - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress)
> > >   - LTP wants the memfd name exposed to fdescfs
> > >   - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup.
> > >     (?)
> > >
> > >   Interested parties can install and run LTP from ports (devel/linux-ltp) to
> > >   confirm any fixes.
> > >
> > >   PR:         240874
> > >   Reviewed by:        kib, trasz
> > >   Differential Revision:      https://reviews.freebsd.org/D21845
> >
> > RELNOTES?
> >
> > >
> > > Modified:
> > >   head/sys/amd64/linux/linux_dummy.c
> > >   head/sys/amd64/linux32/linux32_dummy.c
> > >   head/sys/arm64/linux/linux_dummy.c
> > >   head/sys/compat/linux/linux.c
> > >   head/sys/compat/linux/linux.h
> > >   head/sys/compat/linux/linux_file.c
> > >   head/sys/compat/linux/linux_file.h
> > >   head/sys/i386/linux/linux_dummy.c
> >
> > Should __FreeBSD_version be bumped?
> >
> 
> I'm roping in trasz@, because I'm unsure on either of these points --
> I haven't paid attention and don't know if we typically include linux
> syscalls that we implement in relnotes, and given that this commit
> only really affects pre-compiled Linux binaries I'm not sure if
> there's any utility in bumping __FreeBSD_version; presumably ports
> folks can't do anything differently here, and binaries will work just
> the same.

I don't think we need to bump the version here.  As for the relnotes:
I hadn't considered that before, but it sounds like a good idea; we
probably do want to at least enumerate the major Linuxulator changes
there.