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 D1AB9C433F5 for ; Tue, 12 Apr 2022 05:14:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39DFC6B0071; Tue, 12 Apr 2022 01:14:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 326CE6B0073; Tue, 12 Apr 2022 01:14:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C7476B0074; Tue, 12 Apr 2022 01:14:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id 06FAB6B0071 for ; Tue, 12 Apr 2022 01:14:18 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B56BFA8322 for ; Tue, 12 Apr 2022 05:14:17 +0000 (UTC) X-FDA: 79347060954.24.D82CFAA Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by imf06.hostedemail.com (Postfix) with ESMTP id 33025180003 for ; Tue, 12 Apr 2022 05:14:17 +0000 (UTC) Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-e2afb80550so7780157fac.1 for ; Mon, 11 Apr 2022 22:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=7AXHvKyDS+8sXsKK4DrpbEGpG8JmWPbR7ulEunl5/Pc=; b=MIKtm3AFEh6CUVVNwUV8SeElPxDQU+nDCsyp+WcUsmZ4pYGMDS8fAcdOR85R0GnShf Y4SvxZp6GJGIWSDO3Qz0y+u4ZcAKbd5h4QgxfwJ80V2XMN4GDeNiF7fIlHS12g+G1n/h Kv7zR3bRSH86ipJifMek23BAEcPpsO3GQOK2qAQPq7d5D/TFRqQckEDpcn4OYWx7WoM9 lUklPUH6KUc5SlQqi1stBQ4I3bHiGY7ZT6LaR8lgLF5UeZqRnpzjDs527tWEzRy8OZZn nmt6hJ/Qq1aIeTJZ8BRsG/eRuI5lX0MY/pv7AqCy9vDclBFJLYkpepT8CENCuRctsE08 JerA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=7AXHvKyDS+8sXsKK4DrpbEGpG8JmWPbR7ulEunl5/Pc=; b=Udea+GwBhiaRwPMQ+1jS2fY0M4Tg5f1IjPqdFrd/GeXU2oTuf1k/Mvm/biUIsrlsXG +hTLcfSmv7rHnXGRD3qQKjPtzVAERmiyiTZIzZMfxLJYE8qoBGYsGjBHG5PVcfvdDV0s MiT+SQ0wyAZrPb0+KwMmmiCVJVF6sCJxId032sQ/tL4203zYdewhgLOzLvhj+jDVLvZh XMKPA7rAl5MjqVfb+ga4C0AHjkp8GCBsOWkUeLofYB6CWyHPnQx2K/YvbKqprmNwKQXr k0ETd2bLVKmji1YofmXyhbA8a5OmA9qYRFcNWL8/JgaH/VqDOyMhepYSNy7X7jB+yvQa sj8Q== X-Gm-Message-State: AOAM5315cKC7ihl3CsS10h95uFj/hSTk+KvDFdzT3OXmhxGqN5zcHE3Y UjDhueVK/a3qtQw2OHjXXkFkzQ== X-Google-Smtp-Source: ABdhPJzGUlHADzn2yFu7M3obTMzPSe7EDZTZ3EDogaZbWHy2xdUqchu+tTmHlhlBd5Pwc/mriWkvvQ== X-Received: by 2002:a05:6870:5390:b0:de:f680:db03 with SMTP id h16-20020a056870539000b000def680db03mr1269177oan.237.1649740456270; Mon, 11 Apr 2022 22:14:16 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id e9-20020a056820060900b003216277bfdasm12481870oow.19.2022.04.11.22.14.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Apr 2022 22:14:15 -0700 (PDT) Date: Mon, 11 Apr 2022 22:14:00 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: "Kirill A. Shutemov" cc: Chao Peng , Sean Christopherson , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , Shakeel Butt , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com Subject: Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK In-Reply-To: <20220411153433.6sqqqd6vzhyfjee6@box.shutemov.name> Message-ID: <2c39702b-2a71-cda2-685-93908763912@google.com> References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <20220310140911.50924-5-chao.p.peng@linux.intel.com> <20220408130254.GB57095@chaop.bj.intel.com> <20220411153433.6sqqqd6vzhyfjee6@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: 8qxg6rkbau5kct4sikxforcei5zfa3fc Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MIKtm3AF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of hughd@google.com designates 209.85.160.41 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 33025180003 X-HE-Tag: 1649740457-658823 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 Mon, 11 Apr 2022, Kirill A. Shutemov wrote: > On Fri, Apr 08, 2022 at 09:02:54PM +0800, Chao Peng wrote: > > > I think the correct approach is to not do the locking automatically for SHM_F_INACCESSIBLE, > > > and instead require userspace to do shmctl(.., SHM_LOCK, ...) if userspace knows the > > > consumers don't support migrate/swap. That'd require wrapping migrate_page() and then > > > wiring up notifier hooks for migrate/swap, but IMO that's a good thing to get sorted > > > out sooner than later. KVM isn't planning on support migrate/swap for TDX or SNP, > > > but supporting at least migrate for a software-only implementation a la pKVM should > > > be relatively straightforward. On the notifiee side, KVM can terminate the VM if it > > > gets an unexpected migrate/swap, e.g. so that TDX/SEV VMs don't die later with > > > exceptions and/or data corruption (pre-SNP SEV guests) in the guest. > > > > SHM_LOCK sounds like a good match. > > Emm, no. shmctl(2) and SHM_LOCK are SysV IPC thing. I don't see how they > fit here. I am still struggling to formulate a constructive response on MFD_INACCESSIBLE in general: but before doing so, let me jump in here to say that I'm firmly on the side of SHM_LOCK being the right model - but admittedly not through userspace calling shmctl(2). Please refer to our last year's posting "[PATCH 10/16] tmpfs: fcntl(fd, F_MEM_LOCK) to memlock a tmpfs file" for the example of how Shakeel did it then (though only a small part of that would be needed for this case): https://lore.kernel.org/linux-mm/54e03798-d836-ae64-f41-4a1d46bc115b@google.com/ And until such time as swapping is enabled, this memlock accounting would be necessarily entailed by "MFD_INACCESSIBLE", or however that turns out to be implemented: not something that we could trust userspace to call separately. Hugh