From patchwork Tue Jul 3 08:27:18 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10503421 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7081D60225 for ; Tue, 3 Jul 2018 08:27:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 607AC2879B for ; Tue, 3 Jul 2018 08:27:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5461A2888E; Tue, 3 Jul 2018 08:27:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DC57B2879B for ; Tue, 3 Jul 2018 08:27:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D48526B0006; Tue, 3 Jul 2018 04:27:23 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id CF7256B0007; Tue, 3 Jul 2018 04:27:23 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE6056B000E; Tue, 3 Jul 2018 04:27:23 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id 7DB176B0006 for ; Tue, 3 Jul 2018 04:27:23 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id e1-v6so837856pld.23 for ; Tue, 03 Jul 2018 01:27:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=tMTG5fpGRA9vpSWsW1nUE3P7exhkPQNyjcKuyr+wc8k=; b=X6t1zez/IWOIi11/RKqE4TqDZ+oUxu4Nmyp+376vW8EwMgMWtl7CfhjdT+oKr9cUM+ 8ZNAqCfg3xAXfn37khMGbDXsndUDI73tVDafD2D3iHE07iVY3LKztJntVptXxMLZhyoS eARX28gcgIPk8hIyZeZyTr+I50FL2BEm6MWM+PfNLdyJQFnyqWCg0/GAXcQgaEWVbEIp sJzfo4csrmB20TNgrDVfvZrUO7+MN980QecvOYkIwwbO8Fop8PKlEqBt+4JcBE6tS1ec dvnm58qPVAJQQJuAy7NHHJ3PYBMt+cF72MFQ2fMO5UWCU8iM1cW+TdB/RV/FK9nfIcP7 rTQw== X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: APt69E36NOabZcWqtQ5MW7CVmg+PDbjv0stBlI3NlsyTP5v/oOxg/plO gn8tJwscAsKEQeiYIzBXga/rh3Br6+TM/3wGeGXNSLRuKVDM7G4t4frtEjWa8OCMSouXA4TqCUS x6VwTCFjNoRl6+VGx7Xf4Z/W7O6dtE6tf3pTunyZcxBwIIaqM2kgq5laNZVWOUng= X-Received: by 2002:a62:d544:: with SMTP id d65-v6mr8102728pfg.107.1530606443177; Tue, 03 Jul 2018 01:27:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfK+4kZbt6z/3YOWOwSJFlt8/mwXxujnyjEvE53Fev3H4Uj6FDB4FaXgmUlHY5QGUwfv2g6 X-Received: by 2002:a62:d544:: with SMTP id d65-v6mr8102695pfg.107.1530606442428; Tue, 03 Jul 2018 01:27:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530606442; cv=none; d=google.com; s=arc-20160816; b=GGpe2uXVUiohCvWT8IGkuFqtpWXfeMEXqcq1HQWXAPYS6nJ9Sfyw23FFjKouqFmXtL KydNyTL341/o+pi2z6GKwi+6erFCEzTPKnmeRvy8+2snAaXe1BOPbewnvPWJAJNen0mS hsF55ocuwUxLZO5GsZTECOAnpdJKgZu4xOCNijjildKQBmetqQhQFKyYj7rMCP84DOnp 4VWtWDV3hearYZUTfQ94vCrN5ej7q66dCCL3BHYX3dc75iIYLAw5/eyhOcZXZ/kp68oO KHeajrv2pXbnQexHcwG2r2i5x++S00aCrphJIHd0Vf4giZ1WdzAeS+F5mAYsOcjWZu5O 8Grw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=tMTG5fpGRA9vpSWsW1nUE3P7exhkPQNyjcKuyr+wc8k=; b=LYB8gvbhBMN2uAqYo19p0Wk+qVble7EPN8PUXk56MTz4Hy15kPptgfiEuW75LfeXz1 sZ6EKcD0nUympl459jgLC72G57u/12IeS04iygGkppjYYj3Pnu4WPyn2rvd3gjxbSCpV oykfsr8w/auYca4DBp4rI2+Wp5CP1Ayz2qJNtW5wx/bXIao5b3VYDfFyxXzzQw03Ym4T CKxWFruQdqcs3dSbNIrSZIhtzRaJ5GoERBi1DTO5F6OtJm58dIq3sYLPnUvRhnMx9You SmpE+koEBSeOoQTfIJLCr8VD/+4SGhSexVfBlIbgUbj7orCH/domzI7+6Hpr5COUoHSt WWfw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 5-v6si602361plx.517.2018.07.03.01.27.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 01:27:22 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 8946FACF3; Tue, 3 Jul 2018 08:27:19 +0000 (UTC) Date: Tue, 3 Jul 2018 10:27:18 +0200 From: Michal Hocko To: "Kirill A. Shutemov" Cc: Yang Shi , willy@infradead.org, ldufour@linux.vnet.ibm.com, akpm@linux-foundation.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, namhyung@kernel.org, tglx@linutronix.de, hpa@zytor.com, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v3 PATCH 4/5] mm: mmap: zap pages with read mmap_sem for large mapping Message-ID: <20180703082718.GF16767@dhcp22.suse.cz> References: <1530311985-31251-1-git-send-email-yang.shi@linux.alibaba.com> <1530311985-31251-5-git-send-email-yang.shi@linux.alibaba.com> <20180702123350.dktmzlmztulmtrae@kshutemo-mobl1> <20180702124928.GQ19043@dhcp22.suse.cz> <20180703081205.3ue5722pb3ko4g2w@kshutemo-mobl1> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180703081205.3ue5722pb3ko4g2w@kshutemo-mobl1> User-Agent: Mutt/1.10.0 (2018-05-17) 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: X-Virus-Scanned: ClamAV using ClamSMTP On Tue 03-07-18 11:12:05, Kirill A. Shutemov wrote: > On Mon, Jul 02, 2018 at 02:49:28PM +0200, Michal Hocko wrote: > > On Mon 02-07-18 15:33:50, Kirill A. Shutemov wrote: > > [...] > > > I probably miss the explanation somewhere, but what's wrong with allowing > > > other thread to re-populate the VMA? > > > > We have discussed that earlier and it boils down to how is racy access > > to munmap supposed to behave. Right now we have either the original > > content or SEGV. If we allow to simply madvise_dontneed before real > > unmap we could get a new page as well. There might be (quite broken I > > would say) user space code that would simply corrupt data silently that > > way. > > Okay, so we add a lot of complexity to accommodate broken userspace that > may or may not exist. Is it right? :) I would really love to do the most simple and obious thing but the argument that current semantic of good data or SEGV on racing threads is no longer preserved sounds valid to me. Remember optimizations shouldn't eat your data. How do we ensure that we won't corrupt data silently? Besides that if this was so simple then we do not even need any kernel code. You could do that from glibc resp. any munmap wrapper. So maybe the proper answer is, if you do care then just help the system and DONTNEED your data before you munmap as an optimization for large mappings. diff --git a/mm/mmap.c b/mm/mmap.c index 336bee8c4e25..86ffb179c3b5 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2811,6 +2811,8 @@ EXPORT_SYMBOL(vm_munmap); SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len) { profile_munmap(addr); + if (len > LARGE_NUMBER) + do_madvise(addr, len, MADV_DONTNEED); return vm_munmap(addr, len); }