On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: > + Jani, who'll continue with -fixes > > On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote: >> On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen >> <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: >> > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote: >> > > CFL was missing from intel_early_ids[]. >> > > >> > > Cc: Ingo Molnar <mingo@xxxxxxxxxx> >> > > Cc: H. Peter Anvin <hpa@xxxxxxxxx> >> > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> >> > > Cc: x86@xxxxxxxxxx >> > > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> >> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx> >> > >> > This should come with a Fixes: line to be picked up to -fixes. The IDs >> >> I thought this didn't deserve CC to stable since alpha support was >> removed for CFL only for 4.15. > > I don't think system memory corruption is really acceptable even for > alpha quality support :P > >> > have been added in smaller chunks and reworked after, so backporting >> > will be required. For this level of fix, my recommendation would be to >> > actively provide a cleanly applying backports to affected stable >> > versions. >> >> Are you saying this should be proactive rather than reactive? I don't >> see this mentioned on >> Documentation/process/stable-kernel-rules.rst... the only thing I see >> there regarding patches that don't apply >> cleanly is that I may bring more patches through a tag for each version. >> >> If we are indeed going to cc stable I can submit a v2 with added tags. >> If a patch that can be cc'ed to stable >> needs to be provided we may need to improve our docs, too. > > That's correct. But once Cc:d stable, we can see from the GIT history > that it'll bounce back because it won't apply. For this specific case > that might cause system memory corruption, I'd make an exception and be > proactive. Another option would be to cherry-pick 0890540e21cf1156b4cf960a4c1c734db4e816f9 and 41693fd5237397d3c61b311af0fda1f6f39297c2 so then all commits apply cleanly. Lucas De Marchi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
