Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 15 Aug 2002 19:56:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 15 Aug 2002 19:56:26 -0400 Received: from mx1.elte.hu ([157.181.1.137]:18831 "HELO mx1.elte.hu") by vger.kernel.org with SMTP id ; Thu, 15 Aug 2002 19:56:26 -0400 Date: Fri, 16 Aug 2002 02:00:57 +0200 (CEST) From: Ingo Molnar Reply-To: Ingo Molnar To: Linus Torvalds Cc: Jamie Lokier , Subject: Re: [patch] user-vm-unlock-2.5.31-A2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1128 Lines: 31 On Thu, 15 Aug 2002, Linus Torvalds wrote: > > okay. And it also makes sense for a newly forked task to know (and cache) > > its own PID, without having to call getpid() again. > > Well, it won't. The pid write is _after_ we've done the copy_mm(), so > the child will never see it. hmm. > That looks like a potential mistake, though - it causes extra COW-faults > and it also means that this particular optimization (which I kind of > like) won't work. > > However, if you want to fix it, you'd need to either move the > clone_thread() earlier, or you'd need to move the CLONE_SETTID logic up > to the generic layer (that latter path may make more sense, since if > glibc starts using this interface, you obviously need to do this in all > architectures anyway) CLONE_SETTID indeed makes more sense in the do_fork() proper, there's absolutely nothing x86-ish about it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/