tasks: Don't set parent's sticky bit when in a finalizer #48919
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vtjnash
approved these changes
Mar 6, 2023
jpsamaroo
force-pushed
the
jps/finalizer-parent-no-sticky
branch
from
12e34e1 to
dbd8802
Compare
vtjnash
approved these changes
Mar 9, 2023
|
Could you resolve the conflict in base/task.jl? |
jpsamaroo
force-pushed
the
jps/finalizer-parent-no-sticky
branch
from
dbd8802 to
d3d1d32
Compare
Done |
Xnartharax
pushed a commit
to Xnartharax/julia
that referenced
this pull request
Apr 19, 2023
Keno
added a commit
that referenced
this pull request
Jul 19, 2023
In #48919, the tid selection logic inside `enq_task` gained a `!GC.in_finalizer()` condition. However, this made it possible for `workqueue_at` to be reached with `tid==0`, which would attempt and out-of-bounds write under `@inbounds`, corrupting memory. This was not caught in the test suite despite `--check-bounds=yes`, because our `--check-bounds=yes` is currently best effort. That would be fixed by #50239, which exposed this bug.
Keno
added a commit
that referenced
this pull request
Jul 19, 2023
In #48919, the tid selection logic inside `enq_task` gained a `!GC.in_finalizer()` condition. However, this made it possible for `workqueue_at` to be reached with `tid==0`, which would attempt and out-of-bounds write under `@inbounds`, corrupting memory. This was not caught in the test suite despite `--check-bounds=yes`, because our `--check-bounds=yes` is currently best effort. That would be fixed by #50239, which exposed this bug. This PR attempts to fix this by marking any tasks launched inside a finalizer as not sticky. Finalizers don't have any thread they run on semantically, so i don't think there's a meaningful sense in which tasks launched inside finalizers could be sticky.
KristofferC
pushed a commit
that referenced
this pull request
Jul 24, 2023
In #48919, the tid selection logic inside `enq_task` gained a `!GC.in_finalizer()` condition. However, this made it possible for `workqueue_at` to be reached with `tid==0`, which would attempt and out-of-bounds write under `@inbounds`, corrupting memory. This was not caught in the test suite despite `--check-bounds=yes`, because our `--check-bounds=yes` is currently best effort. That would be fixed by #50239, which exposed this bug. This PR attempts to fix this by marking any tasks launched inside a finalizer as not sticky. Finalizers don't have any thread they run on semantically, so i don't think there's a meaningful sense in which tasks launched inside finalizers could be sticky. (cherry picked from commit bd8350b)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When spawning a child task via
@async, we "poison" the parent by setting theirstickyflag totrueto ensure that parent and child are co-scheduled on the same thread. This is obviously unideal, and also is potentially incorrect when this happens within a GC finalizer (which co-opts an unsuspecting task to run itself). This PR uses theGC.in_finalizerquery added in #48857 to ensure that this does not happen when the parent is running within a GC finalizer.