On Sat, 16 Jun 2018 20:56:51 -0400 Keno Fischer <k...@juliacomputing.com> wrote:
> Signed-off-by: Keno Fischer <k...@juliacomputing.com> > --- > 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;