From: Daniel McNeil <daniel@osdl.org>
To: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: Janet Morgan <janetmor@us.ibm.com>,
Badari Pulavarty <pbadari@us.ibm.com>,
"linux-aio@kvack.org" <linux-aio@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH linux-2.6.0-test10-mm1] dio-read-race-fix
Date: 30 Dec 2003 16:29:17 -0800 [thread overview]
Message-ID: <1072830557.712.49.camel@ibm-c.pdx.osdl.net> (raw)
In-Reply-To: <20031230045334.GA3484@in.ibm.com>
On Mon, 2003-12-29 at 20:53, Suparna Bhattacharya wrote:
> On Thu, Dec 11, 2003 at 04:51:33PM -0800, Daniel McNeil wrote:
> > I've done more testing with added debug code.
> >
> > It looks like the filemap_write_and_wait() call is returning
> > with data that has not made it disk.
> >
> > I added code to filemap_write_and_wait() to check if
> > mapping->dirty_pages is not empty after calling filemap_fdatawrite()
> > and filemap_fdatawait() and retry. Even with the retry, the test still
> > sees uninitialized data when running tests overnight (I added a printk
> > so I know the retry is happening). There are pages left on the
> > dirty_pages list even after the write and wait.
>
> There are two calls to filemap_write_and_wait() for a DIO read
> -- do you know in which if these cases you see dirty pages after
> the write and wait ? The first is called without i_sem protection,
> so it is possible for pages to be dirtied by a parallel buffered
> write which is OK because this is just an extra/superfluous call
> when it comes to DIO reads. The second call, however happens with i_sem
> held and is used to guarantee that there are no exposures, so if
> you are seeing remant dirty pages in this case it would be something
> to worry about.
>
Yes there are two calls. I'm assuming that the retry was caused by the
call w/o holding the i_sem, since pages can be dirtied in parallel.
My debug output shows every filemap_write_and_wait() and which pages are
on the dirty, io, and locked list and which pages are on the clean list
after the wait. (yes, this is lots of output)
I changed the test a little bit -- if the test sees non-zero data, it
opens a new file descriptor and re-reads the data without O_DIRECT and
also re-reads the 1st page of the non-zero data using O_DIRECT.
What the debug output shows is:
The 1st filemap_write_and_wait() writes out some data.
The 2nd filemap_write_and_wait() sees different dirty pages. The pages
that are seen non-zero by the test (many pages -- 243 in one case) are
on the dirty_pages list before the write and on the clean_pages list
after the wait. But some of the pages at the end of the clean list,
are seen by the test program as non-zero.
Since I added the DIO re-read, the debug output shows for the 2nd
re-read:
the 1st filemap_write_and_wait() with NO dirty pages
the 2nd filemap_write_and_wait() with dirty pages AFTER the pages
that mis-matched and the original plus these pages on the clean
list after the wait.
The 2nd re-read and the read without O_DIRECT both get zeroed data.
Conclusions:
===========
I'm not sure. :(
It appears like the pages are put on the clean list and PG_writeback is
cleared while the i/o is in flight and the DIO reads are put on the
queue ahead of the writeback.
I am trying to figure out how to add more debug code to prove this
or figure out what else is going on.
I'm open to suggestions.
Daniel
next prev parent reply other threads:[~2003-12-31 0:29 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3FCD4B66.8090905@us.ibm.com>
2003-12-06 1:29 ` [PATCH linux-2.6.0-test10-mm1] dio-read-race-fix Daniel McNeil
2003-12-08 18:23 ` Daniel McNeil
2003-12-12 0:51 ` Daniel McNeil
2003-12-17 1:25 ` [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch Daniel McNeil
2003-12-17 2:03 ` Andrew Morton
2003-12-17 19:25 ` Daniel McNeil
2003-12-17 20:17 ` Janet Morgan
2003-12-31 9:18 ` Suparna Bhattacharya
2003-12-31 9:35 ` Andrew Morton
2003-12-31 9:55 ` Suparna Bhattacharya
2003-12-31 9:59 ` Andrew Morton
2003-12-31 10:09 ` Suparna Bhattacharya
2003-12-31 10:10 ` Andrew Morton
2003-12-31 10:48 ` Suparna Bhattacharya
2003-12-31 10:53 ` Andrew Morton
2003-12-31 10:54 ` Andrew Morton
2003-12-31 11:17 ` Andrew Morton
2003-12-31 22:34 ` [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch Daniel McNeil
2003-12-31 22:41 ` [PATCH linux-2.6.1-rc1-mm1] aiodio_fallback_bio_count.patch Daniel McNeil
2003-12-31 23:46 ` Andrew Morton
2004-01-02 5:14 ` Suparna Bhattacharya
2004-01-02 7:46 ` Andrew Morton
2004-01-05 3:55 ` Suparna Bhattacharya
2004-01-05 5:06 ` Andrew Morton
2004-01-05 5:28 ` Suparna Bhattacharya
2004-01-05 5:28 ` Andrew Morton
2004-01-05 6:06 ` Suparna Bhattacharya
2004-01-05 6:14 ` Lincoln Dale
2003-12-31 22:47 ` [PATCH linux-2.6.1-rc1-mm1] dio_isize.patch Daniel McNeil
2003-12-31 23:42 ` [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch Andrew Morton
2004-01-02 4:20 ` Suparna Bhattacharya
2004-01-02 4:36 ` Andrew Morton
2004-01-02 5:50 ` [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch Suparna Bhattacharya
2004-01-02 7:31 ` Andrew Morton
2004-01-05 13:49 ` Marcelo Tosatti
2004-01-05 20:27 ` Andrew Morton
2004-03-29 15:44 ` Marcelo Tosatti
2004-01-11 23:14 ` Janet Morgan
2004-01-11 23:44 ` Andrew Morton
2004-01-12 18:00 ` filemap_fdatawait.patch Daniel McNeil
2004-01-12 19:39 ` [PATCH linux-2.6.0-test10-mm1] filemap_fdatawait.patch Janet Morgan
2004-01-12 19:46 ` Daniel McNeil
2004-01-13 4:12 ` Janet Morgan
2003-12-30 4:53 ` [PATCH linux-2.6.0-test10-mm1] dio-read-race-fix Suparna Bhattacharya
2003-12-31 0:29 ` Daniel McNeil [this message]
2003-12-31 6:09 ` Suparna Bhattacharya
2004-01-08 23:55 ` Daniel McNeil
2004-01-09 3:55 ` Suparna Bhattacharya
2004-02-05 1:39 ` [PATCH 2.6.2-rc3-mm1] DIO read race fix Daniel McNeil
2004-02-05 1:54 ` Badari Pulavarty
2004-02-05 2:07 ` Andrew Morton
2004-02-05 2:54 ` Janet Morgan
2004-02-05 3:19 ` Andrew Morton
2004-02-05 3:43 ` Suparna Bhattacharya
2004-02-05 5:33 ` Andrew Morton
2004-02-05 17:52 ` Daniel McNeil
2004-02-05 18:53 ` Badari Pulavarty
2004-03-29 15:41 ` [PATCH linux-2.6.0-test10-mm1] dio-read-race-fix Suparna Bhattacharya
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=1072830557.712.49.camel@ibm-c.pdx.osdl.net \
--to=daniel@osdl.org \
--cc=akpm@osdl.org \
--cc=janetmor@us.ibm.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=suparna@in.ibm.com \
/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 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).