Messages in this thread | | | Date | Sun, 21 Mar 1999 00:08:25 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Odd code in iput() (since 2.1.60). What for? |
| |
On Sat, 20 Mar 1999, G. Allen Morris III wrote:
> It is my understanding that iget() will return an inode even if > its link count is zero. You still have to call iput on the > inode to get i_count back to zero. And I don't think that > this inode would be DIRTY.
Ahem... How does it matter? If the iput() in question doesn't drive i_count into 0 the code in question isn't executed at all. If you are giving up the last reference *and* nlink is zero - the thing will be removed from hash, ->delete_inode() will be called and unless it will rehash the sucker (which it shouldn't and doesn't) clear_inode() will be called and inode will got to freelist. Code in question not executed again. The only cases when it may be executed and be *not* a no-op: a) delete_inode() decides to link the sucker somewhere instead of killing it for good and rehashes it. Will work *only* if the inode will be also made clean. Doesn't look right for me, besides nobody actually tries to pull such stunts. b) inode we've called is clean, hashed and not on the main list (and we gave up the last in-core reference). In this case we transfer it to the main list. Not to mention the fact that it can never happen (AFAICS) it sounds really odd.
> It may be that there should be an iget...() that does not return > deleted inodes. (I could use it in NFSD, to get at the inode cache.)
It would be *wrong* (and mostly pointless) on normal filesystems and it can be trivially checked on any fs, anyway, so... Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |