Add safety checks when rendering kernel key strings #8327
Merged
+384
−91
Conversation
This file contains 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
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/8327
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit e9926e7 with merge base 8697fe4 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D69324821 |
larryliu0820
approved these changes
Feb 10, 2025
dbort
force-pushed
the
export-D69324821
branch
from
b6fbd2c to
015af26
Compare
dbort
added a commit
to dbort/executorch
that referenced
this pull request
Feb 10, 2025
Summary: The old code assumed that it was handed a MAX_SIZE buffer, and that the list of TensorMeta values would never generate a string longer than that size. This PR adds explicit size tracking and an error code to the API, and now returns an error if the buffer is too small for the provided values. While I'm here, move MAX_SIZE out of the public API, since it's not an intrinsic aspect of kernel keys. This is technically a BC-breaking change, but I don't expect that any users are actually depending on it. Also: - Fix some unused var warnings (one of which was a real bug where we ignored an Error) - Silence the Meta-internal linter by moving to std::array in several places, code chunks I needed to touch anyway because of the new `make_kernel_key` parameter Add unit tests for all modified code. Reviewed By: larryliu0820 Differential Revision: D69324821
dbort
added a commit
to dbort/executorch
that referenced
this pull request
Feb 10, 2025
Summary: The old code assumed that it was handed a MAX_SIZE buffer, and that the list of TensorMeta values would never generate a string longer than that size. This PR adds explicit size tracking and an error code to the API, and now returns an error if the buffer is too small for the provided values. While I'm here, move MAX_SIZE out of the public API, since it's not an intrinsic aspect of kernel keys. This is technically a BC-breaking change, but I don't expect that any users are actually depending on it. Also: - Fix some unused var warnings (one of which was a real bug where we ignored an Error) - Silence the Meta-internal linter by moving to std::array in several code chunks I needed to touch anyway because of the new `make_kernel_key` parameter Add unit tests for all modified code. Reviewed By: larryliu0820 Differential Revision: D69324821
dbort
force-pushed
the
export-D69324821
branch
from
015af26 to
7f1f28a
Compare
|
This pull request was exported from Phabricator. Differential Revision: D69324821 |
1 similar comment
|
This pull request was exported from Phabricator. Differential Revision: D69324821 |
Summary: The old code assumed that it was handed a MAX_SIZE buffer, and that the list of TensorMeta values would never generate a string longer than that size. This PR adds explicit size tracking and an error code to the API, and now returns an error if the buffer is too small for the provided values. While I'm here, move MAX_SIZE out of the public API, since it's not an intrinsic aspect of kernel keys. This is technically a BC-breaking change, but I don't expect that any users are actually depending on it. Also: - Fix some unused var warnings, which uncovered a couple places where we ignored an Error. Along similar lines, replaced EXPECT with ASSERT when validating kernel registration so we don't try to run the rest of the test after a registration error. - Silence the Meta-internal linter by moving to std::array in several code chunks I needed to touch anyway because of the new `make_kernel_key` parameter. Add unit tests for all modified code. Reviewed By: larryliu0820 Differential Revision: D69324821
dbort
force-pushed
the
export-D69324821
branch
from
7f1f28a to
e9926e7
Compare
|
This pull request was exported from Phabricator. Differential Revision: D69324821 |
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.
Summary:
The old code assumed that it was handed a MAX_SIZE buffer, and that the list of TensorMeta values would never generate a string longer than that size.
This PR adds explicit size tracking and an error code to the API, and now returns an error if the buffer is too small for the provided values.
While I'm here, move MAX_SIZE out of the public API, since it's not an intrinsic aspect of kernel keys. This is technically a BC-breaking change, but I don't expect that any users are actually depending on it.
Also:
make_kernel_keyparameter.Add unit tests for all modified code.
Differential Revision: D69324821