Hi,
On Wed, Jan 16, 2002 at 08:34:42PM +0100, Jan Kara wrote:
> I was going through the code forward and backward and from the left
> to the right :) and the only way I see how this can happen is when
> quota file is on the different filesystem than it belongs too (actually
> nobody forbids it, even there is an optional parameter to usrquota
> mount option which specifies where is the quota file). But in that case
> it's rather trivial and I'd expect users would see the problem rather
> often. So Branko do you have quota files on the filesystem they belong to?
Right --- one scenario we already wondered about was if the quota
files were symlinks.
> Otherwise I really can't understand how this can happen - quota code
> obviously got correct file pointer so I guess it can't be corruption
> or something like that... especially when the pointer is setup once
> on quotaon() and then it's not touched. Also I can't imagine how
> dquot would get wrong superblock pointer...
Right. The only thing I could think of was a race in the locking of
the dquot, leading the dquot struct itself to get reused at an awkward
moment. One route would be if there were too many dqput's on some
path: the test in dqput():
if (!dquot->dq_count) {
printk("VFS: dqput: trying to free free dquot\n");
printk("VFS: device %s, dquot of %s %d\n",
is really rather permissive, and should probably be a BUG(). Branko,
can you see if there have been any traces of that message in your
logs?
I'll have a look through recent ext2 dquot patches to see if we've
missed any fixes in ext3, but I think we're uptodate there.
Cheers,
Stephen
