From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264492AbTIDBmc (ORCPT ); Wed, 3 Sep 2003 21:42:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264495AbTIDBmb (ORCPT ); Wed, 3 Sep 2003 21:42:31 -0400 Received: from dp.samba.org ([66.70.73.150]:24497 "EHLO lists.samba.org") by vger.kernel.org with ESMTP id S264492AbTIDBm3 (ORCPT ); Wed, 3 Sep 2003 21:42:29 -0400 From: Rusty Russell To: Hugh Dickins Cc: Jamie Lokier , Andrew Morton , Ingo Molnar , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH] Alternate futex non-page-pinning and COW fix In-reply-to: Your message of "Wed, 03 Sep 2003 12:19:53 +0100." Date: Thu, 04 Sep 2003 11:30:04 +1000 Message-Id: <20030904014229.2EFBF2C097@lists.samba.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In message you write: > On Wed, 3 Sep 2003, Jamie Lokier wrote: > > I have an obvious fix for mremap(): rehash all the futexes in its > > range. That's not in the attached patch, but it will be in the next one. > > Will it be worth the code added to handle it? I wonder the same of > non-linear (sys_mremap and sys_remap_file_pages, familiar troublemakers). > But all credit for handling them, good to reduce "undefined behaviour"s. I don't have a problem with the omission. mremap is logically equivalent to munmap + mmap, so it's a subset of the "I unmapped underneath my futex!". It's not like it's going to happen without the caller knowing: if the address doesn't change, then the futexes won't break. If they do, the caller needs to reset them anyway. Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.