linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).