From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAE40244667 for ; Mon, 26 Jan 2026 14:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769438250; cv=none; b=Qxln7bi1pNDWhqxxelnWWEuo2RdkvQoFZ+cyBO2CW5YQSHuJKV9n7DEnA98SI3Ozpiffuqtd1tUvcKGZR4tnM7sBn2d7q/jo0eWr3i5GcvVW32C53IXZC1I/7fjGqU+ForcF8uXCkpj+4b7L17QVlDBoakgXDQ5BOY6E0yzEvCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769438250; c=relaxed/simple; bh=gdfx2feLN6TCXDpAa4ggnSeI5KqTW3J3K6FBc2yfOFE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dhBr7RXb4rTY28ewWnVP88RbpArDoU9W6N3DRlANNxMgZKJaQuae4DETnAJs0fYu+e8CMTa7q/C7CCCJyDQU7kr3X4IquwJ8ZZuUUq8n8vEIx6eNAUevgccwjytxB9Z28kVc+VyLK39k4PBVNWyVtbUGJnvnVDngXXBOP9SFYU4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rf6nge47; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rf6nge47" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0CDDC116C6; Mon, 26 Jan 2026 14:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769438250; bh=gdfx2feLN6TCXDpAa4ggnSeI5KqTW3J3K6FBc2yfOFE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rf6nge473dxjqTDe76VCvV99QZTDzBZNcuE4AVsvRCx1tVdM4YvKftbA0xuh1CZ63 iVw1pHZyedxQSBviJM/DhVKJzpNTb25ztptjSIqJv/oD1AfIzNakztu1716jOz++yv FRkE8N4q762X+u0hBJQlN1daImLdQ4h+qGCSlSjfEVTnS+dpfVnkM0LsFkMVerHwiy /K25y+D3H/rD9K+QXYDiF4Z/y/NOiPEqicW6qbDLZ6tS9GbZSybVTjprj65FtqeaCB hZdClXbebcJoi9B+cRjIMeYgpJS8aCMazKmgbhPli7JipLNWZZCLJKE2MJqzutD9Fs llFvM0qNIaMUw== Date: Mon, 26 Jan 2026 16:37:23 +0200 From: Mike Rapoport To: Pratyush Yadav Cc: Alexander Graf , Pasha Tatashin , Hugh Dickins , Baolin Wang , Andrew Morton , Jason Gunthorpe , Samiullah Khawaja , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm: memfd_luo: preserve file seals Message-ID: References: <20260123095854.535058-1-pratyush@kernel.org> <20260123095854.535058-3-pratyush@kernel.org> <2vxzqzrca6cm.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2vxzqzrca6cm.fsf@kernel.org> Hi Pratyush, On Mon, Jan 26, 2026 at 01:47:21PM +0100, Pratyush Yadav wrote: > Hi Mike, > > On Sun, Jan 25 2026, Mike Rapoport wrote: > > On Fri, Jan 23, 2026 at 10:58:51AM +0100, Pratyush Yadav wrote: ... > >> - file = memfd_alloc_file("", 0); > >> + /* > >> + * The seals are preserved. Allow sealing here so they can be added > >> + * later. > >> + */ > >> + file = memfd_alloc_file("", MFD_ALLOW_SEALING); > > > > I think we should select flags passed to memfd_alloc_file() based on > > ser->seals (and later based on ser->seals and ser->flags). > > Not sure what you mean. > > I think the only seal we can set via memfd_alloc_file() flags is > MFD_NOEXEC_SEAL, which is really a F_SEAL_EXEC and plus a change of the > inode's mode. And now that I think of it, that is a valid use case that > we might as well support. But I think that should be done by preserving > the mode of the inode directly, and then copying the seals back. The > main reason for that is that the mode can be changed after the memfd is > created too. > > Other than that, all other seals are set by fcntl (via > memfd_add_seals()), so I don't see what else we can pass to > memfd_alloc_file(). Hmm, "using ser->seals" was bad phrasing :) Now we add support for creating memfd with MFD_ALLOW_SEALING and at some point we'd want MFD_HUGETLB and huge page size. So I think we should have a field in ser that will define what flags should be used for creation of memfd and based on the value of that field pass the flags to memfd_alloc_file(). For seals support this field can be hardwired to MFD_ALLOW_SEALING at preserve time. > >> if (IS_ERR(file)) { > >> pr_err("failed to setup file: %pe\n", file); > >> err = PTR_ERR(file); > >> goto free_ser; > >> } > >> > >> + err = memfd_add_seals(file, ser->seals); > > > > I'm not sure using MFD_ALLOW_SEALING is enough if there was F_SEAL_EXEC in > > seals. > > Why not? memfd_add_seals() can handle F_SEAL_EXEC as far as I can tell. I just noticed it behaved differently :) Looks like F_SEAL_EXEC indeed can handle it. > -- > Regards, > Pratyush Yadav -- Sincerely yours, Mike.