From: Theodore Ts'o <tytso@mit.edu>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: meetmehiro@gmail.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [Bug 50981] generic_file_aio_read ?: No locking means DATA CORRUPTION read and write on same 4096 page range
Date: Mon, 26 Nov 2012 11:45:55 -0500 [thread overview]
Message-ID: <20121126164555.GL31891@thunk.org> (raw)
In-Reply-To: <20121126163328.ACEB011FE9C@bugzilla.kernel.org>
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
next parent reply other threads:[~2012-11-26 16:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-50981-5823@https.bugzilla.kernel.org/>
[not found] ` <20121126163328.ACEB011FE9C@bugzilla.kernel.org>
2012-11-26 16:45 ` Theodore Ts'o [this message]
2012-11-26 18:59 ` [Bug 50981] generic_file_aio_read ?: No locking means DATA CORRUPTION read and write on same 4096 page range Hiro Lalwani
2012-11-26 20:05 ` Hugh Dickins
2012-11-26 20:13 ` Christoph Hellwig
2012-11-26 21:28 ` Dave Chinner
2012-11-26 21:39 ` Christoph Hellwig
2012-11-26 21:49 ` Theodore Ts'o
2012-11-26 22:09 ` Christoph Hellwig
2012-11-27 1:32 ` Theodore Ts'o
2012-11-27 4:27 ` Dave Chinner
2012-11-26 22:17 ` Dave Chinner
2012-11-26 20:15 ` Zach Brown
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=20121126164555.GL31891@thunk.org \
--to=tytso@mit.edu \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=meetmehiro@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).