Thread (12 messages) 12 messages, 4 authors, 2017-07-25

Re: [PATCH v5 1/5] mm: add vm_insert_mixed_mkwrite()

From: Jan Kara <jack@suse.cz>
Date: 2017-07-25 12:50:37
Also in: linux-ext4, linux-fsdevel, linux-mm, lkml, nvdimm

On Tue 25-07-17 14:15:22, Christoph Hellwig wrote:
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. That being said I
don't care about the WARN_ON too deeply but it can help to catch DAX bugs
so if we can keep it I'd prefer to do so...

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help