Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754776AbbGFKLp (ORCPT ); Mon, 6 Jul 2015 06:11:45 -0400 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:23247 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753770AbbGFKLm (ORCPT ); Mon, 6 Jul 2015 06:11:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AuDAAjU5pV/2ZJAg5cFoJ8VGC/TIV3AoErTQEBAQEBAYELQQWDXgEBBCcRHiMQCAMYCSUPAigeBg0BBwKIKg7IFgEBAQEBAQQBAQEBAQEci0uFBgeEKwEEjQeHDo0ijE6GcYNdJoQLLjEBAQGCSAEBAQ Message-ID: <559A545A.80508@internode.on.net> Date: Mon, 06 Jul 2015 19:41:38 +0930 From: Arthur Marsh User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Peter Zijlstra CC: linux-kernel@vger.kernel.org, Rusty Russell , Steven Rostedt , Mathieu Desnoyers , Oleg Nesterov , "Paul E. McKenney" Subject: Re: lock-up with module: Optimize __module_address() using a latched RB-tree References: <55997889.5020101@internode.on.net> <20150706100447.GX3644@twins.programming.kicks-ass.net> In-Reply-To: <20150706100447.GX3644@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1797 Lines: 53 Peter Zijlstra wrote on 06/07/15 19:34: > On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote: >> On this machine, a single core Athlon 64 with a 32 bit current Linus' git >> head kernel, I get a lock-up early in the boot process. (A dmesg output of a >> successful boot-up of kernel 4.1.0 up to and slightly passed the point where >> the git head kernel locks up is attached). >> >> A photo of the lock-up appears at: >> >> http://www.users.on.net/~arthur.marsh/20150706462.jpg > > So building a kernel with your .config (and a similar GCC) I was able to > match up the Code: with actual compiler output. > > The faulting instruction is a dereference of mod->module_core through: > > __modules_address() > mod_find() > latch_tree_find() > mod_tree_comp() > __mod_tree_val() > > 20e0: 8b 90 44 01 00 00 mov 0x144(%eax),%edx > > Now eax is NULL, which will have given you the splat. > > The curious thing is that the mod pointer is obtained from the > mod_tree_node structure: > > 20d0: 8b 46 fc mov -0x4(%esi),%eax > > And esi looks like a regular kernel pointer. > > Furthermore, we explicitly set the mod pointers in mod_tree_insert() > before linking in the nodes. > > This all has the smell of memory corruption, this gfx card you need to > pull, you're not accidentally using a binary driver for that? > No, it's the standard kernel radeon driver. If it's of any use I can reboot the machine with the kernel that goes boom and the video card removed. Arthur. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/