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]

Date:	Fri, 14 Nov 2008 10:19:48 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Christoph Lameter <cl@...ux-foundation.org>
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 Friday 14 November 2008 01:10:32 Christoph Lameter wrote:
> On Thu, 13 Nov 2008, Rusty Russell wrote:
> > > The cpu alloc patchset gets rid of about half the hooks in the page
> > > allocator and slab allocator.
> >
> > Sure, but we could convert those today to alloc_percpu etc.
>
> The percpu_ptr macros etc are not upercase suggesting that it is a
> function but the functions do weird things like passing through the
> type. This is confusing.

No it's not, we have several like that.  And noone's going to somehow get 
confused and misuse it.  Finally, we don't change APIs just to meet some sense 
of neatness.

> alloc_percpu() does not allow specifying a GFP mask therefore does not
> support zeroing and is not extendable for the future.

It is defined to be zeroing.  And it is very unclear that (1) future 
implementations will be able to support GFP_ATOMIC reasonably, and (2) that we 
want people to do that.  If we do, we fix it.

> It does not allow
> specifying an alignment therefore tight packing is not possible.

It absolutely does.  That's why it takes a type!

> Plus the name alloc_percpu() suggests that it is a function but its a
> macro doing things with typing.

You said that before.

> CPU_PTR and THIS_CPU can be applied both to percpu pointers and
> percpu variables. The new API unifies the handling which is required in
> order for the new cpu_ops to work both on statically and dynamically
> allocated percpu data.

And if you called them per_cpu_ptr and __get_cpu_ptr they would have these 
same properties.  But now the names would be consistent.

So let's just reimplement the original API and be done.
Rusty.
--
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/