All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org, jfs-discussion@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, cluster-devel@redhat.com,
	linux-f2fs-devel@lists.sourceforge.net,
	v9fs-developer@lists.sourceforge.net,
	linux-nilfs@vger.kernel.org, linux-block@vger.kernel.org,
	dhowells@redhat.com, akpm@linux-foundation.org,
	hch@infradead.org, ross.zwisler@linux.intel.com,
	mawilcox@microsoft.com, jack@suse.com, viro@zeniv.linux.org.uk,
	corbet@lwn.net, neilb@suse.de, clm@fb.com, tytso@mit.edu,
	axboe@kernel.dk, josef@toxicpanda.com, hubcap@omnibond.com,
	rpeterso@redhat.com, bo.li.liu@oracle.com
Subject: Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it
Date: Wed, 10 May 2017 07:18:21 -0700	[thread overview]
Message-ID: <20170510141821.GB1590@bombadil.infradead.org> (raw)
In-Reply-To: <20170509154930.29524-14-jlayton@redhat.com>

On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote:
> +++ b/lib/errseq.c
> @@ -0,0 +1,199 @@
> +#include <linux/err.h>
> +#include <linux/bug.h>
> +#include <linux/atomic.h>
> +#include <linux/errseq.h>
> +
> +/*
> + * An errseq_t is a way of recording errors in one place, and allowing any
> + * number of "subscribers" to tell whether it has changed since an arbitrary
> + * time of their choosing.

You use the word "time" in several places in the documentation, but I think
it's clearer to say "sampling point" or "sample", since you're not using jiffies
or nanoseconds.  For example, I'd phrase this paragraph this way:

 * An errseq_t is a way of recording errors in one place, and allowing any
 * number of "subscribers" to tell whether it has changed since they last
 * sampled it.

> + * The general idea is for consumers to sample an errseq_t value at a
> + * particular point in time. Later, that value can be used to tell whether any
> + * new errors have occurred since that time.

 * The general idea is for consumers to sample an errseq_t value.  That
 * value can be used to tell whether any new errors have occurred since
 * the last time it was sampled.

> +/* The "ones" bit for the counter */

Maybe "The lowest bit of the counter"?

> +/**
> + * errseq_check - has an error occurred since a particular point in time?

"has an error occurred since the last time it was sampled"

> +/**
> + * errseq_check_and_advance - check an errseq_t and advance it to the current value
> + * @eseq: pointer to value being checked reported

"value being checked reported"?

> +int errseq_check_and_advance(errseq_t *eseq, errseq_t *since)
> +{
> +	int err = 0;
> +	errseq_t old, new;
> +
> +	/*
> +	 * Most callers will want to use the inline wrapper to check this,
> +	 * so that the common case of no error is handled without needing
> +	 * to lock.
> +	 */
> +	old = READ_ONCE(*eseq);
> +	if (old != *since) {
> +		/*
> +		 * Set the flag and try to swap it into place if it has
> +		 * changed.
> +		 *
> +		 * We don't care about the outcome of the swap here. If the
> +		 * swap doesn't occur, then it has either been updated by a
> +		 * writer who is bumping the seq count anyway, or another
> +		 * reader who is just setting the "seen" flag. Either outcome
> +		 * is OK, and we can advance "since" and return an error based
> +		 * on what we have.
> +		 */
> +		new = old | ERRSEQ_SEEN;
> +		if (new != old)
> +			cmpxchg(eseq, old, new);
> +		*since = new;
> +		err = -(new & MAX_ERRNO);
> +	}

I probably need to read through the patchset some more to understand this.
Naively, surely "since" should be updated to the current value of 'eseq'
if we failed the cmpxchg()?

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org,
	jack-IBi9RG/b67k@public.gmane.org,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
	corbet-T1hC0tSOHrs@public.gmane.org,
	neilb-l3A5Bk7waGM@public.gmane.org,
	clm-b10kYP2dOMg@public.gmane.org,
	tytso-3s7WtUTddSA@public.gmane.org,
	axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
	josef-DigfWCa+lFGyeJad7bwFQA@public.gmane.org,
	hubcap-gqc3UtWaqJ5Wk0Htik3J/w@public.gmane.org,
	rpeterso-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	bo.li.liu-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it
