Synchronization Techniques in 2.2 Kernel

Synchronization Techniques in 2.2 Kernel

[Wayne Cuddy]

I am working on a custom driver for a project at work.  We are working with
Debian 2.2, the code is compiled as a module.  At this time I am not able to
switch our project to the 2.4.x kernels so I require a solution using 2.2.x.

The driver has the capability to control many cards at once.  It is written
such that when the read system call is invoked data available on any card is
returned, so we don't use a separate file descriptor for each card.

I believe I have a "race condition" in the drivers read method when blocking
I/O is used and there is no data in the DMA buffers.  Here is some very basic
pseudo code for the driver's read method:

driver_read()
{
	start_card = x;
	
	while(1)
	{
		if(card_has_data(x))
			return data;

		x = next_card(x);
		
		if(start_card == x)
		{
			/* none of the cards has any data, sleep
			 * on a wait queue */
			interruptible_sleep_on.....
		}
	}
}

After the device performs the DMA it will wake the driver via the interrupt
handler.  The problem is how to handle the situation where the driver checks a
card for data, no data is available and it moves on to the next card.  While
checking the rest of the cards data may arrive on the 1st card, the interrupt
handler will fire and complete before the driver goes to sleep on the wait
queue.

If I understand wait_queues correctly the process has to be sleeping before a
wake_up call will have any effect (I.E. they are not queued).  Can this be
worked around with semaphores or some other method?  I am open to ideas here.

Any and all help is appreciated.

Wayne

Re: Synchronization Techniques in 2.2 Kernel

[Brian Strand]

Wayne Cuddy wrote:

>If I understand wait_queues correctly the process has to be sleeping before a
>wake_up call will have any effect (I.E. they are not queued).  Can this be
>worked around with semaphores or some other method?  I am open to ideas here.
>
>Any and all help is appreciated.
>
>Wayne
>
I apologize in advance if this is not quite right, having only done 
"hello world" kernel modules thus far (plus a good deal of kernel source 
browsing).  I think you need to "unfold" the interruptible_sleep_on call 
and do it yourself by adding current to the wait queue before checking 
any cards, setting current->state = TASK_INTERRUPTIBLE, then checking 
all cards and if none has data, calling schedule.  When you get back 
from schedule (i.e. your ISR has received data and done a wake_up) or 
any card has data, remove yourself from the wait queue and set your 
state to runnable.  This hopefully gives you the "atomic check condition 
and sleep if not satisfied" behavior.

Regards,
Brian Strand

Re: Synchronization Techniques in 2.2 Kernel

[David Woodhouse]

bstrand@switchmanagement.com said:
> I apologize in advance if this is not quite right, having only done
> "hello world" kernel modules thus far (plus a good deal of kernel
> source  browsing).  I think you need to "unfold" the
> interruptible_sleep_on call  and do it yourself by adding current to
> the wait queue before checking  any cards, setting current->state =
> TASK_INTERRUPTIBLE, then checking  all cards and if none has data,
> calling schedule.

You're right. It is very difficult to use sleep_on() and friends safely, 
and for that reason the plan is (or at least _has_ been) to take them all 
away in 2.5.



--
dwmw2