From: Nick Piggin <npiggin@suse.de>
To: Albert Herranz <albert_herranz@yahoo.es>,
aya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: page_mkwrite vs pte dirty race in fb_defio
Date: Wed, 26 May 2010 02:01:49 +1000 [thread overview]
Message-ID: <20100525160149.GE20853@laptop> (raw)
Hi,
I couldn't find where this patch (49bbd815fd8) was discussed, so I'll
make my own thread. Adding a few lists to cc because it might be of
interest to driver and filesystem writers.
The old ->page_mkwrite calling convention was causing problems exactly
because of this race, and we solved it by allowing page_mkwrite to
return with the page locked, and the lock will be held until the
pte is marked dirty. See commit b827e496c893de0c0f142abfaeb8730a2fd6b37f.
I hope that should provide a more elegant solution to your problem. I
would really like you to take a look at that, because we already have
filesystem code (NFS) relying on it, and more code we have relying on
this synchronization, the more chance we would find a subtle problem
with it (also it should be just nicer).
Thanks,
Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de>
To: Albert Herranz <albert_herranz@yahoo.es>,
aya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: page_mkwrite vs pte dirty race in fb_defio
Date: Wed, 26 May 2010 02:01:49 +1000 [thread overview]
Message-ID: <20100525160149.GE20853@laptop> (raw)
Hi,
I couldn't find where this patch (49bbd815fd8) was discussed, so I'll
make my own thread. Adding a few lists to cc because it might be of
interest to driver and filesystem writers.
The old ->page_mkwrite calling convention was causing problems exactly
because of this race, and we solved it by allowing page_mkwrite to
return with the page locked, and the lock will be held until the
pte is marked dirty. See commit b827e496c893de0c0f142abfaeb8730a2fd6b37f.
I hope that should provide a more elegant solution to your problem. I
would really like you to take a look at that, because we already have
filesystem code (NFS) relying on it, and more code we have relying on
this synchronization, the more chance we would find a subtle problem
with it (also it should be just nicer).
Thanks,
Nick
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2010-05-25 16:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 16:01 Nick Piggin [this message]
2010-05-25 16:01 ` page_mkwrite vs pte dirty race in fb_defio Nick Piggin
2010-05-25 18:26 ` Albert Herranz
2010-05-25 18:26 ` Albert Herranz
2010-05-25 18:26 ` Albert Herranz
2010-05-25 18:47 ` Nick Piggin
2010-05-25 18:47 ` Nick Piggin
2010-05-25 18:47 ` Nick Piggin
2010-05-25 22:13 ` [Bulk] " Albert Herranz
2010-05-25 22:13 ` Albert Herranz
2010-05-25 22:13 ` Albert Herranz
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=20100525160149.GE20853@laptop \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=albert_herranz@yahoo.es \
--cc=jayakumar.lkml@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
/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.