All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Alexander Graf <graf@amazon.com>,
	 Pasha Tatashin <pasha.tatashin@soleen.com>,
	 Hugh Dickins <hughd@google.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Samiullah Khawaja <skhawaja@google.com>,
	kexec@lists.infradead.org,  linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: memfd_luo: preserve file seals
Date: Tue, 10 Feb 2026 14:53:51 +0100	[thread overview]
Message-ID: <2vxzikc4so0g.fsf@kernel.org> (raw)
In-Reply-To: <20260210131307.GD3076640@nvidia.com> (Jason Gunthorpe's message of "Tue, 10 Feb 2026 09:13:07 -0400")

On Tue, Feb 10 2026, Jason Gunthorpe wrote:

> On Tue, Feb 10, 2026 at 02:10:45PM +0100, Pratyush Yadav wrote:
>> Hi Jason,
>> 
>> On Mon, Jan 26 2026, Jason Gunthorpe wrote:
>> 
>> > On Sun, Jan 25, 2026 at 02:03:29PM +0200, Mike Rapoport wrote:
>> >> > @@ -67,11 +72,13 @@ struct memfd_luo_folio_ser {
>> >> >  struct memfd_luo_ser {
>> >> >  	u64 pos;
>> >> >  	u64 size;
>> >> > +	u64 seals:8;
>> >> 
>> >> Kernel uABI defines seals as unsigned int, I think we can spare u32 for
>> >> them and reserve a u32 flags for other memfd flags (MFD_CLOEXEC,
>> >> MFD_HUGETLB etc).
>> >
>> > It is a bit worse than that, the "v2" version is only going to support
>> > some set of seals (probably the set defined in v6.19) and if there are
>> > new seals down the road then this needs a version bump.
>> 
>> If we are running say kernel X, then X + 1 will always support a
>> superset of the seals, since the seals are UAPI. So it should be able to
>> handle all the seals that are given to it by X. This only becomes a
>> problem on rollbacks. Is this what you are worried about or am I missing
>> something?
>
> I think you need a check at some point only permitting seals that are
> defined right now.
>
> Eg some future v7.19 kernel has MEMFD_SEAL_XX it should not be allowed
> through luo until the API is bumped to v3

Makes sense. Will add.

-- 
Regards,
Pratyush Yadav


      reply	other threads:[~2026-02-10 13:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23  9:58 [PATCH 0/2] mm: memfd_luo: preserve file seals Pratyush Yadav
2026-01-23  9:58 ` [PATCH 1/2] memfd: export memfd_{add,get}_seals() Pratyush Yadav
2026-01-25 11:52   ` Mike Rapoport
2026-01-23  9:58 ` [PATCH 2/2] mm: memfd_luo: preserve file seals Pratyush Yadav
2026-01-25 12:03   ` Mike Rapoport
2026-01-26 12:47     ` Pratyush Yadav
2026-01-26 14:37       ` Mike Rapoport
2026-02-10 13:15         ` Pratyush Yadav
2026-01-26 18:31     ` Jason Gunthorpe
2026-02-10 13:10       ` Pratyush Yadav
2026-02-10 13:13         ` Jason Gunthorpe
2026-02-10 13:53           ` Pratyush Yadav [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2vxzikc4so0g.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=graf@amazon.com \
    --cc=hughd@google.com \
    --cc=jgg@nvidia.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=rppt@kernel.org \
    --cc=skhawaja@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.