Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1559350

llist code relies on undefined behaviour, upsets llvm/clang

Show all headers | View raw

Hi,

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.

Build with -DFIX, such that the llist_node has a zero offset from the
start of the struct, and things work.

Is anyone other than ppc64le building kernels with llvm/clang these
days? This should reproduce on ARM64 and x86-64.

Anton
--

#include <stdio.h>

#define __compiler_offsetof(a, b)                                       \
        __builtin_offsetof(a, b)

#undef offsetof
#ifdef __compiler_offsetof
#define offsetof(TYPE, MEMBER)  __compiler_offsetof(TYPE, MEMBER)
#else
#define offsetof(TYPE, MEMBER)  ((size_t)&((TYPE *)0)->MEMBER)
#endif

struct llist_node {
        struct llist_node *next;
};

#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)( (char *)__mptr - offsetof(type,member) );})

#define llist_entry(ptr, type, member)          \
        container_of(ptr, type, member)

#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))

struct foo {
#ifndef FIX
	unsigned long a;
#endif
	struct llist_node ll;
};

void working(void);

struct llist_node *ptr;

void bar(void)
{
	struct foo *f;

	llist_for_each_entry(f, ptr, ll) {
	}

	working();
}

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

llist code relies on undefined behaviour, upsets llvm/clang Anton Blanchard <anton@samba.org> - 2017-01-15 22:40 +0100
  Re: llist code relies on undefined behaviour, upsets llvm/clang Peter Zijlstra <peterz@infradead.org> - 2017-01-16 10:10 +0100
    Re: llist code relies on undefined behaviour, upsets llvm/clang Anton Blanchard <anton@samba.org> - 2017-01-16 12:50 +0100
      Re: llist code relies on undefined behaviour, upsets llvm/clang Peter Zijlstra <peterz@infradead.org> - 2017-01-16 14:00 +0100
        Re: llist code relies on undefined behaviour, upsets llvm/clang Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2017-01-16 14:10 +0100
  RE: llist code relies on undefined behaviour, upsets llvm/clang David Laight <David.Laight@ACULAB.COM> - 2017-01-16 15:40 +0100
    Re: llist code relies on undefined behaviour, upsets llvm/clang Peter Zijlstra <peterz@infradead.org> - 2017-01-16 17:30 +0100

csiph-web