FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 03-04-2009, 03:58 PM
Jan Kara
 
Default 2.6.27.14: BUG: lock held when returning to user space!

> 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@suse.cz>
SuSE CR Labs

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-04-2009, 04:28 PM
Jan Kara
 
Default 2.6.27.14: BUG: lock held when returning to user space!

> On Wed, 2009-03-04 at 17:58 +0100, Jan Kara wrote:
> > > 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?
>
> Linus specificly stated that we are not to keep locks held when
> returning to userspace:
>
> http://lkml.org/lkml/2007/10/27/135
>
> So sure, we could annotate this, but no I won't until you can convince
> both me and Linus that its a sane thing to do.
I didn't write the code . I was just informing how the things are. I agree
it's not a nice thing to do. Hmm, looking at the code, it uses a special
semaphore bd_mount_sem while mutex seems to be enough. Digging in git...
ah, exactly so that lockdep does not complain about it. Ugh. Also
the comment before freeze_bdev() says something about taking s_umount while
it does not take it. That code really seems to need some cleaning...

> The problems include: how can you be sure its the same task calling the
> completing ioctl?
Yeah, I understand the problems.

Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 02:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org