Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues

[Jani Nikula <jani.nikula@intel.com>]

On Thu, 06 Sep 2018, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> A lot of that was that the actual *fixes* were marked for stable, but
> quite often they were preceded by cleanups and other updates that
> didn't actually fix things directly, and that weren't in themselves
> explicitly marked for stable and didn't have a Fixes: tag, because
> they were prep-work.

There's always the struggle of whether to put fixes or cleanups first in
the series. The former makes backports easier, the latter makes the
actual fixes easier. And the prep work could be committed quickly while
the fixes are still being debated.

> So we had _several_ nasty regressions in stable that never showed up
> in mainline, because there was some non-obvious dependency that didn't
> cause a merge conflict, but did cause a "this commit needed that other
> commit to work right".
>
> We should probably at least think about having a way to mark those.
> Something like a "for-stable-because-of-subsequent-patches" tag?

If you know the commit ids of the dependencies, i.e. they've been
applied, per Documentation/process/stable-kernel-rules.rst you could
add:

     Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
     Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
     Cc: <stable@vger.kernel.org> # 3.3.x

listing the dependencies. I don't see that used much, though, so not
sure defining something new could gain more traction.

> Or just more eager use of the table cc? I often feel bad about adding
> "cc: stable" to preparatory patches that don't actually fix the bug,
> but I think it was bad this time around.

If the fix with prep work is in a topic branch, one could add cc: stable
to the merge commit.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center