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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32329C61DBD for ; Tue, 25 Aug 2026 11:18:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 212306B00A5; Tue, 25 Aug 2026 07:18:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EB1C6B00AC; Tue, 25 Aug 2026 07:18:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D8E16B00AD; Tue, 25 Aug 2026 07:18:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D2B686B00A5 for ; Tue, 25 Aug 2026 07:18:31 -0400 (EDT) Received: from smtpin10.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 531161203E9 for ; Tue, 25 Aug 2026 11:18:31 +0000 (UTC) X-FDA: 85139543622.10.CEA869A Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf29.hostedemail.com (Postfix) with ESMTP id A908212000E for ; Tue, 25 Aug 2026 11:18:29 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=YGEZC8Fp; spf=pass (imf29.hostedemail.com: domain of ljs@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1787656709; b=rkea/HnelNthzw6ayjQchOq3m/ZVVsHnazMPEt0bgltG0jTQALRq/WoHmeayGFTNANdmPD 3XtTv39sBMuF1OYZ/97yehPaKe2HB9/x0l3CM57t+4EcnBiDD4mDCdEwFX6A2IaCSoIxCR epmqGmJqCAjPLCJKSHgp/+TpmVuq25c= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=YGEZC8Fp; spf=pass (imf29.hostedemail.com: domain of ljs@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1787656709; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=W05Dx/VZMWvzT1SSodsvq4ca5CdFdSoDwnfBlPLV4jk=; b=wLJaK5C3aYbdB8Pn0v2aWa7AD7zOQ1jI1JdT5cAAbyZAPJ+BwhuV50f376VmHVqKk4hvV6 cnzL8QiSeE5icPObISCpXAKu4MNXWvTbil+IsoBbNV/Hw2Z5ZXuQ/F8G2T1r+BUQacSDik 65deYelT5WtLWZ+84qFzz1zkcVWwaz0= Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id A238940A9F; Tue, 25 Aug 2026 11:18:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D2851F00A3A; Tue, 25 Aug 2026 11:18:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787656708; bh=W05Dx/VZMWvzT1SSodsvq4ca5CdFdSoDwnfBlPLV4jk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=YGEZC8FpPuaGJTkbj+O22U5UJ5eHCoQdZKhpk0mREl2Yhk1RMhKjSQpZVNe31G3m+ YlAF98rAHthuPnCeEeP2BDBRfWFYWrhFCZSj+FQ012T9VJ1eTTtm8QPVK7syzOLegH V9ZiVnNdgicGC8JEfJxGAVgabPWhYKdwE/FTOoMtBnJtXlOq6HM00gzfgnm0ePGNyT bdQx6Ohwqgi0e5QDnLrTGTLLnSBNt+v7tVseSXE2lVvvw6LR7b4r2lfLpcpG/CikO0 0JE1rSzDikmxz0iMjjpw5PlAkn59CAORWeqRN3yCOvyMc0pM7RMZU6Byhgi7nSFckA cGJv4dRxlzK0A== Date: Tue, 25 Aug 2026 12:18:20 +0100 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Daehyeon Ko <4ncienth@gmail.com>, stable@vger.kernel.org, Andrew Morton , Mike Rapoport , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Shuah Khan , Alexei Starovoitov , Daniel Borkmann , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , James Bottomley , Hagen Paul Pfeifer , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH v2] mm/secretmem: properly account locked pages Message-ID: References: <20260822-secretmem-accounting-v2-1-fe445a7c6eb1@kernel.org> <17e9f7d6-d095-44ee-9997-8dc10646f3f8@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17e9f7d6-d095-44ee-9997-8dc10646f3f8@kernel.org> X-Rspamd-Queue-Id: A908212000E X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: kz61czq9ywrkpqe87gqinwgafz7z9rra X-HE-Tag: 1787656709-381255 X-HE-Meta: U2FsdGVkX18hOkhjzUF53J/Du9LEDQQ3YweFTKX3hF6Rc9upqUp3kCzyiUuWWUzhwjknT6jIgs6LrMebbwn1WlLSCZLuJHAgyPi5aIPuboeHJ8WHmBStbF/KR9dsJoWO79Cp3wVnidDToyE/cEHYnj4y8mDBAF7ykuwJC55/eo3oWIr1i6mhWqNwC1gG2mG3s9okBERcCmwCLr/SXWnOZISkQqfrhbnTh65YTt0ohRAcn1eM+3ruXsSj6phMtnzqtaFXkRlAsScfc4zmIw20W+qH/p63dlBWpwUZ7PJILbUGj6zJ8269rbDoE9xkoRXdIPXwwNu8wUaHCsgbePQqICUNEtV1KRgTvb0RsEU5BebyDrFiZRrgDxGRyX/zpoDp1WDfpfMH3Mpl13LxFOmlaCDg5nbJAePxz5QaHe3r93D0EWYtPObrOujs89HSgfT4DEl0vCMQvWZMPpC7Z3JCc1ezcbZaLxSqfvYu4WsRSj9EZcSC4n5xS6Qg1TFVQUDgzkdKVnmAS5kUgg4aFwjPbtsJVnvpNMzrmuxFlln0XOQbPWqsBwQ4+JoIANsgCAK6SU6SlAfBnQsU2vPDfq1ZnATtA6xgTRvn6zJ2Eop2hEEGhoylwQqqE98S8pcMF4ILWuPSkfj5zuP459rZTzFdgkAPcmUk98LMWSvgvYRapjypWtuvkrJXY3k/GdtPl4bCGBAynWZpzgpRnYzFkTvLKfcN7DLlPhjfbhj3CvifVQO0+Ufakpg3SEEFj2wA0SJDXnoNfdrYklXVWid45STOP49pZWGOeqNf7nHjRWIM8l7OTcoKmIZcP6Cgc/wFYl5+tIkAayK+aIW4EUENIMeCd9Ypuexj6BVacLb1GzUf2TQ3ZbbbWVXqLLCwWPN9MpjhASEUj2ctuvnGQWTzNFCvtx5ksu8NYOQ+MGJl+088AgVBwa2dkDjWvex4AnX2CXTnp6JASaN5U4U1tCQz5kk Boh2mZgH iP1bnqMl/WPjLmULvJjZJxHsWv82mDpFCxDEJ9YoHPvZtyBiPmblzvg0+98zvd5Fa+u6e2TwAj4Nmb8O2GcNFD2Ecf9PyODpa8fx7VsMsyJt87GSJ6VLPYq91yYC5scDtfnhsUT4+pLgZLmDVWTSvLQ5idXRxdWQXu4rV7tCk2LuUchGi/aAK6+8FB03p9XJiDAGX9le+HofP6lWazIfwDa9NiSWpOuovYGjIkOcGcV822o+8l0gW8uUMGb2waEotFuJoLVNH9ESwPXOi1Lo17wiT8xhMfWPJsTVBWvNmfU+1Vj+YKmC6Jr5B9dcnTCZ/AssRFCeZYEsY7s5qUDTOskCpboXdSI1fzuNasOQ4RrNYZdq9Rc1B+zVvCBIX05zI3yWuLbf6xqxiUWy3K3atdts+8yyRnfTU9Fl6+BHGFovKUNheKm1Xx7nreChkGEqxC9FC9hKCVkM0E7CKCkknHLqhTZvWYLkHJQEorlNw+8yQe39zp1ZO61V+z2JjpNCXnnY2HWSSwSURfA1zuSJvHFTY8JKCTJ2EqpT1Pd1bpVLxHMKwr0UA7o72927ISCZE9sEADc+Sh5XG137Qbjdzc58fFnLuP/MwQTd5I7kv7Eu+Xi5b40cDY89LJb5bunLdYsz24ejrHn+W63v2FFA2JzDiOQJYjPvFDFuHfy4o54hvFEXuaO84NNZiEcPaY25GltG1GgiIIunpnhIPD8p8IxiuKTNY+lXF6iEiEwq8If3hCh63WYn8MT221M/p+RiS3FoFMA+x2aH0ty+/C9YPomGS8nHQc2VzSSLuzAtzqSsoFmQFQ1Xy83XSniVGHZm0etTejlLiy12Y8BcBQ0d63cG858n2ZEXozR1hCSZq1LCmNwD4hfiwTCG/R/bgG3FWZV3u2XUwhyCAkUdw3sd0RlmL9dYVSXEgw4vNEyTREi2c+Tagie0kYJXRKZWHPbJINuIGUDj8ssrCPhxS2IQqrB2Rcr9t 9/Im7rZ4 FV26jAaWAeReZhd0s45LwUU0HfsPC7Wr Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Aug 25, 2026 at 12:50:57PM +0200, David Hildenbrand (Arm) wrote: > On 8/22/26 21:14, Lorenzo Stoakes (ARM) wrote: > > secretmem has a relatively laissez-faire attitude to accounting the folios > > it allocates. > > > > The intention is that the memory is treated as if it were mlock()'d and > > thus is limited by the RLIMIT_MEMLOCK limit if the CAP_IPC_LOCK capability > > is not in place (which broadly allows unlimited ranges of mlock()'d > > memory). > > > > The lifecycle for memfd accounting against this limit is - account on map, > > unaccount on unmap but the lifecycle of memfd folios is allocate on fault, > > deallocate on inode eviction. > > > > This mismatch is problematic because the folios are unevictable and remain > > so until the inode is evicted (set using mapping_set_unevictable()). > > > > This is problematic as it eliminates usual mlock() semantics - mapping > > folios then unmapping them does not clear their unevictable state, since it > > depends on AS_UNEVICTABLE, not PG_mlocked. > > > > A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply > > map then unmap and VmLck no longer counts the secretmem range (or more > > involved - fork which also achieves the same thing). > > > > Worse - they are not accounted in the process's RSS even if mapped again, > > meaning the OOM killer won't know to kill the process. > > > > A user without the CAP_IPC_LOCK capability can therefore repeatedly > > map/unmap (or map/fork) and consume all available system memory with > > unevictable folios and cause system instability. > > > > A secretmem fd can be passed between processes and over fork so a > > per-process limit simply does not make sense. > > > > So follow the precedent set by io_uring, perf, skbuff, iommufd and xdp - > > track the number of locked pages in user_struct->locked_vm. > > > > Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK > > applies per-user not per-process. Also given the change in scope it doesn't > > make sense to bypass for users with CAP_IPC_LOCK, so remove it. > > > > There is simply no reason to carry on marking the mapping as mlock()'d > > since it's misleading and the lifecycle is now correctly handled, so remove > > this too. > > > > Additionally, fix the selftest which checks the limit as this now must > > assert SIGBUS on limit violation on fault-in. > > > > __secretmem_account_pages() is more or less a duplicate of the code that > > io_uring etc. use, but since this is a bug fix that needs backporting, > > defer any de-duplication efforts to a follow-up. > > > > Reported-by: Daehyeon Ko <4ncienth@gmail.com> > > Closes: https://lore.kernel.org/linux-mm/20260813225328.2010303-1-4ncienth@gmail.com/ > > Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") > > Cc: stable@vger.kernel.org > > Signed-off-by: Lorenzo Stoakes (ARM) > > Can we split off the selftest changes? This stable patch is already pretty big. Yeah I can do! I seem to recall people wanting tests backported too hence the change. > > I'd assume the changes to the selftests are not required just to get if fixed, > because the changes should not be breaking existing user space (and cosnequently > existing selftests). Yup confirmed locally that the changes don't break the tests. > > [...] > > > v1: > > https://patch.msgid.link/20260814-secretmem-accounting-v1-1-d2f8c677980b@kernel.org > > > > To: Andrew Morton > > To: Mike Rapoport > > To: David Hildenbrand > > To: "Liam R. Howlett" > > To: Vlastimil Babka > > To: Suren Baghdasaryan > > To: Michal Hocko > > To: Shuah Khan > > To: Alexei Starovoitov > > To: Daniel Borkmann > > To: "David S. Miller" > > To: Jakub Kicinski > > To: Jesper Dangaard Brouer > > To: John Fastabend > > To: Stanislav Fomichev > > To: James Bottomley > > To: Hagen Paul Pfeifer > > Cc: ljs@kernel.org > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-mm@kvack.org > > Cc: linux-kselftest@vger.kernel.org > > Cc: netdev@vger.kernel.org > > Cc: bpf@vger.kernel.org > > --- > > [...] > > > + > > +static bool secretmem_account_folio(struct secretmem_inode_state *state, > > + const struct folio *folio) > > +{ > > + unsigned long nr_pages; > > Nit: > > const unsinged long nr_pages = folio_nr_pages(folio); Ack > > > + > > + nr_pages = folio_nr_pages(folio); > > + if (!__secretmem_account_pages(state->user, nr_pages)) > > + return false; > > + > > + atomic_long_add(nr_pages, &state->nr_pages_accounted); > > + return true; > > +} > > + > > +static void __secretmem_unaccount_pages(struct secretmem_inode_state *state, > > + unsigned long nr_pages) > > +{ > > + atomic_long_sub(nr_pages, &state->user->locked_vm); > > + atomic_long_sub(nr_pages, &state->nr_pages_accounted); > > +} > > + > > +static void secretmem_unaccount_folio(struct secretmem_inode_state *state, > > + struct folio *folio) > > +{ > > + __secretmem_unaccount_pages(state, folio_nr_pages(folio)); > > +} > > + > > +static void secretmem_unaccount_all_folios(struct secretmem_inode_state *state) > > +{ > > + unsigned long nr_pages_accounted; > > + > > + nr_pages_accounted = atomic_long_read(&state->nr_pages_accounted); > > + __secretmem_unaccount_pages(state, nr_pages_accounted); > > +} > > + > > static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > { > > struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > struct inode *inode = file_inode(vmf->vma->vm_file); > > + struct secretmem_inode_state *state = inode->i_private; > > pgoff_t offset = vmf->pgoff; > > gfp_t gfp = vmf->gfp_mask; > > unsigned long addr; > > @@ -72,8 +134,15 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > goto out; > > } > > > > + if (!secretmem_account_folio(state, folio)) { > > + folio_put(folio); > > + ret = VM_FAULT_SIGBUS; > > + goto out; > > + } > > + > Okay, that works because secretmem does not support any form of truncate, in > particular, no FALLOC_FL_PUNCH_HOLE. Yeah exactly. I think I covered that off somewhere in my essay-length commit msg but if not but yeah that is a thing that I noted. > > Overall, the idea sounds good to me. Nothing jumped at me. Thanks! So in a way you kinda... Ack it right? :P If only there were a tag for that 🤔 ;) > > -- > Cheers, > > David -- Cheers, Lorenzo