lkml.org 
[lkml]   [2007]   [Oct]   [27]   [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 Sat, 27 Oct 2007, Peter Zijlstra wrote:

> > > [ 592.752781] ================================================
> > > [ 592.753478] [ BUG: lock held when returning to user space! ]
> > > [ 592.753880] ------------------------------------------------
> > > [ 592.754262] hwclock/1452 is leaving the kernel with locks still held!
> > > [ 592.754655] 1 lock held by hwclock/1452:
> > > [ 592.755007] #0: (&rtc->char_lock){--..}, at: [<c02a7ebb>] rtc_dev_open+0x2e/0x7e
> > Yes, this is because rtc keeps a char_lock mutex locked as long as the
> > device is open, to avoid concurrent accessess.
> I think, in this case, the lock is associated with a kernel object that
> is properly cleaned up if the holding tasks gets a SIGKILL. But in
> general I'd like to see this kind of thing go away.

Yes, but the fact is that is really is invalid use of mutex -- because the
mutex owner could become seriously wrong after fork() or sending the
filedescriptor through unix socket ... this easily leads to broken
situation.

This seems to have been introduced in e824290e5d ... Alessandro, could you
convert this to test_and_set_bit()/clear_bit() semantics instead of a
mutex please?

Thanks,

--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-10-28 00:49    [W:0.163 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site