Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp3795642imm; Mon, 2 Jul 2018 05:51:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKImMjLWTK625xfMIpZTnHXTRWLal0XL3p5j0AGolQElnSchlP5Q6G+GHrMCLV56STHOqfpK X-Received: by 2002:a17:902:a416:: with SMTP id p22-v6mr25876867plq.228.1530535871684; Mon, 02 Jul 2018 05:51:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530535871; cv=none; d=google.com; s=arc-20160816; b=J+Yp6OXhLi5mqXJoHWyBSkbqLxQIZF0xwrztGLYFFLREI4obUHTXdXaE+LNh70LKIp HsmUERpdouKUzmeLIiSAOXP7nktp/ejbAZbv5BkwWIm5UbVYbagfw2TeRFrSiEuxK7hR bK8bG5xcWiz/pluVJOJ7seyoyQ7tiSabeEpMdSPbMKY8m1WPJXbfkP3w28Zlol4w+3ak aeBxSoZwoNMYwBof6WUlLAoWWfpfDyOjalD4aVk2jUEyvVNebE0YkP4YDsYWoIiRz8rm /x+Y7s10PbT61IyCZYTttIYQUhlcswM/efkrBehjZSMcGiCXZ1el1jLrSHX8lpb/i3DT RuzA== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=sVj7HAQ+L5qynjMYM3ZW1sxVd1e5+VcPDhrMDG2XQu0=; b=kIrL30ucrzq008meWSujdmnV9Cn/ZCY202OF7pNR3ccRLYtiZt4PLiQPlOCDjOxk+4 atz+M69D/vP0xsfMSg/JsrC4jm1ml03kh7cvOaOSsTc6Ye09i+LOrLknxdDFyHQHv/fW Tdbe2ooBrxMd5QL8W6nfvuIsOeGThdWdF+Dd8wh1T4v8rL6jeLgzDIn3dn6OgmXH702p CQjGbv+FZZ7M89jywQp3NTCjWC9o+PXij6gv+vvyBTqpRfd/gDuRcNNJqjPJXcR6/1Q9 dYKhyJFsbZsnn/tfMezsfbvmuC8EbBImZ6FwHvQf8Ypj+Xp7k/YDUlbk2Wnhna03k9oG VFYw== 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 q66-v6si16353021pfd.153.2018.07.02.05.50.57; Mon, 02 Jul 2018 05:51:11 -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 S1752174AbeGBMte (ORCPT + 99 others); Mon, 2 Jul 2018 08:49:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:34916 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751493AbeGBMtb (ORCPT ); Mon, 2 Jul 2018 08:49:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 47039AF63; Mon, 2 Jul 2018 12:49:30 +0000 (UTC) Date: Mon, 2 Jul 2018 14:49:28 +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: <20180702124928.GQ19043@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180702123350.dktmzlmztulmtrae@kshutemo-mobl1> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Michal Hocko SUSE Labs