Re: Use of mutex in interrupt context flawed/impossible, need advice.

Re: Use of mutex in interrupt context flawed/impossible, need advice.

[Robert Hancock]

Leon Woestenberg wrote:
> Hello,
> 
> 
> I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.
> 
> Userspace updates a look-up-table using write(). The driver tries to
> write this LUT to the FPGA in the (video frame) interrupt handler. It
> is important that the LUT is consistent and thus changed atomically.
> Note that it is not important that the LUT is updated each interrupt.
> 
> The current approach is to try-down()ing a binary semaphore in
> interrupt context, and write the LUT to the FPGA if the semaphore was
> down()ed, do nothing else.
> The write() down()s the semaphore as well before updating the
> in-driver-copy of the LUT, then up()s it again.
> 
> I understand this design is not clean (*2), and not even possible with
> mutexes, as mutex_trylock() is not interrupt safe.
> 
> My current approach would be to have userspace write into a shadow
> copy, and use a spinlock to update the live copy. The interrupt then
> would try a spinlock.

Unless this update into the FPGA takes a significant amount of time, I 
wouldn't bother with that complexity - just do spin_lock_irq/irqsave on 
that spinlock.

Using a trylock for this rather sucks since the behavior is entirely 
non-deterministic. It could take a really long time in some cases for 
the trylock to ever succeed.

> 
> My feeling is that we have a  valid use of mutex_trylock() in
> interrupt context; "i.e. update LUT if we can do so consistently and
> in time, or not at all".
> 
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Use of mutex in interrupt context flawed/impossible, need advice.

[Leon Woestenberg]

Hello,


I'm converting an out-of-tree (*1) driver from binary semaphore to mutex.

Userspace updates a look-up-table using write(). The driver tries to
write this LUT to the FPGA in the (video frame) interrupt handler. It
is important that the LUT is consistent and thus changed atomically.
Note that it is not important that the LUT is updated each interrupt.

The current approach is to try-down()ing a binary semaphore in
interrupt context, and write the LUT to the FPGA if the semaphore was
down()ed, do nothing else.
The write() down()s the semaphore as well before updating the
in-driver-copy of the LUT, then up()s it again.

I understand this design is not clean (*2), and not even possible with
mutexes, as mutex_trylock() is not interrupt safe.

My current approach would be to have userspace write into a shadow
copy, and use a spinlock to update the live copy. The interrupt then
would try a spinlock.

My feeling is that we have a  valid use of mutex_trylock() in
interrupt context; "i.e. update LUT if we can do so consistently and
in time, or not at all".

I would like to know why this is not so, and if someone has a cleaner
proposal than the "try spinlock" approach?

Regards,
-- 
Leon

*1: specific to driving a certain FPGA with certain logic. I can post
the source code on request.
*2: http://lkml.org/lkml/2007/6/23/143

Re: Use of mutex in interrupt context flawed/impossible, need advice.

[Oliver Neukum]

Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> I would like to know why this is not so, and if someone has a cleaner
> proposal than the "try spinlock" approach?

Keep the semaphore.

	Regards
		Oliver

Re: Use of mutex in interrupt context flawed/impossible, need advice.

[Leon Woestenberg]

Hello,

On Nov 22, 2007 5:11 PM, Oliver Neukum <oliver@neukum.org> wrote:
> Am Donnerstag 22 November 2007 schrieb Leon Woestenberg:
> > I would like to know why this is not so, and if someone has a cleaner
> > proposal than the "try spinlock" approach?
>
> Keep the semaphore.
>
I forgot to mention that I would like to be prepared for, and use the
-rt patch soon. I understand (maybe wrongly?) that semaphores are not
real-time pre-emptible, mutexes and spinlocks are.

Regards,
-- 
Leon

Re: Use of mutex in interrupt context flawed/impossible, need advice.

[Michal Schmidt]

On Thu, 22 Nov 2007 17:19:44 +0100
"Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:

> I forgot to mention that I would like to be prepared for, and use the
> -rt patch soon. I understand (maybe wrongly?) that semaphores are not
> real-time pre-emptible, mutexes and spinlocks are.

Semaphores are preemptible, but they don't do priority inheritance.

Michal

Re: Use of mutex in interrupt context flawed/impossible, need advice.

[Arjan van de Ven]

On Thu, 22 Nov 2007 17:02:44 +0100
"Leon Woestenberg" <leon.woestenberg@gmail.com> wrote:

> Hello,
> 
> 
> I'm converting an out-of-tree (*1) driver from binary semaphore to
> mutex.
> 
> Userspace updates a look-up-table using write(). The driver tries to
> write this LUT to the FPGA in the (video frame) interrupt handler. It
> is important that the LUT is consistent and thus changed atomically.
> Note that it is not important that the LUT is updated each interrupt.
> 
> The current approach is to try-down()ing a binary semaphore in
> interrupt context, and write the LUT to the FPGA if the semaphore was
> down()ed, do nothing else.
> The write() down()s the semaphore as well before updating the
> in-driver-copy of the LUT, then up()s it again.
> 
> I understand this design is not clean (*2), and not even possible with
> mutexes, as mutex_trylock() is not interrupt safe.
> 
> My current approach would be to have userspace write into a shadow
> copy, and use a spinlock to update the live copy. The interrupt then
> would try a spinlock.
>

I suspect you need to copy the userspace data anyway, so I don't see
why the spinlock approach would be wrong; if the update itself is short
and non-sleeping, it's even better than a mutex or semaphore.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org