symlinks and NWFS

From: Alexander Viro (aviro@redhat.com)
Date: Fri May 12 2000 - 07:17:47 EDT

  • Next message: John Cavan: "Re: PATCH: rewrite of invalidate_inode_pages"

    On Thu, 11 May 2000, Jeff V. Merkey wrote:

    > I have only the variable page size mapping layer left to regress and a
    > MKISOFS bug remaining before submitting diff's to Alan/Linus for
    > 2.0/2.2/2.4. Everything else (less HFS integration) has been
    > completed. IA64 will be posted after I test it on an IA64 box (which
    > Intel has kindly offered to make available for us to test on end of this
    > month).

    Ugh... Jeff, I've looked at your code (my apologies for brainfart re RPC -
    I've got coffee and I'm back to sanity) and there are some places that look
    fishy.
            1) // if somebody already freed the directory record for this ino,
               // then just return.
               in read() sounds *wrong*. If it means what it seems to mean it
               breaks the semantics of unlink() - unlink() should have no effect
               on later read() if the file had been opened prior to it.
               POSIX-mandated, yodda, yodda and there is a lot of software relying
               on that.
            2) As for the symlinks... What's wrong with nwfs_readpage(), why do
               you bother with the NWReadFile() thing? If it's just a matter of
               NUL-termination - call the nwfs_readpage() and put '\0' into the
               right place after that.
            3) nwfs_rename() looks deadlocky - you lock two objects and do not
               seem to care about the order of locking. And you are doing that
               very close to the entry, so it doesn't look like some other
               serialization may save you here.
            4) Ditto for rmdir() - same story, same potential problem.

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



    This archive was generated by hypermail 2b29 : Fri May 12 2000 - 07:22:42 EDT