lkml.org 
[lkml]   [2008]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: lock held when returning to user space
On Wed, 12 Mar 2008, Frank Munzert wrote:

> Unit record devices are not meant for concurrent read or write by
> multiple users, that's why we need to serialize access. The driver's
> open method uses mutex_trylock or mutex_lock_interruptible to ensure
> exclusive access to the device, while its release method uses
> mutex_unlock.

Which is wrong usage of mutex.

> As a consequence, lockdep complains about locks being held when returning to
> user space. We used a very simple char device driver (appended below) to
> produce this message:
> ------------------------------------------------
> testapp/2683 is leaving the kernel with locks still held!
[ ... ]
> For the vmur device driver it is crucial to have only one process access a
> given unit record device node at a given time. So having open hold the mutex
> and return to user space is exactly what we want.

No, it is not. You probably want just to have a single-bit flag somewhere,
and update/check it atomically, see below.

> Is there any annotation to tell lockdep to suppress or bypass this kind
> of warning?

No, as it is a real bug if you use mutexes in this way. What happens if
process that has called open() on your device (and has not closed it yet)
calls fork()?
Another breakage scenario -- what if the filedescriptor is sent through
unix socket to another process? etc.

Look at test_and_set_bit_lock() and clear_bit_unlock(), those you want to
use.

--
Jiri Kosina
SUSE Labs



\
 
 \ /
  Last update: 2008-03-12 22:43    [W:0.092 / U:2.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site