linux-kernel - Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

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.0811210842580.24965@quilx.com>
Date:	Fri, 21 Nov 2008 08:49:29 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

On Fri, 21 Nov 2008, Stephen Rothwell wrote:

> > I would not mind if you would take over from here.
>
> So, should I remove the cpu_alloc tree from linux-next?

I think the cpu_alloc branch itself is fine because it only contains the
allocator and a single use case. The only point of disagreement at this
point is the uppercase / lowercase use. Currently its a separate API (its
not replacing allocpercpu) and therefore easy to merge.

The more invasive stuff is stage2 and the following which is not in next
yet. The way I envision to go forward is with a gradual transition to the
new APIs converting dynamic percpu users to use the new percpu operations
and functionality.

The whole thing becomes riskier if we directly replace all allocpercpu
users as proposed by Rusty.

Rusty, are you going to take this on?

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