Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1739380
| From | Dave Chinner <david@fromorbit.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/7] xfs: protect S_DAX transitions in XFS write path |
| Date | 2017-09-26 02:10 +0200 |
| Message-ID | <utLBL-5lc-3@gated-at.bofh.it> (permalink) |
| References | <utKPp-4Lc-5@gated-at.bofh.it> <utKPp-4Lc-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Sep 25, 2017 at 05:14:01PM -0600, Ross Zwisler wrote: > In the current XFS write I/O path we check IS_DAX() in > xfs_file_write_iter() to decide whether to do DAX I/O, direct I/O or > buffered I/O. This check is done without holding the XFS_IOLOCK, though, > which means that if we allow S_DAX to be manipulated via the inode flag we > can run into this race: > > CPU 0 CPU 1 > ----- ----- > xfs_file_write_iter() > IS_DAX() << returns false > xfs_ioctl_setattr() > xfs_ioctl_setattr_dax_invalidate() > xfs_ilock(XFS_MMAPLOCK|XFS_IOLOCK) > sets S_DAX > releases XFS_MMAPLOCK and XFS_IOLOCK > xfs_file_buffered_aio_write() > does buffered I/O to DAX inode, death > > Fix this by ensuring that we only check S_DAX when we hold the XFS_IOLOCK > in the write path. NACK. This breaks concurrent direct IO write semantics. We must not take XFS_IOLOCK_EXCL on direct IO writes unless it is absolutely necessary - there are lots of applications out there that rely on these semantics for performance. CHeers, Dave. -- Dave Chinner david@fromorbit.com
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 4/7] xfs: protect S_DAX transitions in XFS write path Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-26 01:20 +0200 Re: [PATCH 4/7] xfs: protect S_DAX transitions in XFS write path Dave Chinner <david@fromorbit.com> - 2017-09-26 02:10 +0200
csiph-web