10 Aug, 2010

1 commit

  • Using:

    gcc (GCC) 4.5.0 20100610 (prerelease)

    The following warnings appear:

    fs/readdir.c: In function `filldir64':
    fs/readdir.c:240:15: warning: `dirent' is used uninitialized in this function
    fs/readdir.c: In function `filldir':
    fs/readdir.c:155:15: warning: `dirent' is used uninitialized in this function
    fs/compat.c: In function `compat_filldir64':
    fs/compat.c:1071:11: warning: `dirent' is used uninitialized in this function
    fs/compat.c: In function `compat_filldir':
    fs/compat.c:984:15: warning: `dirent' is used uninitialized in this function

    The warnings are related to the use of the NAME_OFFSET() macro. Luckily,
    it appears as though the standard offsetof() macro is what is being
    implemented by NAME_OFFSET(), thus we can fix the warning and use a more
    standard code construct at the same time.

    Signed-off-by: Kevin Winchester
    Cc: Al Viro
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kevin Winchester
     

14 Jan, 2009

3 commits


23 Oct, 2008

1 commit


25 Aug, 2008

1 commit


07 Dec, 2007

1 commit


09 May, 2007

2 commits


09 Dec, 2006

1 commit

  • This patch changes struct file to use struct path instead of having
    independent pointers to struct dentry and struct vfsmount, and converts all
    users of f_{dentry,vfsmnt} in fs/ to use f_path.{dentry,mnt}.

    Additionally, it adds two #define's to make the transition easier for users of
    the f_dentry and f_vfsmnt.

    Signed-off-by: Josef "Jeff" Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef "Jeff" Sipek
     

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
     

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