Eric Lee / smarc-fsl-linux-kernel

10 Jan, 2012

1 commit

  • ac69e0928   Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs ... Browse Code »

    * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
    ext2/3/4: delete unneeded includes of module.h
    ext{3,4}: Fix potential race when setversion ioctl updates inode
    udf: Mark LVID buffer as uptodate before marking it dirty
    ext3: Don't warn from writepage when readonly inode is spotted after error
    jbd: Remove j_barrier mutex
    reiserfs: Force inode evictions before umount to avoid crash
    reiserfs: Fix quota mount option parsing
    udf: Treat symlink component of type 2 as /
    udf: Fix deadlock when converting file from in-ICB one to normal one
    udf: Cleanup calling convention of inode_getblk()
    ext2: Fix error handling on inode bitmap corruption
    ext3: Fix error handling on inode bitmap corruption
    ext3: replace ll_rw_block with other functions
    ext3: NULL dereference in ext3_evict_inode()
    jbd: clear revoked flag on buffers before a new transaction started
    ext3: call ext3_mark_recovery_complete() when recovery is really needed

    Linus Torvalds
     

09 Jan, 2012

1 commit

  • 6c2155b9c   ext{3,4}: Fix potential race when setversion ioctl updates inode ... Browse Code »

    The EXT{3,4}_IOC_SETVERSION ioctl() updates i_ctime and i_generation
    without i_mutex. This can lead to a race with the other operations that
    update i_ctime. This is not a big issue but let's make the ioctl consistent
    with how we handle e.g. other timestamp updates and use i_mutex to protect
    inode changes.

    Signed-off-by: Djalal Harouni
    Signed-off-by: Jan Kara

    Djalal Harouni
     

04 Jan, 2012

2 commits

11 Oct, 2011

1 commit

25 Jun, 2011

1 commit

24 Mar, 2011

1 commit

11 Jan, 2011

1 commit

  • 9c5274923   ext3: Add FITRIM handling ... Browse Code »

    The ioctl takes fstrim_range structure (defined in include/linux/fs.h) as an
    argument specifying a range of filesystem to trim and the minimum size of an
    continguous extent to trim. After the FITRIM is done, the number of bytes
    passed from the filesystem down the block stack to the device for potential
    discard is stored in fstrim_range.len. This number is a maximum discard amount
    from the storage device's perspective, because FITRIM called repeatedly will
    keep sending the same sectors for discard. fstrim_range.len will report the
    same potential discard bytes each time, but only sectors which had been written
    to between the discards would actually be discarded by the storage device.
    Further, the kernel block layer reserves the right to adjust the discard ranges
    to fit raid stripe geometry, non-trim capable devices in a LVM setup, etc.
    These reductions would not be reflected in fstrim_range.len.

    Thus fstrim_range.len can give the user better insight on how much storage
    space has potentially been released for wear-leveling, but it needs to be one
    of only one criteria the userspace tools take into account when trying to
    optimize calls to FITRIM.

    Thanks to Greg Freemyer for better commit message.

    Signed-off-by: Lukas Czerner
    Signed-off-by: Jan Kara

    Lukas Czerner
     

03 Apr, 2009

1 commit

09 Jan, 2009

1 commit

  • 04143e2fb   ext3: tighten restrictions on inode flags ... Browse Code »

    At the moment there are few restrictions on which flags may be set on
    which inodes. Specifically DIRSYNC may only be set on directories and
    IMMUTABLE and APPEND may not be set on links. Tighten that to disallow
    TOPDIR being set on non-directories and only NODUMP and NOATIME to be set
    on non-regular file, non-directories.

    Introduces a flags masking function which masks flags based on mode and
    use it during inode creation and when flags are set via the ioctl to
    facilitate future consistency.

    Signed-off-by: Duane Griffin
    Acked-by: Andreas Dilger
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Duane Griffin
     

23 Oct, 2008

1 commit

  • 2d7c820e5   ext3: add checks for errors from jbd ... Browse Code »

    If the journal has aborted due to a checkpointing failure, we have to
    keep the contents of the journal space. Otherwise, the filesystem will
    lose uncheckpointed metadata completely and become inconsistent. To
    avoid this, we need to keep needs_recovery flag if checkpoint has
    failed.

    With this patch, ext3_put_super() detects a checkpointing failure from
    the return value of journal_destroy(), then it invokes ext3_abort() to
    make the filesystem read only and keep needs_recovery flag. Errors
    from journal_flush() are also handled by this patch in some places.

    Signed-off-by: Hidehiro Kawai
    Cc: Jan Kara
    Cc: Stephen Rothwell
    Cc: Al Viro
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hidehiro Kawai
     

19 Apr, 2008

1 commit

15 Nov, 2007

1 commit

  • e47776a0a   Forbid user to change file flags on quota files ... Browse Code »

    Forbid user from changing file flags on quota files. User has no bussiness
    in playing with these flags when quota is on. Furthermore there is a
    remote possibility of deadlock due to a lock inversion between quota file's
    i_mutex and transaction's start (i_mutex for quota file is locked only when
    trasaction is started in quota operations) in ext3 and ext4.

    Signed-off-by: Jan Kara
    Cc: LIOU Payphone
    Cc:
    Acked-by: Dave Kleikamp
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

18 Jul, 2007

1 commit

  • 3bd858ab1   Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check ... Browse Code »

    Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
    users to it. This is done because we want to avoid bugs in the future
    where we check for only effective fsuid of the current task against a
    file's owning uid, without simultaneously checking for CAP_FOWNER as
    well, thus violating its semantics.
    [ XFS uses special macros and structures, and in general looked ...
    untouchable, so we leave it alone -- but it has been looked over. ]

    The (current->fsuid != inode->i_uid) check in generic_permission() and
    exec_permission_lite() is left alone, because those operations are
    covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
    falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.

    Signed-off-by: Satyam Sharma
    Cc: Al Viro
    Acked-by: Serge E. Hallyn
    Signed-off-by: Linus Torvalds

    Satyam Sharma
     

09 May, 2007

1 commit

  • 28be5abb4   ext3: copy i_flags to inode flags on write ... Browse Code »

    A patch that stores inode flags such as S_IMMUTABLE, S_APPEND, etc. from
    i_flags to EXT3_I(inode)->i_flags when inode is written to disk. The same
    thing is done on GETFLAGS ioctl.

    Quota code changes these flags on quota files (to make it harder for
    sysadmin to screw himself) and these changes were not correctly propagated
    into the filesystem (especially, lsattr did not show them and users were
    wondering...).

    Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into
    ext3-specific i_flags. Hence, when someone sets these flags via a
    different interface than ioctl, they are stored correctly.

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

    Jan Kara
     

09 Dec, 2006

1 commit

01 Oct, 2006

1 commit

26 Jun, 2006

1 commit

26 Apr, 2006

1 commit

23 Mar, 2006

1 commit

12 Jan, 2006

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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