| 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: Sat, 12 May 2007 12:16:32 +0200 From: Bert Wesarg <wesarg@...ormatik.uni-halle.de> To: Ulrich Drepper <drepper@...hat.com> Cc: Andi Kleen <ak@...e.de>, Linux Kernel <linux-kernel@...r.kernel.org> Subject: Re: getcpu after sched_setaffinity Hello, (Please CC me, thank you) Ulrich Drepper wrote: > The attached test program fails on a dual core (and probably SMP) > machine on x86-64. Depending on where the thread starts, in one of the > iterations the sched_setffinity() call succeeds but then sched_getcpu() > fails to report the correct CPU. > > In set_cpus_allowed migrate_task() is called if the new CPU set does not > include the current CPU. I hope that migrate_task() also works for > p==current. > > This leaves the x86-64 vgetcpu() implementation as the weak point. Is > the caching causing problems? Should migrate_task() make sure the cache > is reset? > > You need a very recent glibc to compile (glibc-2.5.90-22 in rawhide). > If this is not available replace the sched_getcpu() call. But make sure > you pass a pointer to a cache. > > A question not related to this problem, but may I ask why the libc don't use[1] the linux/getcpu.h header to get the opaque struct vgetcpu_cache? Thank You Bert Wesarg [1]: http://sourceware.org/ml/glibc-cvs/2007-q2/msg00098.html - 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