| 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
| ||
|
Message-ID: <47E3EA27.7020800@s5r6.in-berlin.de> Date: Fri, 21 Mar 2008 18:02:31 +0100 From: Stefan Richter <stefanr@...6.in-berlin.de> To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> CC: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c PS, I wrote: > Tetsuo Handa wrote: >> So, it is impossible to know whether I am inside a spinlock or not. >> OK. That's not what I want to do. >> >> I want to make sure that my code (not a device driver) is called only >> from a context where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/ >> get_user_pages()/kmap() etc. are permitted. >> Is "if (in_atomic()) return;" check a correct method for avoiding >> deadlocks when my code was accidentally called from a context >> where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/ >> kmap() etc. are not permitted? No. Quoting Andrew: "in_atomic() returns false inside spinlock on non-preemptible kernels." > You shouldn't sleep while holding a spinlock. As soon as another thread or interrupt handler or tasklet > attempts to take the spinlock, it will be stuck in a busy-wait loop. -- Stefan Richter -=====-==--- --== =-=-= http://arcgraph.de/sr/ -- 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