Re: 2.6.17-rc5-mm3-lockdep - locking error in quotaon

From: Jan Kara
Date: Mon Jun 05 2006 - 16:04:09 EST


>
> > following confuses the code (and I agree that it's kind of ugly from
> > quota code to do that):
> > i_mutex of inode containing quota file is acquired after all other
> > quota locks. i_mutex of all other inodes is acquired before quota locks.
> > Quota code makes sure (by resetting inode operations and setting special
> > flag on inode) that noone tries to enter quota code while holding
> > i_mutex on a quota file...
>
> can you point this out in a bit more detail, eg where exactly is this
> happening? I think it is in this bit
> /* As we bypass the pagecache we must now flush the inode so that
> * we see all the changes from userspace... */
> write_inode_now(inode, 1);
> /* And now flush the block cache so that kernel sees the changes
> */
> invalidate_bdev(sb->s_bdev, 0);
> mutex_lock(&inode->i_mutex);
> mutex_lock(&dqopt->dqonoff_mutex);
> if (sb_has_quota_enabled(sb, type)) {
> error = -EBUSY;
> goto out_lock;
>
> but that doesn't quite match your description...
This piece of code is there just because we avoid page cache when
doing quota writes. That is a different story and should cause problems
with your lock checker.
Standard way of running quota is:
- get i_mutex for data_inode
- write some data to data_inode
- requires allocation -> calls DQUOT_ALLOC_SPACE
- DQUOT_ALLOC_SPACE acquires some quota locks, decides it wants to
write out quota structure (e.g. because we are journaling quota and
must preserve quota integrity)
- acquires dqio_sem, calls filesystem specific quota writing
function - e.g. ext3_quota_write()
- this function acquires i_mutex for quota file

I think this is the type of circle your checker has found.

Honza
-
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/