Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3530593imm; Mon, 6 Aug 2018 06:28:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpei5voR8Zhn9//jlgRUTX27Llt7QoqvdbyNxp18m8XogYwALPTeeHnU1rtO2JxO0O4vJe9z X-Received: by 2002:a63:fe02:: with SMTP id p2-v6mr14632771pgh.148.1533562084632; Mon, 06 Aug 2018 06:28:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533562084; cv=none; d=google.com; s=arc-20160816; b=IFJ/E40D2B5TE0Ho84EwGm0hPqSYaqL9i15a8p53oif9E+VGZCrL0mAvMPshrg2Naz hFp7TLnJYLyAaUsjdRA9kRSmYvglDALzs8sOTpcHiF++hvA+Jvd6rvUSM1EmcKwz5K0M hJaFuxVEkI/eeMT/irNFv/VzZVnbmX5YMcEt/vgmZK3Y5TUZt1OKVO1j/f7uCewGWWu5 LUQNVDMQU4HQwenJHkkVf/8lGUCWn6lMF7VQhpn6GDgoaMsUNFuB2UJthrSHamj3Y8fq UbKdbq2XHWT2WhzrkqAH5m8Vl7n6Hbx1cVkjTZRCYKXkWiM0CkF80hENWGcOtnuDHw9F lalA== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=5KGdeeUFDVlYfuSih4n4DSlO1S0IsHqEQ+kMpAV/ICs=; b=B/9jz9qR5Fv8LoWxty2gBUhDiOdhoMy22aRREHB8QrZLoRm/a4eeWNXY6QUOpS1/T1 3PXBER0kril78n2RzIQLsVB4al8RQx0wJIYyIuUfwu9oNN/kcjdQR4U4tRh5S8Gkyl/p +Fgp4+x+onkJLSn509+bKK+nBgfJgoNvdPB+87Jj0Pfy2fNslN1iwytRVadp/LHKGtDJ 5dryhs5gaYEn5tcopnW+4eycaWxnjzrhKvOtdqyHf+4saYmHkwE0MXbaj2X1UV3D1PKd hXFedzezw1+NtLzuCDmLoCm0HxQb6h9/QRkGU3wkHRfgaob8GKW3ywuh+Bj8F2icGs2o h33A== 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 t128-v6si12818771pgt.614.2018.08.06.06.27.49; Mon, 06 Aug 2018 06:28:04 -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 S1728475AbeHFPgH (ORCPT + 99 others); Mon, 6 Aug 2018 11:36:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:32822 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727510AbeHFPgH (ORCPT ); Mon, 6 Aug 2018 11:36:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 02966AFE0; Mon, 6 Aug 2018 13:26:58 +0000 (UTC) Date: Mon, 6 Aug 2018 15:26:57 +0200 From: Michal Hocko To: Yang Shi Cc: willy@infradead.org, ldufour@linux.vnet.ibm.com, kirill@shutemov.name, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v6 PATCH 1/2] mm: refactor do_munmap() to extract the common part Message-ID: <20180806132657.GB22858@dhcp22.suse.cz> References: <1532628614-111702-1-git-send-email-yang.shi@linux.alibaba.com> <1532628614-111702-2-git-send-email-yang.shi@linux.alibaba.com> <20180803085335.GH27245@dhcp22.suse.cz> <7b84088a-4e49-ed7c-e750-7aba5cc17f11@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7b84088a-4e49-ed7c-e750-7aba5cc17f11@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 03-08-18 13:47:19, Yang Shi wrote: > > > On 8/3/18 1:53 AM, Michal Hocko wrote: > > On Fri 27-07-18 02:10:13, Yang Shi wrote: > > > Introduces three new helper functions: > > > * munmap_addr_sanity() > > > * munmap_lookup_vma() > > > * munmap_mlock_vma() > > > > > > They will be used by do_munmap() and the new do_munmap with zapping > > > large mapping early in the later patch. > > > > > > There is no functional change, just code refactor. > > > > > > Reviewed-by: Laurent Dufour > > > Signed-off-by: Yang Shi > > > --- > > > mm/mmap.c | 120 ++++++++++++++++++++++++++++++++++++++++++-------------------- > > > 1 file changed, 82 insertions(+), 38 deletions(-) > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > index d1eb87e..2504094 100644 > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -2686,34 +2686,44 @@ int split_vma(struct mm_struct *mm, struct vm_area_struct *vma, > > > return __split_vma(mm, vma, addr, new_below); > > > } > > > -/* Munmap is split into 2 main parts -- this part which finds > > > - * what needs doing, and the areas themselves, which do the > > > - * work. This now handles partial unmappings. > > > - * Jeremy Fitzhardinge > > > - */ > > > -int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, > > > - struct list_head *uf) > > > +static inline bool munmap_addr_sanity(unsigned long start, size_t len) > > munmap_check_addr? Btw. why does this need to have munmap prefix at all? > > This is a general address space check. > > Just because I extracted this from do_munmap, no special consideration. It > is definitely ok to use another name. > > > > > > { > > > - unsigned long end; > > > - struct vm_area_struct *vma, *prev, *last; > > > - > > > if ((offset_in_page(start)) || start > TASK_SIZE || len > TASK_SIZE-start) > > > - return -EINVAL; > > > + return false; > > > - len = PAGE_ALIGN(len); > > > - if (len == 0) > > > - return -EINVAL; > > > + if (PAGE_ALIGN(len) == 0) > > > + return false; > > > + > > > + return true; > > > +} > > > + > > > +/* > > > + * munmap_lookup_vma: find the first overlap vma and split overlap vmas. > > > + * @mm: mm_struct > > > + * @vma: the first overlapping vma > > > + * @prev: vma's prev > > > + * @start: start address > > > + * @end: end address > > This really doesn't help me to understand how to use the function. > > Why do we need both prev and vma etc... > > prev will be used by unmap_region later. But what does it stand for? Why cannot you take prev from the returned vma? In other words, if somebody reads this documentation how does he know what the prev is supposed to be used for? > > > + * > > > + * returns 1 if successful, 0 or errno otherwise > > This is a really weird calling convention. So what does 0 tell? /me > > checks the code. Ohh, it is nothing to do. Why cannot you simply return > > the vma. NULL implies nothing to do, ERR_PTR on error. > > A couple of reasons why it is implemented as so: > > ??? * do_munmap returns 0 for both success and no suitable vma > > ??? * Since prev is needed by finding the start vma, and prev will be used > by unmap_region later too, so I just thought it would look clean to have one > function to return both start vma and prev. In this way, we can share as > much as possible common code. > > ??? * In this way, we just need return 0, 1 or error no just as same as what > do_munmap does currently. Then we know what is failure case exactly to just > bail out right away. > > Actually, I tried the same approach as you suggested, but it had two > problems: > > ??? * If it returns the start vma, we have to re-find its prev later, but > the prev has been found during finding start vma. And, duplicate the code in > do_munmap_zap_rlock. It sounds not that ideal. > > ??? * If it returns prev, it might be null (start vma is the first vma). We > can't tell if null is a failure or success case Even if you need to return both vma and prev then it would be better to simply return vma directly than having this -errno, 0 or 1 return semantic. -- Michal Hocko SUSE Labs