[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170509154930.29524-28-jlayton@redhat.com>
Date: Tue, 9 May 2017 11:49:30 -0400
From: Jeff Layton <jlayton@...hat.com>
To: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-mm@...ck.org, jfs-discussion@...ts.sourceforge.net,
linux-xfs@...r.kernel.org, cluster-devel@...hat.com,
linux-f2fs-devel@...ts.sourceforge.net,
v9fs-developer@...ts.sourceforge.net, linux-nilfs@...r.kernel.org,
linux-block@...r.kernel.org
Cc: dhowells@...hat.com, akpm@...ux-foundation.org, hch@...radead.org,
ross.zwisler@...ux.intel.com, mawilcox@...rosoft.com,
jack@...e.com, viro@...iv.linux.org.uk, corbet@....net,
neilb@...e.de, clm@...com, tytso@....edu, axboe@...nel.dk,
josef@...icpanda.com, hubcap@...ibond.com, rpeterso@...hat.com,
bo.li.liu@...cle.com
Subject: [PATCH v4 27/27] mm: clean up comments in me_pagecache_dirty
This no longer applies with the new writeback error tracking and
reporting infrastructure.
Signed-off-by: Jeff Layton <jlayton@...hat.com>
---
mm/memory-failure.c | 35 +++++------------------------------
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4b56e53e5378..be5f998a0772 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -642,37 +642,12 @@ static int me_pagecache_dirty(struct page *p, unsigned long pfn)
if (mapping) {
/*
* IO error will be reported by write(), fsync(), etc.
- * who check the mapping.
- * This way the application knows that something went
- * wrong with its dirty file data.
+ * who check the mapping. This way the application knows that
+ * something went wrong when writing back its dirty file data.
*
- * There's one open issue:
- *
- * The EIO will be only reported on the next IO
- * operation and then cleared through the IO map.
- * Normally Linux has two mechanisms to pass IO error
- * first through the AS_EIO flag in the address space
- * and then through the PageError flag in the page.
- * Since we drop pages on memory failure handling the
- * only mechanism open to use is through AS_AIO.
- *
- * This has the disadvantage that it gets cleared on
- * the first operation that returns an error, while
- * the PageError bit is more sticky and only cleared
- * when the page is reread or dropped. If an
- * application assumes it will always get error on
- * fsync, but does other operations on the fd before
- * and the page is dropped between then the error
- * will not be properly reported.
- *
- * This can already happen even without hwpoisoned
- * pages: first on metadata IO errors (which only
- * report through AS_EIO) or when the page is dropped
- * at the wrong time.
- *
- * So right now we assume that the application DTRT on
- * the first EIO, but we're not worse than other parts
- * of the kernel.
+ * Note that errors are reported only once per file
+ * description, but should be reported on all open file
+ * descriptions for this inode.
*/
mapping_set_error(mapping, -EIO);
}
--
2.9.3
Powered by blists - more mailing lists