linux-ext4 - [Bug 12224] journal activity on inactive partition causes inactive harddrive spinup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081215024735.0490F10800F@picon.linux-foundation.org>
Date:	Sun, 14 Dec 2008 18:47:34 -0800 (PST)
From:	bugme-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 12224] journal activity on inactive partition causes inactive harddrive spinup

http://bugzilla.kernel.org/show_bug.cgi?id=12224





------- Comment #5 from tytso@....edu  2008-12-14 18:47 -------
>     Activity on one partition (hda1) causes kjournald to also write
> to another partition (sda1).  This in turn causes the harddrive
> which contains sda1 to spinup or not spindown.  I've activated
> laptop-mode using laptop-mode-tools. hda1 and sda1 are both
> formatted with ext3.  On unaffected kernels (e.g. 2.6.27.5) btrace
> produces no output.  On affected kernels (e.g. 2.6.27.6, 2.6.27-rc7)
> btrace produces output as below.

I've looked at the changes between 2.6.27.5 and 2.6.27.6, and I don't
see anything that might explain such a regression.  Indeed, there's
only one patch between .5 and .6 that even touches ext3, and the patch
seems pretty innocent.

Is /dev/sda1 even mounted?  It doesn't included up in your /etc/mtab
listing.

The only thing I can suggest is to try 2.6.27.6 with the only patch
that touches ext3 reverted (i.e., unapply it with patch -R).  If the
problem still shows up, I would suggest getting the linux-2.6.27.y
tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y.git

And then doing a git bisection search to try to find the guilty
commit.

Regards,

                                        - Ted
commit a0b8bfb34743b6e6c2bb06ad5a270590d90270f7
Author: Arthur Jones <ajones@...erbed.com>
Date:   Fri Nov 7 00:05:17 2008 +0000

    ext3: wait on all pending commits in ext3_sync_fs

    commit c87591b719737b4e91eb1a9fa8fd55a4ff1886d6 upstream

    In ext3_sync_fs, we only wait for a commit to finish if we started it, but
    there may be one already in progress which will not be synced.

    In the case of a data=ordered umount with pending long symlinks which are
    delayed due to a long list of other I/O on the backing block device, this
    causes the buffer associated with the long symlinks to not be moved to the
    inode dirty list in the second phase of fsync_super.  Then, before they
    can be dirtied again, kjournald exits, seeing the UMOUNT flag and the
    dirty pages are never written to the backing block device, causing long
    symlink corruption and exposing new or previously freed block data to
    userspace.

    This can be reproduced with a script created
    by Eric Sandeen <sandeen@...hat.com>:

        #!/bin/bash

        umount /mnt/test2
        mount /dev/sdb4 /mnt/test2
        rm -f /mnt/test2/*
        dd if=/dev/zero of=/mnt/test2/bigfile bs=1M count=512
        touch
       
/mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
        ln -s
       
/mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
        /mnt/test2/link
        umount /mnt/test2
        mount /dev/sdb4 /mnt/test2
        ls /mnt/test2/
        umount /mnt/test2

    To ensure all commits are synced, we flush all journal commits now when
    sync_fs'ing ext3.

    Signed-off-by: Arthur Jones <ajones@...erbed.com>
    Cc: Eric Sandeen <sandeen@...hat.com>
    Cc: Theodore Ts'o <tytso@....edu>
    Cc: <linux-ext4@...r.kernel.org>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index f38a5af..810bf7c 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2365,13 +2365,12 @@ static void ext3_write_super (struct super_block * sb)

 static int ext3_sync_fs(struct super_block *sb, int wait)
 {
-       tid_t target;
-
        sb->s_dirt = 0;
-       if (journal_start_commit(EXT3_SB(sb)->s_journal, &target)) {
-               if (wait)
-                       log_wait_commit(EXT3_SB(sb)->s_journal, target);
-       }
+       if (wait)
+               ext3_force_commit(sb);
+       else
+               journal_start_commit(EXT3_SB(sb)->s_journal, NULL);
+
        return 0;
 }



-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html