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]
Message-ID: <20090302235120.GF27240@localdomain>
Date:	Mon, 2 Mar 2009 15:51:20 -0800
From:	Ravikiran G Thirumalai <kiran@...lex86.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	shai@...lex86.org
Subject: Re: [PATCH] x86: don't compile vsmp_64 for 32bit

On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote:
>
>* Ravikiran G Thirumalai <kiran@...lex86.org> wrote:
>
>> 
>> True, but by how much? 212 bytes, out of 7285943 bytes which 
>> is very very small percentage wise.
>
>How does this eliminate the validity of the patch?
>

It costs 212 bytes to leave is_vsmp_box() to not just be a dummy no-op.
Having is_vsmp_box() detect if the hardware is indeed vSMP, is meaningful even when
CONFIG_VSMP is not turned on.   This is because is_vsmp_box() is used to
tell the kernel, that although the cpus being used are supposed to have TSCs
in sync, they are not really in sync.  This is because
you cannot ensure TSCs won't drift between multiple boards being aggregated
on vSMP systems. Take the case of distro kernels.   Distro kernels typically do
not have CONFIG_X86_VSMP on.  Due to the large internode cacheline
setting, CONFIG_VSMP would not be on on the generic distro installer kernels.
If is_vsmp_box() is a no-op, the generic distro installer kernels will
assume TSCs to be synched, which is bad.  Hence, it will be nice if, for
the cost of 212 bytes, vsmp64.o be compiled either unconditionally, OR
conditionally for 64bit architectures only.  The question is, is 212 bytes out
of 7285943 bytes too expensive for the generic kernels?  I hope not.

Thanks,
Kiran
--
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