Re: Race conditions galore (2.0.33 and possibly 2.1.x)

Stephen R. van den Berg (srb@cuci.nl)
Thu, 25 Dec 1997 17:07:28 +0100

Gerard Roudier wrote:
>The patch that fixes your problem makes differences when an interrupt
>from the SCSI controller that will unlock the buffer occurs during the
>queuing of disk requests.
>As stated by Linus and Bill, and probably checked by lots of other people,
>your change should not make differences on the wait_on_buffer() final
>behaviour.

True. The only thing that could arguably be influenced by my patch
is that we do not reset current->state to TASK_UNINTERRUPTIBLE
after it (apparently) has changed from within run_task_queue(&tq_disk)
*without* unlocking the buffer.
The buffer is then unlocked later, without setting the task to being
runnable again.

>Given the strangeness of the problem you reported, checking the effect
>of not using 'write and invalidate' should help, IMO.
>Trying another CPU, for example a PENTIUM, should help too.

I wanted to wait for patches in the md driver.
But, if that doesn't happen soon, I guess I could change the "write
and invalidate" behaviour.

>> eth0: DC21041 at 0xe000 (PCI bus 0, device 11), h/w address 00:80:48:e8:67:ee,
>> and requires IRQ10 (provided by PCI BIOS).

>This board is also master capable.

I know. It does. I only use master capable devices.

-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).


To boldly program, where *no* man has programmed before!