From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [PATCH, RFC] check for frozen filesystems in the mmap path Date: Tue, 21 Apr 2009 10:15:37 -0500 Message-ID: <49EDE319.10701@redhat.com> References: <49E7C323.9040805@redhat.com> <20090421140045.F125.A69D9226@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel , Linux Kernel Mailing List To: KOSAKI Motohiro Return-path: Received: from mx2.redhat.com ([66.187.237.31]:54986 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755194AbZDUPPm (ORCPT ); Tue, 21 Apr 2009 11:15:42 -0400 In-Reply-To: <20090421140045.F125.A69D9226@jp.fujitsu.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: KOSAKI Motohiro wrote: > >> Index: linux-2.6/mm/memory.c >> =================================================================== >> --- linux-2.6.orig/mm/memory.c >> +++ linux-2.6/mm/memory.c >> @@ -1944,6 +1944,7 @@ static int do_wp_page(struct mm_struct * >> * read-only shared pages can get COWed by >> * get_user_pages(.write=1, .force=1). >> */ >> + vfs_check_frozen(old_page->mapping->host->i_sb, SB_FREEZE_WRITE); >> if (vma->vm_ops && vma->vm_ops->page_mkwrite) { >> struct vm_fault vmf; >> int tmp; > > it seems strage. > > 1. it seems to have a race > > CPU0 CPU1 > ---------------------------------------------------- > do_wp_page > vfs_check_frozen > ioctl_fsfreeze > freeze_bdev > __fsync_super > process touch mem > > vfs_check_frozen only wait to unfreeze, but not prevent new > new freeze request starting. Well, I think that is ok. I don't *think* that any IO can actually happen to the filesystem even if it gets dirtied via mmap, so if a bit of mmap-dirtied memory sneaks in before it's actually frozen, I'm not sure that's really a problem. The goal was to prevent massive amounts of memory from getting dirtied, backed by the frozen filesystem. This would potentially lead to a situation where the un-freezing thread was stuck waiting for memory to free up, stuck behind waiting for the filesystem to unfreeze for writeout, and we can't unfreeze. > 2. this logic kill multi thread application. > > this logic mean mmap_sem grabbing until unfreeze. > it mean othrer thread in the same process can't page-fault although > it don't touch frozen-sb. > it seems strange. Hm, I hadn't thought about this ... On the one hand, ->page_mkwrite can already sleep, though a userspace freeze/unfreeze could potentially take much much longer. freeze/unfreeze *should* happen very quickly, but nothing enforces that. Do you have any suggestions? Thanks, -Eric