Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 27 Sep 2002 05:13:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 27 Sep 2002 05:13:17 -0400 Received: from mx2.elte.hu ([157.181.151.9]:49126 "HELO mx2.elte.hu") by vger.kernel.org with SMTP id ; Fri, 27 Sep 2002 05:13:16 -0400 Date: Fri, 27 Sep 2002 11:27:05 +0200 (CEST) From: Ingo Molnar Reply-To: Ingo Molnar To: Martin Wirth Cc: linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [patch] 'sticky pages' support in the VM, futex-2.5.38-C5 In-Reply-To: <3D941150.8060409@dlr.de> 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: 989 Lines: 25 On Fri, 27 Sep 2002, Martin Wirth wrote: > Maybe you can resurrect your approach by using a sticky counter instead > of a flag. If there are really that many unused fields in struct page > for the case considered here this should be possible. well obviously it can be solved by putting more stuff into struct page, but this whole exercise centers around trying to avoid that. > But another point: what happens if get_user_pages (and the > sticky-setting) is called after the fork completed? If there was no > write access to the page between the fork and the futex call you may get > the same race. this is not a problem, the patch solves this, by using the 'writable' flag to get_user_page(), which un-COWs any potential COW page. 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/