Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Help with 4.3 mod to kill uninteruptable procs.
Message-ID: <19078@rpp386.cactus.org>
Date: 27 Feb 91 16:05:08 GMT
References: <1991Feb19.001941.29928@lynx.CS.ORST.EDU> <5583@awdprime.UUCP> <1991Feb27.105436.1554@thunder.mcrcim.mcgill.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 56
X-Clever-Slogan: Recycle or Die.

In article <1991Feb27.105436.1554@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>> 	DISABLE_INTERRUPTS;
>> 	while (some_status & some_busy_flag)
>> 		sleep (&some_status, PRI_O_MINE);
>> 	ENABLE_INTERRUPTS;
>> 	some_status |= some_busy_flag;
>
>I would tend to move the enable after the bit set.  I think at present
>it doesn't make any difference, but only because kernel code can't be
>preempted, except in a limited way by interrupts, and the interrupt
>handler never sets or clears the busy bit.  If either of these changes,
>you'll be glad you have the enable after the setting of the busy bit!

If any of the other bits are modified at interrupt level you have to
make =any= modifications to =any= bits in the status word with interrupts
disabled for the highest level the word is modified at.

Consider the execution of a process off interrupt level which is then
interrupted by the device being serviced.  Thread "A" is the non-interrupt
level execution, and thread "B" is the instruction stream executed at
interrupt time.  It isn't a big window, but with Murphy at the controls ...

Thread A				Thread B

wakes up, checks bits and
sees that resource is free

loads the word at 'some_status'
so it can set the busy bit and
write it back

					POING! interrupt occurs and
					device driver loads word at
					'some_status' so it can set
					some bit.  the bit gets set
					and the word gets written
					back

execution resumes after the
interrupt with the original
value of 'some_status' still
in the register it was loaded
in to - without the bit set
from the interrupt service
routine

the 'some_busy_bit' is set and
the word written back to
'some_status'.  the action taken
during the interrupt service has
been overwritten.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.