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

[Jan Kara <jack@suse.cz>]

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