Date: Wed, 10 May 2017 07:18:21 -0700	[thread overview]
Message-ID: <20170510141821.GB1590@bombadil.infradead.org> (raw)
In-Reply-To: <20170509154930.29524-14-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote:
> +++ b/lib/errseq.c
> @@ -0,0 +1,199 @@
> +#include <linux/err.h>
> +#include <linux/bug.h>
> +#include <linux/atomic.h>
> +#include <linux/errseq.h>
> +
> +/*
> + * An errseq_t is a way of recording errors in one place, and allowing any
> + * number of "subscribers" to tell whether it has changed since an arbitrary
> + * time of their choosing.

You use the word "time" in several places in the documentation, but I think
it's clearer to say "sampling point" or "sample", since you're not using jiffies
or nanoseconds.  For example, I'd phrase this paragraph this way:

 * An errseq_t is a way of recording errors in one place, and allowing any
 * number of "subscribers" to tell whether it has changed since they last
 * sampled it.

> + * The general idea is for consumers to sample an errseq_t value at a
> + * particular point in time. Later, that value can be used to tell whether any
> + * new errors have occurred since that time.

 * The general idea is for consumers to sample an errseq_t value.  That
 * value can be used to tell whether any new errors have occurred since
 * the last time it was sampled.

> +/* The "ones" bit for the counter */

Maybe "The lowest bit of the counter"?

> +/**
> + * errseq_check - has an error occurred since a particular point in time?

"has an error occurred since the last time it was sampled"

> +/**
> + * errseq_check_and_advance - check an errseq_t and advance it to the current value
> + * @eseq: pointer to value being checked reported

"value being checked reported"?

> +int errseq_check_and_advance(errseq_t *eseq, errseq_t *since)
> +{
> +	int err = 0;
> +	errseq_t old, new;
> +
> +	/*
> +	 * Most callers will want to use the inline wrapper to check this,
> +	 * so that the common case of no error is handled without needing
> +	 * to lock.
> +	 */
> +	old = READ_ONCE(*eseq);
> +	if (old != *since) {
> +		/*
> +		 * Set the flag and try to swap it into place if it has
> +		 * changed.
> +		 *
> +		 * We don't care about the outcome of the swap here. If the
> +		 * swap doesn't occur, then it has either been updated by a
> +		 * writer who is bumping the seq count anyway, or another
> +		 * reader who is just setting the "seen" flag. Either outcome
> +		 * is OK, and we can advance "since" and return an error based
> +		 * on what we have.
> +		 */
> +		new = old | ERRSEQ_SEEN;
> +		if (new != old)
> +			cmpxchg(eseq, old, new);
> +		*since = new;
> +		err = -(new & MAX_ERRNO);
> +	}

I probably need to read through the patchset some more to understand this.
Naively, surely "since" should be updated to the current value of 'eseq'
if we failed the cmpxchg()?

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org, jfs-discussion@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, cluster-devel@redhat.com,
	linux-f2fs-devel@lists.sourceforge.net,
	v9fs-developer@lists.sourceforge.net,
	linux-nilfs@vger.kernel.org, linux-block@vger.kernel.org,
	dhowells@redhat.com, akpm@linux-foundation.org,
	hch@infradead.org, ross.zwisler@linux.intel.com,
	mawilcox@microsoft.com, jack@suse.com, viro@zeniv.linux.org.uk,
	corbet@lwn.net, neilb@suse.de, clm@fb.com, tytso@mit.edu,
	axboe@kernel.dk, josef@toxicpanda.com, hubcap@omnibond.com,
	rpeterso@redhat.com, bo.li.liu@oracle.com
Subject: Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it
Date: Wed, 10 May 2017 07:18:21 -0700	[thread overview]
Message-ID: <20170510141821.GB1590@bombadil.infradead.org> (raw)
In-Reply-To: <20170509154930.29524-14-jlayton@redhat.com>

