Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp933737yba; Fri, 26 Apr 2019 11:10:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwA4sF74Yso1DG8zJQ6R1AmlKXx9P06S6gN9PTRIsZGburumOoO4Wc1pSSafbcDnOukpBEC X-Received: by 2002:a65:65c9:: with SMTP id y9mr44971870pgv.47.1556302205979; Fri, 26 Apr 2019 11:10:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556302205; cv=none; d=google.com; s=arc-20160816; b=LyH+IyDsEDOpfjsrnIcoaEar9zxKrnXDgFIZIzLj5SEWAcx4/n/kUqrTtICobc0qvz YTMEQblhfja1Khw89Gh4KgLvPPjk1IE8rAdwATEb0knTg8Bh6+QqIWWKlZ2Fofd7mTjs tSZ6XX6Jkwmpd7Q2fyarY7ADQrs7jU5Z/gzbCu1LfVo9wyeQPCIgNz0Dbi7fkLD8Toa9 87irGoZ14wxA9k5KFNNa9G22Z/855r3pzfBuTN4HngXxk43EQQWJBH0gRGOuO7tOymzt BocR0zQlw4YqOWuFb+Ugf54YfNtVCtBxBeSKu4dXUvYkur1Gvg2oJcYZVLkqmo6k44EB R5wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KSDUm6zaly7/6QejATEjb8e1RQYiq+vEm5C7j7vxPK4=; b=ELSInk50/ifSSbLMmmaH0sULvCWJwo5wybtsXUHqpLToyF6P7h6QNgtLgQzEelZg5X BeCL6cCn61Q3+Cy+CP1HX+lvWZbiFqv0O7onRdGh65o2/oQs/V/j18WrgNb3HRZ5pISg 4Juz6VNu//RYETDWI/htmQHBxLdL+JwjIBzmOg7gP2UBu+qKhIyQ+jumHKkgRs0w3Uxt y7DiOtoMfSEct5OGHY8+XiwPxweOlJna9nwxjHuDva5S3qmadewl7gWI2hbHkZFIuXo0 mu8FLs+jeCjb5IXVRZhzOMUJJaxuAO07GyMj59phJgdFnBBc0ioC0Upmimyth2oWbVA5 Ahug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mM2gNYUi; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 24si25978704pfi.21.2019.04.26.11.09.48; Fri, 26 Apr 2019 11:10:05 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=mM2gNYUi; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726191AbfDZSI6 (ORCPT + 99 others); Fri, 26 Apr 2019 14:08:58 -0400 Received: from mail-it1-f195.google.com ([209.85.166.195]:55951 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725875AbfDZSI5 (ORCPT ); Fri, 26 Apr 2019 14:08:57 -0400 Received: by mail-it1-f195.google.com with SMTP id y134so7258731itc.5 for ; Fri, 26 Apr 2019 11:08:57 -0700 (PDT) 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=KSDUm6zaly7/6QejATEjb8e1RQYiq+vEm5C7j7vxPK4=; b=mM2gNYUi/70Hohs3RgWqrz/IAXrbekJ+xfzhbMuc83HLnonIIOAND8fNLzPeKY7OuX zTZ2ysZFPHaq/GVmztzTKZpMaUVgb/a2UKfMV7n9uNEsnfJJpnoOIlObqAPabtxxM5BF 8EkrQ4g60BXzRK3XIivpMG6AUJWmUF7YNBMjXBlwvXzDninFtVk7kcZROUswKjpscx+S k8FmnA06rbRfLjsHTVczdHxUFYFcdvCgt3MOHEPjiL0iwEqb+kqxeS6AyPfeUJFAeoEj BwKjLi7+5pGLTI/Pt+0JEphCU0qFdZ0G0ONukVUui6NTbN0xkLJtSGm7UZbKvqf0UVBw kAxA== 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=KSDUm6zaly7/6QejATEjb8e1RQYiq+vEm5C7j7vxPK4=; b=XvU2JHLjtVuvPBzzAqkRXtaZjRLRk2m2I4f47VeYOO/tgtDq+mIkk/evbYiHGN6DBf disMDG0cBI9liMWhr8esnBA90CH9VcKd55wWM8HGxBGyQRfw3z8ZieA1fUTCf44z5jiB YIdK/qnghk/6wvbMe5GHI/lSI6mpJMwCLsT8VS3Feb5po/Fm70ro8IdwS3Quy8PFsh2K X5m/bhf1gS+asHfnEvIgi7TUXnJk5p28pjALJnxZjFNSQry+MdvP16BgKXHHe5CK9EwD PC//NA+lDqDFnXzUka/agRWgX9MRPqMdpXq2+W59r5qEKiFqCIEouj+5df1yhYxAs4Gq dtjw== X-Gm-Message-State: APjAAAW6nIJhxLLBMFZNqEv2SpFNCXeO18EVYynyQxzZuqKJlyVuEvgM ch7xfG8zynMriywEaTEnsMK4xCENfh/QuUwbHw643kw1TMM= X-Received: by 2002:a24:eb04:: with SMTP id h4mr7779231itj.16.1556302136456; Fri, 26 Apr 2019 11:08:56 -0700 (PDT) MIME-Version: 1.0 References: <20190424211038.204001-1-matthewgarrett@google.com> <20190425121410.GC1144@dhcp22.suse.cz> <20190425123755.GX12751@dhcp22.suse.cz> <20190426052520.GB12337@dhcp22.suse.cz> In-Reply-To: <20190426052520.GB12337@dhcp22.suse.cz> From: Matthew Garrett Date: Fri, 26 Apr 2019 11:08:44 -0700 Message-ID: Subject: Re: [PATCH V2] mm: Allow userland to request that the kernel clear memory on release To: Michal Hocko Cc: linux-mm@kvack.org, Linux Kernel Mailing List , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 25, 2019 at 10:25 PM Michal Hocko wrote: > > On Thu 25-04-19 13:39:01, Matthew Garrett wrote: > > Yes, given MADV_DONTDUMP doesn't imply mlock I thought it'd be more > > consistent to keep those independent. > > Do we want to fail madvise call on VMAs that are not mlocked then? What > if the munlock happens later after the madvise is called? I'm not sure if it's strictly necessary. We already have various combinations of features that only make sense when used together and which can be undermined by later actions. I can see the appeal of designing this in a way that makes it harder to misuse, but is that worth additional implementation complexity?