From owner-svn-src-all@freebsd.org Mon Jun 29 17:43:01 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 654993500A8; Mon, 29 Jun 2020 17:43:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wZZs263Nz47Qm; Mon, 29 Jun 2020 17:43:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 27AF318B2E; Mon, 29 Jun 2020 17:43:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id v19so13456276qtq.10; Mon, 29 Jun 2020 10:43:01 -0700 (PDT) X-Gm-Message-State: AOAM532iDus0sVz9z3hV4DZHZQZcV9thAEpVKG0mv0998v/lHG4NUsQy O2B10af9jdlJiILEfTwXaMRiHnq7Ec5Pojg9KCk= X-Google-Smtp-Source: ABdhPJw/8TJ4pk78leirkf+lMBOzNt4osz72RKXl4mNr1Z688bIqRnZ3m6hpEpEcUr9Vd5yLAeco3ir1YNYNlG+8z7Q= X-Received: by 2002:ac8:691:: with SMTP id f17mr16726262qth.60.1593452580615; Mon, 29 Jun 2020 10:43:00 -0700 (PDT) MIME-Version: 1.0 References: <202006290309.05T39ETZ044859@repo.freebsd.org> <20200629152717.2ojwnipxkmjaoix2@mutt-hbsd> In-Reply-To: <20200629152717.2ojwnipxkmjaoix2@mutt-hbsd> From: Kyle Evans Date: Mon, 29 Jun 2020 12:42:49 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r362769 - in head/sys: amd64/linux amd64/linux32 arm64/linux compat/linux i386/linux To: Shawn Webb Cc: src-committers , svn-src-all , svn-src-head , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 17:43:01 -0000 On Mon, Jun 29, 2020 at 10:27 AM Shawn Webb 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. Thanks, Kyle Evans