Re: 2.6.27.14: BUG: lock held when returning to user space!

[Jan Kara]

> On Wed, 2009-02-25 at 15:21 +0100, Frank van Maarseveen wrote:
> > An lvextend -L+16G command for a logical volume while being mounted rw
> > as ext3 triggered the following on 2.6.27.14:
> > 
> > ================================================
> > [ BUG: lock held when returning to user space! ]
> > ------------------------------------------------
> > lvextend/29191 is leaving the kernel with locks still held!
> > 2 locks held by lvextend/29191:
> >  #0: (&type->s_umount_key #15){....}, at: [<c019edfb>] get_super+0x6b/0xb0
> >  #1: (&journal->j_barrier){....}, at: [<c01f9af3>] journal_lock_updates+0xc3/0xd0
> 
> Do recent kernels still say this?
  I'd say so. We really hold j_barrier mutex when leaving the kernel
after FIFREEZE ioctl (the call path goes as freeze_bdev -> ext3_freeze
-> journal_lock_updates) until FITHAW is called. As far as I know it was
designed this way...
  It would be a pity to completely exclude j_barrier mutex from lockdep
control so would it be possible to mark the mutex (or even that
particular acquisition of the mutex) so that lockdep does not warn when
we return with it to userspace?

									Honza
-- 
Jan Kara <jack@xxxxxxx>
SuSE CR Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/