Re: FAILED: patch "[PATCH] xen: Fix x86 sched_clock() interface for xen" failed to apply to 4.14-stable tree

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

On Wed, Jan 23, 2019 at 09:23:19AM +0100, Juergen Gross wrote:
> On 22/01/2019 23:37, Boris Ostrovsky wrote:
> > On 1/22/19 5:15 PM, Hans van Kranenburg wrote:
> >> On 1/22/19 11:08 PM, Boris Ostrovsky wrote:
> >>> On 1/21/19 4:58 AM, gregkh@linuxfoundation.org wrote:
> >>>> The patch below does not apply to the 4.14-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>.
> >>> I am actually not convinced this fix is needed for 4.14 (or earlier). I
> >>> couldn't reproduce this bug.
> >>>
> >>> I think we also need Pasha Tatashin's time series (38669ba205d1 and
> >>> friends) for the problem to show up.
> >> It happens after f94c8d1169, and it was really easy to reproduce for me
> >> (or not to) during bisecting.
> >>
> >> https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg02356.html
> >>
> > 
> > Hmm.. I ran 4.14.91 and see no problems.
> 
> dmesg from current linux-4.14.y branch:
> 
> [   53.155208] Freezing user space processes ... (elapsed 0.001 seconds)
> done.
> [   53.156614] OOM killer disabled.
> [   53.156616] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [   53.171864] suspending xenstore...
> [   53.212606] xen:events: Xen HVM callback vector for event delivery is
> enabled
> [   53.212606] Xen Platform PCI: I/O protocol version 1
> [   53.212606] xen:grant_table: Grant tables using version 1 layout
> [   53.212606] xen: --> irq=9, pirq=16
> [   53.212606] xen: --> irq=8, pirq=17
> [   53.212606] xen: --> irq=12, pirq=18
> [   53.212606] xen: --> irq=1, pirq=19
> [   53.212606] xen: --> irq=6, pirq=20
> [   53.212606] xen: --> irq=24, pirq=21
> [18446741328.844150] OOM killer enabled.
> [18446741328.844153] Restarting tasks ... done.
> [18446741328.893762] Setting capacity to 16777216
> 
> So the issue is present in 4.14. BTW, I have an internal bug report for
> this issue from 4.12 kernel. :-)
> 
> Greg, one question for the backport: the least intrusive way seems to be
> to add another patch from upstream (commit 38669ba205d178d2d38b). Should
> I add this patch separately, or do you want me to include it in the
> backported patch?

Stick to upstream as close as possible, so if it takes 1, or 2, or 10
patches from upstream submit them all.  Every time we try to "only take
a part of a fix", or "rewrite it to be smaller" we get it wrong.  Every
time...

thanks,

greg k-h