On Fri, 16 Aug 2019 at 22:28, Shu-Chun Weng via Qemu-devel <qemu-devel@nongnu.org> wrote: > > Add support for the memfd_create syscall. If the host does not have the > libc wrapper, translate to a direct syscall with NC-macro. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1734792 > Signed-off-by: Shu-Chun Weng <s...@google.com> > --- > include/qemu/memfd.h | 4 ++++ > linux-user/syscall.c | 11 +++++++++++ > util/memfd.c | 2 +- > 3 files changed, 16 insertions(+), 1 deletion(-) > > diff --git a/include/qemu/memfd.h b/include/qemu/memfd.h > index d551c28b68..975b6bdb77 100644 > --- a/include/qemu/memfd.h > +++ b/include/qemu/memfd.h > @@ -32,6 +32,10 @@ > #define MFD_HUGE_SHIFT 26 > #endif > > +#if defined CONFIG_LINUX && !defined CONFIG_MEMFD > +int memfd_create(const char *name, unsigned int flags); > +#endif > + > int qemu_memfd_create(const char *name, size_t size, bool hugetlb, > uint64_t hugetlbsize, unsigned int seals, Error > **errp); > bool qemu_memfd_alloc_check(void); > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index 8367cb138d..b506c1f40e 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -20,6 +20,7 @@ > #include "qemu/osdep.h" > #include "qemu/cutils.h" > #include "qemu/path.h" > +#include "qemu/memfd.h" > #include <elf.h> > #include <endian.h> > #include <grp.h> > @@ -11938,6 +11939,16 @@ static abi_long do_syscall1(void *cpu_env, int num, > abi_long arg1, > /* PowerPC specific. */ > return do_swapcontext(cpu_env, arg1, arg2, arg3); > #endif > +#ifdef TARGET_NR_memfd_create > + case TARGET_NR_memfd_create: > + p = lock_user_string(arg1); > + if (!p) { > + return -TARGET_EFAULT; > + } > + ret = get_errno(memfd_create(p, arg2));
I think here you may need to call fd_trans_unregister(ret); since memfd_create() returns a file descriptor. (This call unregisters any pre-existing hooks for "we need to mangle the data for reads/writes of this file descriptor", in case the fd was previously being used for a file descriptor type that needed that.) This is what eg NR_open does. Laurent -- do I have this right? It's not entirely clear to me that we could ever be in a situation where a syscall like open or memfd_create returns an fd that's got an fd_trans hook active, because that would imply we'd failed to delete the hook on fd-close somehow. Is this just a belt-and-braces bit of coding ? thanks -- PMM