From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx168.postini.com [74.125.245.168]) by kanga.kvack.org (Postfix) with SMTP id A2DE86B006C for ; Mon, 26 Nov 2012 13:59:37 -0500 (EST) Received: by mail-wi0-f179.google.com with SMTP id hj6so2877048wib.8 for ; Mon, 26 Nov 2012 10:59:36 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20121126164555.GL31891@thunk.org> References: <20121126163328.ACEB011FE9C@bugzilla.kernel.org> <20121126164555.GL31891@thunk.org> Date: Tue, 27 Nov 2012 00:29:35 +0530 Message-ID: Subject: Re: [Bug 50981] generic_file_aio_read ?: No locking means DATA CORRUPTION read and write on same 4096 page range From: Hiro Lalwani Content-Type: multipart/alternative; boundary=001636ef0283d38c4104cf6a88f3 Sender: owner-linux-mm@kvack.org List-ID: To: Theodore Ts'o Cc: bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org --001636ef0283d38c4104cf6a88f3 Content-Type: text/plain; charset=ISO-8859-1 Thanks a lot Theodore Ts'o ... Thanks to all (kernel,ext4 ..etc. )developer for quick debug and response... On Mon, Nov 26, 2012 at 10:15 PM, Theodore Ts'o wrote: > On Mon, Nov 26, 2012 at 04:33:28PM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=50981 > > > > as this is working properly with XFS, so in ext4/ext3...etc also we > shouldn't > > require synchronization at the Application level,., FS should take care > of > > locking... will we expecting the fix for the same ??? > > Meetmehiro, > > At this point, there seems to be consensus that the kernel should take > care of the locking, and that this is not something that needs be a > worry for the application. Whether this should be done in the file > system layer or in the mm layer is the current question at hand --- > since this is a bug that also affects btrfs and other non-XFS file > systems. > > So the question is whether every file system which supports AIO should > add its own locking, or whether it should be done at the mm layer, and > at which point the lock in the XFS layer could be removed as no longer > necessary. > > I've added linux-mm and linux-fsdevel to make sure all of the relevant > kernel developers are aware of this question/issue. > > Regards, > > - Ted > -- thanks & regards Hiro Lalwani --001636ef0283d38c4104cf6a88f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0Thanks a lot Theodore Ts'o ...

=A0Thanks to all (= kernel,ext4 ..etc. )developer for quick debug and response...

On Mon, Nov 26, 2012 at 10:15 PM= , Theodore Ts'o <tytso@mit.edu> wrote:
On Mon, Nov 26, 2012 at 04:33:28PM +0000, bugzilla-daemon@bugzil= la.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=3D50981
>
> as this is working properly with XFS, so in ext4/ext3...etc also we sh= ouldn't
> require synchronization at the Application level,., FS should take car= e of
> locking... will we expecting the fix for the same ???

Meetmehiro,

At this point, there seems to be consensus that the kernel should take
care of the locking, and that this is not something that needs be a
worry for the application. =A0Whether this should be done in the file
system layer or in the mm layer is the current question at hand ---
since this is a bug that also affects btrfs and other non-XFS file
systems.

So the question is whether every file system which supports AIO should
add its own locking, or whether it should be done at the mm layer, and
at which point the lock in the XFS layer could be removed as no longer
necessary.

I've added linux-mm and linux-fsdevel to make sure all of the relevant<= br> kernel developers are aware of this question/issue.

Regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 - Ted



--
thanks &= regards
Hiro Lalwani
--001636ef0283d38c4104cf6a88f3-- -- 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: email@kvack.org