On Tue, Mar 8, 2022 at 6:40 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Tue, Mar 08, 2022 at 11:08:48AM +0100, Greg KH wrote: > > > When one looks at xfstest bug reports on the list for xfs on kernels > v4.19 > > > one has to wonder if using xfs on kernels v5.x.y is a wise choice. > > > > That's up to the xfs maintainers to discuss. > > > > > Which makes me wonder: how do the distro kernel maintainers keep up > > > with xfs fixes? > > > > Who knows, ask the distro maintainers that use xfs. What do they do? > > This is something which is being worked, so I'm not sure we'll need to > discuss the specifics of the xfs stable backports at LSF/MM. I'm > hopeful that by May, we'll have come to some kind of resolution of > that topic. Wonderful! > > One of my team members has been working with Darrick to set up a set > of xfs configs[1] recommended by Darrick, and she's stood up an > automated test spinner using gce-xfstests which can watch a git branch > and automatically kick off a set of tests whenever it is updated. > Sasha has also provided her with a copy of his scripts so we can do > automated cherry picks of commits with Fixes tags. So the idea is > that we can, hopefully in a mostly completely automated fashion, do > the backports and do a full set of regression tests on those stable > backports of XFS bug fixes. > > [1] https://github.com/tytso/xfstests-bld/tree/master/kvm-xfstests/test-appliance/files/root/fs/xfs/cfg > > Next steps are to get a first tranche of cherry-picks for 5.10 and > probably 5.15, and use the test spinner to demonstrate that they don't > have any test regressions (if there are, we'll drop those commits). > Once we have a first set of proposed stable backports for XFS, we'll > present them to the XFS development community for their input. There > are a couple of things that could happen at this point, depending on > what the XFS community is willing to accept. > > The first is that we'll send these tested stable patches directly to > Greg and Sasha for inclusion in the LTS releases, with the linux-xfs > list cc'ed so they know what's going into the stable trees. > > The second is that we send them only to the linux-xfs list, and they > have to do whatever approval they want before they go into the > upstream stable trees. > > And the third option, if they aren't willing to take our work or they > choose to require manual approvals and those approvals are taking too > long, is that we'll feed the commits into Google's Container-Optimized > OS (COS) kernel, so that our customers can get those fixes and so we > can support XFS fully. This isn't our preferred path; we'd prefer to > take the backports into the COS tree via the stable trees if at all > possible. (Note: if requested, we could also publish these > backported-and-tested commits on a git tree for other distros to > take.) > > There are still some details we'll need to work out; for example, will > the XFS maintainers let us do minor/obvious patch conflict > resolutions, or perhaps those commits which don't cherry-pick cleanly > will need to go through some round of approval by the linux-xfs list, > if the "we've run a full set of tests and there are no test > regressions" isn't good enough for them. > If you publish the list of fix commits that did not apply cleanly, individual contributors that have personal interest in those fixes can help with the backporting work, pass them back to your bot for testing and then try to get the backport patches acked/reviewed. Perhaps we can discuss those details in LSF/MM, but even getting to auto selected, auto tested dumb fix patches will be far better than the current state of v5.10.y. Thanks, Amir.
