Message-Id: <20080807105251.bf28cbd0.akpm@linux-foundation.org>
Date:	Thu, 7 Aug 2008 10:52:51 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	sliedes@...hut.fi
Cc:	bugme-daemon@...zilla.kernel.org, linux-ext4@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: [Bugme-new] [Bug 11266] New: unable to handle kernel paging
 request in ext2_free_blocks


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu,  7 Aug 2008 05:53:37 -0700 (PDT) bugme-daemon@...zilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11266
> 
>            Summary: unable to handle kernel paging request in
>                     ext2_free_blocks
>            Product: File System
>            Version: 2.5
>      KernelVersion: 2.6.27-rc2 + patch for #10976 (now in -mm)
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: ext2
>         AssignedTo: akpm@...l.org
>         ReportedBy: sliedes@...hut.fi
> 
> 
> Latest working kernel version: (I think at least 2.6.25.4 works)
> Earliest failing kernel version:
> Distribution: Minimal Debian sid (unstable)
> Hardware Environment: qemu x86
> Software Environment:
> Problem Description:
> 
> Mere rm -rf after mounting on an intentionally corrupted partition occasionally
> causes "BUG: unable to handle kernel paging request" in ext2_free_blocks. 
> 
> Unfortunately the issue seems to be timing sensitive (or something), doing it
> on the same filesystem only sometimes results in the crash :( But I have
> reproduced it something like 6 times now with brief testing.
> 
> If you wish, I can attach some filesystems with which I have been able to
> reproduce this at least once.
> 
> Another thing I could do is take a look at it with the new kernel debugger
> (which I haven't tried yet) if none of you are able to figure out this from the
> traces. Is there something you would specifically want me to take a look at?
> The local and referenced variables at ext2_free_blocks(), I guess?
> 
> I think I ran quite extensive tests on 2.6.25.4 & ext2, so I suspect (but am
> not sure, I've made some changes to the way I test) this bug is newer than
> 2.6.25.4. I could do some bisecting too, but I haven't managed to automate the
> thing yet.
> 
> Here's a script I run under qemu, google for zzuf (it's a fuzzer), and timeout
> is from the Debian package `timeout':
> 
> ----------
> #!/bin/sh
> 
> if [ "`hostname`" != "fstest" ]; then
>    echo "This is a dangerous script."
>    echo "Set your hostname to \`fstest\' if you want to use it."
>    exit 1
> fi
> 
> umount /dev/hdb
> umount /dev/hdc
> /etc/init.d/sysklogd stop
> /etc/init.d/klogd stop
> /etc/init.d/cron stop
> mount /dev/hda / -t ext3 -o remount,ro || exit 1
> 
> ulimit -t 20
> 
> for ((s=$1; s<1000000000; s++)); do
>   umount /mnt
>   echo '***** zzuffing *****' seed $s
>   zzuf -r 0:0.03 -s $s </dev/hdc >/dev/hdb || exit
>   mount /dev/hdb /mnt -o errors=continue || continue
>   cd /mnt || continue
>   cp -r doc doc2 >&/dev/null
>   find -xdev >&/dev/null
>   find -xdev -print0 2>/dev/null |xargs -0 touch -- 2>/dev/null
>   mkdir tmp >&/dev/null
>   echo whoah >tmp/filu 2>/dev/null
>   rm -rf /mnt/* >&/dev/null
>   cd /
> done
> ----------
> 
> The attached backtraces all start from the time of mounting the filesystem.
> 

Yes, please do test 2.6.26.

Aneesh, your recent changes to the ext2 block allocator would have to
be prime suspects here.

--
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

Powered by blists - more mailing lists