18 Jul, 2007

8 commits

  • There's a clear subfunctionality of reconnecting a given dentry to the main
    dentry tree in find_exported_dentry, that can be called both for the dentry
    we're looking for or it's parent directory.

    This patch splits the subfunctionality out into a separate helper to make the
    code more readable and document it's intent. As a nice side-optimization we
    can avoid getting a superfluous dentry reference count in the case we need to
    reconnect a directory on it's own.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Break the loop that finds the root of a disconnected subtree into a helper of
    its own to make reading easier and document the intent.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • All callers of find_acceptable_alias check if the current dentry is acceptable
    before looking for other acceptable aliases using find_acceptable_alias. Move
    the check into find_acceptable_alias to make the code a little more dense and
    add a comment to find_acceptable_alias that documents its intent.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Rework some logic in find_exported_dentry so that we only have a single
    S_ISDIR check and logic that makes clear to the reader what we're really doing
    here.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Currently exportfs uses a way to call methods very differently from the rest
    of the kernel. This patch changes it to the standard conventions for method
    calls.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Currently NFSD calls directly into filesystems through the export_operations
    structure. I plan to change this interface in various ways in later patches,
    and want to avoid the export of the default operations to NFSD, so this patch
    adds two simple exportfs_encode_fh/exportfs_decode_fh helpers for NFSD to call
    instead of poking into exportfs guts.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • When the exportfs interface was added the expectation was that filesystems
    provide an operation to convert from a file handle to an inode/dentry, but it
    kept a backwards compat option that still calls into iget.

    Calling into iget from non-filesystem code is very bad, because it gives too
    little information to filesystem, and simply crashes if the filesystem doesn't
    implement the ->read_inode routine.

    Fortunately there are only two filesystems left using this fallback: efs and
    jfs. This patch moves a copy of export_iget to each of those to implement the
    get_dentry method.

    While this is a temporary increase of lines of code in the kernel it allows
    for a much cleaner interface and important code restructuring in later
    patches.

    [akpm@linux-foundation.org: add jfs_get_inode_flags() declaration]
    Signed-off-by: Dave Kleikamp
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • currently the export_operation structure and helpers related to it are in
    fs.h. fs.h is already far too large and there are very few places needing the
    export bits, so split them off into a separate header.

    [akpm@linux-foundation.org: fix cifs build]
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Neil Brown
    Cc: Steven French
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

09 May, 2007

1 commit


03 Oct, 2006

1 commit

  • These patches make the kernel pass 64-bit inode numbers internally when
    communicating to userspace, even on a 32-bit system. They are required
    because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
    for example. The 64-bit inode numbers are then propagated to userspace
    automatically where the arch supports it.

    Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
    number returned by stat64() or getdents64() to differentiate files, and
    failing because the 64-bit inode number space was compressed to 32-bits, and
    so overlaps occur.

    This patch:

    Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
    inode number so that 64-bit inode numbers can be passed back to userspace.

    The stat functions then returns the full 64-bit inode number where
    available and where possible. If it is not possible to represent the inode
    number supplied by the filesystem in the field provided by userspace, then
    error EOVERFLOW will be issued.

    Similarly, the getdents/readdir functions now pass the full 64-bit inode
    number to userspace where possible, returning EOVERFLOW instead when a
    directory entry is encountered that can't be properly represented.

    Note that this means that some inodes will not be stat'able on a 32-bit
    system with old libraries where they were before - but it does mean that
    there will be no ambiguity over what a 32-bit inode number refers to.

    Note similarly that directory scans may be cut short with an error on a
    32-bit system with old libraries where the scan would work before for the
    same reasons.

    It is judged unlikely that this situation will occur because modern glibc
    uses 64-bit capable versions of stat and getdents class functions
    exclusively, and that older systems are unlikely to encounter
    unrepresentable inode numbers anyway.

    [akpm: alpha build fix]
    Signed-off-by: David Howells
    Cc: Trond Myklebust
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

22 May, 2006

1 commit

  • Address a problem found when a Linux NFS server uses the "subtree_check"
    export option.

    The "subtree_check" NFS export option was designed to prohibit a client
    from using a file handle for which it should not have permission. The
    algorithm used is to ensure that the entire path to the file being
    referenced is accessible to the user attempting to use the file handle. If
    some part of the path is not accessible, then the operation is aborted and
    the appropriate version of ESTALE is returned to the NFS client.

    The error, ESTALE, is unfortunate in that it causes NFS clients to make
    certain assumptions about the continued existence of the file. They assume
    that the file no longer exists and refuse to attempt to access it again.
    In this case, the file really does exist, but access was denied by the
    server for a particular user.

    A better error to return would be an EACCES sort of error. This would
    inform the client that the particular operation that it was attempting was
    not allowed, without the nasty side effects of the ESTALE error.

    Signed-off-by: Peter Staubach
    Acked-By: NeilBrown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Staubach
     

19 Jan, 2006

1 commit

  • find_exported_dentry contains two duplicate loops to find an alias that the
    acceptable callback likes. Split this out to a new helper and switch from
    list_for_each to list_for_each_entry to make it more readable.

    Signed-off-by: Christoph Hellwig
    Acked-by: NeilBrown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

10 Jan, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds