[lkml]   [2002]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client)
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.021 / U:19.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site