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

[Greg Kurz]

On Mon, 14 Feb 2022 17:43:51 +0300
Vitaly Chikunov <vt@altlinux.org> wrote:

> 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.
> 


I prefer g_new0() for the exact reasons that are provided in QEMU's
official coding style docs/devel/style.rst:

---

Prefer ``g_new(T, n)`` instead of ``g_malloc(sizeof(T) * n)`` for the following
reasons:

* It catches multiplication overflowing size_t;
* It returns T ``*`` instead of void ``*``, letting compiler catch more type 
errors.

Declarations like

.. code-block:: c

    T *v = g_malloc(sizeof(*v))

are acceptable, though.

---

I'm fine with the acceptable version as well. The only important thing is
to fix the synth backend.

Cheers,

--
Greg

> 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
> >