Re: [Bug 50981] generic_file_aio_read ?: No locking means DATA CORRUPTION read and write on same 4096 page range
From: Hiro Lalwani <hidden>
Date: 2012-11-26 18:59:35
Also in:
linux-fsdevel
From: Hiro Lalwani <hidden>
Date: 2012-11-26 18:59:35
Also in:
linux-fsdevel
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 [off-list ref] wrote:
On Mon, Nov 26, 2012 at 04:33:28PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:quoted
https://bugzilla.kernel.org/show_bug.cgi?id=50981 as this is working properly with XFS, so in ext4/ext3...etc also weshouldn'tquoted
require synchronization at the Application level,., FS should take careofquoted
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