linux-kernel - Re: [PATCH] Allocate module.ref array dynamically

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: <Pine.LNX.4.64.0811201038580.19948@quilx.com>
Date:	Thu, 20 Nov 2008 10:47:24 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	Eric Dumazet <dada1@...mosbay.com>, Takashi Iwai <tiwai@...e.de>,
	Andreas Gruenbacher <agruen@...e.de>,
	Jan Blunck <jblunck@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Mike Travis <travis@....com>
Subject: Re: [PATCH] Allocate module.ref array dynamically

On Sun, 16 Nov 2008, Rusty Russell wrote:

> > And other flags can become necessary if percpu areas gain the ability of
> > being dynamically extended.
>
> And other flags become impossible, eg. GFP_ATOMIC.

There are other flags that may become relevant like GFP_THISNODE, reclaim
settings (counter allocation from filesystem context) etc.

> The strange indirection was from someone's failed experiment at only
> allocating only online cpus.  We should kill that as a separate patch.

I fully agree.

> There are several seperate things here (this is to make sure my head is
> straight and to clarify for others skimming):
>
> 1) Make the dynamic percpu allocator use the static percpu system.
>    - Agreed, always the aim, never quite happened.

Ack.

> 2) Make zeroing optional
>    - Disagree, adds API complexity for corner case with no gain.  Using
>      gfp_t for it is even worse, since it implies GFP_ATOMIC is valid or
>      sensible.

It does not imply that. Various allocations limit the type of flags that
can be passed. Also there may be situations in which GFP_ATOMIC will make
sense in the future f.e. if a percpu counter structure has to be allocated
from an interrupt context.

GFP_FS, GFP_IO, GFP_NOFAIL GFP_ZERO GFP_NOMEMALLOC GFP_THISNODE and
GFP_HARDWALL could all be relevant for a dynamically extending percpu
allocator since memory reclaim could be triggered.

> 3) Change API to use CAPS for macros
>    - Strongly disagree, Linus doesn't use CAPS for type-taking macros
>      (list_entry, container_of, min_t), it's ugly, and status-quo wins.

That is the cause for many problems because people assume these can be
handled like a function.

> 4) Get rid of unused "online-only" percpu allocators.
>    - Agree, and will simplify implementation and macro tangle.

Ack.

> 5) Make dynamic percpu var access more efficient.
>    - Agree, obviously.  x86 for the moment, the rest can follow (or not).

Ack.
>
> 6) Use percpu allocations more widely.
>    - Definitely, I have some other patches which use it too.  And makes even
>      more sense once (5) is done.

Ack.

> 7) Make percpu area grow dynamically.
>    - Yes, but a thorny tangle esp. with IA64.  The cmdline hack is probably
>      sufficient meanwhile, and parallels can be drawn with vmalloc.

Allright. Please check with David Miller who wants to allocate thousands
of network interfaces which all need a MIB block.

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