On Mon, 26 Nov 2012, Theodore Ts'o wrote: > On Mon, Nov 26, 2012 at 04:33:28PM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx 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. Gosh, that's a very sudden new consensus. The consensus over the past ten or twenty years has been that the Linux kernel enforce locking for consistent atomic writes, but skip that overhead on reads - hasn't it? > 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. Thanks, that's helpful; but I think linux-mm people would want to defer to linux-fsdevel maintainers on this: mm/filemap.c happens to be in mm/, but a fundamental change to VFS locking philosophy is not mm's call. I don't see that page locking would have anything to do with it: if we are going to start guaranteeing reads atomic against concurrent writes, then surely it's the size requested by the user to be guaranteed, spanning however many pages and fs-blocks: i_mutex, or a more efficiently crafted alternative. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
