linux-ext4 - Re: [PATCH v7 15/22] dax: set errors in mapping when writeback fails

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 17 Jun 2017 08:39:53 -0400
From:   Jeff Layton <jlayton@...hat.com>
To:     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>
Cc:     Carlos Maiolino <cmaiolino@...hat.com>,
        Eryu Guan <eguan@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Christoph Hellwig <hch@...radead.org>,
        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 15/22] dax: set errors in mapping when writeback fails

On Fri, 2017-06-16 at 15:34 -0400, Jeff Layton wrote:
> Jan Kara's description for this patch is much better than mine, so I'm
> quoting it verbatim here:
> 
> 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.
> 
> 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>
> ---
>  fs/dax.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 9899f07acf72..c663e8cc2a76 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -856,8 +856,10 @@ int dax_writeback_mapping_range(struct address_space *mapping,
>  
>  			ret = dax_writeback_one(bdev, dax_dev, mapping,
>  					indices[i], pvec.pages[i]);
> -			if (ret < 0)
> +			if (ret < 0) {
> +				mapping_set_error(mapping, ret);
>  				goto out;
> +			}
>  		}
>  	}
>  out:

I should point out here that Ross had an issue with this patch in an
earlier set, that I addressed with a flag in the last set. The flag is
icky though.

In this set, patch #6 should make it unnecessary:

    mm: clear AS_EIO/AS_ENOSPC when writeback initiation fails

Ross, could you test that this set still works ok for you with dax? It
should apply reasonably cleanly on top of linux-next.

Thanks,
-- 
Jeff Layton <jlayton@...hat.com>