18 Oct, 2007

6 commits


20 Jul, 2007

2 commits

  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    This rips out support for the dtor pointer from kmem_cache_create()
    completely and fixes up every single callsite in the kernel (there were
    about 224, not including the slab allocator definitions themselves,
    or the documentation references).

    Signed-off-by: Paul Mundt

    Paul Mundt
     
  • 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

2 commits

  • The jbd2-debug file used to be located in /proc/sys/fs/jbd2-debug, but it
    incorrectly used create_proc_entry() instead of the sysctl routines, and
    no proc entry was ever created.

    Instead of fixing this we might as well move the jbd2-debug file to
    debugfs which would be the preferred location for this kind of tunable.
    The new location is now /sys/kernel/debug/jbd2/jbd2-debug.

    Signed-off-by: Jose R. Santos
    Signed-off-by: "Theodore Ts'o"

    Jose R. Santos
     
  • When the JBD code was forked to create the new JBD2 code base, the
    references to CONFIG_JBD_DEBUG where never changed to
    CONFIG_JBD2_DEBUG. This patch fixes that.

    Signed-off-by: Jose R. Santos
    Signed-off-by: "Theodore Ts'o"

    Jose R. Santos
     

17 Jul, 2007

2 commits

  • Replace (n & (n-1)) in the context of power of 2 checks with
    is_power_of_2().

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

    vignesh babu
     
  • We have to check that also the second checkpoint list is non-empty before
    dropping the transaction.

    Signed-off-by: Jan Kara
    Cc: Chuck Ebbert
    Cc: Kirill Korotaev
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

09 May, 2007

3 commits


08 Dec, 2006

4 commits

  • In the current jbd code, if a buffer on BJ_SyncData list is dirty and not
    locked, the buffer is refiled to BJ_Locked list, submitted to the IO and
    waited for IO completion.

    But the fsstress test showed the case that when a buffer was already
    submitted to the IO just before the buffer_dirty(bh) check, the buffer was
    not waited for IO completion.

    Following patch solves this problem. If it is assumed that a buffer is
    submitted to the IO before the buffer_dirty(bh) check and still being
    written to disk, this buffer is refiled to BJ_Locked list.

    Signed-off-by: Hisashi Hifumi
    Cc: Jan Kara
    Cc: "Stephen C. Tweedie"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hisashi Hifumi
     
  • Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     
  • Move process freezing functions from include/linux/sched.h to freezer.h, so
    that modifications to the freezer or the kernel configuration don't require
    recompiling just about everything.

    [akpm@osdl.org: fix ueagle driver]
    Signed-off-by: Nigel Cunningham
    Cc: "Rafael J. Wysocki"
    Cc: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nigel Cunningham
     
  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

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

    Christoph Lameter
     

29 Oct, 2006

1 commit

  • When running several fsx's and other filesystem stress tests, we found
    cases where an unmapped buffer was still being sent to submit_bh by the
    ext3 dirty data journaling code.

    I saw this happen in two ways, both related to another thread doing a
    truncate which would unmap the buffer in question.

    Either we would get into journal_dirty_data with a bh which was already
    unmapped (although journal_dirty_data_fn had checked for this earlier, the
    state was not locked at that point), or it would get unmapped in the middle
    of journal_dirty_data when we dropped locks to call sync_dirty_buffer.

    By re-checking for mapped state after we've acquired the bh state lock, we
    should avoid these races. If we find a buffer which is no longer mapped,
    we essentially ignore it, because journal_unmap_buffer has already decided
    that this buffer can go away.

    I've also added tracepoints in these two cases, and made a couple other
    tracepoint changes that I found useful in debugging this.

    Signed-off-by: Eric Sandeen
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sandeen
     

21 Oct, 2006

1 commit

  • A disk generated some I/O error, after it, I hitted
    J_ASSERT(transaction->t_updates > 0) in journal_stop().

    It seems to happened on ext3_truncate() path from stack trace. Then,
    maybe the following case may trigger J_ASSERT(transaction->t_updates > 0).

    ext3_truncate()
    -> ext3_free_branches()
    -> ext3_journal_test_restart()
    -> ext3_journal_restart()
    -> journal_restart()
    transaction->t_updates--;
    /* another process aborted journal */
    -> start_this_handle()
    returns -EROFS without transaction->t_updates++;

    -> ext3_journal_stop()
    -> journal_stop()
    J_ASSERT(transaction->t_updates > 0)

    If journal was aborted in middle of journal_restart(), ext3_truncate()
    may trigger J_ASSERT().

    Signed-off-by: OGAWA Hirofumi
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

17 Oct, 2006

1 commit

  • This is Eric Sesterhenn's jbd patch applied to jbd2.
    Commit: 41716c7c21b15e7ecf14f0caf1eef3980707fb74

    His words:

    Since commit d1807793e1e7e502e3dc047115e9dbc3b50e4534 we dereference a NULL
    pointer. Coverity id #1432. We set journal to NULL, and use it directly
    afterwards.

    Signed-off-by: Dave Kleikamp
    Cc: Eric Sesterhenn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Kleikamp
     

12 Oct, 2006

6 commits