The test for in_atomic() in arch/m68k/atari/time.c was introduced by:
| commit 69961c375288bdab7604e0bb1c8d22999bb8a347
| Author: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
(incorrect attribution due to missing `From: Roman Zippel' line. my bad)
| Date: Mon Oct 9 22:23:31 2006 +0200
|
| [PATCH] m68k/Atari: Interrupt updates
|
| Misc Atari fixes:
| - initialize correct number of atari irqs
| - silence vbl interrupt until it's used by atafb
| - use mdelay() to read clock if necessary
---------- Forwarded message ----------
Date: Thu, 20 Mar 2008 18:08:02 -0700
From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
To: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
Cc: David Brownell <david-b@xxxxxxxxxxx>, Richard Purdie <rpurdie@xxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxx>,
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, netdev@xxxxxxxxxxxxxxx,
Martin Schwidefsky <schwidefsky@xxxxxxxxxx>,
Heiko Carstens <heiko.carstens@xxxxxxxxxx>, linux-usb@xxxxxxxxxxxxxxx,
linux-wireless@xxxxxxxxxxxxxxx, video4linux-list@xxxxxxxxxx,
Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>, lm-sensors@xxxxxxxxxxxxxx
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c
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-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
