From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1borLY-000791-KU for qemu-devel@nongnu.org; Tue, 27 Sep 2016 08:18:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1borLS-0007Rk-0i for qemu-devel@nongnu.org; Tue, 27 Sep 2016 08:18:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1borLR-0007Rc-Qo for qemu-devel@nongnu.org; Tue, 27 Sep 2016 08:18:45 -0400 Date: Tue, 27 Sep 2016 13:18:41 +0100 From: "Daniel P. Berrange" Message-ID: <20160927121841.GM3967@redhat.com> Reply-To: "Daniel P. Berrange" References: <20160923110300.23502.55001.malonedeb@soybean.canonical.com> <20160927030621.20862-1-rafael.tinoco@canonical.com> <20160927083626.GC3967@redhat.com> <7220810B-7C81-4B51-BDE5-7BC0022F3605@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7220810B-7C81-4B51-BDE5-7BC0022F3605@canonical.com> Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1626972 <1626972@bugs.launchpad.net> Cc: qemu-devel@nongnu.org On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote: > > On Sep 27, 2016, at 05:36, Daniel P. Berrange wrote: > > > > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: > >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback > >> mechanism for systems not supporting memfd_create syscall (started > >> being supported since 3.17). > > > > This is really dubious code in general and IMHO should just > > be reverted. > > There are numerous people relying on older kernels in openstack > deployments - sometimes with specific drivers (ovswitch, dpdk, > infiniband) holding kernel upgrades - but still in need of upgrading > userland (e.g. newer releases). Having a fallback mechanism seems > appropriate for those cases. I'm not against some kind of fallback - just about the way it silently creates files in /tmp. > > Note that the filename, per se, is not as important as other files, > since qemu won't provide it for being accessed by external programs, and, > deletes the file, while keeping the descriptor, right after its creation > (due to its nature, that is probably why it was created in /tmp). If it doesn't shared with other processes, and is deleted immediately, why does the file need to be on disk at all ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|