| 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
| ||
|
Message-ID: <20111213173542.GH11747@quack.suse.cz> Date: Tue, 13 Dec 2011 18:35:42 +0100 From: Jan Kara <jack@...e.cz> To: Witold Baryluk <baryluk@....if.uj.edu.pl> Cc: "Rafael J. Wysocki" <rjw@...k.pl>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Kernel Testers List <kernel-testers@...r.kernel.org>, Maciej Rutecki <maciej.rutecki@...il.com>, Florian Mickler <florian@...kler.org>, linux-ext4@...r.kernel.org, Andreas Dilger <adilger.kernel@...ger.ca>, Theodore Ts'o <tytso@....edu> Subject: Re: [Bug #39732] JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash. Hi, On Tue 13-12-11 05:11:44, Witold Baryluk wrote: > On 08-28 21:01, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.39 and 3.0. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.39 and 3.0. Please verify if it still should > > be listed and let the tracking team know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=39732 > > Subject : JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 2512725). There's a risk of filesystem corruption in case of system crash. > > Submitter : Witold Baryluk <baryluk@....if.uj.edu.pl> > > Date : 2011-07-22 04:22 (38 days old) > > This bug still exists in 3.1.0 and 3.2.0-rc5 > > I spoted it again few days ago, because I moved from me laptop with 2GB > to temporary desktop with 256MB of RAM, and not it > triggers like a mad. > > So my initial suspicious that it only shows up on big memory > presure was correct. > > > It is just like this > # dmesg | grep dirty > [122647.953872] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1019852). There's a risk of filesystem corruption in case of system crash. > [122647.954598] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1043195). There's a risk of filesystem corruption in case of system crash. > [122647.955213] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1043197). There's a risk of filesystem corruption in case of system crash. > [122689.978864] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 498559). There's a risk of filesystem corruption in case of system crash. > [122705.485461] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 68282). There's a risk of filesystem corruption in case of system crash. > [122705.486046] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 68284). There's a risk of filesystem corruption in case of system crash. > [122705.496916] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 68365). There's a risk of filesystem corruption in case of system crash. > [122705.612423] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 69218). There's a risk of filesystem corruption in case of system crash. > [122706.531297] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 833896). There's a risk of filesystem corruption in case of system crash. > [122720.863807] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 914979). There's a risk of filesystem corruption in case of system crash. > [122721.046789] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 890090). There's a risk of filesystem corruption in case of system crash. > [122721.088280] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 916474). There's a risk of filesystem corruption in case of system crash. > [122721.176979] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 928182). There's a risk of filesystem corruption in case of system crash. > [122721.177593] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 927783). There's a risk of filesystem corruption in case of system crash. > [122721.371654] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 920655). There's a risk of filesystem corruption in case of system crash. > [122721.543676] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 967035). There's a risk of filesystem corruption in case of system crash. > [122728.396687] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1043474). There's a risk of filesystem corruption in case of system crash. > [122736.283876] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 713478). There's a risk of filesystem corruption in case of system crash. > [122743.576350] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 745551). There's a risk of filesystem corruption in case of system crash. > [122743.889259] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 828117). There's a risk of filesystem corruption in case of system crash. > [122752.077022] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 905082). There's a risk of filesystem corruption in case of system crash. > [122752.125005] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 905294). There's a risk of filesystem corruption in case of system crash. > [122752.784390] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1030306). There's a risk of filesystem corruption in case of system crash. > [122752.785053] JBD: Spotted dirty metadata buffer (dev = dm-3, blocknr = 1031593). There's a risk of filesystem corruption in case of system crash. > # > > dm-4 is ext4 partition mounted at /var > dm-4 is on LVM on luksCrypt on ATA drive. > > I'm using currently stock Debian testing kernel: > $ uname -a > Linux sredniczarny 3.1.0-1-686-pae #1 SMP Tue Nov 29 19:01:56 UTC 2011 i686 GNU/Linux > $ cat /proc/version > Linux version 3.1.0-1-686-pae (Debian 3.1.4-1) (waldi@...ian.org) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Tue Nov 29 19:01:56 UTC 2011 > $ > > 32-bit intel compatible cpu Thanks for report. Actually I was able to reproduce these messages with data=journal mode as well when running bash_shared_mapping test. The culprit of the problem is that block_mkwrite() as used in ext4_page_mkwrite() marks buffers dirty and JBD2 notices this before we clear dirty bits later in ext4_page_mkwrite() (since JBD2 doesn't use page lock for protection when inspecting buffers). So for data=journal mode we'll probably have to reimplement what block_page_mkwrite() does in a slightly different manner tweaked for the needs of data=journal mode. Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists