[dayatsin-amd]

Summary

Stacked on #9394 (base branch users/ashetaia/fmm-svm-api-reland), so this diff
is one commit on top of that PR.

#9394 tracks SVM-API registrations by page-aligned base. Every buffer sharing a
base therefore shares one tracking entry: one refcount, and one extent grown to
the largest span ever registered at that base and never reduced. Two
consequences:

1. Over-revoke by grown extent. A hot heap base keeps a large extent for as
   long as any registration at that base is alive. When the last one is dropped,
   the inverse SET_ATTR (NO_ACCESS per GPU plus CLR_FLAGS of COHERENT and
   EXT_COHERENT) is issued over that whole extent instead of over the buffer
   being deregistered. Clearing the coherency flags silently downgrades a range
   from fine- to coarse-grained, so a GPU read of memory that is still live
   elsewhere can return stale data with no fault.
2. Sweep skips an enclosing range. The interval subtraction that is supposed
   to protect surviving registrations starts at rbtree_lookup_nearest(base, LEFT), which is only the immediate predecessor by address. A longer
   registration further left still covers base but is never visited, so its
   pages get revoked underneath it.

This was seen as output corruption in an inference workload that disappears with
HSA_USE_SVM=0, which disables the SVM-API registration path entirely.

Changes

• Track one entry per registration, keyed by the exact user pointer that
  register and deregister both carry, so each registration revokes only its own
  extent. The extent can still grow, but only across repeat registrations of the
  same pointer - which an allocator cannot produce while the first registration
  is still live.
• Start the sweep at the first range that can still reach base, bounded by the
  largest tracked extent, instead of at the immediate predecessor.
• Insert the tracking entry after the ioctl succeeds. The reject that motivated
  reserving it up front was removed earlier in Reland: fix(rocr/thunk): Revoke SVM-API GPU access on deregister, with register re-grant #9394, so this also drops the
  error-path rollback gap and the args leak on that path (both raised in review
  on Reland: fix(rocr/thunk): Revoke SVM-API GPU access on deregister, with register re-grant #9394).

Not addressed here: register grants ACCESS_IN_PLACE to every GPU in the
process while the map step only grants to the caller's agent whitelist. That
widening needs fmm_register_mem_svm_api to receive the node array and is worth
its own change.

JIRA ID

JIRA ID : ROCM-28520

Test plan

• libhsakmt compiles clean, no new warnings
• Traced the kfdtest coverage added by Reland: fix(rocr/thunk): Revoke SVM-API GPU access on deregister, with register re-grant #9394 against the new keying:
  SVMApiDeregisterTest phases 1-3, SVMApiSharedPageTest,
  SVMApiOverlapReproTest and SVMApiRegisterReGrant all still hold,
  including the assertions that motivated the base-keyed design
• Run the above kfdtests on gfx942 with HSA_XNACK=1
• Confirm the workload corruption is gone with the SVM-API path enabled
  (HSA_USE_SVM unset)

Made with Cursor

[therock-pr-bot]

✅ All Policy Checks Passed

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

🎉 All policy checks passed!

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[therock-pr-bot]

🚫 Please fix the failed policies before requesting reviews.

The following policy checks failed:

• ❌ Unit Test

The Not ready to Review label has been added to this PR.
Once all policies pass, the label will be removed automatically.

[shwetagkhatri]

LGTM