linux-kernel - Re: [GIT PULL] x86, percpu: implement and use reserved percpu alloc

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: <386072610903072037q532de253n5697dca04d155710@mail.gmail.com>
Date:	Sun, 8 Mar 2009 12:37:21 +0800
From:	Bryan Wu <cooloney@...nel.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	mingo@...e.hu, rusty@...tcorp.com.au, tglx@...utronix.de,
	x86@...nel.org, linux-kernel@...r.kernel.org, hpa@...or.com,
	efault@....de, jaswinder@...nel.org
Subject: Re: [GIT PULL] x86, percpu: implement and use reserved percpu alloc

On Fri, Mar 6, 2009 at 2:46 PM, Tejun Heo <tj@...nel.org> wrote:
>
> Hello,
>
> Please pull from the following git vector.
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu
>
> This patchset implements reserved percpu alloc from the first chunk
> and uses it for static perpcu variables in modules on x86_64.  This is
> necessary because x86_64 expects symbols to be relocatable using 32bit
> relocations but dynamic percpu allocation does not guarantee it
> leading to relocation overflow during module load.
>
> This can happen to any of the x86_64 percpu first chunk allocators but
> the embedding allocator is most likely to trigger it as the first
> chunk is located in the normal kernel memory allocation area while all
> the other chunks will be allocated in the vmalloc area which is very
> far from the first chunk.
>
> This type of reservation will be necessary for other architectures too
> where addressing mode used for percpu acess uses offsets with limited
> range to access symbols (e.g. ia64 w/ the magic 64k percpu page).
>
> This problem was first reported and bisected by Mike Galbraith[2].
>
> This patchset is against the current x86/core/percpu[1] and contains
> the following patches.
>
>  0001-percpu-clean-up-percpu-constants.patch
>  0002-percpu-cosmetic-renames-in-pcpu_setup_first_chunk.patch
>  0003-percpu-improve-first-chunk-initial-area-map-handlin.patch
>  0004-percpu-use-negative-for-auto-for-pcpu_setup_first_c.patch
>  0005-x86-make-embedding-percpu-allocator-return-excessiv.patch
>  0006-percpu-add-an-indirection-ptr-for-chunk-page-map-ac.patch
>  0007-percpu-module-implement-reserved-allocation-and-us.patch
>  0008-x86-percpu-setup-reserved-percpu-area-for-x86_64.patch
>
> 0001-0004 makes misc updates to percpu in preparation of later
> changes.  0005 fixes a case where excessive memory can be set aside in
> the first chunk when using the embedding allocator.  0006-0008
> implement reserved allocation and use it for x86_64.
>
> Bryan Wu, can you please review #0001?  It contains small change in
> blackfin.  It's mostly trivial but just in case.
>

Hi Tejun,

Sorry for the delay, it looks fine for me.

-Bryan

> Diffstat follows.
>
>  arch/blackfin/include/asm/percpu.h |   10 -
>  arch/x86/kernel/setup_percpu.c     |   73 +++++++---
>  include/linux/percpu.h             |   60 +++-----
>  kernel/module.c                    |    2
>  mm/percpu.c                        |  267 ++++++++++++++++++++++++++-----------
>  5 files changed, 274 insertions(+), 138 deletions(-)
>
> Thanks.
>
> --
> tejun
>
> [1] f254f3909efaf59ca2d0f408de2d044dace60706
> [2] http://thread.gmane.org/gmane.linux.kernel/801799
>
--
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/