lkml.org 
[lkml]   [2002]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client)
From
>>>>> " " == NIIBE Yutaka <gniibe@m17n.org> writes:

> 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.

Sure, but it is a consequence of a badly broken server that violates
the NFS specs concerning file handles. Rigging the client in order to
cope with *all* the consequences in terms of unfsd races is an
exercise in futility - it cannot be done.

The solution is not to keep flogging the dead horse that is unfsd. It
is to put the effort into fixing knfsd so that it can cope with all
those cases where people are using unfsd today.

Cheers,
Trond
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.136 / U:25.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site