Re: Proposal: int (permission*)(struct dentry *, int)

From: Alexander Viro (viro@math.psu.edu)
Date: Sun May 14 2000 - 04:37:46 EDT

  • Next message: Pierfrancesco Caci: "2.3.99-pre8 AX25 trouble"

    On Sun, 14 May 2000, Roman V. Shaposhnick wrote:

    > Looks good from my point of view.
    >
    > btw, my opinion is that for the "external representation" purposes all inode
    > operations that can possibly deal with files ( IOW: terminal nodes of the
    > dentry tree ) should get dentry as an argument.

    _NOT_. Even ->permission() thing is murky, but for stuff like ->link() -
    forget it. NFS _is_ deeply perverted - forcing the results of botched
    protocol design upon every fs out there is wrong. I can see the point for
    doing struct file * in _some_ cases, but getting stuff tied to dentry is
    asking for trouble. Heck, the less filesystems know and care about dcache
    the less creepy stuff is lurking out there. Just look what kind of games
    NFS tries to play with dcache and weep. Or watch the lovely stuff
    devfs_unlink() does - especially in free_dentries(). Or you can get
    your kicks looking at the crap (sorry, Petr, but it _is_ crap - populating
    dcache really shouldn't be done by readdir()) in ncp_readdir().

    BTW, folks - those of you who are doing filesystems outside of the main
    tree and
            a) do tests for ->d_count somewhere or
            b) have ->d_delete() different from if (...) d_drop(dentry);
    - show up. In the first case I bet that you've got a race on hands, in the
    second - I'ld like to look at the code; this area needs to be changed if
    we want SMP-safe dput().
                                                    Al, BKernelJanitorFH

    PS: Yes, NFS is the place where the latest races cropped in. Dcache ones.
    Why are you asking?

    -
    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 : Sun May 14 2000 - 04:42:00 EDT