From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhDNM-0002Fz-47 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 05:08:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhDNI-0007Uf-0g for qemu-devel@nongnu.org; Wed, 30 Sep 2015 05:08:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhDNH-0007UG-S1 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 05:08:31 -0400 Date: Wed, 30 Sep 2015 12:08:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20150930120817-mutt-send-email-mst@redhat.com> References: <1443544494-28737-1-git-send-email-marcandre.lureau@redhat.com> <1443544494-28737-7-git-send-email-marcandre.lureau@redhat.com> <20150930120224-mutt-send-email-mst@redhat.com> <1999582688.20418438.1443604015953.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1999582688.20418438.1443604015953.JavaMail.zimbra@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 06/24] memfd: add fallback for memfd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Cc: haifeng lin , thibaut collet , jasowang@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, marcandre lureau On Wed, Sep 30, 2015 at 05:06:55AM -0400, Marc-Andr=E9 Lureau wrote: > Hi >=20 > ----- Original Message ----- > > On Tue, Sep 29, 2015 at 06:34:36PM +0200, marcandre.lureau@redhat.com= wrote: > > > From: Marc-Andr=E9 Lureau > > >=20 > > > Add an open/unlink/mmap fallback for system that do not support mem= fd. > > > This patch may require additional SELinux policies to work for enfo= rced > > > systems, but should gracefully fail nonetheless. > > >=20 > > > Signed-off-by: Marc-Andr=E9 Lureau > >=20 > > I'd rather just fail migration. >=20 > So we don't provide this compatibility code and migration should fail. >=20 > Would it be enough to check if memfd works at early runtime and add a m= igration blocker for vhost-user? Or is it possible to recover if migratio= n fails when memfd fails to allocate? I would thing the former is better. Fine with me. > >=20 > > > --- > > > util/memfd.c | 22 ++++++++++++++++++++-- > > > 1 file changed, 20 insertions(+), 2 deletions(-) > > >=20 > > > diff --git a/util/memfd.c b/util/memfd.c > > > index 3168902..970b5b0 100644 > > > --- a/util/memfd.c > > > +++ b/util/memfd.c > > > @@ -84,8 +84,26 @@ void *qemu_memfd_alloc(const char *name, size_t = size, > > > unsigned int seals, > > > return NULL; > > > } > > > } else { > > > - perror("memfd"); > > > - return NULL; > > > + const char *tmpdir =3D getenv("TMPDIR"); > > > + gchar *fname; > > > + > > > + tmpdir =3D tmpdir ? tmpdir : "/tmp"; > > > + > > > + fname =3D g_strdup_printf("%s/memfd-XXXXXX", tmpdir); > > > + mfd =3D mkstemp(fname); > > > + unlink(fname); > > > + g_free(fname); > > > + > > > + if (mfd =3D=3D -1) { > > > + perror("mkstemp"); > > > + return NULL; > > > + } > > > + > > > + if (ftruncate(mfd, size) =3D=3D -1) { > > > + perror("ftruncate"); > > > + close(mfd); > > > + return NULL; > > > + } > > > } > > > =20 > > > ptr =3D mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, mfd,= 0); > > > -- > > > 2.4.3 > >=20