On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote:
> +++ b/lib/errseq.c
> @@ -0,0 +1,199 @@
> +#include <linux/err.h>
> +#include <linux/bug.h>
> +#include <linux/atomic.h>
> +#include <linux/errseq.h>
> +
> +/*
> + * An errseq_t is a way of recording errors in one place, and allowing any
> + * number of "subscribers" to tell whether it has changed since an arbitrary
> + * time of their choosing.

You use the word "time" in several places in the documentation, but I think
it's clearer to say "sampling point" or "sample", since you're not using jiffies
or nanoseconds.  For example, I'd phrase this paragraph this way:

 * An errseq_t is a way of recording errors in one place, and allowing any
 * number of "subscribers" to tell whether it has changed since they last
 * sampled it.

> + * The general idea is for consumers to sample an errseq_t value at a
> + * particular point in time. Later, that value can be used to tell whether any
> + * new errors have occurred since that time.

 * The general idea is for consumers to sample an errseq_t value.  That
 * value can be used to tell whether any new errors have occurred since
 * the last time it was sampled.

> +/* The "ones" bit for the counter */

Maybe "The lowest bit of the counter"?

> +/**
> + * errseq_check - has an error occurred since a particular point in time?

"has an error occurred since the last time it was sampled"

> +/**
> + * errseq_check_and_advance - check an errseq_t and advance it to the current value
> + * @eseq: pointer to value being checked reported

"value being checked reported"?

> +int errseq_check_and_advance(errseq_t *eseq, errseq_t *since)
> +{
> +	int err = 0;
> +	errseq_t old, new;
> +
> +	/*
> +	 * Most callers will want to use the inline wrapper to check this,
> +	 * so that the common case of no error is handled without needing
> +	 * to lock.
> +	 */
> +	old = READ_ONCE(*eseq);
> +	if (old != *since) {
> +		/*
> +		 * Set the flag and try to swap it into place if it has
> +		 * changed.
> +		 *
> +		 * We don't care about the outcome of the swap here. If the
> +		 * swap doesn't occur, then it has either been updated by a
> +		 * writer who is bumping the seq count anyway, or another
> +		 * reader who is just setting the "seen" flag. Either outcome
> +		 * is OK, and we can advance "since" and return an error based
> +		 * on what we have.
> +		 */
> +		new = old | ERRSEQ_SEEN;
> +		if (new != old)
> +			cmpxchg(eseq, old, new);
> +		*since = new;
> +		err = -(new & MAX_ERRNO);
> +	}

I probably need to read through the patchset some more to understand this.
Naively, surely "since" should be updated to the current value of 'eseq'
if we failed the cmpxchg()?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it
Date: Wed, 10 May 2017 07:18:21 -0700	[thread overview]
Message-ID: <20170510141821.GB1590@bombadil.infradead.org> (raw)
In-Reply-To: <20170509154930.29524-14-jlayton@redhat.com>

On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote:
> +++ b/lib/errseq.c
> @@ -0,0 +1,199 @@
> +#include <linux/err.h>
> +#include <linux/bug.h>
> +#include <linux/atomic.h>
> +#include <linux/errseq.h>
> +
> +/*
> + * An errseq_t is a way of recording errors in one place, and allowing any
> + * number of "subscribers" to tell whether it has changed since an arbitrary
> + * time of their choosing.

You use the word "time" in several places in the documentation, but I think
it's clearer to say "sampling point" or "sample", since you're not using jiffies
or nanoseconds.  For example, I'd phrase this paragraph this way:

 * An errseq_t is a way of recording errors in one place, and allowing any
 * number of "subscribers" to tell whether it has changed since they last
 * sampled it.

> + * The general idea is for consumers to sample an errseq_t value at a
> + * particular point in time. Later, that value can be used to tell whether any
> + * new errors have occurred since that time.

 * The general idea is for consumers to sample an errseq_t value.  That
 * value can be used to tell whether any new errors have occurred since
 * the last time it was sampled.

> +/* The "ones" bit for the counter */

Maybe "The lowest bit of the counter"?

