On Thu, Feb 9, 2023 at 12:21 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Wed, Feb 08, 2023 at 11:40:59AM -0800, Darrick J. Wong wrote: > > On Wed, Feb 08, 2023 at 09:02:58PM +0200, Amir Goldstein wrote: > > > On Wed, Feb 8, 2023 at 7:52 PM Leah Rumancik <leah.rumancik@xxxxxxxxx> wrote: > > > > > > > > Hello again, > > > > > > > > Here is the next batch of backports for 5.15.y. Testing included > > > > 25 runs of auto group on 12 xfs configs. No regressions were seen. > > > > I checked xfs/538 was run without issue as this test was mentioned > > > > in 56486f307100. Also, from 86d40f1e49e9, I ran ran xfs/117 with > > > > XFS compiled as a module and TEST_FS_MODULE_REOLOAD set, but I was > > > > unable to reproduce the issue. > > > > > > Did you find any tests that started to pass or whose failure rate reduced? > > > > I wish Leah had, but there basically aren't any tests for the problems > > fixed in this set for her to find. :( > ..... > > > There are very few Fixes: annotations in these commits so it is hard for > > > me to assess if any of them are relevant/important/worth the effort/risk > > > to backport to 5.10. > > > > <nod> Dave's fixpatches rarely have Fixes tags attached. It's difficult > > to get him to do that because he has so much bad history with AUTOSEL. > > I've tried to get him to add them in the past, but if I'm already > > stressed out and Dave doesn't reply then I tend to merge the fix and > > move on. > > In my defense, all the "fixes" from me in this series (except for > the one with a fixes tag on it) date back so long ago it was > difficult to identify what commit actually introduced the issue. > Once we're talking about "it's been there for at least a decade" - > espcially for fuzzer issues - identifying the exact commit is time > consuming and often not possible, nor really useful for anything. > I wouldn't want anyone to spend more time on fuzzer issues and I myself have given those very little attention. My expectation is to always have a Fixes tag when a developer knows they are fixing a regression and best effort when it is easy for the developer to determine when the buggy code was merged. It doesn't even have to be in the form of a Fixes tag. If the cover letter says "fixes to the $FEATURE from v5.18" that is good enough for me. As a stable maintainer, if a commit has no Fixes tag and no hint in the cover letter about relevant kernel versions, I will assume it is relevant to the LTS kernel and spend time on the manual triage. If a developer adds a Fixes tag where relevant, that can save my time by eliminating commits irrelevant for e.g. 5.10.y. This wasn't the case in this series I guess. > I'm also not going to tag a patch with "fixes commit xyz" when > commit xyz isn't actually the cause of the problem just so that > someone can blindly use that as a "it's got a fixes tag on it, we > should back port it" trigger. > > That's the whole problem with AUTOSEL - blindly applying anything > with a fixes tag on it that merges cleanly into an older kernel - > and the whole point of having a human actually manage the stable > kernel backports. > > The stable XFS kernel maintainer is supposed to be actively looking > at the commits that go into the upstream kernel to determine if they > are relevant or not to the given stable kernel, regardless of > whether they address fstests failures, have fixes/stable tags on > them, etc. If all we needed stable maintainers to do is turn a crank > handle, then we'd be perfectly OK with AUTOSEL and the upstream > stable kernel process.... > Yes. The reason I did not pick any of the commits in this series for 5.10 is not because lack of Fixes/tests, but because I read the cover letters (thanks for the links Leah!) and commit messages and conclude that the risk/effort does not make the cut. But this conclusion was based very much on my own intuition and my own interpretation of the cover letters. This is why I asked Chandan to take another look. I encourage any developer who writes a cover letter to share their own opinion about the relevancy and risks associated with backporting their patch set to LTS kernels - make it as vague statement as you wish, anything that can help a human LTS maintainer do their job better. Thanks, Amir.
