I've noticed one more thing here:
On Sun 23-03-14 15:08:32, Matthew Wilcox wrote:
....
> +ssize_t dax_do_io(int rw, struct kiocb *iocb, struct inode *inode,
> + const struct iovec *iov, loff_t offset, unsigned nr_segs,
> + get_block_t get_block, dio_iodone_t end_io, int flags)
> +{
...
> + retval = dax_io(rw, inode, iov, offset, end, get_block, &bh);
> +
> + if ((flags & DIO_LOCKING) && (rw == READ))
> + mutex_unlock(&inode->i_mutex);
> +
> + inode_dio_done(inode);
> +
> + if ((retval > 0) && end_io)
> + end_io(iocb, offset, retval, bh.b_private);
In direct IO code, we first call end_io() callback and do
inode_dio_done() only after that. Since filesystems use i_dio_count for
protecting against different races, calling end_io() after inode_dio_done()
can open all sorts of subtle races.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>