On 03/05/2015 12:35 PM, Jan Kara wrote: > On Thu 05-03-15 11:32:25, Boaz Harrosh wrote: >> On 03/05/2015 11:24 AM, Boaz Harrosh wrote: <> >> >> Just as curiosity, does the freezing code goes and turns all mappings >> into read-only, Also for pfn mapping? > Hum, that's a good question. Probably we don't end up doing that. For > > normal filesystems we sync all inodes which also writeprotects all pages > (in clear_page_dirty_for_io() - for normal filesystems we know that if page > is writeably mapped it is dirty). However this won't happen for pfn > mapping as we don't have dirty pages. So we probably need dax_freeze() > implementation that will walk through all inodes with writeable mappings and > writeprotect them. > I'll go head and try my shot on implementing a dax_freeze(). But I will please need help with where to call it from. Probably something like: if (IS_DAX(inode)) dax_freeze(inode); else sync(inode) So to share the for-all-inodes-in-sb loop. And also the IS_DAX(inode) is per inode, for example dirs need the regular sync (if they are using page cache) >> Do you think there is already an xfstest freezing test that should now >> fail, and will succeed after this patch (v2). Something like: >> * mmap-read/write before the freeze >> * freeze the fs >> * Another thread tries to mmap-write, should get stuck >> * unfreeze the fs >> * Now mmap-writer continues > I don't remember there would be any test to specifically test this. > OK Thanks, I was hopping we should already test for mmap vs freeze. This is not special for our case. Actually mmap is the most fragile access. > Honza > Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
