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]
Message-ID: <4A149B89.3010104@kernel.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