linux-ext4 - Re: [PATCH] ext2: Report metadata errors during fsync

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20091126133139.GB4834@quack.suse.cz>
Date:	Thu, 26 Nov 2009 14:31:39 +0100
From:	Jan Kara <jack@...e.cz>
To:	Andreas Dilger <adilger@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, Jan Kara <jack@...e.cz>,
	linux-ext4@...r.kernel.org, tytso@....edu, chris.mason@...cle.com
Subject: Re: [PATCH] ext2: Report metadata errors during fsync

On Wed 25-11-09 16:17:32, Andreas Dilger wrote:
> On 2009-11-25, at 14:48, Andrew Morton wrote:
> >On Wed, 25 Nov 2009 11:24:53 +0100
> >Jan Kara <jack@...e.cz> wrote:
> >>When an IO error happens while writing metadata buffers, we should
> >>better report it and call ext2_error since the filesystem is probably
> >>no longer consistent. Sometimes such IO errors happen while flushing
> >>thread does background writeback, the buffer gets later evicted
> >>from memory, and thus the only trace of the error remains as
> >>AS_EIO bit
> >>set in blockdevice's mapping. So we check this bit in ext2_fsync and
> >>report the error although we cannot be really sure which buffer we
> >>failed to write.
> >
> >So this doesn't cause significant changes in runtime behaviour unless
> >the operator specified errors=remount-ro or errors=panic?
> 
> 
> Debian, at least, always mounts filesystems with errors=remount-ro.
> 
> I _was_ thinking that this would cause errors for even regular file
> data, but since it is the bdev mapping and regular files have their
> own mappings any errors on the regular files should appear on a
> different mapping (which is eventually returned via simple_fsync()).
>
> The only errors returned from the bdev mapping should be metadata
> errors, and we always want to call ext*_error() for those.
  Exactly. Since ext2 handles also directories via page cache, even errors
in directory blocks will not end up in block device's page cache.


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