From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751313AbdAPJGL (ORCPT ); Mon, 16 Jan 2017 04:06:11 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:58798 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750907AbdAPJFy (ORCPT ); Mon, 16 Jan 2017 04:05:54 -0500 Date: Mon, 16 Jan 2017 10:05:40 +0100 From: Peter Zijlstra To: Anton Blanchard Cc: behanw@converseincode.com, ying.huang@intel.com, akpm@linux-foundation.org, oleg@redhat.com, Segher Boessenkool , mingo@elte.hu, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: llist code relies on undefined behaviour, upsets llvm/clang Message-ID: <20170116090540.GE3159@twins.programming.kicks-ass.net> References: <20170116083600.47175073@kryten> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170116083600.47175073@kryten> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 16, 2017 at 08:36:00AM +1100, Anton Blanchard wrote: > 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. Last I checked I couldn't build a x86_64 kernel with llvm. So no, not something I've ever ran into. Also, I would argue that this is broken in llvm, the kernel very much relies on things like this all over the place. Sure, we're way outside of what the C language spec says, but who bloody cares ;-) If llvm wants to compile the kernel, it needs to learn the C dialect the kernel uses.