Hi,
We have encountered another funny with ext3 on 2.4.
Like the kernel NFS server, we have a routine in InterMezzo that does
something like looking up an inode by inode number. (compare
intermezzo's presto_ilookup or knfsd's nfsfh_iget)
Effectively both of these routines do
ilookup()
{
inode = iget(sb, ino)
if (inode->i_nlink==0)
iput(inode);
....
}
We find that this oopses if the file is recently deleted:
echo foo > file
rm file
"ilookup file" oopses.
We suspect that iget gets the inode _without_ hitting ext3_read_inode,
ie. it is still in the hash lists.
What happens is what we re-enter the ext3_delete_inode path,
and something goes wrong when it hits the ext3_orphan_del routine.
I think that something is awry, because I would have hoped that after
the unlink has run, the inode would not go through another round of
ext3_delete_inode. It would be best if ext3_read_inode __was__ called
and returned a bad inode, which is more or less what is promised in
the comment above the routine.
Do we know what is going on here?
- Peter -
