From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757580Ab2DTTdP (ORCPT ); Fri, 20 Apr 2012 15:33:15 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:58594 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751657Ab2DTTdH (ORCPT ); Fri, 20 Apr 2012 15:33:07 -0400 Date: Fri, 20 Apr 2012 12:32:45 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Linus Torvalds cc: Al Viro , linux-fsdevel@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford , Dmitry Kasatkin , Mimi Zohar , David Miller , Andrew Morton Subject: Re: [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) In-Reply-To: Message-ID: References: <1334754302.2137.8.camel@falcor> <1334772473.2137.22.camel@falcor> <20120418183938.GH6589@ZenIV.linux.org.uk> <1334865448.2429.35.camel@falcor> <20120420004303.GB6871@ZenIV.linux.org.uk> <20120420190418.GK6871@ZenIV.linux.org.uk> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Apr 2012, Linus Torvalds wrote: > On Fri, Apr 20, 2012 at 12:04 PM, Al Viro wrote: > > > > Deferring the final pass after dropping ->mmap_sem is going to be > > interesting; what would protect ->vm_next on those suckers? > > Just remove them from the active list, and keep them linked to each > other using vm_next. > > After all, the only case we care about is the case where the vma gets > removed entirely, so we just put them on their own list. > > In fact, that's what we already do for other reasons. See > detach_vmas_to_be_unmapped(). > > So vm_next is actually entirely *private* by this time, and needs no > locking at all. > > As far as I can tell, we could just make do_munmap() return that > private list, and then do the fput's and freeing of the list outside > the mmap_sem lock. > > That actually looks pretty simple. There are a fair number of callers, > which looks to be the main annoyance. But fixing it up with some > pattern of "do finish_munmap after drooping the mmap_sem" doesn't look > *complicated*, just slightly annoying. > > The *bigger* annoyance is actually "do_mmap()", which does a > do_munmap() as part of it, so it needs the same cleanup too. > > There might be other cases that do munmap as part of their operation > (and that have the mmap_sem held outside of the caller), but > do_munmap() and do_mmap() seem to be the two obvious ones. > > Many of the callers seem to do the mmap_sem() right around the call, > though (see binfmt_elf.c for example), so it really would be a rather > local fixup. Yes, that's exactly how I was thinking of it. Hugh