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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 202FBC433F5 for ; Fri, 4 Mar 2022 19:26:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D77C8D0002; Fri, 4 Mar 2022 14:26:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 991D68D0001; Fri, 4 Mar 2022 14:26:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 876408D0002; Fri, 4 Mar 2022 14:26:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 7BD428D0001 for ; Fri, 4 Mar 2022 14:26:04 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 4E7D41201CA for ; Fri, 4 Mar 2022 19:26:04 +0000 (UTC) X-FDA: 79207684248.14.93B5D34 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf14.hostedemail.com (Postfix) with ESMTP id C1703100026 for ; Fri, 4 Mar 2022 19:26:03 +0000 (UTC) Received: by mail-yb1-f202.google.com with SMTP id k10-20020a056902070a00b0062469b00335so8150617ybt.14 for ; Fri, 04 Mar 2022 11:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=J64es7HM/NEnjdZCnfIshrO3wOmcq5xIZ4GZ3l0aZZI=; b=GItdpzKUBGucNm4WOe+HN7O/1STAH96AycQndTvxw/AJHcG/IZXBQqhHpuZ05xhR4h s4/tKY3tQeE7DrutZ5Ai6jwAl8HZtsKW56JRi+K1/bpZ5fj9ArMcTSHKmuftwci5pnc5 8185Z7VFl8q58WBsa5DKcW7AqVcRHiRJlzc8uTybp2GtjLt3aimA8WJqpE9dZYDCaKpg nSDfUCu2diH4MZ2AkU0UqvXwMpOpJHeKUdcg+CDWj/hZdns7uGct3IOKaTBZkWLRZBTm LT0ppGdP7Ddd/W2mtx4Yd4qmSgUu1hBcDWvQ1o0GawHtl57BA07e3RkLP77VwgB12XvH SzyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=J64es7HM/NEnjdZCnfIshrO3wOmcq5xIZ4GZ3l0aZZI=; b=tScBfHzYAq9zgnC5PRSc1jg3CrlhQzADG6Y6R50+HInINCjsqZejYSHoR3t//yEbCf poLfKVFjn2+aT5u3DB3MRkAAK4GFFtR0kyAkTIebZvX7FtuJQavQP60Dkt9MYpZrjop6 R6+6khVsCtU6eQKvtlVTqvg3bgdfUfGt8eOMSFTGcANt2EFOxbeo74qvz3zxk05BQVxN P4CqKwL62FOW/XWq9wYnqKDkes3/a7VZvBSKI7cE7/prCakeU9dJ20Z2/6Akp1olhiSq pb0Aj45YVwY5XskeBAvUMxRqsmgnqvthWYL4I+3bcNyQIHw+cHiuxqgUIfQphrwusv/Q YW6A== X-Gm-Message-State: AOAM531BaAkwEhrDv8RFyMxiXlj5wOAM+1fIfyWUUcES202DJwIxx+Wr Gd4Fjw3L34bqkw7H+RojqVI4N60YkXEqcA== X-Google-Smtp-Source: ABdhPJx1JBku7Y5F4eCh0ATGfGMRZ6wb/cJ1gQZwri0EnQCSBm4x3jk1yCC9794gkFLFxVD0xxm+uUa1OAahIg== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:28b]) (user=shakeelb job=sendgmr) by 2002:a05:6902:3cc:b0:628:73aa:9c7f with SMTP id g12-20020a05690203cc00b0062873aa9c7fmr20910540ybs.632.1646421963101; Fri, 04 Mar 2022 11:26:03 -0800 (PST) Date: Fri, 4 Mar 2022 19:26:00 +0000 In-Reply-To: <20220304171912.305060-1-hannes@cmpxchg.org> Message-Id: <20220304192600.rvmgbg72aq6idooc@google.com> Mime-Version: 1.0 References: <20220304171912.305060-1-hannes@cmpxchg.org> Subject: Re: [PATCH] mm: madvise: MADV_DONTNEED_LOCKED From: Shakeel Butt To: Johannes Weiner Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Nadav Amit , David Hildenbrand , dgilbert@redhat.com, Mike Kravetz , linux-mm@kvack.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C1703100026 X-Stat-Signature: otetoaw1wdfhqm9b61h4apasrufh1yam Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GItdpzKU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of 3y2ciYggKCDwqfYiccjZemmejc.amkjglsv-kkitYai.mpe@flex--shakeelb.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3y2ciYggKCDwqfYiccjZemmejc.amkjglsv-kkitYai.mpe@flex--shakeelb.bounces.google.com X-HE-Tag: 1646421963-215701 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, Mar 04, 2022 at 12:19:12PM -0500, Johannes Weiner wrote: > MADV_DONTNEED historically rejects mlocked ranges, but with > MLOCK_ONFAULT and MCL_ONFAULT allowing to mlock without populating, > there are valid use cases for depopulating locked ranges as well. > Users mlock memory to protect secrets. There are allocators for secure > buffers that want in-use memory generally mlocked, but cleared and > invalidated memory to give up the physical pages. This could be done > with explicit munlock -> mlock calls on free -> alloc of course, but > that adds two unnecessary syscalls, heavy mmap_sem write locks, vma > splits and re-merges - only to get rid of the backing pages. > Users also mlockall(MCL_ONFAULT) to suppress sustained paging, but are > okay with on-demand initial population. It seems valid to selectively > free some memory during the lifetime of such a process, without having > to mess with its overall policy. > Why add a separate flag? Isn't this a pretty niche usecase? > - MADV_DONTNEED has been bailing on locked vmas forever. It's at least > conceivable that someone, somewhere is relying on mlock to protect > data from perhaps broader invalidation calls. Changing this behavior > now could lead to quiet data corruption. > - It also clarifies expectations around MADV_FREE and maybe > MADV_REMOVE. It avoids the situation where one quietly behaves > different than the others. MADV_FREE_LOCKED can be added later. > - The combination of mlock() and madvise() in the first place is > probably niche. But where it happens, I'd say that dropping pages > from a locked region once they don't contain secrets or won't page > anymore is much saner than relying on mlock to protect memory from > speculative or errant invalidation calls. It's just that we can't > change the default behavior because of the two previous points. > Given that, an explicit new flag seems to make the most sense. > Signed-off-by: Johannes Weiner > Acked-by: Michal Hocko Reviewed-by: Shakeel Butt