linux-kernel - Re: [GIT PATCH] x86,percpu: fix pageattr handling with remap allocator

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:	Thu, 21 May 2009 09:08:41 +0900
From:	Tejun Heo <tj@...nel.org>
To:	suresh.b.siddha@...el.com
CC:	"H. Peter Anvin" <hpa@...or.com>,
	"JBeulich@...ell.com" <JBeulich@...ell.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-kernel-owner@...r.kernel.org" 
	<linux-kernel-owner@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PATCH] x86,percpu: fix pageattr handling with remap allocator

Hello,

Suresh Siddha wrote:
>> Hmmm... I can't really follow what you're suggesting.  Can you please
>> explain it in more detailed way?
> 
> Ok. Before I make another attempt walking that hill :)

Heh... the problem is that unless I understand what you're trying to
achieve (and vice-versa), our discussion is likely to be riddled with
confusions, and currently either you're misunderstanding the whole
thing or I'm being slow (not too unusual :-).  It would be nice to
determine which way it is.

> I was talking to Peter and it seems there are some requests to change
> the first percpu unit allocation for each possible cpu using bootmem
> allocator, to allocating the corresponding unit at the cpu online time.
> 
> Do you have plans to change this?

Yeap, once the remaining archs are converted, that's the next stop.
With recently posted patchset, only three remain - sparc64, powerpc64
and sparc64.  Davem is working on sparc64.  I'm planning on doing
powerpc64.  ia64 is a bit tricky as it already remaps percpu areas but
I'm sure we'll find a way around it.  After that, yeap, the dynamic
online thing.

> If we do this allocation during the corresponding cpu online time
> and don't end up using big pages, then also we avoid all these
> aliasing issues...

The dynamic onlining will probably use 4k pages so, yeah, it won't
have the alias issues but that's not the issue here, right?  You can
already avoid aliasing that way by simply using 4k allocator from the
get-go.

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/