LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chris Mason <chris.mason@oracle.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
"Ananiev, Leonid I" <leonid.i.ananiev@intel.com>,
Zach Brown <zach.brown@oracle.com>,
linux-aio@kvack.org, linux-kernel@vger.kernel.org,
Suparna bhattacharya <suparna@in.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] aio: propogate post-EIOCBQUEUED errors to completion event
Date: Tue, 20 Feb 2007 11:38:16 -0500 [thread overview]
Message-ID: <1171989496.6271.32.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <1171988988.6271.26.camel@heimdal.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Tue, 2007-02-20 at 11:30 -0500, Trond Myklebust wrote:
> > One option is to have invalidate_inode_pages2_range continue if it can't
> > toss a page but still return something that O_DIRECT ignores (living
> > with the race), but it looks like I can make a launder_page op that does
> > the right thing. I'll give it a shot.
>
> I already sent in a patch to do that last week.
To be more precise, here are the 2 patches that I sent to lkml last
week. One ensures that we don't stop the invalidation just because of
the existence of an unsynced dirty page. The other gets rid of the EIO
for that case.
Cheers
Trond
[-- Attachment #2: linux-2.6.20-001-fix_invalidate_inode_pages2_range_return.dif --]
[-- Type: message/rfc822, Size: 1156 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: No Subject
Date: Sat, 13 Jan 2007 02:28:13 -0500
Message-ID: <1171989417.6271.29.camel@heimdal.trondhjem.org>
Fix invalidate_inode_pages2_range() so that it does not immediately exit
just because a single page in the specified range could not be removed.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
mm/truncate.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index ebf3fcb..0f4b6d1 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -375,10 +375,10 @@ int invalidate_inode_pages2_range(struct address_space *mapping,
pagevec_init(&pvec, 0);
next = start;
- while (next <= end && !ret && !wrapped &&
+ while (next <= end && !wrapped &&
pagevec_lookup(&pvec, mapping, next,
min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
- for (i = 0; !ret && i < pagevec_count(&pvec); i++) {
+ for (i = 0; i < pagevec_count(&pvec); i++) {
struct page *page = pvec.pages[i];
pgoff_t page_index;
[-- Attachment #3: linux-2.6.20-002-invalidate_inode_pages2_dont_fail_on_dirty.dif --]
[-- Type: message/rfc822, Size: 1856 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: No Subject
Date: Sat, 13 Jan 2007 02:28:13 -0500
Message-ID: <1171989417.6271.30.camel@heimdal.trondhjem.org>
invalidate_inode_pages2() should not try to fix races between direct_IO and
mmap(). It should only be trying to clear out pages that were dirty before
the direct_IO write (see generic_file_direct_IO()).
Skipping dirty pages should therefore not result in an error.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
mm/truncate.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index 0f4b6d1..c3ff820 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -318,6 +318,8 @@ EXPORT_SYMBOL(invalidate_mapping_pages);
* invalidation guarantees, and cannot afford to leave pages behind because
* shrink_list() has a temp ref on them, or because they're transiently sitting
* in the lru_cache_add() pagevecs.
+ * Note: this function just skips pages that are dirty without flagging
+ * an error.
*/
static int
invalidate_complete_page2(struct address_space *mapping, struct page *page)
@@ -330,7 +332,7 @@ invalidate_complete_page2(struct address_space *mapping, struct page *page)
write_lock_irq(&mapping->tree_lock);
if (PageDirty(page))
- goto failed;
+ goto dirty;
BUG_ON(PagePrivate(page));
__remove_from_page_cache(page);
@@ -338,9 +340,9 @@ invalidate_complete_page2(struct address_space *mapping, struct page *page)
ClearPageUptodate(page);
page_cache_release(page); /* pagecache ref */
return 1;
-failed:
+dirty:
write_unlock_irq(&mapping->tree_lock);
- return 0;
+ return 1;
}
static int do_launder_page(struct address_space *mapping, struct page *page)
next prev parent reply other threads:[~2007-02-20 16:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-19 20:35 Zach Brown
2007-02-19 20:47 ` Benjamin LaHaise
2007-02-19 21:07 ` Zach Brown
2007-02-19 20:58 ` Ananiev, Leonid I
2007-02-19 21:50 ` Chris Mason
2007-02-20 0:21 ` Benjamin LaHaise
2007-02-20 0:26 ` Zach Brown
2007-02-20 0:28 ` Chris Mason
2007-02-20 16:01 ` Trond Myklebust
2007-02-20 16:06 ` Benjamin LaHaise
2007-02-20 16:06 ` Arjan van de Ven
2007-02-20 16:19 ` Chris Mason
2007-02-20 16:08 ` Chris Mason
2007-02-20 16:29 ` Trond Myklebust
2007-02-20 16:38 ` Trond Myklebust [this message]
2007-02-20 18:40 ` Zach Brown
2007-02-21 0:05 ` Trond Myklebust
2007-02-20 14:08 ` Ananiev, Leonid I
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=1171989496.6271.32.camel@heimdal.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=akpm@linux-foundation.org \
--cc=bcrl@kvack.org \
--cc=chris.mason@oracle.com \
--cc=leonid.i.ananiev@intel.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.ibm.com \
--cc=zach.brown@oracle.com \
--subject='Re: [PATCH] aio: propogate post-EIOCBQUEUED errors to completion event' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).