From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id F41A66005A4 for ; Tue, 5 Jan 2010 01:09:51 -0500 (EST) Received: by pxi5 with SMTP id 5so11162235pxi.12 for ; Mon, 04 Jan 2010 22:09:50 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20100104182429.833180340@chello.nl> <20100104182813.753545361@chello.nl> <20100105092559.1de8b613.kamezawa.hiroyu@jp.fujitsu.com> <28c262361001042029w4b95f226lf54a3ed6a4291a3b@mail.gmail.com> Date: Tue, 5 Jan 2010 15:09:47 +0900 Message-ID: <28c262361001042209k7241dd38l3d51d230e7b68a5@mail.gmail.com> Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() From: Minchan Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: KAMEZAWA Hiroyuki , Peter Zijlstra , "Paul E. McKenney" , Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , cl@linux-foundation.org, "hugh.dickins" , Nick Piggin , Ingo Molnar List-ID: Hi, Linus. On Tue, Jan 5, 2010 at 1:48 PM, Linus Torvalds wrote: > > > On Tue, 5 Jan 2010, Minchan Kim wrote: >> >> Isn't it protected by get_file and iget? > > When the vma is mapped, yes. > >> Am I miss something? > > remove_vma() will have done a > > =C2=A0 =C2=A0 =C2=A0 =C2=A0fput(vma->vm_file); > > and other house-keeping (removing the executable info, doing > vm_ops->close() etc). > > And that is _not_ done delayed by RCU, and as outlined in my previous > email I think that if the code really _does_ delay it, then munmap() (and > exit) need to wait for the RCU callbacks to have been done, because > otherwise the file may end up being busy "asynchronously" in ways that > break existing semantics. > > Just as an example: imagine a script that does "fork()+execve()" on a > temporary file, and then after waiting for it all to finish with wait4() > does some re-write of the file. It currently works. But what if the > open-for-writing gets ETXTBUSY because the file is still marked as being > VM_DENYWRITE, and RCU hasn't done all the callbacks? > > Or if you do the i_writecount handling synchronously (which is likely fin= e > - it really is just for ETXTBUSY handling, and I don't think speculative > page faults matter), what about a shutdown sequence (or whatever) that > wants to unmount the filesystem, but the file is still open - as it has t= o > be - because the actual close is delayed by RCU. > > So the patch-series as-is is fundamentally buggy - and trying to fix it > seems painful. > > I'm also not entirely clear on how the race with page table tear-down vs > page-fault got handled, but I didn't read the whole patch-series very > carefully. I skimmed through it and got rather nervous about it all. It > doesn't seem too large, but it _does_ seem rather cavalier about all the > object lifetimes. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linus > Thanks for careful explanation, Linus. My humble opinion is following as. Couldn't we synchronize rcu in that cases(munmap, exit and so on)? It can delay munap and exit but it would be better than handling them by mo= re complicated things, I think. And both cases aren't often cases so we can achieve advantage than disadvantage? --=20 Kind regards, Minchan Kim -- 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: email@kvack.org