02 Nov, 2011

1 commit


23 Jul, 2011

1 commit

  • sbi->s_mutex isn't needed for isofs at all so we can just remove it. Generally,
    since isofs is always mounted read-only, filesystem structure cannot change
    under us. So buffer_head contents stays constant after it's filled in. That
    leaves us with possible changes of global data structures. Superblock changes
    only during filesystem mount (even remount does not change it), inodes are only
    filled in during reading from disk. So there are no changes of these structures
    to bother about.

    Arguments why sbi->s_mutex can be removed at each place:
    isofs_readdir: Accesses sb, inode, filp, local variables => s_mutex not needed
    isofs_lookup: Protected by directory's i_mutex. Accesses sb, inode, dentry,
    local variables => s_mutex not needed
    rock_ridge_symlink_readpage: Protected by page lock. Accesses sb, inode,
    local variables => s_mutex not needed.

    Signed-off-by: Jan Kara
    Signed-off-by: Al Viro

    Jan Kara
     

05 Oct, 2010

1 commit

  • As in other file systems, we can replace the big kernel lock
    with a private mutex in isofs. This means we can now access
    multiple file systems concurrently, but it also means that
    we serialize readdir and lookup across sleeping operations
    which previously released the big kernel lock. This should
    not matter though, as these operations are in practice
    serialized through the hardware access.

    The isofs_get_blocks functions now does not take any lock
    any more, it used to recursively get the BKL. After looking
    at the code for hours, I convinced myself that it was never
    needed here anyway, because it only reads constant fields
    of the inode and writes to a buffer head array that is
    at this time only visible to the caller.

    The get_sb and fill_super operations do not need the locking
    at all because they operate on a file system that is either
    about to be created or to be destroyed but in either case
    is not visible to other threads.

    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

10 Dec, 2009

1 commit


26 Jul, 2008

1 commit

  • Some iso9660 images contain files with rockridge data that is either
    incorrect or incompletely parsed. Prior to commit
    f2966632a134e865db3c819346a1dc7d96e05309 ("[PATCH] rock: handle directory
    overflows") (included with kernel 2.6.13) the kernel ignored the rockridge
    data for these files, while still allowing the files to be accessed under
    their non-rockridge names. That commit inadvertently changed things so
    that files with invalid rockridge data could not be accessed at all. (I
    ran across the problem when comparing some old CDs with hard disk copies I
    had made long ago under kernel 2.4: a few of the files on the hard disk
    copies were no longer visible on the CDs.)

    This change reverts to the pre-2.6.13 behavior.

    Signed-off-by: Adam Greenblatt
    Reviewed-by: Pekka Enberg
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adam Greenblatt
     

08 Feb, 2008

1 commit

  • Stop the ISOFS filesystem from using read_inode(). Make isofs_read_inode()
    return an error code, and make isofs_iget() pass it on.

    Signed-off-by: David Howells
    Cc: Jan Kara
    Acked-by: Christoph Hellwig
    Cc: "Dave Young"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

29 Jun, 2006

1 commit


22 Jun, 2005

10 commits


26 Apr, 2005

1 commit

  • fs/isofs includes trimmed down to something resembling sanity.

    Kernel-only parts of linux/iso_fs.h and entire linux/iso_fs_{sb,i}.h
    moved to fs/isofs/isofs.h.

    A lot of useless #include in fs/isofs/*.c killed.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

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