lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 07 Sep 2015 15:10:55 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Hemant Kumar <hemant@...ux.vnet.ibm.com>, maddy@...ux.vnet.ibm.com,
	srikar@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	warrier@...ux.vnet.ibm.com, paulus@...ba.org,
	scottwood@...escale.com, sukadev@...ux.vnet.ibm.com,
	linuxppc-dev@...ts.ozlabs.org, mingo@...nel.org
Subject: Re: [PATCH v6 1/2] perf,kvm/powerpc: Add kvm_perf.h for powerpc

On Fri, 2015-09-04 at 17:51 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu:
> > >Should I try to process the 5 together, applying thest two first?
>  
> > Yes, this patchset needs to be applied before applying the other patchset,
> > since there is a direct dependency on these two for the tooling part to
> > work.
>  
> > >I see there are no acks from powerpc arch maintainers, how should we
> > >proceed here? If there are no problems with the arch bits, and if it is
> > >just to enable the tooling part, again, should I process the 5 as just
> > >one series?
>  
> > The reason to split the earlier patchset into two was to separate the
> > tooling/perf/ and arch/powerpc/ side patches, as asked by Michael..
>  
> > Here is the link to that discussion :
> > http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg86916.html
>  
> > If Michael is ok with the patches, you can process all the 5 patches
> > together. Michael?
> 
> Michael?

I'm not particularly happy with it.

Can we at least remove this hunk from the uapi header:

+/* This is to shut the compiler up */
+#define KVM_ENTRY_TRACE ""
+#define KVM_EXIT_TRACE ""
+#define KVM_EXIT_REASON ""


cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