On Fri 20-02-15 08:12:10, Dave Chinner wrote:

On Thu, Feb 19, 2015 at 04:42:41PM +0100, Jan Kara wrote:

quoted

On Thu 19-02-15 08:55:23, Dave Chinner wrote:

quoted

On Wed, Feb 18, 2015 at 11:40:09AM +0100, Jan Kara wrote:

quoted

On Tue 17-02-15 08:37:45, Matthew Wilcox wrote:

quoted

On Tue, Feb 17, 2015 at 09:52:00AM +0100, Jan Kara wrote:

quoted

quoted

quoted

This got added to fix a problem that Dave Chinner pointed out.  We need
the allocated extent to either be zeroed (as ext2 does), or marked as
unwritten (ext4, XFS) so that a racing read/page fault doesn't return
uninitialized data.  If it's marked as unwritten, we need to convert it
to a written extent after we've initialised the contents.  We use the
b_end_io() callback to do this, and it's called from the DAX code, not in
softirq context.

  OK, I see. But I didn't find where ->b_end_io gets called from dax code
(specifically I don't see it anywhere in dax_do_IO() or dax_io()). Can you
point me please?

For faults, we call it in dax_insert_mapping(), the very last thing
before returning in the fault path.  The normal I/O path gets to use
the dio_iodone_t for the same purpose.

  I see. I didn't think of races with reads (hum, I actually wonder whether
we don't have this data exposure problem for ext4 for mmapped write into
a hole vs direct read as well). So I guess we do need those unwritten
extent dances after all (or we would need to have a page covering hole when
writing to it via mmap but I guess unwritten extent dances are somewhat
more standard).

Right, that was the reason for doing it that way - it leveraged all
the existing methods we have for avoiding data exposure races in
XFS. but it's also not just for races - it's for ensuring that if we
crash between the allocation and the write to the persistent store
we don't expose the underlying contents when the system next comes
up.

  Well, ext3/4 handles the crash situation differently - we make sure we
flush data to allocated blocks before committing a transaction that
allocates them. That works perfectly for crashes but doesn't avoid the
race with DIO.

I was talking about direct IO, not buffered IO. DAX is modeled on

  Ah, OK. For DIO writes ext4 uses unwritten extents as well. But the race
I was talking about is between mmap allocating write (i.e. going through
page cache) and DIO read of the same location.

the direct IO stack, not buffered IO. I did go and look at the ext4
IO completion path, and I can see where ext4_end_io_dio() triggers a
commit outside of doing unwritten extent conversion. Can you clue me
in - IO completion in ext4 is a maze of twisty passages...

  I don't quite follow you. Why should ext4_end_io_dio() trigger a commit?

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR