Hello,
> On Wed, Jan 16, 2002 at 08:34:42PM +0100, Jan Kara wrote:
>
...
> > 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():
Umm.. But dquots are never reused. They are allocated from slab, sometimes
they can be put on the free list, on prune_dcache() or invalidate_dquots()
they are freed but they are never reused... I just looked into dqget whether
I got all the initialization right and it seems so (actually I found a way
how dquot with NULL sb pointer can get to dqput (when dqget allocates fresh
structure but later it finds out that it's not needed) but not the way how
dquot with correct but different sb could get there).
> 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.
I don't know about any bug which could cause this but you never know :).
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
