Messages in this thread | | | Date | Tue, 31 May 2005 02:20:27 +0200 | From | Adrian Bunk <> | Subject | Re: inappropriate use of in_atomic() |
| |
On Thu, Mar 10, 2005 at 08:40:06PM -0800, Andrew Morton wrote: > > in_atomic() is not a reliable indication of whether it is currently safe > to call schedule(). > > This is because the lockdepth beancounting which in_atomic() uses is only > accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside > spinlocks if CONFIG_PREEMPT=n. > > Consequently the use of in_atomic() in the below files is probably > deadlocky if CONFIG_PREEMPT=n:
I haven't looked deeper into it, but as a FYI the following files from your list still use in_atomic in 2.6.12-rc5-mm1:
>... > drivers/net/irda/sir_kthread.c > drivers/net/wireless/airo.c > drivers/video/amba-clcd.c > drivers/acpi/osl.c > drivers/ieee1394/ieee1394_transactions.c >...
> Note that the same beancounting is used for the "scheduling while atomic" > warning, so if the code calls schedule with locks held, we won't get a > warning. Both are tied to CONFIG_PREEMPT=y. > > The kernel provides no reliable runtime way of detecting whether or not it > is safe to call schedule(). > > Can we please find ways to change the above code to not use in_atomic()? > Then we can whack #ifndef MODULE around its definition to reduce > reoccurrences. Will probably rename it to something more scary as well. > > Thanks.
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |