Re: [PATCH v6 18/19] x86: Add support for generic vDSO
From: Sasha Levin
Date: Sun Jun 23 2019 - 15:09:48 EST
On Sat, Jun 22, 2019 at 04:46:28PM +0200, Thomas Gleixner wrote:
On Fri, 14 Jun 2019, Sasha Levin wrote:
On Fri, Jun 14, 2019 at 01:15:23PM +0200, Thomas Gleixner wrote:
> On Thu, 30 May 2019, Michael Kelley wrote:
> > Vincenzo -- these changes for Hyper-V are a subset of a larger patch set
> > I have that moves all of the Hyper-V clock/timer code into a separate
> > clocksource driver in drivers/clocksource, with an include file in
> > includes/clocksource. That new include file should be able to work
> > instead of your new mshyperv-tsc.h. It also has the benefit of being
> > ISA neutral, so it will work with my in-progress patch set to support
> > Linux on Hyper-V on ARM64. See https://lkml.org/lkml/2019/5/27/231
> > for the new clocksource driver patch set.
>
> Grrr. That's queued in hyperv-next for whatever reasons.
I queue up our future pull requests there to give them some soaking in
-next.
What? You queue completely unreviewed stuff which touches two other
subsystems to let it soak in next?
It was out on LKML for 2+ weeks before I've pulled it in. As it mostly
touches hyperv bits I felt comfortable to give it time in -next (but not
actually to try and merge it until it gets a few acks).
> Sasha, can you please provide me the branch to pull from so I can have a
> common base for all the various changes floating around?
I'll send you a unified pull request for these changes.
Which has not materialized yet.
Appologies about this. I ended up with way more travel than I would have
liked (writing this from an airport). I've reset our hyperv-next branch
to remove these 3 commits until we figure this out.
TBH, I'm pretty grumpy about those clocksource changes. Here is the
diffstat:
MAINTAINERS | 2
arch/x86/entry/vdso/vclock_gettime.c | 1
arch/x86/entry/vdso/vma.c | 2
arch/x86/hyperv/hv_init.c | 91 ---------
arch/x86/include/asm/hyperv-tlfs.h | 6
arch/x86/include/asm/mshyperv.h | 81 +-------
arch/x86/kernel/cpu/mshyperv.c | 2
arch/x86/kvm/x86.c | 1
drivers/clocksource/Makefile | 1
drivers/clocksource/hyperv_timer.c | 322 +++++++++++++++++++++++++++++++++++
drivers/hv/Kconfig | 3
drivers/hv/hv.c | 156 ----------------
drivers/hv/hv_util.c | 1
drivers/hv/hyperv_vmbus.h | 3
drivers/hv/vmbus_drv.c | 42 ++--
include/clocksource/hyperv_timer.h | 105 +++++++++++
While the world and some more people have been CC'ed on those patches,
neither the clocksource nor the x86 maintainer have been.
When I gave Vincenzo the advise to base his code on that hyper-v branch, I
expected that I find the related patches in my mail backlog. No, they have
not been there because I was not on CC.
Folks, please stop chosing Cc lists as you like. We have well established
rules for that. And please stop queueing random unreviewed patches in
next. Next is not a playground for not ready and unreviewed stuff. No, the
hyper-v inbreed Reviewed-by is not sufficient for anything x86 and
clocksource related.
I'm sorry for this, you were supposed to be Cc'ed on these patches and I
see that you were not.
After chasing and looking at those patches, which have horrible subject
lines and changelogs btw, I was not able to judge quickly whether that
stuff is self contained or not. So no, I fixed up the fallout and rebased
Vincenzos VDSO stuff on mainline w/o those hyperv changes simply because if
they are not self contained they will break bisection badly.
I'm going to push out the VDSO series later today. That will nicely break
in combination with the hyper-next branch. Stephen, please drop that and do
not try to handle the fallout. That stuff needs to go through the proper
channels or at least be acked/reviewed by the relevant maintainers. So the
hyper-v folks can rebase themself and post it proper.
Okay, thank you. We'll rebase and resend.
--
Thanks,
Sasha