From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754705AbZDVBfc (ORCPT ); Tue, 21 Apr 2009 21:35:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752433AbZDVBfW (ORCPT ); Tue, 21 Apr 2009 21:35:22 -0400 Received: from fgwmail7.fujitsu.co.jp ([192.51.44.37]:49241 "EHLO fgwmail7.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644AbZDVBfV (ORCPT ); Tue, 21 Apr 2009 21:35:21 -0400 From: KOSAKI Motohiro To: Eric Sandeen Subject: Re: [PATCH, RFC] check for frozen filesystems in the mmap path Cc: kosaki.motohiro@jp.fujitsu.com, linux-fsdevel , Linux Kernel Mailing List In-Reply-To: <49EDE319.10701@redhat.com> References: <20090421140045.F125.A69D9226@jp.fujitsu.com> <49EDE319.10701@redhat.com> Message-Id: <20090422085833.6268.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Date: Wed, 22 Apr 2009 10:35:14 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >> 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. Ah, I see. one another question. Why dirty limit don't works properly in this case? > > 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?