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 08:15:57 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Jeff Mahoney <jeffm@...e.com>,
	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
Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096


* Jiri Kosina <jkosina@...e.cz> wrote:

> On Tue, 20 Oct 2009, Jiri Kosina wrote:
> 
> > > Commit 34d76c41 introduced the update_shares_data percpu, but it ends up
> > > causing problems on large ia64 machines. Specifically, ia64 is limited
> > > to 64k in percpu vars and with NR_CPUS=4096, that ends up being 32k by
> > > itself. It ends up causing link errors since that is how ia64 enforces
> > > the 64k limit.
> > > 
> > > I can take a deeper look at finding a workable solution but thought I'd
> > > mention it in case you had ideas already.
> > 
> > I am adding some IA64 CCs, as the failure is solely caused by the ia64 
> > percpu implementation/pagefault handler optimization which requires the 
> > .percpu section area not be larger than 64k, which blows up with 34d76c41 
> > and NR_CPUS high enoufh (due to introduction of percpu array being 
> > size-dependent on NR_CPUS).
> 
> How about this one? (untested)
> 
> 
> 
> From: Jiri Kosina <jkosina@...e.cz>
> Subject: sched: move rq_weight data array out of .percpu
> 
> Commit 34d76c41 introduced percpu array update_shares_data, size of which 
> being proportional to NR_CPUS. Unfortunately this blows up ia64 for large 
> NR_CPUS configuration, as ia64 allows only 64k for .percpu section.
> 
> Fix this by allocating this array dynamically and keep only pointer to it 
> percpu.
> 
> Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> --- 
>  kernel/sched.c |   15 +++++++--------
>  1 files changed, 7 insertions(+), 8 deletions(-)

Seems like an IA64 bug to me. It's _very_ easy to get more than 64K of 
percpu data - i'm wondering why IA64 only triggered it now? Sure 
lockdep/lockstat must have triggered it before.

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