Date: Tue, 18 Sep 2012 12:59:20 +0000 From: Poul-Henning Kamp <phk@phk.freebsd.dk> To: arch@freebsd.org Subject: Aliasing issue with TAILQ on ppc64 ? Message-ID: <95608.1347973160@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
In Varnish I have adopted <sys/queue.h> and today I saw a weird issue on a PPC64 platform, which makes me wonder if we have a potential aliasing issue with TAILQs. The backwards pointers in TAILQs point to the forward pointer of the previous element, rather than to the top of the previous element. To go backwards you therefore have to go two steps backwards and one step forward. TAILQ_PREV and TAILQ_LAST do this by assuming that the head and element structures for a TAILQ are the same, and casts the point from &(elem->next) to &head, and dereferences head->last as a proxy for elem->prev. This is elegant, but not type-safe. I have not 100% confirmed, that in the in problem we had with PPC64, the compiler in this case fails to spot the aliasing. When I made the head-struct volatile, the problem went away, which it also did when I put in a function call at the suspect place to force a register spill. I have previously tried to find a way to rewrite TAILQ_LAST/PREV to be type-safe, but utterly failed, and I have reached the conclusion that with the current "API" or minor modifications thereof, that is patently impossible. It may be a good idea to find some way to make sure the compiler spots the potential aliasing, but I am not sufficiently up to date on compiler optimizations to know a safe and reliable way to do that. (Would explicitly casting throuh a void do it ?) Poul-Henning Details: https://github.com/varnish/Varnish-Cache/blob/3.0/bin/varnishd/cache_ban.c lines 388-393. The problem happens on startup, when the ban_head list is empty, and I belive the issue is that the (V)TAILQ_INSERT_HEAD() has not stored the head->last pointer, by the time the (V)TAILQ_LAST() tries to dereference it, and that the compiler does not spot the aliasing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?95608.1347973160>