All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Pino Toscano <ptoscano@redhat.com>,
	"Qemu-devel@nongnu.org" <Qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>,
	libguestfs@redhat.com, mreitz@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [Libguestfs] [PATCH] tests: regressions: make test-big-heap use a temporary empty file
Date: Wed, 21 Mar 2018 22:15:31 +0000	[thread overview]
Message-ID: <20180321221531.GF2787@redhat.com> (raw)
In-Reply-To: <386fe69d-f45b-704a-e936-0211935977ce@redhat.com>

On Wed, Mar 21, 2018 at 03:58:05PM -0500, Eric Blake wrote:
> On 03/21/2018 03:44 PM, Kevin Wolf wrote:
> >>>
> >>>You're right that file locking on a character device like /dev/null is
> >>>not going to work as expected, but is it a case where fcntl() actually
> >>>fails, or is it worse where the fcntl() claiming the locks "succeeds"
> >>>but doesn't do what we want?  That is, what were the actual error
> >>>messages you ran into?
> >>
> >>$ qemu-img --version
> >>qemu-img version 2.10.1(qemu-2.10.1-2.fc27)
> >>Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
> >>$ qemu-img info /dev/null
> >>qemu-img: Could not open '/dev/null': Failed to get "consistent read" lock
> >>Is another process using the image?
> >
> >Not sure where the difference is, but I can't reproduce this on
> >upstream, neither git master nor the v2.10.1 tag:
> 
> Is it a case where file locking actually works, and more than one
> process is trying to lock /dev/null at once?  (qemu-img info is
> short-lived, but could there be another longer-lived process also
> using /dev/null)?
> 
> Does using -r help (if the only reason you're telling qemu-img to
> operate on /dev/null is to probe qemu-img features, can you probe
> those same features without needing to write, which in turn requests
> less locking)?

The original test (before Pino's patch) runs ‘qemu-img info /dev/null’
purely as a way to fork qemu-img.  It's a regression test for some
problem we had with the code that confines qemu-img using resource
limits.  So really nothing much to do with qemu-img at all.  The fix
is to create a temporary file and run qemu-img against that.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

      reply	other threads:[~2018-03-21 22:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180321124417.29242-1-ptoscano@redhat.com>
     [not found] ` <20180321125105.GJ19514@redhat.com>
2018-03-21 13:45   ` [Qemu-devel] [Libguestfs] [PATCH] tests: regressions: make test-big-heap use a temporary empty file Eric Blake
2018-03-21 13:48     ` Pino Toscano
2018-03-21 20:44       ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2018-03-21 20:58         ` Eric Blake
2018-03-21 22:15           ` Richard W.M. Jones [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180321221531.GF2787@redhat.com \
    --to=rjones@redhat.com \
    --cc=Qemu-devel@nongnu.org \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libguestfs@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=ptoscano@redhat.com \
    --cc=qemu-block@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.