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=-2.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 E9326C04AA6 for ; Mon, 29 Apr 2019 21:45:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B04FE2067D for ; Mon, 29 Apr 2019 21:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556574304; bh=mjHNPm5UzQBTfhnbdbEZUXnSMjVIkxkLtBLxdRwsrxU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=oAfqa5BwXrby353KHWvrKxLxvOv54SQ0F5NVXpoTlsmn9xCIIv8IG241ys0Lyf2sY 06sMcHtlqLfWHGvXaN2t9DNdcACVkEOteafQ4W7afGjZFO0Wz7YDnRodeLXbW9Alxu zv4lhr7En01ErEGbBPjWqlxC2Hlucc/4/h5tGgws= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729442AbfD2VpD (ORCPT ); Mon, 29 Apr 2019 17:45:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:53168 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729341AbfD2VpC (ORCPT ); Mon, 29 Apr 2019 17:45:02 -0400 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 95B8DABD7; Mon, 29 Apr 2019 21:45:01 +0000 (UTC) Date: Mon, 29 Apr 2019 17:44:58 -0400 From: Michal Hocko To: Matthew Garrett Cc: linux-mm@kvack.org, Linux Kernel Mailing List , Linux API Subject: Re: [PATCH V2] mm: Allow userland to request that the kernel clear memory on release Message-ID: <20190429214458.GB3715@dhcp22.suse.cz> References: <20190424211038.204001-1-matthewgarrett@google.com> <20190425121410.GC1144@dhcp22.suse.cz> <20190425123755.GX12751@dhcp22.suse.cz> <20190426052520.GB12337@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 26-04-19 11:08:44, Matthew Garrett wrote: > 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? If the complexity is not worth the usual usecases then this should be really documented and noted that without an mlock you are not getting the full semantic and you can leave memory behind on the swap partition. I cannot judge how much that matter but it certainly looks half feature to me but if nobody is going to use the madvise without mlock then it looks certainly much easier to implement. -- Michal Hocko SUSE Labs