Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp492971imm; Wed, 20 Jun 2018 01:35:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJzt+RnZqsSmBF/FQPLOkk9Q4bS1UY0ZVBYP1wfcjwJS1y8ulVZCwSJgGjAOAhu2YTW9NyN X-Received: by 2002:a63:7205:: with SMTP id n5-v6mr17830882pgc.337.1529483734361; Wed, 20 Jun 2018 01:35:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529483734; cv=none; d=google.com; s=arc-20160816; b=lDWoaBuacsTiukN8XugcHQQqbryk3RUggOwH8HoeuV/mJR/q3YUPHMbqEUev1febY9 +Fkdl5DhXWprWrCKeIq7ImmH3q4wuYH6KvXesFcJlE5w9GXp/YyNax3btlSycnXJ4CSA kmyQ46duHo2ldFnRd5AqP0l3/poNv/TyfVLkgYYMjFG3m3/hGAolNkDDdT1JjsjXk5DZ 1Dx92tvIBvt4/NXuaIho6lCkG1byvvUogAKYFFPZjhEEAo0Kd7lTEjyjTsRY3j1RcTem gbLEa8dj69SVSSsyd3vsK4bWnC9PUMqloz6nmem4tHugR+UM/OBxO8eqzYM+mhQ5tXI0 tWSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=24hq3AB5sCB8I6dhzpBgeH38hIVtIRGTs/A17IWWEto=; b=SA1UOt8KFEiobmm8hwRHsbgm7aGFcFH69WkNHqszLfms0MMjdT/2hrYSgFSWxBXsgk UXT75GcDBsmFlVmFgPW/uAXmMaNplvioiOiEabFelu2iDeFP2Vy9UF3AuhJwxPB2vPNJ 4jYI0STJHXFr67doEQHjk+++GTH0gP7aGteswdvaTlbTy+B3Ri5KswNoBdYnkRAC1bTA Fm7A9pTkF2fHcsQLCd05jyB+IfFuGORa1aBvZehN9jYFv8Vu/gdp+MBOxHiRdALSJF30 RwFtavwxsh6Bkv2BKyp7LGouzW9vEhPDdN1myXMEFF5/PCKNfTwcPXYLp5B3rH4eXayb hyVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7-v6si1530921pgo.81.2018.06.20.01.35.20; Wed, 20 Jun 2018 01:35:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754586AbeFTIdv (ORCPT + 99 others); Wed, 20 Jun 2018 04:33:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:57406 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754290AbeFTIdn (ORCPT ); Wed, 20 Jun 2018 04:33:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7E7E8AC53; Wed, 20 Jun 2018 07:17:10 +0000 (UTC) Date: Wed, 20 Jun 2018 09:17:08 +0200 From: Michal Hocko To: Yang Shi Cc: Peter Zijlstra , willy@infradead.org, ldufour@linux.vnet.ibm.com, akpm@linux-foundation.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v2 PATCH 2/2] mm: mmap: zap pages with read mmap_sem for large mapping Message-ID: <20180620071708.GI13685@dhcp22.suse.cz> References: <1529364856-49589-1-git-send-email-yang.shi@linux.alibaba.com> <1529364856-49589-3-git-send-email-yang.shi@linux.alibaba.com> <20180619100218.GN2458@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 19-06-18 14:13:05, Yang Shi wrote: > > > On 6/19/18 3:02 AM, Peter Zijlstra wrote: [...] > > Hold up, two things: you having to copy most of do_munmap() didn't seem > > to suggest a helper function? And second, since when are we allowed to > > Yes, they will be extracted into a helper function in the next version. > > May bad, I don't think it is allowed. We could reform this to: > > acquire write mmap_sem > vma lookup (split vmas) > release write mmap_sem > > acquire read mmap_sem > zap pages > release read mmap_sem > > I'm supposed this is safe as what Michal said before. I didn't get to read your patches carefully yet but I am wondering why do you need to split in the first place. Why cannot you simply unmap the range (madvise(DONTNEED)) under the read lock and then take the lock for write to finish the rest? -- Michal Hocko SUSE Labs