linux-kernel - Re: sparc64 pcpu failures...

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] [day] [month] [year] [list]

Date:	Fri, 18 Sep 2009 10:30:25 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	tj@...nel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Re: sparc64 pcpu failures...

From: Tejun Heo <tj@...nel.org>
Date: Fri, 18 Sep 2009 17:38:58 +0900

> Yes, this would be the result of the new congruent sparse allocator.
> Heh... I didn't really expect that WARN_ON() to actually trigger.
> What it means is that the farthest percpu units were too far to fit
> into vmalloc area so percpu chunks couldn't be allocated in the
> vmalloc area.  Checking... vmalloc area on sparc64 is only 4G so yeap
> that is entirely possible.
> 
> Hmmm... the congruent sparse allocator assumes vmalloc area to be
> larger with some margin than the farthest physical memory nodes.  On
> x86, powerpc and ia64, this holds with sufficient margin.  Would it be
> possible to modify sparc64 memory layout so that the assumption can be
> satisfied?  If that's not possible, going back to lpage is an option
> but in many ways congruent sparse allocator is better.

I'll think about this, thanks.
--
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/