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: <20170627152000.GA29664@infradead.org> Date: Tue, 27 Jun 2017 08:20:00 -0700 From: Christoph Hellwig <hch@...radead.org> To: Jeff Layton <jlayton@...hat.com> Cc: Christoph Hellwig <hch@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...IV.linux.org.uk>, Jan Kara <jack@...e.cz>, tytso@....edu, axboe@...nel.dk, mawilcox@...rosoft.com, ross.zwisler@...ux.intel.com, corbet@....net, Chris Mason <clm@...com>, Josef Bacik <jbacik@...com>, David Sterba <dsterba@...e.com>, "Darrick J . Wong" <darrick.wong@...cle.com>, Carlos Maiolino <cmaiolino@...hat.com>, Eryu Guan <eguan@...hat.com>, David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-block@...r.kernel.org Subject: Re: [PATCH v7 16/22] block: convert to errseq_t based writeback error tracking On Mon, Jun 26, 2017 at 10:34:18AM -0400, Jeff Layton wrote: > The bigger question is -- what about more complex filesystems like > ext4? There are a couple of cases where we can return -EIO or -EROFS on > fsync before filemap_write_and_wait_range is ever called. Like this one > for instance: > > if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb)))) > return -EIO; > > ...and the EXT4_MF_FS_ABORTED case. > > Are those conditions ever recoverable, such that a later fsync could > succeed? IOW, could I do a remount or something such that the existing > fds are left open and become usable again? This looks copied from the xfs forced shutdown code, and in that case it's final and permanent - you'll need an unmount to clear it. > If so, then we really ought to advance the errseq_t in the file when we > catch those cases as well. If we have to do that, then it probably makes > sense to leave the ext4 patch as-is. I think it can switch to the new file helper.
Powered by blists - more mailing lists