Unexpected scheduling with mutexes

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

 



Hi,

I've written a linux kernel module for an USB device. The USB driver
provides 2 read-only character devices, which can be opened only
exclusively by one process:
 - `/dev/cdev_a`
 - `/dev/cdev_b`

The USB device can only handle one request at a time.

The test setup is a follows:
 - Processes A reads data from 1st device: `dd if=/dev/cdev_a of=/tmp/a
bs=X`
 - Processes B reads data from 2nd device: `dd if=/dev/cdev_b of=/tmp/b
bs=X`
 - Process A and B run in parallel
 - After 10 seconds both processes are killed and size of both output
files is compared.

For certain values of `X` there is a significant difference in size
between the two files, which I don't expect.

A read call to the driver does the following:
 1. `mutex_lock_interruptible(iolock)`
 2. `usb_bulk_msg(dev, pipe, buf, X, timeout)`
 3. `mutex_unlock(iolock)`
 4. `copy_to_user(buf)`

What I would expect is the following:
 1. Proc A: `mutex_lock_interruptible(iolock)`
 2. Proc A: `usb_bulk_msg(dev, pipe, buf, X, timeout)`
 3. Scheduling: A -> B
 4. Proc B: `mutex_lock_interruptible(iolock)` -> blocks
 5. Scheduling: B -> A
 6. Proc A: `mutex_unlock(iolock)`
 7. Proc A: `copy_to_user(buf)`
 8. Proc A: `mutex_lock_interruptible(iolock)` -> blocks
 9. Scheduling: A -> B
 10. Proc B: `usb_bulk_msg(dev, pipe, buf, X, timeout)`

But what I see with ftrace is that in step 8, process A still continues.
And it seems that for certain values of X the time inside the critical
region is a multiple of the time slice, so that process B always gets
the time slice when the critical region is blocked. What would be a best
practise solution for this? I was thinking of calling `schedule()` each
time after copying to user space or playing with nice values or using
wait_queues?

-- 
Dipl.-Inf. Martin Christian
Senior Berater Entwicklung Hardware
secunet Security Networks AG

Tel.: +49 201 5454-3612, Fax +49 201 5454-1323
E-Mail: martin.christian@xxxxxxxxxxx
Ammonstraße 74, 01067 Dresden
www.secunet.com



Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux