Hi, On Sat, Apr 4, 2026 at 10:28 PM Greg Kroah-Hartman <[email protected]> wrote: > > On Fri, Apr 03, 2026 at 05:04:54PM -0700, Douglas Anderson wrote: > > NOTE: one potentially "controversial" choice I made in some patches > > was to always reserve a flag ID even if a flag is only used under > > certain CONFIG_ settings. This is a change from how things were > > before. Keeping the numbering consistent and allowing easy > > compile-testing of both CONFIG settings seemed worth it, especially > > since it won't take up any extra space until we've added a lot more > > flags. > > Nah, this is fine, I don't see any problems with this as the original > code kind of was doing the same thing with the "hole" in the structure > if those options were not enabled. > > > I only marked the first patch as a "Fix" since it is the only one > > fixing observed problems. Other patches could be considered fixes too > > if folks want. > > > > I tested the first patch in the series backported to kernel 6.6 on the > > Pixel phone that was experiencing the race. I added extra printouts to > > make sure that the problem was hitting / addressed. The rest of the > > patches are tested with allmodconfig with arm32, arm64, ppc, and > > x86. I boot tested on an arm64 Chromebook running mainline. > > I'm guessing your tests passed? :)
Yup, all the tests that I've run have passed. I also threw in an "allnoconfig" compile test just for good measure. > Anyway, this looks great, unless there are any objections, other than > the "needs to be undefined", which a follow-on patch can handle, I'll > queue them up next week for 7.1-rc1. Thanks. As per the other thread, I'm happy if you or Danilo want to apply it, and I'm happy if you want to make minor fixups when applying. When I see the patches applied, I'll send a followup patch to address the "needs to be undefined" comment, unless Danilo makes that change himself when applying. -Doug
