Eric Lee / smarc-fsl-linux-kernel

30 Mar, 2010

1 commit

  • de329820e   ext3: fix broken handling of EXT3_STATE_NEW ... Browse Code »

    In commit 9df93939b735 ("ext3: Use bitops to read/modify
    EXT3_I(inode)->i_state") ext3 changed its internal 'i_state' variable to
    use bitops for its state handling. However, unline the same ext4
    change, it didn't actually change the name of the field when it changed
    the semantics of it.

    As a result, an old use of 'i_state' remained in fs/ext3/ialloc.c that
    initialized the field to EXT3_STATE_NEW. And that does not work
    _at_all_ when we're now working with individually named bits rather than
    values that get masked. So the code tried to mark the state to be new,
    but in actual fact set the field to EXT3_STATE_JDATA. Which makes no
    sense at all, and screws up all the code that checks whether the inode
    was newly allocated.

    In particular, it made the xattr code unhappy, and caused various random
    behavior, like apparently

    https://bugzilla.redhat.com/show_bug.cgi?id=577911

    So fix the initialization, and rename the field to match ext4 so that we
    don't have this happen again.

    Cc: James Morris
    Cc: Stephen Smalley
    Cc: Daniel J Walsh
    Cc: Eric Paris
    Cc: Jan Kara
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Mar, 2010

1 commit

  • 9df93939b   ext3: Use bitops to read/modify EXT3_I(inode)->i_state ... Browse Code »

    At several places we modify EXT3_I(inode)->i_state without holding i_mutex
    (ext3_release_file, ext3_bmap, ext3_journalled_writepage, ext3_do_update_inode,
    ...). These modifications are racy and we can lose updates to i_state. So
    convert handling of i_state to use bitops which are atomic.

    Signed-off-by: Jan Kara

    Jan Kara
     

11 Nov, 2009

1 commit

  • fe8bc91c4   ext3: Wait for proper transaction commit on fsync ... Browse Code »

    We cannot rely on buffer dirty bits during fsync because pdflush can come
    before fsync is called and clear dirty bits without forcing a transaction
    commit. What we do is that we track which transaction has last changed
    the inode and which transaction last changed allocation and force it to
    disk on fsync.

    Signed-off-by: Jan Kara
    Reviewed-by: Aneesh Kumar K.V

    Jan Kara
     

24 Jun, 2009

1 commit

09 May, 2007

1 commit

27 Sep, 2006

1 commit

26 Jun, 2006

2 commits

  • 43d23f903   [PATCH] ext3_fsblk_t: the rest of in-kernel filesystem blocks conversion ... Browse Code »

    Convert the ext3 in-kernel filesystem blocks to ext3_fsblk_t. Convert the
    rest of all unsigned long type in-kernel filesystem blocks to ext3_fsblk_t,
    and replace the printk format string respondingly.

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

    Mingming Cao
     
  • 1c2bf374a   [PATCH] ext3_fsblk_t: filesystem, group blocks and bug fixes ... Browse Code »

    Some of the in-kernel ext3 block variable type are treated as signed 4 bytes
    int type, thus limited ext3 filesystem to 8TB (4kblock size based). While
    trying to fix them, it seems quite confusing in the ext3 code where some
    blocks are filesystem-wide blocks, some are group relative offsets that need
    to be signed value (as -1 has special meaning). So it seem saner to define
    two types of physical blocks: one is filesystem wide blocks, another is
    group-relative blocks. The following patches clarify these two types of
    blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3
    filesystem limit to 8TB.

    With this series of patches and the percpu counter data type changes in the mm
    tree, we are able to extend exts filesystem limit to 16TB.

    This work is also a pre-request for the recent >32 bit ext3 work, and makes
    the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine
    ext3_fsblk_t from unsigned long to sector_t and redefine the format string for
    ext3 filesystem block corresponding.

    Two RFC with a series patches have been posted to ext2-devel list and have
    been reviewed and discussed:
    http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2

    http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2

    Patches are tested on both 32 bit machine and 64 bit machine, 8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39). Tests
    includes overnight fsx, tiobench, dbench and fsstress.

    This patch:

    Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for
    filesystem wide blocks.

    This patch classifies all block group relative blocks, and ext3_fsblk_t blocks
    occurs in the same function where used to be confusing before. Also include
    kernel bug fixes for filesystem wide in-kernel block variables. There are
    some fileystem wide blocks are treated as int/unsigned int type in the kernel
    currently, especially in ext3 block allocation and reservation code. This
    patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned
    long) type.

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

    Mingming Cao
     

23 Mar, 2006

1 commit

10 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