> enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> called with either interrupts disabled or a spin lock held. The
> checker works by:
Here's the file manifest. Apologies.
drivers/atm/idt77105.c
drivers/atm/iphase.c
drivers/atm/uPD98402.c
drivers/block/cciss.c
drivers/block/cpqarray.c
drivers/char/applicom.c
drivers/char/cyclades.c
drivers/char/epca.c
drivers/char/esp.c
drivers/char/istallion.c
drivers/char/moxa.c
drivers/char/mxser.c
drivers/char/n_r3964.c
drivers/char/rio/rioctrl.c
drivers/char/rio/riotable.c
drivers/char/rio/riotty.c
drivers/char/riscom8.c
drivers/char/serial.c
drivers/char/specialix.c
drivers/i2o/i2o_proc.c
drivers/ide/ide-probe.c
drivers/ide/umc8672.c
drivers/isdn/act2000/act2000_isa.c
drivers/isdn/hisax/gazel.c
drivers/isdn/icn/icn.c
drivers/isdn/isdnloop/isdnloop.c
drivers/md/raid1.c
drivers/net/aironet4500_core.c
drivers/net/depca.c
drivers/net/irda/irport.c
drivers/net/irda/irtty.c
drivers/net/irda/smc-ircc.c
drivers/net/pcmcia/netwave_cs.c
drivers/net/ppp_generic.c
drivers/net/wan/comx-hw-locomx.c
drivers/net/wan/comx-hw-mixcom.c
drivers/net/wan/comx.c
drivers/net/wan/lmc/lmc_main.c
drivers/scsi/aha1542.c
drivers/scsi/atp870u.c
drivers/scsi/psi240i.c
drivers/scsi/sym53c416.c
drivers/scsi/tmscsim.c
drivers/sound/cmpci.c
drivers/sound/emu10k1/audio.c
drivers/sound/emu10k1/midi.c
drivers/sound/midibuf.c
drivers/sound/nm256_audio.c
drivers/sound/sb_ess.c
drivers/sound/sequencer.c
drivers/usb/serial/empeg.c
drivers/usb/serial/keyspan_pda.c
drivers/usb/serial/mct_u232.c
drivers/usb/serial/omninet.c
drivers/usb/serial/usbserial.c
fs/hfs/catalog.c
net/bridge/br_if.c
net/irda/ircomm/ircomm_tty.c
>> enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> > called with either interrupts disabled or a spin lock held. The
> > checker works by:
>
> Here's the file manifest. Apologies.
>
> drivers/atm/idt77105.c
> [...]
> drivers/char/cyclades.c
Unortunately schedule() with disabled interrupts is a feature, it's
needed for the old (deprecated and waiting for termination in 2.5)
sleep_on() functions.
Is it difficult to split it into "interrupts disabled" and "spin lock
held"?
--
Manfred
> Is it difficult to split it into "interrupts disabled" and "spin lock
> held"?
Nope, since it's already done ;-) The suffix of each error message
should say whether it's because you have a spinlock, ints disabled, or
both:
2.4.1/drivers/atm/idt77105.c:153:fetch_stats: ERROR:BLOCK:151:153:
calling blocking fn '__constant_copy_to_user' w/ int's disabled
2.4.1/drivers/atm/iphase.c:2426:ia_led_timer: ERROR:BLOCK:2423:2426:
calling blocking fn 'ia_tx_poll' w/ spin lock held
Dawson
In article <001801c0af8e$bda30c10$5517fea9@local>,
Manfred Spraul <[email protected]> wrote:
>
>Unortunately schedule() with disabled interrupts is a feature, it's
>needed for the old (deprecated and waiting for termination in 2.5)
>sleep_on() functions.
Yes. But that should only cover "sleep_on()" and it's interruptible
cousing "sleep_on_interruptible()". No other blocking call should have
interrupts disabled, I would hope.
The special-case is a fairly specific "some old-style drivers avoid race
conditions by having interrupts disabled over explicit conditional
sleeps", not a generic "you may have interrupts disabled before
blocking".
Linus
Dawson Engler wrote:
>
> > Is it difficult to split it into "interrupts disabled" and "spin lock
> > held"?
>
Is it difficult to test for matching spinlock pairs such as
spin_lock_irq/spin_unlock_irq. Sometimes a spin_lock_irq is followed by
a spin_unlock and a separate interrupt re-enable. This sort of usage,
while not strictly wrong, does make it hard to use the spin_lock/unlock
macros to do preemption. This said, pairing information would be very
helpful. Note, there are several flavors here, not just the one I
cited.
George
Hi Dawson,
On Sat, Mar 17, 2001 at 08:23:34PM -0800, Dawson Engler wrote:
> > enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> > called with either interrupts disabled or a spin lock held. The
> > checker works by:
>
> Here's the file manifest. Apologies.
>
[...]
> drivers/scsi/tmscsim.c
[...]
I'm interested in this one as I'm the maintainer ...
How do I get more details on the problem?
Most other CHECKER reports have been indicating the function where the
problem occurs, this unfortunately not. Am I missing something?
PS: Very nice work! Keep on going!
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security