a persistent bug caused by name conflicts between barrier() macro and function name

[Transpeptidase]

ISSUE:

Environment Information

• PMDK package version(s): PMDK Version 1.11.0
• OS(es) version(s): N/A
• ndctl version(s): N/A
• kernel version(s): N/A
• compiler, libraries, packaging and other related tools version(s): N/A

Please provide a reproduction of the bug:

pmdk/src/libpmem2/x86_64/memcpy/memcpy_nt_avx512f.c

Lines 403 to 415 in 46d4fc9

	static force_inline void
	memmove_movnt_avx512f(char *dest, const char *src, size_t len, flush_fn flush,
	barrier_fn barrier)
	{
	if ((uintptr_t)dest - (uintptr_t)src >= len)
	memmove_movnt_avx512f_fw(dest, src, len, flush);
	else
	memmove_movnt_avx512f_bw(dest, src, len, flush);
	barrier();
	VALGRIND_DO_FLUSH(dest, len);
	}

In this function, the function pointer called barrier is overridden by macro barrier(), which causes function memmove_movnt_avx512f_clflush not issuing sfence instructions.

pmdk/src/core/util.h

Lines 134 to 142 in 46d4fc9

	#ifdef _MSC_VER
	#define force_inline inline __forceinline
	#define NORETURN __declspec(noreturn)
	#define barrier() _ReadWriteBarrier()
	#else
	#define force_inline __attribute__((always_inline)) inline
	#define NORETURN __attribute__((noreturn))
	#define barrier() asm volatile("" ::: "memory")
	#endif

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

[pbalcer]

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?

[Transpeptidase]

I just used memmove_movnt_avx512f_clwb to test PM bandwidth, but found no matter how granular the write is （64B or 128B），the single-core bandwidth is the same and is high :)

[pbalcer]

That makes sense. Thanks.