Unexpected scheduling with mutexes

[Martin Christian]

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 at secunet.com
Ammonstraße 74, 01067 Dresden
www.secunet.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20190327/f5432fd8/attachment.sig>