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.0811121630390.2379@quilx.com>
Date:	Wed, 12 Nov 2008 16:50:46 -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 Thu, 13 Nov 2008, Rusty Russell wrote:

> > > You've introduced a third set of per-cpu primitives, yet the second set
> > > still has 0 users.
> >
> > What second set?
>
> percpu_alloc().

That is a variant of allocpercpu. We have thinned the allocpercpu API
somewhat already. I can drop more portions or I can drop it completely at
the very end of the patchset.

> > cpu. The difference between THIS_CPU and __THIS_CPU is the context check
> > by smp_processor_id()
>
> Thanks, I figured that out, but it's not documented.  I'll happily create a
> patch, but see below.  BTW, did you end up using __THIS_CPU anywhere?

Yes in later patches. This is a total set of 40 or so patches.

> > The caps functions are macros not functions. Macros are
> > capitalized.
>
> Traditionally, yes, but we seem to be more ambivalent in the kernel.
> list_for_each() et. al spring to mind: code would be uglier if we made them
> caps.

Macros being capitalized have a reason: They may do strange things with
the parameters. In particular CPU_ALLOC/CPU_FREE do a determination of
the size of the type. The macros do not take an argument in the
traditional sense. Frankly alloc_percpu(type) is something that looks not
right to me.

> > alloc_percpu must stay until the last remains have been
> > evicted.
>
> OK, you anticipate replacement of all alloc_percpu users?

Yes. If you look at the full patchsets that were posted at various times
during the last year you see that allocpercpu will be gone.

> > And the API does work differently.
>
> I'm afraid the difference has escaped me so far.  Please explain why you can't
> use the current API.  Is this subtle difference going to make the transition
> difficult?

The old api was based on an attempt to introduce a cpu mask. That mask was
never used. See percpu_alloc_mask. The handling is not consistent with the
nature of the percpu sections for other percpu data because allocation is
only done for online processors. So we have semantic differences. The API
is inconsistent and underwent rot. Having to allocate percpu sections if
processors are onlined and offlined causes the need for more hooks. The
cpu alloc patchset gets rid of about half the hooks in the page allocator
and slab allocator.
--
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/