Trond Myklebust wrote:
> Er... Why?
Because the inode could be on inode_unused, being still on the hash at
the client side, and server could reuse the inode (in case of
unfsd/ext3). When the inode will be reused for different type, it
will result error. Here is a scenario for non-patched 2.4.18:
(1) Symbolic link has been removed. The inode is put on inode_unused.
Say the inode # was 0x1234.
(2) Client issue "creat", server returns inode # 0x1234 (by the reuse).
(3) Call chain is:
nfs_create -> nfs_instantiate -> nfs_fhget -> __nfs_fhget -> iget4
iget4 returns the cached inode object on inode_unused.
(4) nfs_fill_inode doesn't fill it, because inode->i_mode is not 0.
(5) nfs_refresh_inode result error because inode->i_mode != fattr->mode.
Note that this is _real_ case.
> If you really want to change something in nfs_find_actor() then the
> following works better w.r.t. init_special_inode() on character
> devices:
>
> if ((inode->i_mode & S_IFMT) != (fattr->mode & S_IFMT))
> return 0;
Well, I've just tested this. This works well, thank you.
-- - 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/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:14 EST