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 PHC | |
Open Source and information security mailing list archives
| ||
|
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