linux-kernel - Re: [Xen-devel] [PATCH 1/2] xen: vnuma support for PV guests running as domU.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Nov 2013 12:48:50 +0100
From:	Dario Faggioli <dario.faggioli@...rix.com>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	<ian.campbell@...rix.com>, <wency@...fujitsu.com>,
	<stefano.stabellini@...citrix.com>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <tangchen@...fujitsu.com>,
	<mingo@...hat.com>, <tglx@...utronix.de>,
	Elena Ufimtseva <ufimtseva@...il.com>, <hpa@...or.com>,
	<xen-devel@...ts.xenproject.org>, <akpm@...ux-foundation.org>,
	<boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: vnuma support for PV guests
 running as domU.

On gio, 2013-11-14 at 11:21 +0000, David Vrabel wrote:
> On 14/11/13 07:26, Dario Faggioli wrote:
> > IIRC, it's more something that was already happening (the breakage, I
> > mean), than a "safety net" for the unforeseeable future. Might be worth
> > giving some context about it, perhaps referencing the email thread or
> > the git commit hash in the comment.
> 
> Yes, a comment like:
> 
> /*
>  * Set a dummy node and return success.  This prevents calling any
>  * hardware-specific initializers which do not work in a PV guest.
>  */
> 
> is better.  No need to refer to any specific threads.  It's pretty clear
> that any hardware-specific init isn't appropriate for a PV guest.
> 
Ok.

> >> +	if (rc != 0) {
> >> +		for (i = 0; i < MAX_LOCAL_APIC; i++)
> >> +			set_apicid_to_node(i, NUMA_NO_NODE);
> >> +		nodes_clear(numa_nodes_parsed);
> >> +		nodes_clear(node_possible_map);
> >> +		nodes_clear(node_online_map);
> >> +		node_set(0, numa_nodes_parsed);
> >> +		numa_add_memblk(0, 0, PFN_PHYS(max_pfn));
> >> +	}
> >> +	return 0;
> >>
> > Ok, so, we always return 'success', as we were saying during last round.
> > However, we do not call dummy_numa_init() directly, and instead we do
> > all these stuff, with the last two statements being exactly what
> > dummy_numa_init() does. Reason is linking, i.e., the fact that
> > dummy_numa_init() is not exported and you can't reach it from here,
> > right?
> 
> I think this bit is fine as-is.
> 
Ok, cool. :-) Shouldn't we then kill or reformulate the comments where
dummy_numa_init is explicitly referenced then?

E.g., this one: /* will pass to dummy_numa_init */

It might be me, but I find it rather confusing. After seeing that, I'd
expect to see that, at some point, either the function returns failure
(which of course we don't want), or a direct call dummy_numa_init().

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)