On Sat, 27 Oct 2007, Peter Zijlstra wrote:

quoted text
> > > [  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
-
unsubscribe notice
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/