Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265451AbTIDSeH (ORCPT ); Thu, 4 Sep 2003 14:34:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265444AbTIDSeH (ORCPT ); Thu, 4 Sep 2003 14:34:07 -0400 Received: from bay-bridge.veritas.com ([143.127.3.10]:33413 "EHLO mtvmime01.veritas.com") by vger.kernel.org with ESMTP id S265451AbTIDSeC (ORCPT ); Thu, 4 Sep 2003 14:34:02 -0400 Date: Thu, 4 Sep 2003 19:35:46 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@localhost.localdomain To: Jamie Lokier cc: Rusty Russell , Andrew Morton , Ingo Molnar , , Linus Torvalds Subject: Re: [PATCH 2] Little fixes to previous futex patch In-Reply-To: <20030904175939.GD30394@mail.jlokier.co.uk> 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: 1231 Lines: 29 On Thu, 4 Sep 2003, Jamie Lokier wrote: > > I don't see why you can't clear the flag: the call to ->populate will > change every page and pte_file to correspond with the linear page > offsets, which is all that !VM_NONLINEAR indicates. You're assuming that one call to sys_remap_file_pages precisely populates a whole vma: no, it's quite likely it'll just do a single page of the vma. > The important things are that the futex is queued prior to checking > curval, the requested page won't change (it's protected by mmap_sem), > and any parallel waker changes the word prior to waking us. Ah, that may well be so, it's beyond me, just so long as Rusty is happy with it. (I don't think you mean "the requested page won't change" - the down_read on mmap_sem does not prevent it from being swapped out before the get_user, but nor does it prevent a replacement page being faulted back in by get_user, and we no longer have any dependence on those being the same physical page.) Hugh - 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/