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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
