Messages in this thread |  | | Date | Tue, 3 Sep 2002 12:07:56 -0400 | Subject | Re: [BK-PATCH-2.5] Introduce new VFS inode cache lookup function | From | Jan Harkes <> |
| |
On Tue, Sep 03, 2002 at 04:31:32PM +0100, Anton Altaparmakov wrote: > On Tue, 3 Sep 2002, Jan Harkes wrote: > > On Tue, Sep 03, 2002 at 06:20:44AM +0100, Anton Altaparmakov wrote: > > > 2) It will return inodes that are I_FREEING or I_CLEAR. I will have to > > > test for these in NTFS and then iput() to wash my hands clean of such > > > garbage. And if I am not mistaken, the iput() actually will BUG(). > > > > If that is the case iget is broken. Perhaps it should test for these > > states in find_inode (and find_inode_fast) and never return them. Are > > those types of inodes still on the inode hash? > > That is of course the big question. As I said I haven't looked at this > very closely...
<handwaving> There is no problem here </handwaving>
invalidate_list, prune_icache, generic_delete_inode, and generic_forget_inode all move the inode off of the inode hash before setting the I_FREEING flag. So inodes in I_FREEING state can not be found by find_inode.
Clear inode bugs when the inode is not I_FREEING, it then clears out the inode and sets I_CLEAR. As a result, inodes in I_CLEAR state can not be found by find_inode either.
So you can safely remove that test in ilookup.
> > > 4) If anything, as Christoph Hellwig suggested to me on #kernel, > > > iget{,5}_locked() should be reimplemented in terms of my ilookup() > > > implementation and not vice versa. (-: > > > > Well, considering that this function (modulo the I_FREEING|I_CLEAR test > > is identical to the first 10 lines in iget5_locked, this could call that > > function. Ofcourse iget_locked is using the 'fast' version of find_inode. > > Yes, indeed, and yes. I recall that Al wanted the _fast() versions to > remain separate. This can be done easily enough here, too. For example > ilookup() and ilookup5() (to remain consistent with iget5() or if you > have a better idea for a name...).
I have no problem with the name. And coda_fid_to_inode could use ilookup5 as well, as currently uses iget with the 'set_fail' trick.
Jan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |