On 9/1/2020 9:06 AM, Doug Berger wrote:
On 9/1/2020 7:00 AM, Greg Kroah-Hartman wrote:

[snip]

Sorry for the confusion, but thanks for the reply.

There is functionality that exists in Linus' tree, but it is not the
result of a single commit that can be easily backported. I have been
unable to find anything in the documentation for submitting a patch to a
stable branch that covers this type of submission so I have sent this as
an RFC about process rather than a patch.

The upstream commit that ultimately results in the functional change is:
commit a32c1c61212d ("arm: simplify detection of memory zone boundaries")

That commit is dependent on other commits that aren't necessary for the
stable branches.

In my downstream kernel I would apply the single line patch included in
my original email, but it is not appropriate to apply that patch to
Linus' tree since the problem does not exist there.

This creates the situation where a simple patch could be applied to a
stable branch to improve its stability, but there is not a clear
upstream commit to reference.

My best guess at this point is to submit patches to the affected stable
branches like the one in my RFC and reference a32c1c61212d as the
upstream commit. This would be confusing to anyone that tried to compare
the submitted patch with the upstream patch since they
wouldn't look at all alike, but the fixes and upstream tags would define
the affected range in Linus' tree.

I would appreciate any guidance on how best to handle this kind of
situation.

You could submit various patches with [PATCH stable x.y] in the subject to indicate they are targeting a specific stable branch, copy sta...@vger.kernel.org as well as all recipients in this email and see if that works.

Not sure if there is a more documented process than that.
--
Florian

Reply via email to