Skip to content

[SYCL][UR][L0 v2] fix use after free on queue #18101

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 2 commits into
base: sycl
Choose a base branch
from

Conversation

igchor
Copy link
Member

@igchor igchor commented Apr 18, 2025

No description provided.

@igchor igchor requested review from a team as code owners April 18, 2025 17:12
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 17:12 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 17:24 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 17:34 — with GitHub Actions Inactive
@igchor igchor force-pushed the event_release_simplify branch from 95ad662 to de67ad7 Compare April 18, 2025 17:43
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 17:43 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 17:53 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 18:04 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 18:04 — with GitHub Actions Inactive
@igchor igchor force-pushed the event_release_simplify branch from de67ad7 to e739c9c Compare April 18, 2025 18:51
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 18:52 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 19:11 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 19:23 — with GitHub Actions Inactive
@igchor igchor temporarily deployed to WindowsCILock April 18, 2025 19:23 — with GitHub Actions Inactive
igchor added 2 commits April 18, 2025 19:50
There was a potential race: if getEventEndTimestamp returns
false and just after that the queue finishes and is destroyed,
we would call deferEventRelease on invalid queue.

This patch reworks the logic for deferring event release.
Instead of registering the events to be released in the queue,
we just clear adjustedEventStartTimestamp and adjustedEventEndTimestamp
to mark the event as not timestamped. Since events are never
actually destroyed, only returned to the pool, any pending
timestamp write will always succeed. Since we are only dealing
with in-order queues, the timestamp can only increase.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant