Re: [PATCH v2 06/11] 9p: darwin: Compatibility defn for XATTR_SIZE_MAX

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Montag, 22. November 2021 01:49:08 CET Will Cohen wrote:
> From: Keno Fischer <keno@juliacomputing.com>
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com>
> [Will Cohen: - Adjust coding style]
> Signed-off-by: Will Cohen <wwcohen@gmail.com>
> ---
>  hw/9pfs/9p.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index c941b46f60..d671995aa4 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -3943,6 +3943,14 @@ 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
> + * 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
> +#endif
>  static void coroutine_fn v9fs_xattrcreate(void *opaque)
>  {
>      int flags, rflags = 0;

That would be 2 GB.

v9fs_xattrcreate() [9p.c] calls g_malloc0(size), if that fails it would
terminate QEMU.

I think it would make sense to simply set this to a reasonable small value for
macOS for now as well. The intended supported scenario for 9p currently is
macOS being host and Linux being guest. So the limitations of Linux would
apply anyway ATM.

Once we have macOS guest support, we can still work on a refinement to support
larger attributes IMO.