Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze)

[Alex Williamson]

On Tue, 27 Oct 2020 23:42:57 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Mon, 26 Oct 2020 at 19:39, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > ----------------------------------------------------------------
> > VFIO update 2020-10-26
> >
> >  * Migration support (Kirti Wankhede)
> >  * s390 DMA limiting (Matthew Rosato)
> >  * zPCI hardware info (Matthew Rosato)
> >  * Lock guard (Amey Narkhede)
> >  * Print fixes (Zhengui li)  
> 
> I get a conflict here in
> include/standard-headers/linux/fuse.h:
> 
> ++<<<<<<< HEAD
>  +#define FUSE_ATTR_FLAGS               (1 << 27)
> ++=======
> + #define FUSE_SUBMOUNTS                (1 << 27)
> ++>>>>>>> remotes/awilliam/tags/vfio-update-20201026.0  
> 
> I assume these should not both be trying to use the same value,
> so something has gone wrong somewhere. The conflicting commit
> now in master is Max's 97d741cc96dd08 ("linux/fuse.h: Pull in from Linux").
> 
> Can you sort out the correct resolution between you, please?
> (My guess is that Max's commit is the erroneous one because
> it doesn't look like it was created via a standard update
> from the kernel headers.)

So as near as I can tell, QEMU commit 97d741cc96dd ("linux/fuse.h: Pull
in from Linux") is fantasy land.  The only thing I can find of this
FUSE_ATTR_FLAGS outside Max's QEMU series is this[1] posting where the
fuse maintainer announces that he's replaced FUSE_ATTR_FLAGS with
FUSE_SUBMOUNTS, but the usage is "slightly different".  Reading that
thread, it seems that virtiofsd probably needed an update but I can't
see that it ever happened.

I'm not comfortable trying to update Max's series to try to determine
if FUSE_SUBMOUNTS can be interchanged with FUSE_ATTR_FLAGS, where the
latter appears to be used to express the new field in struct fuse_attr
exists, but the former appears to be a feature.  My guess would be that
maybe FUSE_KERNEL_MINOR_VERSION needs to be tested instead for this new
field??

Anyway, I hate to pull the big hammer, but I think Max's series is
bogus.  The only thing I can propose is to revert it in its entirety,
after which this series applies cleanly.  I'll post a patch to do that
as I think the code currently in master is on pretty shaky ground with
respect to interpreting flag bits differently from those the kernel
defines.  Thanks,

Alex

[1] https://marc.info/?l=fuse-devel&m=160069539811247