From: Albert Herranz <albert_herranz@yahoo.es>
To: Nick Piggin <npiggin@suse.de>
Cc: aya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [Bulk] Re: page_mkwrite vs pte dirty race in fb_defio
Date: Tue, 25 May 2010 22:13:49 +0000 [thread overview]
Message-ID: <4BFC4B9D.1080902@yahoo.es> (raw)
In-Reply-To: <20100525184700.GJ20853@laptop>
On 05/25/2010 08:47 PM, Nick Piggin wrote:
>>> 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).
>>
>> So if I undestand it correctly, using the "new" calling convention I should just lock the page on fb_deferred_io_mkwrite() and return VM_FAULT_LOCKED to fix the described race for fb_defio.
>
> As far as I can see from quick reading of the fb_defio code, yes
> that should solve it (provided you lock the page inside the mutex,
> of course).
>
Ok, thanks. I'm posting a new version as RFT.
Cheers,
Albert
WARNING: multiple messages have this Message-ID (diff)
From: Albert Herranz <albert_herranz@yahoo.es>
To: Nick Piggin <npiggin@suse.de>
Cc: aya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [Bulk] Re: page_mkwrite vs pte dirty race in fb_defio
Date: Wed, 26 May 2010 00:13:49 +0200 [thread overview]
Message-ID: <4BFC4B9D.1080902@yahoo.es> (raw)
In-Reply-To: <20100525184700.GJ20853@laptop>
On 05/25/2010 08:47 PM, Nick Piggin wrote:
>>> 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).
>>
>> So if I undestand it correctly, using the "new" calling convention I should just lock the page on fb_deferred_io_mkwrite() and return VM_FAULT_LOCKED to fix the described race for fb_defio.
>
> As far as I can see from quick reading of the fb_defio code, yes
> that should solve it (provided you lock the page inside the mutex,
> of course).
>
Ok, thanks. I'm posting a new version as RFT.
Cheers,
Albert
WARNING: multiple messages have this Message-ID (diff)
From: Albert Herranz <albert_herranz@yahoo.es>
To: Nick Piggin <npiggin@suse.de>
Cc: aya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [Bulk] Re: page_mkwrite vs pte dirty race in fb_defio
Date: Wed, 26 May 2010 00:13:49 +0200 [thread overview]
Message-ID: <4BFC4B9D.1080902@yahoo.es> (raw)
In-Reply-To: <20100525184700.GJ20853@laptop>
On 05/25/2010 08:47 PM, Nick Piggin wrote:
>>> 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).
>>
>> So if I undestand it correctly, using the "new" calling convention I should just lock the page on fb_deferred_io_mkwrite() and return VM_FAULT_LOCKED to fix the described race for fb_defio.
>
> As far as I can see from quick reading of the fb_defio code, yes
> that should solve it (provided you lock the page inside the mutex,
> of course).
>
Ok, thanks. I'm posting a new version as RFT.
Cheers,
Albert
--
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 prev parent reply other threads:[~2010-05-25 22:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-25 16:01 page_mkwrite vs pte dirty race in fb_defio Nick Piggin
2010-05-25 16:01 ` 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 ` Albert Herranz [this message]
2010-05-25 22:13 ` [Bulk] " 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=4BFC4B9D.1080902@yahoo.es \
--to=albert_herranz@yahoo.es \
--cc=akpm@linux-foundation.org \
--cc=jayakumar.lkml@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--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.