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: Wed, 14 Mar 2007 10:30:59 +0300 From: Pavel Emelianov <xemul@...ru> To: "Eric W. Biederman" <ebiederm@...ssion.com>, Sukadev Bhattiprolu <sukadev@...ibm.com>, Serge Hallyn <serue@...ibm.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: [RFC] kernel/pid.c pid allocation wierdness Hi. I'm looking at how alloc_pid() works and can't understand one (simple/stupid) thing. It first kmem_cache_alloc()-s a strct pid, then calls alloc_pidmap() and at the end it taks a global pidmap_lock() to add new pid to hash. The question is - why does alloc_pidmap() use at least two atomic ops and potentially loop to find a zero bit in pidmap? Why not call alloc_pidmap() under pidmap_lock and find zero pid in pidmap w/o any loops and atomics? The same is for free_pid(). Do I miss something? Thank, Pavel - 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