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

[Cornelia Huck]

On Wed, 28 Oct 2020 10:28:39 +0100
Max Reitz <mreitz@redhat.com> wrote:

> On 28.10.20 09:11, Cornelia Huck wrote:
> > 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.)  
> > 
> > We should never change things in the synced headers other than via a
> > headers update (excluding fixups of prior messes.) I'm pointing it out
> > whenever I see something like that happening, but nobody is going to
> > catch all of those.  
> 
> Well, it was a kernel update.  Just based on a preliminary version of
> the kernel part of the FUSE submount feature.
> 
> It was clear that the kernel part would have to be merged before the
> qemu/virtiofsd series, and that did happen, but Miklos (the FUSE
> maintainer) fixed some things on top while doing so, an that included
> changing the flag in question.  As Adam wrote, I noted that I would thus
> have to write a v2 of the virtiofsd series.
> 
> Unfortunately, that all was a bit buried in the thread, so I suppose for
> Dave it looked like the kernel series was applied, so the virtiofsd
> series could go in, too.  And I in turn didn't catch that. :/

Yeah, things like that happen, especially if explanations are buried
deeply somewhere :/

> 
> > Is there any place where we can have some kind of automatic check on a
> > pull request for that kind of stuff? We'd need to formalize an "update
> > headers" commit message, or maybe have the update script write some
> > kind of "last updated" file?  
> It would also need to actually check against the kernel tree, because,
> well, I did use the script.  Just against a kernel tree that never came
> to master.

Hm.  That's probably hard to get right, unless we require all updates
to be against a tagged kernel (-rc) version. Not sure if that's too
strict.