Re: [PATCH v5 15/18] iommufd: Persist iommu hardware pagetables for live update

[Samiullah Khawaja]

On Wed, Sep 23, 2026 at 04:59:30PM -0700, John Starks wrote:
> On Mon, Sep 21, 2026 at 12:48:31AM +0000, Samiullah Khawaja wrote:
> > From: YiFei Zhu <zhuyifei@xxxxxxxxxx>
> > +
> > +		/*
> > +		 * When this memory file was mapped it should be sealed and seal
> > +		 * should be sealed. This means that since mapping was done the
> > +		 * memory file was not grown or shrink and the pages being used
> > +		 * until now remain pinned and preserved.
> > +		 */
> > +		if ((pages->seals & req_seals) != req_seals) {
> > +			ret = -EINVAL;
> > +			break;
> > +		}
> > +
>
> Is this sealing business sufficient? Even with the specified
> seals, user mode can still punch a hole in the memfd after it
> has been mapped. This will disassociate those pages from the memfd
> but leave them referenced by the HWPT.

Nice catch. Since punch hole doesn't change size, the shrink/grow seals
will not stop that from happening.

Once the memfd is preserved it is frozen, so punch hole is not allowed
after that. To catch the punch hole between map and iommufd preserve, we
need a truncate count on the memfd that can be checked here. Or we can
iterate through the iopt pages and verify that they are still associated
with the preserved memfd, similar to how memfd preserve already loops
through all the pages. I am inclined towards the iterative solution as
it handles all the future cases.

I will fix this in the next revision.

Thanks,
Sami
> Then, when the memfd gets preserved, the hole will be filled
> by a new set of pages, and only those pages that will be
> preserved across the kexec. The original set, unless I'm missing
> something, will be dangling in the HWPT, allowing attached
> devices to DMA to the wrong memory.