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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>.
> > >
> > > 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
