From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop
Date: Thu, 07 May 2020 13:46:50 +0200 [thread overview]
Message-ID: <3205025.KiTILEyK6o@silver> (raw)
In-Reply-To: <20200506195415.4cc48810@bahia.lan>
On Mittwoch, 6. Mai 2020 19:54:15 CEST Greg Kurz wrote:
> On Wed, 06 May 2020 15:36:16 +0200
>
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote:
> > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > > index 9e046f7acb51..ac84ae804496 100644
> > > > --- a/hw/9pfs/9p.c
> > > > +++ b/hw/9pfs/9p.c
> > > > @@ -2170,7 +2170,7 @@ static int coroutine_fn
> > > > v9fs_do_readdir_with_stat(V9fsPDU *pdu, int32_t count = 0;
> > > >
> > > > struct stat stbuf;
> > > > off_t saved_dir_pos;
> > > >
> > > > - struct dirent *dent;
> > > > + struct dirent dent;
> >
> > One more: since this dirent structure is now on the stack, it should
> > better be initialized for safety reasons.
>
> I don't think so, for two reasons:
> - I can't think of an initializer that would make sense for a dirent
The same as it would (implied - usually, e.g. with gmalloc0()) if you were
allocating it on heap: by initializing it with all zeroes, e.g. just:
struct dirent dent = {};
> - if a future change introduces a branch where dent could be used
> uninitialized, I'd rather give a chance to the compiler to bark
The compiler would reliably bark on using it unitialized if you were about to
access it directly within the same function. But that's not the case here.
dirent is passed by reference to a function which will be altering it. Such
stacked relations usually require more sophisticated diagnostics, like e.g.
exeuting the LLVM sanitizer.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-05-07 11:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 15:53 [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop Greg Kurz
2020-05-06 13:05 ` Christian Schoenebeck
2020-05-06 13:36 ` Christian Schoenebeck
2020-05-06 17:54 ` Greg Kurz
2020-05-07 11:46 ` Christian Schoenebeck [this message]
2020-05-07 13:42 ` Greg Kurz
2020-05-06 17:49 ` Greg Kurz
2020-05-07 11:37 ` Christian Schoenebeck
2020-05-07 14:33 ` Greg Kurz
2020-05-07 15:03 ` Christian Schoenebeck
2020-05-07 16:35 ` Greg Kurz
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=3205025.KiTILEyK6o@silver \
--to=qemu_oss@crudebyte.com \
--cc=groug@kaod.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.