From owner-freebsd-arch@FreeBSD.ORG Tue Sep 18 16:01:09 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32B071065780 for ; Tue, 18 Sep 2012 16:01:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2FD38FC0C for ; Tue, 18 Sep 2012 16:01:08 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so149679lbb.13 for ; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P/I22AwwMhUappU8VsxYUjL18bbS6NrmfApn1ILpwnw=; b=Bk26kGVOhgQwkY3M3gx4yw7Wmkip3hCDzr4AomiJgZGKou8S6+cWvadjom2mQNkpYk 1kEKtmXeOF3lwgut+W54DnN3DBS0COe5uoU68sJ2nsMAgka8FAEsDLI3BqOzaGRjPStX fNe2i9hanXUfhmU8XHtiYImBjc0moPw+MkUg2L7+T8DOcZfcp/o3c06XFE0IBXizDmTe lsJAolU5fc3Oj7cAzWJOIkW6Zl+OM7MnOE37lpK9+u0I5Fl3esYtRjzwJB+7wDBpXX41 mGQyj1iKrPtQSyV5ebjF8vrK0Wiw7OQViujy2CVvKcow4jZ87x19XtBUiqtkyg3+0ADs O6fA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr203174lab.40.1347984067226; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.102.39 with HTTP; Tue, 18 Sep 2012 09:01:07 -0700 (PDT) In-Reply-To: <22286.1347983589@critter.freebsd.dk> References: <22286.1347983589@critter.freebsd.dk> Date: Tue, 18 Sep 2012 17:01:07 +0100 X-Google-Sender-Auth: naMaBNigq_R0ujvTxQAT5n_M_Ik Message-ID: From: Attilio Rao To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:01:09 -0000 On 9/18/12, Poul-Henning Kamp wrote: > In message > > , 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