llist code relies on undefined behaviour, upsets llvm/clang
David Laight
David.Laight at ACULAB.COM
Tue Jan 17 01:34:43 AEDT 2017
From: Anton Blanchard
> Sent: 15 January 2017 21:36
> I was debugging a hang on a ppc64le kernel built with clang, and it
> looks to be undefined behaviour with pointer wrapping in the llist code.
>
> A test case is below. llist_for_each_entry() does container_of() on a
> NULL pointer, which wraps our pointer negative, then adds the same
> offset back in and expects to get back to NULL. Unfortunately clang
> decides that this can never be NULL and optimises it into an infinite
> loop.
...
> #define llist_for_each_entry(pos, node, member) \
> for ((pos) = llist_entry((node), typeof(*(pos)), member); \
> &(pos)->member != NULL; \
> (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
Maybe the above could be rewritten as (untested):
for ((pos) = NULL; (!(pos) ? (node) : ((pos)->member.next) || (pos) = 0) && \
(((pos) = !(pos) ? llist_entry((node), typeof(*(pos)), member) \
: llist_entry((pos)->member.next, typeof(*(pos)), member)),1); )
Provided the compiler assumes that the loop body is never executed with 'pos == 0'
it should generate the same code.
David
More information about the Linuxppc-dev
mailing list