> +/**
> + * errseq_check - has an error occurred since a particular point in time?

"has an error occurred since the last time it was sampled"

> +/**
> + * errseq_check_and_advance - check an errseq_t and advance it to the current value
> + * @eseq: pointer to value being checked reported

"value being checked reported"?

> +int errseq_check_and_advance(errseq_t *eseq, errseq_t *since)
> +{
> +	int err = 0;
> +	errseq_t old, new;
> +
> +	/*
> +	 * Most callers will want to use the inline wrapper to check this,
> +	 * so that the common case of no error is handled without needing
> +	 * to lock.
> +	 */
> +	old = READ_ONCE(*eseq);
> +	if (old != *since) {
> +		/*
> +		 * Set the flag and try to swap it into place if it has
> +		 * changed.
> +		 *
> +		 * We don't care about the outcome of the swap here. If the
> +		 * swap doesn't occur, then it has either been updated by a
> +		 * writer who is bumping the seq count anyway, or another
> +		 * reader who is just setting the "seen" flag. Either outcome
> +		 * is OK, and we can advance "since" and return an error based
> +		 * on what we have.
> +		 */
> +		new = old | ERRSEQ_SEEN;
> +		if (new != old)
> +			cmpxchg(eseq, old, new);
> +		*since = new;
> +		err = -(new & MAX_ERRNO);
> +	}

I probably need to read through the patchset some more to understand this.
Naively, surely "since" should be updated to the current value of 'eseq'
if we failed the cmpxchg()?



  parent reply	other threads:[~2017-05-10 14:18 UTC|newest]

