From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752764AbdJ3UfU (ORCPT ); Mon, 30 Oct 2017 16:35:20 -0400 Received: from scorn.kernelslacker.org ([45.56.101.199]:56850 "EHLO scorn.kernelslacker.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752520AbdJ3UfS (ORCPT ); Mon, 30 Oct 2017 16:35:18 -0400 Date: Mon, 30 Oct 2017 16:35:16 -0400 From: Dave Jones To: Linus Torvalds Cc: Andy Lutomirski , Ingo Molnar , Linux Kernel Mailing List Subject: Re: [4.14-rc7] task struct corruption after fork Message-ID: <20171030203516.ttkflsnlusnvbx23@codemonkey.org.uk> Mail-Followup-To: Dave Jones , Linus Torvalds , Andy Lutomirski , Ingo Molnar , Linux Kernel Mailing List References: <20171030141136.frvuutbxggebtb4u@codemonkey.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Note: SpamAssassin invocation failed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote: > and that location would *almost* make sense in that it's the end of > the same page that contained a "struct task_struct". > > Are you running with VMAP_STACK? Is there perhaps some stale code that > ends up doing the old "stack pointer is in the same allocation as task > struct"? yeah, it's enabled. > If you have the kernel symbols for that image, can you look up if any > of those addresses look like any static kernel symbol addresses? Those > things that have the pattern ffffffff8xxxxxxx might be symbol > addresses and give us a clue about where the values came from. it got clobbered by another build, but I managed to rebuild it from the older config. Modulo modules that were loaded, things should be the same. > ffffffff81172d1e r15 ffffffff81172d00 t usage_match ffffffff81172d30 t HARDIRQ_verbose > ffffffff8426daec r14 ffffffff841cee60 b lock_classes ffffffff844eed00 B nr_lock_classes > ffffed008b17e001 r13 > ffffffff811737e2 r12 ffffffff81173540 t __bfs ffffffff81173970 t check_noncircular > ffffffff8426dbe0 rbp ffffffff841cee60 b lock_classes ffffffff844eed00 B nr_lock_classes > ffff880458bf0008 rbx > ffffffff84590d00 r11 ffffffff841cee60 b lock_classes ffffffff844eed00 B nr_lock_classes > 5 r10 > ffffffff81172d00 r9 ffffffff81172d00 t usage_match > 1 r8 > 1ffff1008b17dfed rax > ffff880458bf00f0 rcx > ffffed008b17dff9 rdx > dffffc0000000000 rsi > 41b58ab3 rdi > ffffffff82a349a8 orig_eax ffffffff828a7f40 R inat_primary_table ffffffff82a42840 r POLY > ffffffff81173540 rip ffffffff81173540 t __bfs > 5a5a5a5a5a5a5a5a > ffffffff8450f080 flags ffffffff844eed40 b list_entries ffffffff846eed60 B nr_list_entries So a bunch of lockdep stuff, and not much else afaics. Dave