On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote:

On 01-08-19, 08:57, Greg KH wrote:

quoted

On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:

quoted

On 01-08-19, 07:30, Julien Thierry wrote:

quoted

I must admit I am not familiar with backport/stable process enough. But
personally I think the your suggestion seems more sensible than
backporting 4 patches.

Or you can maybe ignore patch 25 and say in patch 24 that among the
changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
was moved from post_ttbr_update_workaround as it doesn't exist and
placed in check_and_switch_context() as it is its final destination.

Done that and dropped the other two patches.

quoted

However, I really don't know what's the best way to proceed according to
existing practices. So input from someone else would be welcome.

Lets see if someone comes up and ask me to do something else :)

Keeping the same patches that upstream has is almost always the better
thing to do in the long-run.

That would require two additional patches to be backported, 22 and 23
from this series. From your suggestion it seems that keeping them is
better here ?

Yes. Backporting individual patches as they appear upstream is definitely
the preferred method for -stable. It makes the relationship to mainline
crystal clear, as well as any dependencies between patches that have been
backported. Everytime we tweak something unecessarily in a stable backport,
it just creates the potential for confusion and additional conflicts in
future backports, so it's best to follow the shape of upstream as closely as
possible, even if it results in additional patches.

So I wouldn't worry about total number of patches. I'd worry more about
things like conflicts, deviation from mainline and overall testing coverage.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel