Re: [Qemu-devel] [PATCH v3 07/13] 9p: darwin: Provide a compatibility definition for XATTR_SIZE_MAX

[Greg Kurz]

On Sat, 16 Jun 2018 20:56:51 -0400
Keno Fischer <address@hidden> wrote:

> Signed-off-by: Keno Fischer <address@hidden>
> ---
>  hw/9pfs/9p.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index e650459..abfb8dc 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -3374,6 +3374,13 @@ out_nofid:
>      v9fs_string_free(&name);
>  }
>  
> +#if defined(CONFIG_DARWIN) && !defined(XATTR_SIZE_MAX)
> +/* Darwin doesn't seem to define a maximum xattr size in its user
> +   user space header, but looking at the kernel source, HFS supports
> +   up to INT32_MAX, so use that as the maximum.
> +*/
> +#define XATTR_SIZE_MAX INT32_MAX

XATTR_SIZE_MAX is used to cap the size that was received from the client,
and then we do:

    xattr_fidp->fs.xattr.value = g_malloc0(size);

so I'd rather have something very much smaller than 4 gigs.

I now think that having an explicit dependency on XATTR_SIZE_MAX was a poor
choice actually. The problem isn't related to what the host supports, but
only to set a reasonable limit on what we accept from guests. We don't want
a buggy 9p client to crash QEMU.

TXATTRCREATE is only present in the 9p2000.L protocol, ie, linux guests,
which I don't expect to create extended attributes greater than 64k (ie,
XATTR_SIZE_MAX in the guest). We've been using this value for nearly two
years and nobody complained.

No need for a define. I guess you can open code the limit at the only
location where it is needed, with a short comment.

> +#endif
>  static void coroutine_fn v9fs_xattrcreate(void *opaque)
>  {
>      int flags, rflags = 0;