| 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: Mon, 26 Nov 2007 12:01:22 -0500 From: "Tom Burns" <tom.i.burns@...il.com> To: linux-kernel@...r.kernel.org Subject: Clarification re: outstanding IPC flaws Hi List, Reading current kernel git ipc/sem.c I see the following comment: -- * - The previous code had two flaws: ... * 2) It did not wake up all zero waiting processes. We try to do * better but only get the semops right which only wait for zero or * increase. If there are decrement operations in the operations * array we do the same as before. -- I have some questions about this comment. Most importantly - does this mean that if I have multiple processes queued inside semop() calls with sem_val = -1 (also, if it matters, SEM_UNDO flag is set), I can expect to eventually see none of the queued processes woken up when whoever has the semaphore releases it? If that's the case, is there any semop best-use example I should be following for multiple multi-threaded processes sharing multiple semaphores? Currently I have some globally reachable semaphores doing semop calls with SEM_UNDO. They usually work fine with multiple processes waiting on each other to lock the semaphore, but under certain circumstances a semaphore will be released and none of the processes waiting on the semaphore will be woken up. Thanks in advance, Tom Burns Software Developer - 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