From: Boaz Harrosh <boaz@plexistor.com> To: Dave Chinner <david@fromorbit.com> Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>, Andrew Morton <akpm@linux-foundation.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Jan Kara <jack@suse.cz>, Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, linux-nvdimm <linux-nvdimm@ml01.01.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Eryu Guan <eguan@redhat.com> Subject: Re: [PATCH 3/3] RFC: dax: dax_prepare_freeze Date: Tue, 24 Mar 2015 08:14:59 +0200 [thread overview] Message-ID: <551100E3.9010007@plexistor.com> (raw) In-Reply-To: <20150323224047.GQ28621@dastard> On 03/24/2015 12:40 AM, Dave Chinner wrote: > On Mon, Mar 23, 2015 at 02:54:40PM +0200, Boaz Harrosh wrote: >> From: Boaz Harrosh <boaz@plexistor.com> >> >> When freezing an FS, we must write protect all IS_DAX() >> inodes that have an mmap mapping on an inode. Otherwise >> application will be able to modify previously faulted-in >> file pages. > > All you need to do is lock out page faults once the page is clean; > that's what the sb_start_pagefault() calls are for in the page fault > path - they catch write faults and block them until the filesystem > is unfrozen. Hence I'm not sure why this would be necessary if you > are catching write faults in .pfn_mkwrite.... > Jan pointed it out and he was right I have a test for this. What happens is that since we had a mapping from before the freeze we will not have a page-fault. And the buffers will be modified. As Jan explained in the cache path we do a writeback which turns all pages to read-only. But with dax we do not have writeback so the pages stay read-write mapped. Something needs to loop through the pages and write-protect them. I chose to unmap them because it is the much-much smaller code, and I do not care to optimize the freeze. [Yes, sigh, I will convert the test to an xfstest. May I just add it to some existing fs_freeze test. Only novelty is that we need to write-access an mmap block before the freeze-start, then continue access after the freeze and see modifications ] > Cheers, > Dave. > Thanks Boaz
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <boaz@plexistor.com> To: Dave Chinner <david@fromorbit.com> Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>, Andrew Morton <akpm@linux-foundation.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Jan Kara <jack@suse.cz>, Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org, linux-nvdimm <linux-nvdimm@ml01.01.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Eryu Guan <eguan@redhat.com> Subject: Re: [PATCH 3/3] RFC: dax: dax_prepare_freeze Date: Tue, 24 Mar 2015 08:14:59 +0200 [thread overview] Message-ID: <551100E3.9010007@plexistor.com> (raw) In-Reply-To: <20150323224047.GQ28621@dastard> On 03/24/2015 12:40 AM, Dave Chinner wrote: > On Mon, Mar 23, 2015 at 02:54:40PM +0200, Boaz Harrosh wrote: >> From: Boaz Harrosh <boaz@plexistor.com> >> >> When freezing an FS, we must write protect all IS_DAX() >> inodes that have an mmap mapping on an inode. Otherwise >> application will be able to modify previously faulted-in >> file pages. > > All you need to do is lock out page faults once the page is clean; > that's what the sb_start_pagefault() calls are for in the page fault > path - they catch write faults and block them until the filesystem > is unfrozen. Hence I'm not sure why this would be necessary if you > are catching write faults in .pfn_mkwrite.... > Jan pointed it out and he was right I have a test for this. What happens is that since we had a mapping from before the freeze we will not have a page-fault. And the buffers will be modified. As Jan explained in the cache path we do a writeback which turns all pages to read-only. But with dax we do not have writeback so the pages stay read-write mapped. Something needs to loop through the pages and write-protect them. I chose to unmap them because it is the much-much smaller code, and I do not care to optimize the freeze. [Yes, sigh, I will convert the test to an xfstest. May I just add it to some existing fs_freeze test. Only novelty is that we need to write-access an mmap block before the freeze-start, then continue access after the freeze and see modifications ] > Cheers, > Dave. > Thanks Boaz -- 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>
next prev parent reply other threads:[~2015-03-24 6:15 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-23 12:47 [PATCH 0/3 v3] dax: Fix mmap-write not updating c/mtime Boaz Harrosh 2015-03-23 12:47 ` Boaz Harrosh 2015-03-23 12:49 ` [PATCH 1/3] mm: New pfn_mkwrite same as page_mkwrite for VM_PFNMAP Boaz Harrosh 2015-03-23 22:49 ` Andrew Morton 2015-03-23 22:49 ` Andrew Morton 2015-03-23 12:52 ` [PATCH 2/3] dax: use pfn_mkwrite to update c/mtime + freeze protection Boaz Harrosh 2015-03-23 12:54 ` [PATCH 3/3] RFC: dax: dax_prepare_freeze Boaz Harrosh 2015-03-23 22:40 ` Dave Chinner 2015-03-23 22:40 ` Dave Chinner 2015-03-24 6:14 ` Boaz Harrosh [this message] 2015-03-24 6:14 ` Boaz Harrosh 2015-03-25 2:22 ` Dave Chinner 2015-03-25 2:22 ` Dave Chinner 2015-03-25 8:10 ` Boaz Harrosh 2015-03-25 9:29 ` Dave Chinner 2015-03-25 9:29 ` Dave Chinner 2015-03-25 10:19 ` Boaz Harrosh 2015-03-25 10:19 ` Boaz Harrosh 2015-03-25 20:00 ` Dave Chinner 2015-03-25 20:00 ` Dave Chinner 2015-03-26 8:02 ` Boaz Harrosh 2015-03-26 20:58 ` Dave Chinner 2015-03-26 20:58 ` Dave Chinner 2015-03-24 12:37 ` Boaz Harrosh 2015-03-24 12:37 ` Boaz Harrosh 2015-03-25 2:26 ` Dave Chinner 2015-03-25 2:26 ` Dave Chinner 2015-03-25 8:31 ` Boaz Harrosh 2015-03-25 8:31 ` Boaz Harrosh 2015-03-25 9:41 ` Dave Chinner 2015-03-25 9:41 ` Dave Chinner 2015-03-25 10:40 ` Boaz Harrosh 2015-03-25 10:40 ` Boaz Harrosh 2015-03-25 20:05 ` Dave Chinner 2015-03-25 20:05 ` Dave Chinner 2015-03-23 12:56 ` [PATCH v4] xfstest: generic/080 test that mmap-write updates c/mtime Boaz Harrosh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=551100E3.9010007@plexistor.com \ --to=boaz@plexistor.com \ --cc=akpm@linux-foundation.org \ --cc=david@fromorbit.com \ --cc=eguan@redhat.com \ --cc=hughd@google.com \ --cc=jack@suse.cz \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@ml01.01.org \ --cc=matthew.r.wilcox@intel.com \ --cc=mgorman@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.