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:58:20 +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>, Christoph Lameter <cl@...ux-foundation.org> Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096 Of course I forgot to actually cc. Cc'ing and quoting whole body. Sorry. Tejun Heo wrote: > 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. -- 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