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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1308291227420.6397@kaball.uk.xensource.com>
Date:	Thu, 29 Aug 2013 12:28:43 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Julien Grall <julien.grall@...aro.org>
CC:	Rob Herring <robherring2@...il.com>,
	<xen-devel@...ts.xensource.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>
Subject: Re: [PATCH v2] ARM: xen: only set pm function ptrs for Xen guests

On Wed, 28 Aug 2013, Julien Grall wrote:
> On 28 August 2013 19:20, Rob Herring <robherring2@...il.com> wrote:
> > From: Rob Herring <rob.herring@...xeda.com>
> >
> > xen_pm_init was unconditionally setting pm_power_off and arm_pm_restart
> > function pointers. This breaks multi-platform kernels. Make this
> > conditional on running as a Xen guest and make it a late_initcall to
> > ensure it is setup after platform code for Dom0.
> >
> > Cc: Stefano Stabellini <stefano.stabellini@...citrix.com>
> > Signed-off-by: Rob Herring <rob.herring@...xeda.com>
> > ---
> >  arch/arm/xen/enlighten.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 8a6295c..13a7d1f 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -273,12 +273,15 @@ core_initcall(xen_guest_init);
> >
> >  static int __init xen_pm_init(void)
> >  {
> > +       if (!of_find_compatible_node(NULL, NULL, "xen,xen"))
> > +               return -ENODEV;
> > +
> 
> You should use the macro xen_domain() to check if we are running
> in a Xen guest.

Yep.
Aside from that the patch is fine. Thanks for spotting and fixing this
issue.
I'll add the next version of this patch to the xen queue.
--
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