Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Fix severe peformance issue accessing keys #681

Merged
merged 1 commit into from
Dec 14, 2024

Conversation

nomis
Copy link
Contributor

@nomis nomis commented Aug 16, 2022

The "true" in the call to Generation::create() in OSToken::OSToken() is
used as the umask when it's supposed to be the isToken value (#566).

Remove the default value from isToken because it's dangerous and there are
only two callers. Explicitly pass "true" and "false" for isToken.

Failing to consider this a token generation file means that the value is
never refreshed for read-only operations. All objects are reloaded from
disk every time one of them is refreshed. List operations take a long time
because all of the objects are re-read for each object.

Fixes #680.

The "true" in the call to Generation::create() in OSToken::OSToken() is
used as the umask when it's supposed to be the isToken value (softhsm#566).

Remove the default value from isToken because it's dangerous and there are
only two callers. Explicitly pass "true" and "false" for isToken.

Failing to consider this a token generation file means that the value is
never refreshed for read-only operations. All objects are reloaded from
disk every time one of them is refreshed. List operations take a long time
because all of the objects are re-read for each object.

Fixes softhsm#680.
@nomis
Copy link
Contributor Author

nomis commented Aug 16, 2022

ods-hsmutil list now takes 2.7s instead of 13+ minutes for 311 keys...

@nomis nomis changed the title Fix refresh of OSToken by passing isToken=true to Generation::create() Fix severe peformance issue accessing keys Apr 13, 2023
@nomis nomis mentioned this pull request Apr 13, 2023
antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Oct 31, 2023
antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Oct 31, 2023
@nomis
Copy link
Contributor Author

nomis commented Dec 4, 2023

@halderen it looks like you're nearing the point of making a release for other changes, could you merge this soon?

antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Nov 29, 2024
Copy link
Contributor

@ijsf ijsf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its pretty obvious this is an argument handling mistake in the code. This PR fixes that and makes the function call more explicit.

antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Nov 29, 2024
antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Nov 29, 2024
@jschlyter jschlyter requested a review from bjosv December 2, 2024 05:33
antoinelochet pushed a commit to antoinelochet/SoftHSMv2 that referenced this pull request Dec 3, 2024
Copy link
Contributor

@bjosv bjosv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!
A fixup for #566.
Maybe there is clang-tidy checker that could have helped us catching this, implicit-bool-conversion might be to broad but maybe there is something else in that toolbox.

@jschlyter jschlyter merged commit 4be49e3 into softhsm:develop Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lookups of specific keys are too slow
4 participants