Re: [PULL 0/5] 9p queue 2022-02-10

[Vitaly Chikunov]

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
>