[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180706100008.GA3483@gmail.com>
Date: Fri, 6 Jul 2018 12:00:08 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: KY Srinivasan <kys@...rosoft.com>,
"x86@...nel.org" <x86@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"olaf@...fle.de" <olaf@...fle.de>,
"apw@...onical.com" <apw@...onical.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>
Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
enlightenment.
* Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 6 Jul 2018, Ingo Molnar wrote:
> > * KY Srinivasan <kys@...rosoft.com> wrote:
> > > I am confused. The label ipi_mask_done was introduced in this patch
> > > (the patch under question fixes a circular dependency in this patch):
> > >
> > > commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a
> > > Author: K. Y. Srinivasan <kys@...rosoft.com>
> > > Date: Wed May 16 14:53:31 2018 -0700
> > >
> > > X86/Hyper-V: Enable IPI enlightenments
> > >
> > > Hyper-V supports hypercalls to implement IPI; use them.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>
> > > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> > > Reviewed-by: Michael Kelley <mikelley@...rosoft.com>
> > >
> > > This patch was committed by Thomas some weeks ago and is in linux-next.
> > > This patch is also in 4.18-rc3.
> >
> > And then that name was changed to a different label in:
> >
> > 4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when possible
> >
> > So maybe you were testing on an older kernel. Could you try the latest -tip?
>
> The problem is that the wreckage is in Linus tree and needs to be fixed
> there, i.e. via x86/urgent.
Indeed, I missed that!
> Now we have the new bits queued in x86/hyperv already which collide. So we
> need to merge x86/urgent into x86/hyperv after applying the fix and mop up
> the merge wreckage in x86/hyperv.
>
> I'll have a look tomorrow morning unless you beat me to it.
Ok!
Thanks,
Ingo
Powered by blists - more mailing lists