[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sleep() and device drivers ...



Not long ago I asked for a metod for device driver functions to decide,
whether sleep() was interrupted by a signal or not.

Finally I got a solution myself.

The underlying question of the above is to decide, if a signal handler could
have called the device's close() function thus kfree()ing an object the
sleep()ing function is just operating on.

To decide this we use a counter `intr' which is incremented every time the 
device drivers close() is called and an object is really freed
(if  fileptr->links <= 0):

unsigned long intr = 0;

long
dev_close (fp, pid)
	FILEPTR *fp;
	short pid;
{

	...

	if (fp->links <= 0) {
		++intr;
		/* free the data associated with the fileptr */
	}

	...

	return 0;
}

Furthermore we use a new sleep() function, which looks like this:

short
isleep (queue, cond)
	short queue;
	long cond;
{
	unsinged long ointr = intr;
	sleep (queue, cond);
	return (ointr != intr);
}

Isleep() will return true if there were any 'disposing' calls to
dev_close() while sleep()ing in a device drivers function.
If isleep() returns true, the function calling isleep() should
not touch any objects that could be freed by calls to dev_close() and
perhaps return whatever is equivalent to EINTR or ERESTARTSYS. Like this:

long
dev_read (fp, buf, buflen)
	FILEPTR *fp;
	char *buf;
	long buflen;
{
	while (data not available) {
		if (isleep (IO_Q, (long)fp->devinfo)) {
			/* perhaps fp was freed, so we cannot
			   reference it to see if data is available */
			return ERESTARTSYS;
		}
	}
	
	read the data into `buf';
	...
}

I strongly suggest to change pipefs' device driver and all other devices
drivers which tend to have the same problem in the described way, in order
to avoid references to already freed memory.

Perhaps we should implement ERESTARTSYS in the kernel. If a device
driver function returnes this error code, the kernel should restart the
system call, checking again the filedescriptors, etc. If they are still
valid, perhaps the call can be completed this time without interrupts.

Comments appreciated,

-- Kay Roemer.