All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Andrew Morton <akpm@osdl.org>,
	neilb@suse.de, okir@suse.de, nfs@lists.sourceforge.net
Subject: Re: Problems with mmap consistency
Date: Tue, 28 Feb 2006 02:04:46 +0100	[thread overview]
Message-ID: <20060228010446.GI5410@g5.random> (raw)
In-Reply-To: <1140892927.7877.24.camel@lade.trondhjem.org>

On Sat, Feb 25, 2006 at 01:42:07PM -0500, Trond Myklebust wrote:
> The only case where we allow ourselves to rely on writepage() is for
> mmapped files, where the whole concept of "user context" is all pretty
> blurry anyway.

Ok. I trust you on the nfs lowlevel part and I think Neil's comment on
this is interesting.

However I want to clarify a few things on those two patches. While you
currently don't relay on the dirty bitflag when it's clear, you
definitely relay on the dirty bitflag when it's set (because your
.set_page_dirty callback is set to __set_page_dirty_nobuffers).


I mean, you don't relay on the dirty bitflag after writepage has been
called and the page is clean, but like every other kernel fs (including
ext2) you relay on it _before_ writepage is invoked. The race my patch
wants to address is a race where a page becomes from dirty to clean,
without writepage being invoked and without the lowlevel fs ever
noticing that the page has been marked dirty.

If you had a lowlevel implementation of .set_page_dirty, you had a
slight chance to fix the race locally to the fs, but you didn't use it,
not even Neil's patch modified set_page_dirty.

So no matter how you change the code inside linux/fs/*, unless you hack
more around .set_page_dirty there's no chance for you to fix the
fs-corruption source that my patch fixed in the VM (in linux/mm/*).

So again those two patches are completely orthogonal, both are needed
and they should be considered separately: they fixes two completely
different bugs. The fact both bugs can lead to a similar kind of fs
corruption now seems just a pure coincidence.

The fact my fix fixed the testcase fully, seems to mean that the
lowlevel race has a much smaller window to trigger and the highlevel
race in the VM was the biggest offender (at least for the testcase that
Olaf posted here, dunno about other workloads).

Thanks.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2006-02-28  1:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17 10:57 Problems with mmap consistency Olaf Kirch
2006-02-17 15:15 ` Trond Myklebust
2006-02-24  4:01   ` Andrea Arcangeli
2006-02-24  6:15     ` Neil Brown
2006-02-24 16:08       ` Andrea Arcangeli
2006-02-24 23:39         ` Andrew Morton
2006-02-25  0:33           ` Andrea Arcangeli
2006-02-25  0:59             ` Trond Myklebust
2006-02-25  1:17               ` Andrew Morton
2006-02-25  4:59                 ` Andrea Arcangeli
2006-02-25 14:55                   ` Trond Myklebust
2006-02-25 17:27                     ` Andrea Arcangeli
2006-02-25 18:42                       ` Trond Myklebust
2006-02-27  0:26                         ` Neil Brown
2006-02-28  1:04                         ` Andrea Arcangeli [this message]
2006-02-26 22:33         ` Neil Brown
2006-02-24  7:12     ` Olaf Kirch

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=20060228010446.GI5410@g5.random \
    --to=andrea@suse.de \
    --cc=akpm@osdl.org \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    --cc=okir@suse.de \
    --cc=trond.myklebust@fys.uio.no \
    /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.