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
| ||
|
Date: Thu, 13 Nov 2008 18:20:41 -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 Fri, 14 Nov 2008, Rusty Russell wrote: > > 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. But some uses do not need zeroing. They currently have no choice. And other flags can become necessary if percpu areas gain the ability of being dynamically extended. Zeroing percpu areas on systems with lots of cpus can take awhile in particular since these areas may be on remote nodes. > > It does not allow > > specifying an alignment therefore tight packing is not possible. > > It absolutely does. That's why it takes a type! alloc_percpu is based on __alloc_percpu which currently does not take an alignment. Guess we could get there by removing the intermediate functions and making alloc_percpu call cpu_alloc. However, there are only a few places that use allocpercpu and all of those are touched by necesssity by the full cpu alloc patchset. At mininum we need to add the allocation flags and add cpu ops as well as review the preemption at each call site etcin order to use the correct call. So why bother with the old API? > > 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. Having macros that do type casting on results and do macro operations on parameters look like functions does not seem to be right. We can make it consistent at the end by renaming the remaining ones. Having an uppercase CPU_PTR and such in the source clarifies that something special is going on. This is consistent with other uses in the kernel. This is CPP magic after all (see examples in include/linux/kernel.h or slab.h f.e.) -- 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/
Powered by blists - more mailing lists