On Tue, Jul 25, 2017 at 02:50:37PM +0200, Jan Kara wrote:

On Tue 25-07-17 14:15:22, Christoph Hellwig wrote:

quoted

On Tue, Jul 25, 2017 at 11:35:08AM +0200, Jan Kara wrote:

quoted

On Tue 25-07-17 10:01:58, Christoph Hellwig wrote:

quoted

On Tue, Jul 25, 2017 at 01:14:00AM +0300, Kirill A. Shutemov wrote:

quoted

I guess it's up to filesystem if it wants to reuse the same spot to write
data or not. I think your assumptions works for ext4 and xfs. I wouldn't
be that sure for btrfs or other filesystems with CoW support.

Or XFS with reflinks for that matter.  Which currently can't be
combined with DAX, but I had a somewhat working version a few month
ago.

But in cases like COW when the block mapping changes, the process
must run unmap_mapping_range() before installing the new PTE so that all
processes mapping this file offset actually refault and see the new
mapping. So this would go through pte_none() case. Am I missing something?

Yes, for DAX COW mappings we'd probably need something like this, unlike
the pagecache COW handling for which only the underlying block change,
but not the page.

Right. So again nothing where the WARN_ON should trigger.

Yes. I was confused on how COW is handled.

Acked-by: Kirill A. Shutemov <redacted>

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>