On Mon, 2026-10-19 at 10:35 +0200, Christian König wrote:
On 10/16/26 22:26, Karl Mehltretter wrote:
On Tue, Feb 17, 2026 at 08:11:34PM -0400, Jason Gunthorpe wrote:
- match_args.attach = attach;
- if (dmabuf->ops->match_mapping) {
ret = dmabuf->ops->match_mapping(&match_args);- }
attach->dmabuf = dmabuf; attach->importer_ops = importer_ops; attach->importer_priv = importer_priv;
I may misunderstand the intended contract. match_mapping() runs while the attachment is still zeroed and without dmabuf->resv held.
Patch 11's amdgpu callback needs importer_ops and importer_priv, so its XGMI match cannot work here. Patch 12's VFIO callback asserts dmabuf-
resv and
reads priv->vdev, which cleanup changes under that lock.
Should the core initialize the attachment and hold dmabuf->resv for match_mapping(), or should callbacks avoid attachment and lock- protected state?
Right. This completely misplaced.
The matching can't be done at attachment time, but rather needs to be done before creating a mapping while holding the resv lock so that the matching decision can't change.
So question is what exactly should the contract be? Looking at the pcie_p2p negotiation today it looks somewhat like.
1) Importer and exporter agree at attach time what mappings are allowed pending placement conditions and other attachers. 2) At map-time the mapping is negotiated taking all constraints into account. 3) The negotiated mapping is valid until an invalidate_mappings() callback is received.
Following this would allow a re-implementation of pcie_p2p as a mapping type and would allow a controlled link-severing to send an invalidate_mappings() notifier and the mappings to be re-negotiated.
Importers requiring an early hint as to what the actual mapping would look like would need to be prepared to re-consider at map-time, with a reasonable assumption that the reconsideration and re-mapping would happen seldom enough.
Thanks, Thomas
Regards, Christian.
Thanks, Karl