* Alex Williamson (alex.william...@redhat.com) wrote: > On Tue, 27 Oct 2020 23:42:57 +0000 > Peter Maydell <peter.mayd...@linaro.org> wrote: > > > On Mon, 26 Oct 2020 at 19:39, Alex Williamson > > <alex.william...@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.)
Eww that's messy; copying in Miklos to see what's going on. > 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?? They're part of the init flags sent in the negotiation; so they should be fine. > 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, Yeh the kernel header is king in the definition of those flags. It maybe bet, but I'd like to see what Miklos says. Dave > Alex > > [1] https://marc.info/?l=fuse-devel&m=160069539811247 -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK