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:	Tue, 20 Oct 2009 22:57:26 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Jeff Mahoney <jeffm@...e.com>, Jiri Kosina <jkosina@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Tony Luck <tony.luck@...el.com>,
	Fenghua Yu <fenghua.yu@...el.com>, linux-ia64@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096

Ingo Molnar wrote:
> IA64 should be fixed really - we can get past the 64K of percpu data 
> limit anytime we add a few more pages of per-cpu data to the kernel - 
> the scheduler just happened to be the one to cross it this time.

Christoph (cc'd hi!) was talking about re-purposing one of reserved
generic registers (for current or something, I don't remember the
details) for percpu base and just getting the original one via percpu
access.  With that we should be able to lift the limitation without
much performance penalty.

> Saying that all static percpu data must be below 64K, which will only be 
> noticed once IA64 gets its testing act together months after it's been 
> created is silly. If you want to enforce such a limit make it testable 
> in a _timely_ fashion. Or fix the limit really.

Yeah, the problem probably was that it only pushes the perpcu area
very slightly over the limit depending on configuration so it's not
too surprising that it didn't get reported for some time.  Also, the
linker script thing is a sanity check which is intentionally put there
to trigger when this happens so that it can be found out clearly
during build time.

In the long term, it will be a good idea to lift that restriction.
That said, I really don't think we should be adding NR_CPUS sized
array to percpu area either.  Things like that quickly become very
scary with N*1024 cpu configurations.

Thanks.

-- 
tejun
--
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