From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16402C11D0C for ; Thu, 20 Feb 2020 18:37:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD31024673 for ; Thu, 20 Feb 2020 18:37:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GesQ7lYk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD31024673 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 825826B0008; Thu, 20 Feb 2020 13:37:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D6006B000A; Thu, 20 Feb 2020 13:37:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 712176B000C; Thu, 20 Feb 2020 13:37:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 57D5B6B0008 for ; Thu, 20 Feb 2020 13:37:07 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 090318248047 for ; Thu, 20 Feb 2020 18:37:07 +0000 (UTC) X-FDA: 76511362494.24.money91_78489339f4837 X-HE-Tag: money91_78489339f4837 X-Filterd-Recvd-Size: 4456 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 18:37:06 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id j17so34917527edp.3 for ; Thu, 20 Feb 2020 10:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/YLO2bhUMXaHjjPXShp3huY7KpBtYfU38ziSj3KJtuA=; b=GesQ7lYk8wtZKtmYXQL7fOf8FPAcNkpaXnz+pGMSsJ6UFBQf3mabWlZGElbQsvjQYq Czb00gxji/FQzvdSbj/gzPxrmrly/B/H73V5+iih6bnYg1dlzlo2pBrDFFLm9co9oYOI 0k+O0x/3t3FF8+8tFiUTS8CsL/Q+nQGCL6gD4XLjMLQ2My+WEQdk2vqSNuPmRSu6yvoH P+k5oO3SwR+9M5xefJGB1ysLKencdBayMGWZT+Wzf0A6+T27omS+WvK2GhxURkJEGybm Yvps14ZPdFJdVa7Qfnn2znyx/CoTXsSlLYgIWP35JipzWdYdy5lRg6t3TJ1tMm5BEGhB +pLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/YLO2bhUMXaHjjPXShp3huY7KpBtYfU38ziSj3KJtuA=; b=pOn/Z/GZCMrqrpGMeMJE4eI3+Pufh1wm40vfF/pn/P9PxIq//jrR1ZkQTWn3VpnIg6 zL2Yu/7CwvP7HUMtn3tpTtjIqfeAJgd4A8tsUEkQtnsblGT6EMg5PMiG+liQJn8vQQz+ NiI1Oy/9Yixa3JBOkYPCb8iv96LS4aIzVsJ0nd6Gp6GKDILfZSM0YTsJGDrv4HGkzziy P/Am0tY3M210Uav0SZb3lbAvEydSge4DEnFWVUODk/sOgzC5SSawUAen6cHhfS0omulH WXQIFl8HKRghL+pJlfjg180cc/JoXN/FTChAQK2euMprcMohSxluZt7cNpIMF3QWMY69 mN/Q== X-Gm-Message-State: APjAAAVqHV/pN1UENHEPQ7MX1qfndzE2ajWE4hoca7RN3Xq7PUirLiyP zQaTZj977VWj5pL1fd7g6e9+60s6GCg8m90kJulWsA== X-Google-Smtp-Source: APXvYqxrghlu/JDWCN4t4BnUKHd0MsnmE1Vp+aqUdtfvoWzihkUYU4fRwdrUP4RI6V9L0uALG2Pft6Zxunx7cJsOx0c= X-Received: by 2002:a17:906:4e01:: with SMTP id z1mr31260697eju.46.1582223824847; Thu, 20 Feb 2020 10:37:04 -0800 (PST) MIME-Version: 1.0 References: <20200218173221.237674-1-bgeffon@google.com> <20200220171554.GA44866@google.com> In-Reply-To: <20200220171554.GA44866@google.com> From: Brian Geffon Date: Thu, 20 Feb 2020 10:36:38 -0800 Message-ID: Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). To: Minchan Kim Cc: Andrew Morton , "Michael S . Tsirkin" , Arnd Bergmann , LKML , linux-mm , Linux API , Andy Lutomirski , Will Deacon , Andrea Arcangeli , Sonny Rao , Joel Fernandes , Yu Zhao , Jesse Barnes , Florian Weimer , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Minchan, > And here we got error if the addr is in non-anonymous-private vma so the > syscall will fail but old vma is gone? I guess it's not your intention? This is exactly what happens today in several situations, because vma_to_resize is called unconditionally. For example if the old vma has VM_HUGETLB and old_len < new_len it would have unmapped a portion and then in vma_to_resize returned -EINVAL, similarly when old_len = 0 with a non-sharable mapping it will have called do_munmap only to fail in vma_to_resize, if the vma has VM_DONTEXPAND set and you shrink the size with old_len < new_len it would return -EFAULT after having done the unmap on the decreased portion. So I followed the pattern to keep the change simple and maintain consistency with existing behavior. But with that being said, Kirill made the point that resizing a VMA while also using MREMAP_DONTUNMAP doesn't have any clear use case and I agree with that, I'm unable to think of a situation where you'd want to resize a VMA and use MREMAP_DONTUNMAP. So I'm tempted to mail a new version which returns -EINVAL if old_len != new_len that would resolve this concern here as nothing would be unmapped ever at the old position add it would clean up the change to very few lines of code. What do you think? Thank you for taking the time to review. Brian