On Wed, 28 Oct 2020 10:28:39 +0100 Max Reitz <mre...@redhat.com> wrote:
> On 28.10.20 09:11, Cornelia Huck 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.) > > > > 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.