Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

[Manfred Spraul]

>> 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

Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

[Dawson Engler]

> 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

Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

[george anzinger]

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

Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

[Linus Torvalds]

In article <001801c0af8e$bda30c10$5517fea9@local>,
Manfred Spraul <manfred@colorfullife.com> 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

[CHECKER] blocking w/ spinlock or interrupt's disabled

[Dawson Engler]

> 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

Re: [CHECKER] blocking w/ spinlock or interrupt's disabled

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

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  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, FRG                               SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]