18 Jul, 2007

1 commit

  • 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
     

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
     

29 Jun, 2006

1 commit


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
     

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