Xref: utzoo comp.unix.xenix:4041 comp.unix.wizards:13029 Path: utzoo!utgpu!watmath!clyde!att!ulysses!sfsup!sfmag!der From: der@sfmag.UUCP (D.Rorke) Newsgroups: comp.unix.xenix,comp.unix.wizards Subject: Re: wakeup() race condition. (theory) Message-ID: <1302@sfmag.UUCP> Date: 30 Nov 88 18:47:45 GMT References: <455@mrecvax.UUCP> Organization: AT&T Information Systems, Summit, NJ Lines: 56 > > A few days ago, I posted an article describing a problem > with a driver that didn't return from a sleep(), though > the call to wakeup was performed. > > The process remained in a curious state. It was reported by > ps as runnable (no sleep chan), but the run list pointer > was 0. It also didn't respond to any signal. > > A point to note is that the driver's interrupt routine > priority is 7, and that this routine is calling wakeup() > to awaken the sleeping process. > > Theory: > Sleep & wakeup both call spl6() to ensure secure access to > the process queues, (Well, this is not theory, the calls are > there...) and it is possible for the driver's device to > interrupt as a wakeup() is running, isn't it ? > > As this driver (as SCO xenix serial driver) is running with > prio 7, it's not blocked by spl6() and then it may interfere > with the running wakeup by, say, runnig another wakeup. > > Solution: (?) > Not to call any wakeup at prio 7, that is, put every driver > interrupt routine that calls wakeup at prio 6 or below. > > I would be glad to hear some guru opinion on the topic. Arghh. Most current implementations of wakeup() are not reentrant. I assume yours is not if it's bothering to do an spl6(). Non reentrant wakeup() implementations should set the interrupt level to the highest possible level while executing in a critical section. As you noted, a wakeup() that sets some intermediate interrupt level can be interrupted by an interrupt handler that could potentially call wakeup(). This could cause the problem you observed. It could also panic your system if the sleep queues are implemented as linked lists. The solution you propose above is OK but a better solution (if you have source) is to fix wakeup() to set the highest interrupt level supported by the hardware. Dave Rorke attunix!der > -- > Carlos G. Mendioroz> Work: +54 (1) 313-8082 Fax: +54 (1) 311-1249 > Home: +54 (1) 71-3473 ; Malabia 2659 11 B, Buenos Aires, 1425 ARGENTINA *** REPLACE THIS LINE WITH YOUR MESSAGE ***