On Thu, 20 Mar 2008 21:36:04 -0300 Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > Well, so far so good for LEDs, but what about the other users of in_atomic > that apparently should not be doing it either? Ho hum. Lots of cc's added. ./arch/x86/mm/pageattr.c Looks wrong. ./arch/m68k/atari/time.c Possibly buggy: deadlockable ./sound/core/seq/seq_virmidi.c Possibly buggy ./net/iucv/iucv.c ./kernel/power/process.c Just a debug check. ./drivers/s390/char/sclp_tty.c Possibly buggy: deadlockable ./drivers/s390/char/sclp_vt220.c Possibly buggy: deadlockable ./drivers/s390/net/netiucv.c Possibly buggy: deadlockable ./drivers/char/isicom.c Possibly buggy: deadlockable ./drivers/usb/misc/sisusbvga/sisusb_con.c Possibly buggy: deadlockable ./drivers/net/usb/pegasus.c Possibly buggy: deadlockable (I assume) ./drivers/net/wireless/airo.c Possibly buggy: deadlockable ./drivers/net/wireless/rt2x00/rt73usb.c Possibly buggy: deadlockable (I assume) ./drivers/net/wireless/rt2x00/rt2500usb.c Possibly buggy: deadlockable (I assume) ./drivers/net/wireless/hostap/hostap_ioctl.c Possibly buggy: deadlockable (I assume) ./drivers/net/wireless/zd1211rw/zd_usb.c Possibly buggy: deadlockable (I assume) ./drivers/net/irda/sir_dev.c Possibly buggy: deadlockable ./drivers/net/netxen/netxen_nic_niu.c Possibly buggy: deadlockable ./drivers/net/netxen/netxen_nic_init.c Possibly buggy: deadlockable ./drivers/ieee1394/ieee1394_transactions.c Possibly buggy: deadlockable ./drivers/video/amba-clcd.c Possibly buggy: deadlockable ./drivers/i2c/i2c-core.c Possibly buggy: deadlockable The usual pattern for most of the above is if (!in_atomic()) do_something_which_might_sleep(); problem is, in_atomic() returns false inside spinlock on non-preptible kernels. So if anyone calls those functions inside spinlock they will incorrectly schedule and another task can then come in and try take the already-held lock. Now, it happens that in_atomic() returns true on non-preemtible kernels when running in interrupt or softirq context. But if the above code really is using in_atomic() to detect am-i-called-from-interrupt and NOT am-i-called-from-inside-spinlock, they should be using in_irq(), in_softirq() or in_interrupt(). -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
