stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Handling of patches missing in stable releases based on Fixes: tags
@ 2020-03-21 16:13 Guenter Roeck
  2020-03-21 19:17 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 2+ messages in thread
From: Guenter Roeck @ 2020-03-21 16:13 UTC (permalink / raw)
  To: stable, Greg Kroah-Hartman, Sasha Levin

Hi,

we now have a script that identifies patches in stable releases which were
later fixed upstream, but the fix was not applied to the respective stable
releases. We identify such patches based on Fixes: tags in the upstream
kernel.

Example: Upstream commit c54c7374ff4 ("drm/dp_mst: Skip validating ports
during destruction, just ref") was applied to v4.4.y as commit 05d994f68019.
It was later reverted upstream with commit 9765635b307, but the revert has
(at least not yet) found its way into v4.4.y.

This is an easy example, where the revert should (or at least I think it
should) be applied to v4.4.y (and possibly to later kernels - I didn't check).
A more tricky patch is commit 3ef240eaff36 ("futex: Prevent exit livelock")
in v5.4.y, which was later fixed upstream with commit 51bfb1d11d6 ("futex:
Fix kernel-doc notation warning"). I am not entirely sure what to do with
that, given that it only fixes documentation (though that may of course also
be valuable).

How should we handle this ? Would it be ok to send half-automated requests
to the stable mailing list, for example with basic test results ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Handling of patches missing in stable releases based on Fixes: tags
  2020-03-21 16:13 Handling of patches missing in stable releases based on Fixes: tags Guenter Roeck
@ 2020-03-21 19:17 ` Greg Kroah-Hartman
  0 siblings, 0 replies; 2+ messages in thread
From: Greg Kroah-Hartman @ 2020-03-21 19:17 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: stable, Sasha Levin

On Sat, Mar 21, 2020 at 09:13:47AM -0700, Guenter Roeck wrote:
> Hi,
> 
> we now have a script that identifies patches in stable releases which were
> later fixed upstream, but the fix was not applied to the respective stable
> releases. We identify such patches based on Fixes: tags in the upstream
> kernel.

THat's great.

> Example: Upstream commit c54c7374ff4 ("drm/dp_mst: Skip validating ports
> during destruction, just ref") was applied to v4.4.y as commit 05d994f68019.
> It was later reverted upstream with commit 9765635b307, but the revert has
> (at least not yet) found its way into v4.4.y.
> 
> This is an easy example, where the revert should (or at least I think it
> should) be applied to v4.4.y (and possibly to later kernels - I didn't check).
> A more tricky patch is commit 3ef240eaff36 ("futex: Prevent exit livelock")
> in v5.4.y, which was later fixed upstream with commit 51bfb1d11d6 ("futex:
> Fix kernel-doc notation warning"). I am not entirely sure what to do with
> that, given that it only fixes documentation (though that may of course also
> be valuable).
> 
> How should we handle this ? Would it be ok to send half-automated requests
> to the stable mailing list, for example with basic test results ?

Sure, half-automated requests are fine, send them on!

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-03-21 19:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-21 16:13 Handling of patches missing in stable releases based on Fixes: tags Guenter Roeck
2020-03-21 19:17 ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).