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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6CE92C54F70 for ; Sun, 19 Apr 2020 18:00:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E49221974 for ; Sun, 19 Apr 2020 18:00:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="b5UUF65T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E49221974 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5EDE68E0005; Sun, 19 Apr 2020 14:00:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59E408E0003; Sun, 19 Apr 2020 14:00:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B4218E0005; Sun, 19 Apr 2020 14:00:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 307CF8E0003 for ; Sun, 19 Apr 2020 14:00:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DF0885DD5 for ; Sun, 19 Apr 2020 18:00:19 +0000 (UTC) X-FDA: 76725368958.25.turn19_1ff3cb62dd845 X-HE-Tag: turn19_1ff3cb62dd845 X-Filterd-Recvd-Size: 4729 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Sun, 19 Apr 2020 18:00:19 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id u6so7432148ljl.6 for ; Sun, 19 Apr 2020 11:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KquQ7eqJ5WxLr4ruGXMoT/FQZYgAagIrOw4D8jrNTS4=; b=b5UUF65TFhoiwY6dQWiWGe/vGQW+FgBnonYQnlUUCMjWlRU22RHod2dAIgJ3iz6fXV iHPKFSUyF0y9t9WsYQQ9kcB4/DxZHIV6ObTaC9u1rZW5FgGVn0mO6KxSqN3rfAPJuw14 TD6cuXjvI56ndC599LrGWOU/QkG+aROAcxZTk= 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=KquQ7eqJ5WxLr4ruGXMoT/FQZYgAagIrOw4D8jrNTS4=; b=YhfrPOLPenxHSLv4V9d9/gbR6dDcr8nMLBtA1yFTCtFfbcrIMooXQ+wK6VpG/vJ3ri OPoQmYYCUDJ4VeowoUMVbLsgcgSP8nxa1HE9KQXN3cOkaBpNme2ZFeiUKJMSHoq1DXHT UbeAORt1uDCvT/1R8ngbH9vw3o9u0RCzpRyXaxeovNckBsR39GSKL/wZoPgBGpVf2WnD ZgDRN/ZaXBctLIj7wK/NWKLbHv3WfYq/h1ZvhCqAWe9K9YtPAKf6/XmwTt36bwItiZnr +bIU1EgDdaTQ3hP/UwJzrS0begNcWXIp+syH4tog6JpSt3JntEn/X7XEuH2wggwumYUP THvQ== X-Gm-Message-State: AGi0PubmNyKpnUv9ZXyVVGQmmHiaP2D8j7vjtih6ejyZqHceGqPjM8AM Zl05HulNFd7o7jYhOJIx9j5BfePV53E= X-Google-Smtp-Source: APiQypJ98tDwH/1Sdzlgt6+pDHTMBrVr6jbxLX2oFjnMmuOo9X/mW3PDaEIKPBPxso+Uev1Yby11+Q== X-Received: by 2002:a2e:8805:: with SMTP id x5mr8077532ljh.223.1587319216679; Sun, 19 Apr 2020 11:00:16 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id k6sm23432134lfm.91.2020.04.19.11.00.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 11:00:15 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id f18so1395597lja.13 for ; Sun, 19 Apr 2020 11:00:15 -0700 (PDT) X-Received: by 2002:a2e:8512:: with SMTP id j18mr3316865lji.201.1587319215104; Sun, 19 Apr 2020 11:00:15 -0700 (PDT) MIME-Version: 1.0 References: <20200417172556.217480-1-bgeffon@google.com> In-Reply-To: <20200417172556.217480-1-bgeffon@google.com> From: Linus Torvalds Date: Sun, 19 Apr 2020 10:59:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Fix MREMAP_DONTUNMAP accounting on VMA merge To: Brian Geffon Cc: Andrew Morton , Andy Lutomirski , Sonny Rao , Jesse Barnes , Dmitry Vyukov , Minchan Kim , "Kirill A . Shutemov" , Vlastimil Babka , Linux Kernel Mailing List , Linux-MM , Linux API , syzbot 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: On Fri, Apr 17, 2020 at 10:26 AM Brian Geffon wrote: > > However, MREMAP_DONTUNMAP leaves that original portion in place which > means that the VMA which was split and then remerged is not actually > split at the end of the mremap. I was waiting to hear others comment on this, but it's been very quiet. The patch looks correct to me, and the explanation is great. I'm inclined to just apply it. HOWEVER. I started looking at copy_vma(), and noticed that we seem to have exactly one caller: move_vma(). So I do have a query: would it perhaps not be a good idea to simply remove the "vma_merge()" call from copy_vma(), and do at the end of move_vma() instead? I don't hate this patch either, and I'll happily apply it if people prefer this one, but before doing that I thought I'd ask whether maybe instead of fixing up the mess made by vma_merge() that people didn't think about, maybe we should fix it at the underlying source of the problem? Are there any advantages to merging early? Shouldn't the basic principle be that we'd strive to always do the vma_merge() at the end of an operation that might have generated a mergable sequence of vma's? Linus