summaryrefslogtreecommitdiff
path: root/drivers/gpio
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2012-10-29 02:24:57 (GMT)
committerTheodore Ts'o <tytso@mit.edu>2012-10-29 02:24:57 (GMT)
commitffb5387e85d528fb6d0d924abfa3fbf0fc484071 (patch)
treeb4e444479eada05eb93c3f1b2099a018c5aef116 /drivers/gpio
parent8f0d8163b50e01f398b14bcd4dc039ac5ab18d64 (diff)
downloadlinux-fsl-qoriq-ffb5387e85d528fb6d0d924abfa3fbf0fc484071.tar.xz
ext4: fix unjournaled inode bitmap modification
commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed ext4_new_inode() such that the inode bitmap was being modified outside a transaction, which could lead to corruption, and was discovered when journal_checksum found a bad checksum in the journal during log replay. Nix ran into this when using the journal_async_commit mount option, which enables journal checksumming. The ensuing journal replay failures due to the bad checksums led to filesystem corruption reported as the now infamous "Apparent serious progressive ext4 data corruption bug" [ Changed by tytso to only call ext4_journal_get_write_access() only when we're fairly certain that we're going to allocate the inode. ] I've tested this by mounting with journal_checksum and running fsstress then dropping power; I've also tested by hacking DM to create snapshots w/o first quiescing, which allows me to test journal replay repeatedly w/o actually power-cycling the box. Without the patch I hit a journal checksum error every time. With this fix it survives many iterations. Reported-by: Nix <nix@esperi.org.uk> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org
Diffstat (limited to 'drivers/gpio')
0 files changed, 0 insertions, 0 deletions