Re: [PATCH v6 08/12] fork: Clear PASID for new mm

Hi Fenghua,

On Thu, 25 Feb 2021 22:17:11 +0000, Fenghua Yu [off-list ref] wrote:

Hi, Jean,

On Wed, Feb 24, 2021 at 11:19:27AM +0100, Jean-Philippe Brucker wrote:

quoted

Hi Fenghua,

[Trimmed the Cc list]

On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote:  

quoted

When a new mm is created, its PASID should be cleared, i.e. the PASID
is initialized to its init state 0 on both ARM and X86.  

I just noticed this patch was dropped in v7, and am wondering whether we
could still upstream it. Does x86 need a child with a new address space
(!CLONE_VM) to inherit the PASID of the parent?  That doesn't make much
sense with regard to IOMMU structures - same PASID indexing multiple
PGDs?  

You are right: x86 should clear mm->pasid when a new mm is created.
This patch somehow is losted:(

quoted

Currently iommu_sva_alloc_pasid() assumes mm->pasid is always
initialized to 0 and fails on forked tasks. I'm trying to figure out
how to fix this. Could we clear the pasid on fork or does it break the
x86 model?  

x86 calls ioasid_alloc() instead of iommu_sva_alloc_pasid(). So

We should consolidate at some point, there is no need to store pasid in two
places.

functionality is not a problem without this patch on x86. But I think

I feel the reason that x86 doesn't care is that mm->pasid is not used
unless bind_mm is called. For the fork children even mm->pasid is non-zero,
it has no effect since it is not loaded onto MSRs.
Perhaps you could also add a check or WARN_ON(!mm->pasid) in load_pasid()?

we do need to have this patch in the kernel because PASID is per addr
space and two addr spaces shouldn't have the same PASID.

Agreed.

Who will accept this patch?

Thanks.

-Fenghua

Thanks,

Jacob