31 Mar, 2011

1 commit


22 Oct, 2010

1 commit

  • All uses of the BKL in freevxfs were the result of a pushdown into
    code that doesn't really need it. As Christoph points out, this
    is a read-only file system, which eliminates most of the races in
    readdir/lookup.

    Signed-off-by: Arnd Bergmann
    Cc: Christoph Hellwig

    Arnd Bergmann
     

28 May, 2010

1 commit

  • Do not use the fallback default_llseek() if the readdir operation of the
    filesystem still uses the big kernel lock.

    Since llseek() modifies
    file->f_pos of the directory directly it may need locking to not confuse
    readdir which usually uses file->f_pos directly as well

    Since the special characteristics of the BKL (unlocked on schedule) are
    not necessary in this case, the inode mutex can be used for locking as
    provided by generic_file_llseek(). This is only possible since all
    filesystems, except reiserfs, either use a directory as a flat file or
    with disk address offsets. Reiserfs on the other hand uses a 32bit hash
    off the filename as the offset so generic_file_llseek() can get used as
    well since the hash is always smaller than sb->s_maxbytes (= (512 << 32) -
    blocksize).

    Signed-off-by: Jan Blunck
    Acked-by: Jan Kara
    Acked-by: Anders Larsen
    Cc: Frederic Weisbecker
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    jan Blunck
     

08 Feb, 2008

1 commit

  • Stop the FreeVXFS filesystem from using iget() and read_inode(). Replace
    vxfs_read_inode() with vxfs_iget(), and call that instead of iget().
    vxfs_iget() then uses iget_locked() directly and returns a proper error code
    instead of an inode in the event of an error.

    vxfs_fill_super() returns any error incurred when getting the root inode
    instead of EINVAL.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: David Howells
    Acked-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

13 Feb, 2007

1 commit

  • Many struct inode_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

09 Dec, 2006

1 commit


01 Aug, 2006

1 commit

  • Commit 7b2fd697427e73c81d5fa659efd91bd07d303b0e in the historical GIT tree
    stopped calling the readdir member of a file_operations struct with the big
    kernel lock held, and fixed up all the readdir functions to do their own
    locking. However, that change added calls to unlock_kernel() in
    vxfs_readdir, but no call to lock_kernel(). Fix this by adding a call to
    lock_kernel().

    Signed-off-by: Josh Triplett
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     

29 Mar, 2006

1 commit

  • This is a conversion to make the various file_operations structs in fs/
    const. Basically a regexp job, with a few manual fixups

    The goal is both to increase correctness (harder to accidentally write to
    shared datastructures) and reducing the false sharing of cachelines with
    things that get dirty in .data (while .rodata is nicely read only and thus
    cache clean)

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

30 Jun, 2005

1 commit

  • This patch addresses the following minor issues:

    - Typo in printk
    - Redundant casts
    - Use C99 struct initializers instead of memset
    - Parenthesis around return value
    - Use inline instead of __inline__

    Signed-off-by: Pekka Enberg
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     

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