-
Notifications
You must be signed in to change notification settings - Fork 509
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
a persistent bug caused by name conflicts between barrier() macro and function name #5292
Comments
The implementation of hardware fencing for non-temporal memcpy variants is done using a function pointer. Some of those pointers were called "barrier" which unfortunately overlaps with a function-like macro that's used for compiler barriers. This meant that a compiler barrier was being used instead of a hardware store barrier. This patch changes the compiler barrier to a static inline function called "compiler_barrier" to avoid name conflicts. Fixes pmem#5292 Reported-by: @Transpeptidase
Thank you for finding this. Such an unfortunate thing to overlook... Macros are evil after all ;) If you don't mind me asking, how did you find the problem? Just by analyzing the code or through the use of some tool? |
The implementation of hardware fencing for non-temporal memcpy variants is done using a function pointer. Some of those pointers are called "barrier" which unfortunately overlaps with a function-like macro that's used for compiler barriers. This meant that a compiler barrier was being used instead of a hardware store barrier. This patch changes the compiler barrier to a static inline function called "compiler_barrier" to avoid name conflicts. Fixes pmem#5292 Reported-by: @Transpeptidase
I just used |
That makes sense. Thanks. |
The implementation of hardware fencing for non-temporal memcpy variants is done using a function pointer. Some of those pointers are called "barrier" which unfortunately overlaps with a function-like macro that's used for compiler barriers. This meant that a compiler barrier was being used instead of a hardware store barrier. This patch changes the compiler barrier to a static inline function called "compiler_barrier" to avoid name conflicts. Fixes pmem#5292 Reported-by: @Transpeptidase
The implementation of hardware fencing for non-temporal memcpy variants is done using a function pointer. Some of those pointers are called "barrier" which unfortunately overlaps with a function-like macro that's used for compiler barriers. This meant that a compiler barrier was being used instead of a hardware store barrier. This patch changes the compiler barrier to a static inline function called "compiler_barrier" to avoid name conflicts. Fixes pmem#5292 Reported-by: @Transpeptidase
ISSUE:
Environment Information
Please provide a reproduction of the bug:
pmdk/src/libpmem2/x86_64/memcpy/memcpy_nt_avx512f.c
Lines 403 to 415 in 46d4fc9
In this function, the function pointer called
barrier
is overridden by macro barrier(), which causes functionmemmove_movnt_avx512f_clflush
not issuingsfence
instructions.pmdk/src/core/util.h
Lines 134 to 142 in 46d4fc9
How often bug is revealed: (always, often, rare):
Actual behavior:
Use the barrier macro
Expected behavior:
Call the barrier function pointer
Details
Additional information about Priority and Help Requested:
Are you willing to submit a pull request with a proposed change? (Yes, No) Yes
Requested priority: (Showstopper, High, Medium, Low) High
The text was updated successfully, but these errors were encountered: