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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E70FAC433FE for ; Tue, 12 Apr 2022 14:36:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbiDLOi6 (ORCPT ); Tue, 12 Apr 2022 10:38:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351383AbiDLOi4 (ORCPT ); Tue, 12 Apr 2022 10:38:56 -0400 Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B69C45BE6C for ; Tue, 12 Apr 2022 07:36:38 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id c1so2499646qkf.13 for ; Tue, 12 Apr 2022 07:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=evNj2CNMoMsw5e7L6RfPQYGJFzo3TZYC7FsieHWZ5Ls=; b=P4KDTA4ChNl8eFo5TaRAl/5FnI/hVHjJzJBo1xbfO6E6tcQCaqBfnBN1z5fv3DfE1u iQILgHtSz7DDusNSlvJP3Z1yMP4+yKAQ2Eyz628hQVcLvQ+BxsdlwhsUbE6fvWB/Q2is KJFMZcpNQuQ1kXRm/7dZww/aXDBDg6Qg87XJBXqMNal9QHP5YcfHOuo4039oAPwifclm Ni6jxAqEXJAsTg1vDWd5O4322/PPXZOhWqI7cTTZAicevA8+5AkWYEBaFSAdm27ELa3S niv0qlWzCgCFeZ31VkUUBPNxRCHtURSjk4RK/eF6eqwh/psh+4pwILguC3l2W1BosUlI tCIg== 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=evNj2CNMoMsw5e7L6RfPQYGJFzo3TZYC7FsieHWZ5Ls=; b=IqfC4F7LpgqMxYr4HARncP6pyQsipgDQXxJTdfV+a/L5XfxBDLy6MYJaqqTD1Y52RI kowfQEF+yeiSrggyR6jUSNNrHhXD3RjH2ggcTewUXm65PYk0hlrfZARUj86o0QXD2ZJl pXD8s+DpRUVEI/xgFxM7mD6lsWAr7SJ6NYu8Jyw2h9fQ3bqJI+uy2HnWC1J708uuj6t2 I24/sKiE1jDxfdTuSrawwWo6KqKXcT08EHIRlLxodisr6AH2764k5EJxuLwOZBPy0GZM upRg9xpDUG50LOHP47SdwYgWun5gbQ2H42e/y/6q4F1p+FnPisgVBLPp1rAwxuAx6YW3 9WIg== X-Gm-Message-State: AOAM5322c6wduuT7ArEbHwEXhim/QSknZ8IOcKsFfjSmvy1lI7AxceWU b2v+XBXM9VSseZPaIzQW9BWt6w== X-Google-Smtp-Source: ABdhPJySHPHmQqifS2wea+F5V8gixdYIV//Jv7wOTevmOQGVNlVLMxWAFhJpJjukoZ7Xd9/fbgNIYA== X-Received: by 2002:a37:990:0:b0:69a:976:be4e with SMTP id 138-20020a370990000000b0069a0976be4emr3264529qkj.321.1649774197434; Tue, 12 Apr 2022 07:36:37 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id n7-20020ac85a07000000b002f1421dac8csm324215qta.80.2022.04.12.07.36.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 07:36:36 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1neHdE-000uGn-C6; Tue, 12 Apr 2022 11:36:36 -0300 Date: Tue, 12 Apr 2022 11:36:36 -0300 From: Jason Gunthorpe To: David Hildenbrand Cc: Sean Christopherson , Andy Lutomirski , Chao Peng , kvm list , Linux Kernel Mailing List , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Linux API , qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "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" , "Nakajima, Jun" , Dave Hansen , Andi Kleen Subject: Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK Message-ID: <20220412143636.GG64706@ziepe.ca> References: <20220310140911.50924-1-chao.p.peng@linux.intel.com> <20220310140911.50924-5-chao.p.peng@linux.intel.com> <02e18c90-196e-409e-b2ac-822aceea8891@www.fastmail.com> <7ab689e7-e04d-5693-f899-d2d785b09892@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ab689e7-e04d-5693-f899-d2d785b09892@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Fri, Apr 08, 2022 at 08:54:02PM +0200, David Hildenbrand wrote: > RLIMIT_MEMLOCK was the obvious candidate, but as we discovered int he > past already with secretmem, it's not 100% that good of a fit (unmovable > is worth than mlocked). But it gets the job done for now at least. No, it doesn't. There are too many different interpretations how MELOCK is supposed to work eg VFIO accounts per-process so hostile users can just fork to go past it. RDMA is per-process but uses a different counter, so you can double up iouring is per-user and users a 3rd counter, so it can triple up on the above two > So I'm open for alternative to limit the amount of unmovable memory we > might allocate for user space, and then we could convert seretmem as well. I think it has to be cgroup based considering where we are now :\ Jason