Aliasing issue with TAILQ on ppc64 ?

[Attilio Rao]

On 9/18/12, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message
> <CAJ-FndCsf2Xsn=1ioHyr_tn3-yAFOE7E9-wrjp4rcQJajhZvpg at mail.gmail.com>
> , Attilio Rao writes:
>
>>The only way I can see this
>>code is safe is, infact, to lock it with proper locks around the
>>operations.
>
> This is not about locking: at the time where this croaks there is
> only one thread.
>
> The problem is that:
>
> 	// Empty, freshly initialized ban_head
>
> 	b = valid_ban_object();
> 	TAILQ_INSERT_HEAD(&ban_head, b, list);
>
> 	be = TAILQ_LAST(&ban_head, banhead_s);
>
> Causes a sig#11 in TAILQ_LAST().
>
> I belive it is a NULL dereference, and I belive it happens
> because the compiler overoptimizes TAILQ_{LAST|PREV}()

Yep, it likely means you need to use compiler memory barriers then.
I didn't look into details the implementation of TAILQ (but I can if
you want) to point you precisely where, but it seems you already know
that code well enough to tell where.

Compiler memory barriers will avoid the compiler to reorder
loads/stores before/after it and currently we use the gcc idiom for it
__asm __volatile (" " : : : "memory") which forces a registers
reflush. This also avoids the compiler to optimize some variables in
the registers when traversing a barrier, saving the usage of
"volatile" more often.

TAILQ is certainly subjective to aliasing because it is inlined code,
so, differently from hard functions which are safe with gcc compiling
flags.

However, please note that this type of issue is not only related to
ppc64, but to all gcc/clang supported platforms.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein