On Sat, Apr 18, 2020 at 01:38:41PM -0400, Sasha Levin wrote:
On Sat, Apr 18, 2020 at 12:05:13PM -0400, Sasha Levin wrote:
On Sat, Apr 18, 2020 at 07:37:08AM -0500, Eric W. Biederman wrote:
gregkh@linuxfoundation.org writes:
The patch below does not apply to the 5.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
So for anyone who cares the fix I refer to in the commit comment is the workaround that keeps the past implementation from being a real problem.
I just see this as code cleanup so I can remove the old workaround. The old workaround will cause posix_cpu_timers_exit_group to be called early on particular variants of multi-threaded exec, resulting in the corresponding cpu clock stopping. So this does represent a real fix.
However using a cpu timer of another process to signal things in your process is rare, and the case is breaks is only in certain obscure variations of a multi-threaded exec. Further no one has to my knowledge complained in over a decade.
If someone sees that fix as important, and something that needs to be backported, it will be easiest to backport my earlier cleanup patches in the same series.
For 5.6, 5.5, and 5.4 it was enough to take:
60f2ceaa8111 ("posix-cpu-timers: Remove unnecessary locking around cpu_clock_sample_group")
as a dependency. Based on the commit message there it should be safe so I did just that.
Ignore that, I've dropped it for now.
THanks, I agree, this should just be left alone for now.
greg k-h