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