Eric Lee / smarc-fsl-linux-kernel

02 Nov, 2011

1 commit

19 Dec, 2010

1 commit

15 Jun, 2010

1 commit

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

11 Oct, 2008

1 commit

  • 44519faf2   jbd2: fix error handling for checkpoint io ... Browse Code »

    When a checkpointing IO fails, current JBD2 code doesn't check the
    error and continue journaling. This means latest metadata can be
    lost from both the journal and filesystem.

    This patch leaves the failed metadata blocks in the journal space
    and aborts journaling in the case of jbd2_log_do_checkpoint().
    To achieve this, we need to do:

    1. don't remove the failed buffer from the checkpoint list where in
    the case of __try_to_free_cp_buf() because it may be released or
    overwritten by a later transaction
    2. jbd2_log_do_checkpoint() is the last chance, remove the failed
    buffer from the checkpoint list and abort the journal
    3. when checkpointing fails, don't update the journal super block to
    prevent the journaled contents from being cleaned. For safety,
    don't update j_tail and j_tail_sequence either
    4. when checkpointing fails, notify this error to the ext4 layer so
    that ext4 don't clear the needs_recovery flag, otherwise the
    journaled contents are ignored and cleaned in the recovery phase
    5. if the recovery fails, keep the needs_recovery flag
    6. prevent jbd2_cleanup_journal_tail() from being called between
    __jbd2_journal_drop_transaction() and jbd2_journal_abort()
    (a possible race issue between jbd2_log_do_checkpoint()s called by
    jbd2_journal_flush() and __jbd2_log_wait_for_space())

    Signed-off-by: Hidehiro Kawai
    Signed-off-by: Theodore Ts'o

    Hidehiro Kawai
     

07 Jun, 2008

1 commit

26 May, 2008

1 commit

20 Mar, 2008

1 commit

  • d00256766   jbd2: correctly unescape journal data blocks ... Browse Code »

    Fix a long-standing typo (predating git) that will cause data corruption if a
    journal data block needs unescaping. At the moment the wrong buffer head's
    data is being unescaped.

    To test this case mount a filesystem with data=journal, start creating and
    deleting a bunch of files containing only JBD2_MAGIC_NUMBER (0xc03b3998), then
    pull the plug on the device. Without this patch the files will contain zeros
    instead of the correct data after recovery.

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

    Duane Griffin
     

07 Feb, 2008

1 commit

05 Feb, 2008

1 commit

29 Jan, 2008

1 commit

  • 818d276ce   ext4: Add the journal checksum feature ... Browse Code »

    The journal checksum feature adds two new flags i.e
    JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT and JBD2_FEATURE_COMPAT_CHECKSUM.

    JBD2_FEATURE_CHECKSUM flag indicates that the commit block contains the
    checksum for the blocks described by the descriptor blocks.
    Due to checksums, writing of the commit record no longer needs to be
    synchronous. Now commit record can be sent to disk without waiting for
    descriptor blocks to be written to disk. This behavior is controlled
    using JBD2_FEATURE_ASYNC_COMMIT flag. Older kernels/e2fsck should not be
    able to recover the journal with _ASYNC_COMMIT hence it is made
    incompat.
    The commit header has been extended to hold the checksum along with the
    type of the checksum.

    For recovery in pass scan checksums are verified to ensure the sanity
    and completeness(in case of _ASYNC_COMMIT) of every transaction.

    Signed-off-by: Andreas Dilger
    Signed-off-by: Girish Shilamkar
    Signed-off-by: Dave Kleikamp
    Signed-off-by: Mingming Cao

    Girish Shilamkar
     

18 Oct, 2007

1 commit

20 Jul, 2007

1 commit

  • b38bd33a6   fix ext4/JBD2 build warnings ... Browse Code »

    Looking at the current linus-git tree jbd_debug() define in
    include/linux/jbd2.h

    extern u8 journal_enable_debug;

    #define jbd_debug(n, f, a...) \
    do { \
    if ((n) fs/ext4/inode.c: In function ‘ext4_write_inode’:
    > fs/ext4/inode.c:2906: warning: comparison is always true due to limited
    > range of data type
    >
    > fs/jbd2/recovery.c: In function ‘jbd2_journal_recover’:
    > fs/jbd2/recovery.c:254: warning: comparison is always true due to
    > limited range of data type
    > fs/jbd2/recovery.c:257: warning: comparison is always true due to
    > limited range of data type
    >
    > fs/jbd2/recovery.c: In function ‘jbd2_journal_skip_recovery’:
    > fs/jbd2/recovery.c:301: warning: comparison is always true due to
    > limited range of data type
    >
    Noticed all warnings are occurs when the debug level is 0. Then found
    the "jbd2: Move jbd2-debug file to debugfs" patch
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0f49d5d019afa4e94253bfc92f0daca3badb990b

    changed the jbd2_journal_enable_debug from int type to u8, makes the
    jbd_debug comparision is always true when the debugging level is 0. Thus
    the compile warning occurs.

    Thought about changing the jbd2_journal_enable_debug data type back to
    int, but can't, because the jbd2-debug is moved to debug fs, where
    calling debugfs_create_u8() to create the debugfs entry needs the value
    to be u8 type.

    Even if we changed the data type back to int, the code is still buggy,
    kernel should not print jbd2 debug message if the
    jbd2_journal_enable_debug is set to 0. But this is not the case.

    The fix is change the level of debugging to 1. The same should fixed in
    ext3/JBD, but currently ext3 jbd-debug via /proc fs is broken, so we
    probably should fix it all together.

    Signed-off-by: Mingming Cao
    Cc: Jeff Garzik
    Cc: Theodore Tso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     

18 Jul, 2007

1 commit

09 May, 2007

1 commit

12 Oct, 2006

5 commits