All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Dmitry V . Levin" <ldv@altlinux.org>,
	qemu-devel@nongnu.org, Greg Kurz <groug@kaod.org>
Subject: Re: [PULL 0/5] 9p queue 2022-02-10
Date: Mon, 14 Feb 2022 17:43:51 +0300	[thread overview]
Message-ID: <20220214144351.dp57o6jyfvliwkos@altlinux.org> (raw)
In-Reply-To: <2442070.WHyy189egQ@silver>

Christian,

On Mon, Feb 14, 2022 at 12:44:48PM +0100, Christian Schoenebeck wrote:
> On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote:
> > The synth backend should be fixed to honor d_reclen, or
> > at least to allocate with g_new0().
> 
> Yes, I overlooked that this is not initialized with zero already.
> 
> With g_new0() d_reclen would be zero and qemu_dirent_dup() would then fallback 
> to the portable branch (as I assumed it already would):

Perhaps, this additional change should be added (I only found two instances of
V9fsSynthOpenState allocation):

diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -182,7 +182,7 @@ static int synth_opendir(FsContext *ctx,
     V9fsSynthOpenState *synth_open;
     V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data;
 
-    synth_open = g_malloc(sizeof(*synth_open));
+    synth_open = g_malloc0(sizeof(*synth_open));
     synth_open->node = node;
     node->open_count++;
     fs->private = synth_open;
@@ -266,7 +266,7 @@ static int synth_open(FsContext *ctx, V9fsPath *fs_path,
     V9fsSynthOpenState *synth_open;
     V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data;
 
-    synth_open = g_malloc(sizeof(*synth_open));
+    synth_open = g_malloc0(sizeof(*synth_open));
     synth_open->node = node;
     node->open_count++;
     fs->private = synth_open;

> Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation size, 
> because it is known that some systems define dirent as flex-array (zero d_name 
> size).

(To be precise) not just zero, but 1 byte. Also, to remind, for some
filesystems, such as CIFS, actual d_name size could be longer than NAME_MAX.
Because of that struct dirent cannot be allocated statically or with simple
sizeof.

> 
> I know Greg would not favour this solution (using g_new0), but it's the most 
> minimalistic and most portable solution. So I would favour it for now.

Why g_new0 and not just g_malloc0? This is smallest code change, which seems
appropriate for a bug fix.

Thanks,

> 
> A cleaner solution on the long-term would be turning V9fsSynthOpenState's 
> 'dent' member into a pointer and adding a new function to osdep like:
> 
> struct dirent *
> qemu_dirent_new(const char* name) {
>     ...
> }
> 
> But I would like to postpone that qemu_dirent_new() solution, e.g. because I 
> guess some people would probably not like qemu_dirent_new() to have in osdep, 
> as it is probably not a general purpose function, and I am not keen putting 
> qemu_dirent_new() into a different location than qemu_dirent_dup(), because it 
> would raise the danger that system dependent code might deviate in future.
> 
> Best regards,
> Christian Schoenebeck
> 


  reply	other threads:[~2022-02-14 15:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck
2022-02-10 11:21 ` [PULL 3/5] tests/9pfs: Fix leak of local_test_path Christian Schoenebeck
2022-02-10 11:21 ` [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread Christian Schoenebeck
2022-02-10 11:21 ` [PULL 2/5] tests/9pfs: fix mkdir() being called twice Christian Schoenebeck
2022-02-10 11:21 ` [PULL 1/5] tests/9pfs: use g_autofree where possible Christian Schoenebeck
2022-02-10 11:21 ` [PULL 4/5] tests/9pfs: Use g_autofree and g_autoptr " Christian Schoenebeck
2022-02-13 20:33 ` [PULL 0/5] 9p queue 2022-02-10 Peter Maydell
2022-02-14  9:47   ` Christian Schoenebeck
2022-02-14  9:55     ` Peter Maydell
2022-02-14 12:09       ` Christian Schoenebeck
2022-02-14 10:36     ` Greg Kurz
2022-02-14 11:44       ` Christian Schoenebeck
2022-02-14 14:43         ` Vitaly Chikunov [this message]
2022-02-14 17:40           ` Christian Schoenebeck
2022-02-15  7:01           ` Greg Kurz
2022-02-16 10:30             ` Christian Schoenebeck
2022-02-16 14:23               ` Greg Kurz
2022-02-16 15:19               ` Philippe Mathieu-Daudé via
2022-02-16 16:09               ` Vitaly Chikunov
2022-02-16 16:20                 ` Christian Schoenebeck

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=20220214144351.dp57o6jyfvliwkos@altlinux.org \
    --to=vt@altlinux.org \
    --cc=groug@kaod.org \
    --cc=ldv@altlinux.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    /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.