-
Notifications
You must be signed in to change notification settings - Fork 49
shared: Use unsigned char in hash calculation #248
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
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked at the hash_superfast
commit and I suspect we really need a test for it to land.
The rest of the patches look great.
not very happy with changing the result... if we are changing I think we need to add some instrumentation and compare the amound of collisions we have with the current hash table size. Also... if we are changing, I'd rather add a pre step in which we (possibly) process the first element to get an aligned buffer on u16, so we don't have to use get_unaligned(). However most of our strings are really small, so I'm not sure it will make a noticeable difference. |
If newly created module in kmod_module_new could not be added to hash, return an error. Otherwise it is possible to create multiple independent structs with the same name, which the hash set is supposed to prevent. An error only occurs in out of memory conditions. Signed-off-by: Tobias Stoeckmann <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Link: #248 Signed-off-by: Lucas De Marchi <[email protected]>
Follow up of aad7c69, which fixes the same issue in another function. Signed-off-by: Tobias Stoeckmann <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Link: #248 Signed-off-by: Lucas De Marchi <[email protected]>
Use %zu for size_t, not %zd which would be for ssize_t. Signed-off-by: Tobias Stoeckmann <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Link: #248 Signed-off-by: Lucas De Marchi <[email protected]>
Applied all but the first. Please rebase and let's continue the discussion on how to land this fix. |
Characters in key are supposed to be handled unsigned. Explicitly cast key[2] in case the key contains 8-bit ASCII. Even though we cannot support such keys in indices, we might still use them in module names and tools like modinfo. Signed-off-by: Tobias Stoeckmann <[email protected]>
53a224a
to
9803c44
Compare
Spotted these while investigating #26.
Since these don't fix the issue but would basically lead all to a single PR, I've grouped them in a single one instead.