From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:51470 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752347AbdHJOWv (ORCPT ); Thu, 10 Aug 2017 10:22:51 -0400 From: Jeff Moyer To: Jan Kara Cc: Lukas Czerner , linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, david@fromorbit.com Subject: Re: [PATCH v6] fs: Fix page cache inconsistency when mixing buffered and AIO DIO References: <1500463692-4982-1-git-send-email-lczerner@redhat.com> <1502369997-15665-1-git-send-email-lczerner@redhat.com> <20170810135640.GB14925@quack2.suse.cz> Date: Thu, 10 Aug 2017 10:22:47 -0400 In-Reply-To: <20170810135640.GB14925@quack2.suse.cz> (Jan Kara's message of "Thu, 10 Aug 2017 15:56:40 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jan Kara writes: > On Thu 10-08-17 14:59:57, Lukas Czerner wrote: >> Currently when mixing buffered reads and asynchronous direct writes it >> is possible to end up with the situation where we have stale data in the >> page cache while the new data is already written to disk. This is >> permanent until the affected pages are flushed away. Despite the fact >> that mixing buffered and direct IO is ill-advised it does pose a thread >> for a data integrity, is unexpected and should be fixed. >> >> Fix this by deferring completion of asynchronous direct writes to a >> process context in the case that there are mapped pages to be found in >> the inode. Later before the completion in dio_complete() invalidate >> the pages in question. This ensures that after the completion the pages >> in the written area are either unmapped, or populated with up-to-date >> data. Also do the same for the iomap case which uses >> iomap_dio_complete() instead. >> >> This has a side effect of deferring the completion to a process context >> for every AIO DIO that happens on inode that has pages mapped. However >> since the consensus is that this is ill-advised practice the performance >> implication should not be a problem. >> >> This was based on proposal from Jeff Moyer, thanks! > > It seems the invalidation can be also removed from > generic_file_direct_write(), can't it? It is duplicit there the same way as > it was in the iomap code... Yep, sure looks that way. -Jeff