On Tue, 12 Dec 2017, Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote: > 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. There's a cc: stable annotation for dependencies like that, see stable kernel rules. I think Greg has stated a preference for picking up dependencies rather than having manually backported patches. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
