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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <c384c5ea0711220802i21e3df45q1d328aea63e7ebf4@mail.gmail.com>
Date:	Thu, 22 Nov 2007 17:02:44 +0100
From:	"Leon Woestenberg" <leon.woestenberg@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Use of mutex in interrupt context flawed/impossible, need advice.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/