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: <1496711306.2815.0.camel@redhat.com> Date: Mon, 05 Jun 2017 21:08:26 -0400 From: Jeff Layton <jlayton@...hat.com> To: Ross Zwisler <ross.zwisler@...ux.intel.com> Cc: 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, corbet@....net, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org, linux-doc@...r.kernel.org Subject: Re: [PATCH v5 08/17] dax: set errors in mapping when writeback fails On Mon, 2017-06-05 at 19:01 -0600, Ross Zwisler wrote: > On Wed, May 31, 2017 at 08:45:31AM -0400, Jeff Layton wrote: > > Jan's description for this patch is much better than mine, so I'm > > quoting it verbatim here: > > > > -----------------8<----------------- > > DAX currently doesn't set errors in the mapping when cache flushing > > fails in dax_writeback_mapping_range(). Since this function can get > > called only from fsync(2) or sync(2), this is actually as good as it can > > currently get since we correctly propagate the error up from > > dax_writeback_mapping_range() to filemap_fdatawrite() > > > > However, in the future better writeback error handling will enable us to > > properly report these errors on fsync(2) even if there are multiple file > > descriptors open against the file or if sync(2) gets called before > > fsync(2). So convert DAX to using standard error reporting through the > > mapping. > > -----------------8<----------------- > > > > For now, only do this when the FS_WB_ERRSEQ flag is set. The > > AS_EIO/AS_ENOSPC flags are not currently cleared in the older code when > > writeback initiation fails, only when we discover an error after waiting > > on writeback to complete, so we only want to do this with errseq_t based > > error handling to prevent seeing duplicate errors on fsync. > > > > Signed-off-by: Jeff Layton <jlayton@...hat.com> > > Reviewed-by: Jan Kara <jack@...e.cz> > > Reviewed-by: Christoph Hellwig <hch@....de> > > Reviewed-and-Tested-by: Ross Zwisler <ross.zwisler@...ux.intel.com> > > Re-tested this version of the series with some injected DAX errors, and it > looks good. Excellent! Thanks very much for helping test it. -- Jeff Layton <jlayton@...hat.com>
Powered by blists - more mailing lists