On Mon, Feb 27, 2023 at 09:47:46AM -0800, Eric Biggers wrote: > > > One of the challanges here is that it's difficult to solicit reviews or > > really any interaction from authors after a commit lands upstream. Look > > at the response rates to Greg's "FAILED" emails that ask authors to > > provide backports to commits they tagged for stable. > > Well, it doesn't help that most of the stable emails aren't sent to the > subsystem's mailing list, but instead just to the individual people mentioned in > the commit. So many people who would like to help never know about it. Let me joining in the discussion. In this case, Greg send these FAILED emails to upstream commit authors, but some of them have expectation that their commits can be backported automatically (without conflicts), so when Greg ask them to "manually" do the backport (and with resolving conflicts between), they have little to no idea on what should they do. That's why there was a doc patch sent [1] specifically on this matter. Fortunately, some others are aware on this and send the backport. > I don't know, is it obvious? You've said in the past that sometimes you'd like > to backport a commit even if the maintainer objects and/or it is known buggy. > https://lore.kernel.org/stable/d91aaff1-470f-cfdf-41cf-031eea9d6aca@xxxxxxxxxxx > also didn't explicitly say "Don't backport this" but instead "This patch has > issues", so maybe that made a difference? > > Anyway, the fact is that it happened. And if it happened in the one bug that I > happened to look at because it personally affected me and I spent hours > bisecting, it probably is happening in lots of other cases too. So it seems the > process is not working... > > Separately from responses to the AUTOSEL email, it also seems that you aren't > checking for any reported regressions or pending fixes for a commit before > backporting it. Simply searching lore for the commit title > https://lore.kernel.org/all/?q=%22drm%2Famdgpu%3A+use+dirty+framebuffer+helper%22 > would have turned up the bug report > https://lore.kernel.org/dri-devel/20220918120926.10322-1-user@am64/ that > bisected a regression to that commit, as well as a patch that Fixes that commit: > https://lore.kernel.org/all/20220920130832.2214101-1-alexander.deucher@xxxxxxx/ > Both of these existed before you even sent the AUTOSEL email! > > So to summarize, that buggy commit was backported even though: > > * There were no indications that it was a bug fix (and thus potentially > suitable for stable) in the first place. > * On the AUTOSEL thread, someone told you the commit is broken. > * There was already a thread that reported a regression caused by the commit. > Easily findable via lore search. > * There was also already a pending patch that Fixes the commit. Again easily > findable via lore search. Recently there was a regression in linux-5.15.y that was caused by faulty backport of upstream 85636167e3206c ("drm/i915: Don't use BAR mappings for ring buffers with LLC") as 4eb6789f9177a5 ("drm/i915: Don't use BAR mappings for ring buffers with LLC"). Fortunately, the upstream commit wasn't AUTOSEL'd by Sasha's scripts and the culprit backport got reverted. [CC'ed the upstream commit author and corresponding ML.] > > So it seems a *lot* of things went wrong, no? Why? If so many things can go > wrong, it's not just a "mistake" but rather the process is the problem... Testing the backports are also important, hence before a stable release is made, there is -rc review when testers can test linux-x.y trees as published in linux-stable-rc.git tree. The testing quality depends on how many testers test and send their report, as well as the type of test. For example, I do basic cross-compile test for arm64 and ppc64. Did they spot the regression I mentioned earlier? Nope, until after the release, where production users reported the regression. If they do, they would have replied to appropriate backported patch that caused the problem. Thanks. [1]: https://lore.kernel.org/linux-doc/20230303162553.17212-1-vegard.nossum@xxxxxxxxxx/ -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
