All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Li Qiang" <liq3ea@gmail.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] util: check the return value of fcntl in qemu_set_{block, noblock}
Date: Thu, 13 Dec 2018 12:39:08 +0000	[thread overview]
Message-ID: <20181213123908.GI5171@redhat.com> (raw)
In-Reply-To: <87o99pa9w8.fsf@dusky.pond.sub.org>

On Thu, Dec 13, 2018 at 01:28:23PM +0100, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On Thu, 13 Dec 2018 at 10:19, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>
> >> On Wed, Dec 12, 2018 at 06:09:37PM -0800, Li Qiang wrote:
> >> > Assert that the return value is not an error. This is like commit
> >> > 7e6478e7d4f for qemu_set_cloexec.
> >> >
> >> > Signed-off-by: Li Qiang <liq3ea@gmail.com>
> >> > ---
> >> >  util/oslib-posix.c | 8 ++++++--
> >> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> >> > index c1bee2a581..4ce1ba9ca4 100644
> >> > --- a/util/oslib-posix.c
> >> > +++ b/util/oslib-posix.c
> >> > @@ -233,14 +233,18 @@ void qemu_set_block(int fd)
> >> >  {
> >> >      int f;
> >> >      f = fcntl(fd, F_GETFL);
> >> > -    fcntl(fd, F_SETFL, f & ~O_NONBLOCK);
> >> > +    assert(f != -1);
> >>
> >> This leads to *awful* diagnostics. We need to print something
> >> useful when it fails so we stand a chance of understanding what
> >> is wrong.
> >
> > It's the same thing we do in qemu_set_cloexec(), though,
> > and nobody's complained about that that I know of. I think
> > we need to understand whether we're getting asserts in
> > vhost_user_test because of something silly like passing -1
> > as the fd, or because the fcntl() can legitimately fail.
> > If the former, the assert isn't a big deal because when
> > we hit it in newly developed code the problem is going
> > to be obvious when run under a debugger. If the latter,
> > we need to actually pass out the error status and fix
> > all the callers to check it...
> 
> Yes.
> 
> Assertions are not expected to fail *by definition*.  When they do,
> there's a bug in the code, and having to look at the code to see what's
> wrong is totally fine.

The problem with this assertion is that there's many places which
call qemu_set_nonblock, so you don't know which code to look at,
as we don't know the caller. 

> When you feel you have to print something fancy when an assertion fails,
> either your feelings are misguided, or the assertion is wrong.

Honestly I'd probably prefer these methods to take an "Error **errp"
and propagate to the caller but that's alot more work.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2018-12-13 12:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13  2:09 [Qemu-devel] [PATCH] util: check the return value of fcntl in qemu_set_{block, noblock} Li Qiang
2018-12-13  6:57 ` no-reply
2018-12-13  9:31   ` Peter Maydell
2018-12-13  9:56     ` Li Qiang
2018-12-13 10:17       ` Daniel P. Berrangé
2018-12-13 10:38         ` Li Qiang
2018-12-13 10:19 ` Daniel P. Berrangé
2018-12-13 11:27   ` Peter Maydell
2018-12-13 12:28     ` Markus Armbruster
2018-12-13 12:39       ` Daniel P. Berrangé [this message]
2018-12-13 12:54         ` Peter Maydell
2018-12-13 14:40           ` Markus Armbruster
2018-12-13 14:43         ` Markus Armbruster

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=20181213123908.GI5171@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=liq3ea@gmail.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@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.