22 Jul, 2007

1 commit


20 Jul, 2007

1 commit


17 Jul, 2007

1 commit

  • This patch adds checking for granted memory while filling up inode data to
    prevent possible NULL pointer usage. If there is not enough memory to fill
    inode data we just mark it as "bad". Also some whitespace cleanup.

    Signed-off-by: Cyrill Gorcunov
    Cc: Jan Kara
    Cc: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Cyrill Gorcunov
     

17 Jun, 2007

1 commit

  • We have to take care that when we call udf_discard_prealloc() from
    udf_clear_inode() we have to write inode ourselves afterwards (otherwise,
    some changes might be lost leading to leakage of blocks, use of free blocks
    or improperly aligned extents).

    Also udf_discard_prealloc() does two different things - it removes
    preallocated blocks and truncates the last extent to exactly match i_size.
    We move the latter functionality to udf_truncate_tail_extent(), call
    udf_discard_prealloc() when last reference to a file is dropped and call
    udf_truncate_tail_extent() when inode is being removed from inode cache
    (udf_clear_inode() call).

    We cannot call udf_truncate_tail_extent() earlier as subsequent open+write
    would find the last block of the file mapped and happily write to the end
    of it, although the last extent says it's shorter.

    [akpm@linux-foundation.org: Make checkpatch.pl happier]
    Signed-off-by: Jan Kara
    Cc: Eric Sandeen
    Cc: Cyrill Gorcunov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

01 Jun, 2007

1 commit

  • update_next_aext() could possibly rewrite values in elen and eloc, possibly
    leading to data corruption when rewriting a file. Use temporary variables
    instead. Also advance cur_epos as it can also point to an indirect extent
    pointer.

    Signed-off-by: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

09 May, 2007

4 commits

  • Make UDF work correctly for files larger than 1GB. As no extent can be
    longer than (1<
    Acked-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     
  • Make UDF use get_bh() instead of directly accessing b_count and use
    brelse() instead of udf_release_data() which does just brelse()...

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

    Jan Kara
     
  • Introduce a structure extent_position to store a position of an extent and
    the corresponding buffer_head in one place.

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

    Jan Kara
     
  • Use sector_t and loff_t for file offsets in UDF filesystem. Otherwise an
    overflow may occur for long files. Also make inode_bmap() return offset in
    the extent in number of blocks instead of number of bytes - for most
    callers this is more convenient.

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

    Jan Kara
     

01 Oct, 2006

1 commit


27 Sep, 2006

1 commit

  • This eliminates the i_blksize field from struct inode. Filesystems that want
    to provide a per-inode st_blksize can do so by providing their own getattr
    routine instead of using the generic_fillattr() function.

    Note that some filesystems were providing pretty much random (and incorrect)
    values for i_blksize.

    [bunk@stusta.de: cleanup]
    [akpm@osdl.org: generic_fillattr() fix]
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Theodore Ts'o
     

29 Jun, 2006

1 commit


02 Apr, 2006

1 commit


26 Mar, 2006

1 commit

  • As Pekka Enberg pointed out, with the if still following the else, you can
    still get a null uid written to the disk if you specify a default uid= without
    uid=forget. In other words, if the desktop user is uid=1000 and the mount
    option uid=1000 is given ( which is done on ubuntu automatically and probably
    other distributions that use hal ), then if any other user besides uid 1000
    owns a file then a 0 will be written to the media as the owning uid instead.

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Phillip Susi
     

09 Mar, 2006

1 commit

  • Fix a bug in udf where it would write uid/gid = 0 to the disk for files
    owned by the id given with the uid=/gid= mount options. It also adds 4 new
    mount options: uid/gid=forget and uid/gid=ignore. Without any options the
    id in core and on disk always match. Giving uid/gid=nnn specifies a
    default ID to be used in core when the on disk ID is -1. uid/gid=ignore
    forces the in core ID to allways be used no matter what the on disk ID is.
    uid/gid=forget forces the on disk ID to always be written out as -1.

    The use of these options allows you to override ownerships on a disk or
    disable ownwership information from being written, allowing the media to be
    used portably between different computers and possibly different users
    without permissions issues that would require root to correct.

    Signed-off-by: Phillip Susi
    Cc: Pekka Enberg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Phillip Susi
     

09 Jan, 2006

1 commit


03 Jan, 2006

1 commit


10 Sep, 2005

1 commit

  • Update the file systems in fs/ implementing a delete_inode() callback to
    call truncate_inode_pages(). One implementation note: In developing this
    patch I put the calls to truncate_inode_pages() at the very top of those
    filesystems delete_inode() callbacks in order to retain the previous
    behavior. I'm guessing that some of those could probably be optimized.

    Signed-off-by: Mark Fasheh
    Acked-by: Christoph Hellwig
    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mark Fasheh
     

01 May, 2005

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