On 0629T1242, Kyle Evans wrote: > On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb <shawn.w...@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. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