Thread overview: 195+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-09 15:49 [PATCH v4 00/27] fs: introduce new writeback error reporting and convert existing API as a wrapper around it Jeff Layton
2017-05-09 15:49 ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49 ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 01/27] fs: remove unneeded forward definition of mm_struct from fs.h Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 11:04   ` Jan Kara
2017-05-10 11:04     ` [Cluster-devel] " Jan Kara
2017-05-10 11:04     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 02/27] mm: drop "wait" parameter from write_one_page Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 03/27] mm: fix mapping_set_error call in me_pagecache_dirty Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 04/27] buffer: use mapping_set_error instead of setting the flag Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 05/27] btrfs: btrfs_wait_tree_block_writeback can be void return Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 11:09   ` Jan Kara
2017-05-10 11:09     ` [Cluster-devel] " Jan Kara
2017-05-10 11:09     ` Jan Kara
2017-05-19  4:07   ` Liu Bo
2017-05-19  4:07     ` [Cluster-devel] " Liu Bo
2017-05-19  4:07     ` Liu Bo
2017-05-19  4:07     ` Liu Bo
2017-05-09 15:49 ` [PATCH v4 06/27] fs: check for writeback errors after syncing out buffers in generic_file_fsync Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 12:48   ` Matthew Wilcox
2017-05-10 12:48     ` [Cluster-devel] " Matthew Wilcox
2017-05-10 12:48     ` Matthew Wilcox
2017-05-09 15:49 ` [PATCH v4 07/27] orangefs: don't call filemap_write_and_wait from fsync Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 08/27] dax: set errors in mapping when writeback fails Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 09/27] nilfs2: set the mapping error when calling SetPageError on writeback Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 10/27] 9p: set mapping error when writeback fails in launder_page Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 11/27] fuse: set mapping error in writepage_locked when it fails Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 11:13   ` Jan Kara
2017-05-10 11:13     ` [Cluster-devel] " Jan Kara
2017-05-10 11:13     ` Jan Kara
2017-05-10 11:13     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 12/27] cifs: set mapping error when page writeback fails in writepage or launder_pages Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 11:14   ` Jan Kara
2017-05-10 11:14     ` [Cluster-devel] " Jan Kara
2017-05-10 11:14     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 22:03   ` NeilBrown
2017-05-09 22:03     ` [Cluster-devel] " NeilBrown
2017-05-10 11:29     ` Jeff Layton
2017-05-10 11:29       ` [Cluster-devel] " Jeff Layton
2017-05-10 11:29       ` Jeff Layton
2017-05-10 11:29       ` Jeff Layton
2017-05-10 11:29       ` Jeff Layton
2017-05-10 11:34   ` Jan Kara
2017-05-10 11:34     ` [Cluster-devel] " Jan Kara
2017-05-10 11:34     ` Jan Kara
2017-05-10 11:58     ` Jeff Layton
2017-05-10 14:18   ` Matthew Wilcox [this message]
2017-05-10 14:18     ` [Cluster-devel] " Matthew Wilcox
2017-05-10 14:18     ` Matthew Wilcox
2017-05-10 14:18     ` Matthew Wilcox
2017-05-10 14:56     ` Jeff Layton
2017-05-10 14:56       ` [Cluster-devel] " Jeff Layton
2017-05-10 14:56       ` Jeff Layton
2017-05-10 14:56       ` Jeff Layton
2017-05-10 14:56       ` Jeff Layton
2017-05-10 14:56       ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 14/27] fs: new infrastructure for writeback error handling and reporting Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 11:48   ` Jan Kara
2017-05-10 11:48     ` [Cluster-devel] " Jan Kara
2017-05-10 11:48     ` Jan Kara
2017-05-10 12:19     ` Jeff Layton
2017-05-10 12:19       ` [Cluster-devel] " Jeff Layton
2017-05-10 12:19       ` Jeff Layton
2017-05-10 12:19       ` Jeff Layton
2017-05-10 12:19       ` Jeff Layton
2017-05-10 13:46       ` Jan Kara
2017-05-10 13:46         ` [Cluster-devel] " Jan Kara
2017-05-10 13:46         ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 15/27] fs: retrofit old error reporting API onto new infrastructure Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-15 10:42   ` Jan Kara
2017-05-15 10:42     ` [Cluster-devel] " Jan Kara
2017-05-15 10:42     ` Jan Kara
2017-05-15 10:42     ` Jan Kara
2017-05-15 17:58     ` Jeff Layton
2017-05-15 17:58       ` [Cluster-devel] " Jeff Layton
2017-05-15 17:58       ` Jeff Layton
2017-05-15 17:58       ` Jeff Layton
2017-05-15 17:58       ` Jeff Layton
2017-05-19 19:20     ` Jeff Layton
2017-05-22 13:38       ` Jan Kara
2017-05-22 13:53         ` Jeff Layton
2017-05-22 17:53           ` Jan Kara
2017-05-22 19:09             ` Jeff Layton
2017-05-23  9:05               ` Jan Kara
2017-05-23  9:05                 ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 16/27] fs: adapt sync_file_range to new reporting infrastructure Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 17/27] mm: remove AS_EIO and AS_ENOSPC flags Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 18/27] mm: don't TestClearPageError in __filemap_fdatawait_range Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 19/27] buffer: set errors in mapping at the time that the error occurs Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-15 11:53   ` Jan Kara
2017-05-15 11:53     ` [Cluster-devel] " Jan Kara
2017-05-15 11:53     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 20/27] cifs: cleanup writeback handling errors and comments Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 21/27] mm: clean up error handling in write_one_page Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-15 12:01   ` Jan Kara
2017-05-15 12:01     ` [Cluster-devel] " Jan Kara
2017-05-15 12:01     ` Jan Kara
2017-05-15 12:01     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 22/27] jbd2: don't reset error in journal_finish_inode_data_buffers Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-15 11:58   ` Jan Kara
2017-05-15 11:58     ` [Cluster-devel] " Jan Kara
2017-05-15 11:58     ` Jan Kara
2017-05-09 15:49 ` [PATCH v4 23/27] gfs2: clean up some filemap_* calls Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-10 16:18   ` Bob Peterson
2017-05-10 16:18     ` [Cluster-devel] " Bob Peterson
2017-05-10 16:18     ` Bob Peterson
2017-05-10 16:18     ` Bob Peterson
2017-05-09 15:49 ` [PATCH v4 24/27][RFC] nfs: convert to new errseq_t based error tracking for writeback errors Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 25/27] Documentation: flesh out the section in vfs.txt on storing and reporting " Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 16:24   ` Jeff Layton
2017-05-09 16:24     ` [Cluster-devel] " Jeff Layton
2017-05-09 16:24     ` Jeff Layton
2017-05-09 16:24     ` Jeff Layton
2017-05-09 16:24     ` Jeff Layton
2017-05-09 16:24     ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 26/27] mm: flesh out comments over mapping_set_error Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49 ` [PATCH v4 27/27] mm: clean up comments in me_pagecache_dirty Jeff Layton
2017-05-09 15:49   ` [Cluster-devel] " Jeff Layton
2017-05-09 15:49   ` Jeff Layton
2017-05-09 15:49   ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170510141821.GB1590@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bo.li.liu@oracle.com \
    --cc=clm@fb.com \
    --cc=cluster-devel@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=hubcap@omnibond.com \
    --cc=jack@suse.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=jlayton@redhat.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=neilb@suse.de \
    --cc=ross.zwisler@linux.intel.com \
    --cc=rpeterso@redhat.com \
    --cc=tytso@mit.edu \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.