All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jaya Kumar <jayakumar.lkml@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	stefani@seibold.net, linux-kernel@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	linux-mm@kvack.org, Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
Date: Mon, 29 Oct 2007 13:35:08 +0100	[thread overview]
Message-ID: <1193661308.27652.47.camel@twins> (raw)
In-Reply-To: <1193652717.27652.45.camel@twins>

On Mon, 2007-10-29 at 11:11 +0100, Peter Zijlstra wrote:
> On Mon, 2007-10-29 at 01:17 -0700, Jaya Kumar wrote:
> > On 10/29/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > On Mon, 22 Oct 2007 16:40:57 +0200 Stefani Seibold <stefani@seibold.net> wrote:
> > > >
> > > > The problem original occurs with the fb_defio driver (driver/video/fb_defio.c).
> > > > This driver use the vm_ops.page_mkwrite() handler for tracking the modified pages,
> > > > which will be in an extra thread handled, to perform the IO and clean and
> > > > write protect all pages with page_clean().
> > > >
> > 
> > Hi,
> > 
> > An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255.
> > 
> > I understood from the thread that PeterZ is looking into page_mkclean
> > changes which I guess went into 2.6.23. I'm also happy to help in any
> > way if the way we're doing fb_defio needs to change.
> 
> Yeah, its the truncate race stuff introduced by Nick in
>   d0217ac04ca6591841e5665f518e38064f4e65bd
> 
> I'm a bit at a loss on how to go around fixing this. One ugly idea I had
> was to check page->mapping before going into page_mkwrite() and when
> that is null, don't bother with the truncate check.

Something like this

---
 mm/memory.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -2300,6 +2300,8 @@ static int __do_fault(struct mm_struct *
 			 * to become writable
 			 */
 			if (vma->vm_ops->page_mkwrite) {
+				struct address_space *mapping = page->mapping;
+
 				unlock_page(page);
 				if (vma->vm_ops->page_mkwrite(vma, page) < 0) {
 					ret = VM_FAULT_SIGBUS;
@@ -2314,7 +2316,7 @@ static int __do_fault(struct mm_struct *
 				 * reworking page_mkwrite locking API, which
 				 * is better done later.
 				 */
-				if (!page->mapping) {
+				if (mapping != page->mapping) {
 					ret = 0;
 					anon = 1; /* no anon but release vmf.page */
 					goto out;



WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Jaya Kumar <jayakumar.lkml@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	stefani@seibold.net, linux-kernel@vger.kernel.org,
	David Howells <dhowells@redhat.com>,
	linux-mm@kvack.org, Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
Date: Mon, 29 Oct 2007 13:35:08 +0100	[thread overview]
Message-ID: <1193661308.27652.47.camel@twins> (raw)
In-Reply-To: <1193652717.27652.45.camel@twins>

On Mon, 2007-10-29 at 11:11 +0100, Peter Zijlstra wrote:
> On Mon, 2007-10-29 at 01:17 -0700, Jaya Kumar wrote:
> > On 10/29/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > On Mon, 22 Oct 2007 16:40:57 +0200 Stefani Seibold <stefani@seibold.net> wrote:
> > > >
> > > > The problem original occurs with the fb_defio driver (driver/video/fb_defio.c).
> > > > This driver use the vm_ops.page_mkwrite() handler for tracking the modified pages,
> > > > which will be in an extra thread handled, to perform the IO and clean and
> > > > write protect all pages with page_clean().
> > > >
> > 
> > Hi,
> > 
> > An aside, I just tested that deferred IO works fine on 2.6.22.10/pxa255.
> > 
> > I understood from the thread that PeterZ is looking into page_mkclean
> > changes which I guess went into 2.6.23. I'm also happy to help in any
> > way if the way we're doing fb_defio needs to change.
> 
> Yeah, its the truncate race stuff introduced by Nick in
>   d0217ac04ca6591841e5665f518e38064f4e65bd
> 
> I'm a bit at a loss on how to go around fixing this. One ugly idea I had
> was to check page->mapping before going into page_mkwrite() and when
> that is null, don't bother with the truncate check.

Something like this

---
 mm/memory.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -2300,6 +2300,8 @@ static int __do_fault(struct mm_struct *
 			 * to become writable
 			 */
 			if (vma->vm_ops->page_mkwrite) {
+				struct address_space *mapping = page->mapping;
+
 				unlock_page(page);
 				if (vma->vm_ops->page_mkwrite(vma, page) < 0) {
 					ret = VM_FAULT_SIGBUS;
@@ -2314,7 +2316,7 @@ static int __do_fault(struct mm_struct *
 				 * reworking page_mkwrite locking API, which
 				 * is better done later.
 				 */
-				if (!page->mapping) {
+				if (mapping != page->mapping) {
 					ret = 0;
 					anon = 1; /* no anon but release vmf.page */
 					goto out;


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

  reply	other threads:[~2007-10-29 12:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22 14:40 vm_ops.page_mkwrite() fails with vmalloc on 2.6.23 Stefani Seibold
2007-10-29  7:40 ` Andrew Morton
2007-10-29  7:40   ` Andrew Morton
2007-10-29  8:17   ` Jaya Kumar
2007-10-29  8:17     ` Jaya Kumar
2007-10-29 10:11     ` Peter Zijlstra
2007-10-29 10:11       ` Peter Zijlstra
2007-10-29 12:35       ` Peter Zijlstra [this message]
2007-10-29 12:35         ` Peter Zijlstra
2007-10-29 14:28         ` Nick Piggin
2007-10-29 14:28           ` Nick Piggin
2007-10-29 17:01     ` Peter Zijlstra
2007-10-29 17:01       ` Peter Zijlstra
2007-10-29 17:51       ` Jaya Kumar
2007-10-29 17:51         ` Jaya Kumar
2007-10-29 18:17         ` Peter Zijlstra
2007-10-29 18:17           ` Peter Zijlstra
2007-10-29 22:16           ` Peter Zijlstra
2007-10-29 22:16             ` Peter Zijlstra
2007-10-30  1:22             ` Jaya Kumar
2007-10-30  1:22               ` Jaya Kumar
2007-10-30  9:56               ` Peter Zijlstra
2007-10-30 10:49                 ` Stefani Seibold
2007-10-30 10:49                   ` Stefani Seibold
2007-10-30 12:39                   ` Hugh Dickins
2007-10-30 12:39                     ` Hugh Dickins
2007-10-30 13:12                     ` Peter Zijlstra
2007-10-30 13:16                 ` Jaya Kumar
2007-10-30 13:16                   ` Jaya Kumar
2007-10-30 13:25                   ` Peter Zijlstra
2007-10-30 15:47                     ` Hugh Dickins
2007-10-30 15:47                       ` Hugh Dickins
2007-10-30 15:51                       ` Peter Zijlstra
2007-11-01  8:02                       ` Jaya Kumar
2007-11-01  8:02                         ` Jaya Kumar
  -- strict thread matches above, loose matches on Subject: below --
2007-10-22 14:45 Stefani Seibold
2007-10-22 16:37 ` Hugh Dickins
2007-10-22 17:03   ` Jaya Kumar
2007-10-22 17:17 ` Peter Zijlstra
2007-10-22 17:20   ` Peter Zijlstra

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=1193661308.27652.47.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=jayakumar.lkml@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=stefani@seibold.net \
    /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.