On Mon 13-01-20 16:34:21, Ritesh Harjani wrote: > Some filesystems (e.g. ext4) need to know in it's writeback path, that > whether DIO is in progress or not. This info may be needed to avoid the > stale data exposure race with DIO reads. > > Signed-off-by: Ritesh Harjani <riteshh@xxxxxxxxxxxxx> > --- > fs/iomap/direct-io.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > index 23837926c0c5..d1c159bd3854 100644 > --- a/fs/iomap/direct-io.c > +++ b/fs/iomap/direct-io.c > @@ -468,9 +468,18 @@ iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter, > flags |= IOMAP_NOWAIT; > } > > + /* > + * Call inode_dio_begin() before we write out and wait for writeback to > + * complete. This may be needed by some filesystems to prevent race > + * like stale data exposure by DIO reads. > + */ > + inode_dio_begin(inode); > + /* So that i_dio_count is incremented before below operation */ > + smp_mb__after_atomic(); I wonder if the barrier shouldn't go into inode_dio_begin() - as a sepatare patch. Because people just treat this as a lock-kind-of-thingy. E.g. btrfs or ceph use inode_dio_begin() in places which I'd consider prone to CPU reordering issues without this barrier... Otherwise the patch looks good to me. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
