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 61ABAC11D25 for ; Thu, 20 Feb 2020 23:56:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2201F24653 for ; Thu, 20 Feb 2020 23:56:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="XXGyT2OT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2201F24653 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 AB65F6B0005; Thu, 20 Feb 2020 18:56:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A672C6B0006; Thu, 20 Feb 2020 18:56:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 956926B0007; Thu, 20 Feb 2020 18:56:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 79AE86B0005 for ; Thu, 20 Feb 2020 18:56:22 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3A5BD4995F7 for ; Thu, 20 Feb 2020 23:56:22 +0000 (UTC) X-FDA: 76512167004.25.crib97_8edf9bd888a09 X-HE-Tag: crib97_8edf9bd888a09 X-Filterd-Recvd-Size: 4836 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 23:56:21 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id j17so178056edp.3 for ; Thu, 20 Feb 2020 15:56:21 -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=NNDEYAC7DB9YZj2gZI9Z6zcgcjYXY0WlNUd/lj4aAPs=; b=XXGyT2OTWpB64th/vPVkrN8ruW2f9cZk6TbylbolgAVKvklROGPImgdexYcm7PLy+f BQTWWPL1F3qIN7l3Dq0t9Uu68LaVEjTVVH3auFqU7GxZPXIvpkmrC16+4Z1H1cJOebL5 Lvo1QJHLtGwmVRsdCOiaMRq4DYeqlDXcfrVJdD7R2pwkOZREAbrYu4uO69FSE1NQjX41 LHAhCWZNeW5WU9pBAp27tB02+HKXN20P76igbJaaQi0x/nItXf1MM5UocyVhxVMtvBJ3 ayy3sAy5iev4TWkVL/NJTUQfH2mnlc/NEqADgydaiOsyVsK7eC5LwvaXHBbFhtT3g4wp 4ivQ== 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=NNDEYAC7DB9YZj2gZI9Z6zcgcjYXY0WlNUd/lj4aAPs=; b=XnoHlRl0w5/5YPpQaV8m/Dq8bW2XUwlGd0wlXcva+tKw8gfTYxIbNaaS0O6ZH7ODZv g3idLxEQ08nFaDwJiOo9tZ25L8ZobHDhJCbxmyv2M9rKyEfbe4pc/PJEUZeIXXRImJWw e4C27zkl/vHFoaQ64BzfaxWgdzisF1b1wsLFjbJn3H86HvVUwlFs4Uk3U+yont668bqc ashaVg88XuPU8ellS8rbF0g+Sn0O1FKwpZITPdoHnrFbcknbrVF795HhFS7GGThBmi9K dSnXQQGRAQnDIWSjrN4z1gLUZl9TA50wELOWFAf3OpuPpUDV43rY9ca01YRCA1L/v07M A0fw== X-Gm-Message-State: APjAAAV3OHxOfx3E6wYurUdFFJuLYhtnBVrNJ48EvVbvdE/+6dtP+k+n IbjBxKMBPDn9pBCUmH0HWQQv3AOLlSUcRhL8vMlclg== X-Google-Smtp-Source: APXvYqzpKwKC1T9/jdMm4FY8y3lkou+3lv6gj8We0ELkhEzlN9PeYavWhHfqwfiG/wqIc9ypFDi9U3oCF2x+1nSM0Og= X-Received: by 2002:a05:6402:6c7:: with SMTP id n7mr30390013edy.177.1582242980107; Thu, 20 Feb 2020 15:56:20 -0800 (PST) MIME-Version: 1.0 References: <20200218173221.237674-1-bgeffon@google.com> <20200220115744.ummq6j5ejp5qojic@box> In-Reply-To: <20200220115744.ummq6j5ejp5qojic@box> From: Brian Geffon Date: Thu, 20 Feb 2020 15:55:53 -0800 Message-ID: Subject: Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap(). To: "Kirill A. Shutemov" Cc: Andrew Morton , "Michael S . Tsirkin" , Arnd Bergmann , LKML , linux-mm , Linux API , Andy Lutomirski , Will Deacon , Andrea Arcangeli , Sonny Rao , Minchan Kim , Joel Fernandes , Yu Zhao , Jesse Barnes , Florian Weimer 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 Kirill, > I have hard time understanding the case when new_len != old_len. > > Correct me if I'm wrong, but looks like that you change the size of old > mapping to be the new_len and then create a new of the same new_len. > > This doesn't look right to me. > > In my opinion, MREMAP_DONTUNMAP has to leave the old mapping intact. And > create the new mapping adjusted to the new_len. > > Other option is to force new_len == old_len if MREMAP_DONTUNMAP is > specified. It would simplify the implementation. And I don't see why > anybody would really want anything else. I had been approaching this as, "do what mremap would have done in this situation except skip the last step." Meaning, whatever the final state of the old mapping was MREMAP_DONTUNMAP meant that you should just not do the unmap operation on the old mapping at the end. But I understand why it's confusing, especially when in the case of the VMA growing you're left with the old vma of size old_len and the new_vma of size new_len but only containing old_len worth of pages. Personally, I don't think this is a problem having that behavior because it can be documented and it just adds a small amount of flexibility. Nonetheless, I agree with you and I also cannot come up with a situation where you'd actually want to do this so I'm willing to restrict it to old_len == new_len and return -EINVAL if not, it simplifies it a bit and accounting becomes a easier because the outcome is always the same two mappings of size old_len and the size of the locked_vm never changes. We can always allow the resize operation later if there becomes a need. If everyone is okay with this restriction I can send a new patch. Thank you again, Brian