From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A92BDCA9EB6 for ; Wed, 23 Oct 2019 13:21:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E31621872 for ; Wed, 23 Oct 2019 13:21:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E31621872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 18D746B0003; Wed, 23 Oct 2019 09:21:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13E4E6B0006; Wed, 23 Oct 2019 09:21:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 053076B0007; Wed, 23 Oct 2019 09:21:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id D820C6B0003 for ; Wed, 23 Oct 2019 09:21:12 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 799D3814A for ; Wed, 23 Oct 2019 13:21:12 +0000 (UTC) X-FDA: 76075110384.20.elbow20_7ee1b544a6d55 X-HE-Tag: elbow20_7ee1b544a6d55 X-Filterd-Recvd-Size: 4221 Received: from Galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Oct 2019 13:21:11 +0000 (UTC) Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNGZV-0002MI-Uz; Wed, 23 Oct 2019 15:21:06 +0200 Date: Wed, 23 Oct 2019 15:21:05 +0200 (CEST) From: Thomas Gleixner To: Cyrill Gorcunov cc: LKML , Ingo Molnar , Peter Zijlstra , linux-mm@kvack.org, Catalin Marinas Subject: Re: [BUG -tip] kmemleak and stacktrace cause page faul In-Reply-To: <20191022145619.GE12121@uranus.lan> Message-ID: References: <20191019114421.GK9698@uranus.lan> <20191022142325.GD12121@uranus.lan> <20191022145619.GE12121@uranus.lan> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 22 Oct 2019, Cyrill Gorcunov wrote: > On Tue, Oct 22, 2019 at 05:23:25PM +0300, Cyrill Gorcunov wrote: > > > > I presume the kmemleak tries to save stack trace too early when estack_pages are not > > yet filled. > > Indeed, at this stage of boot the percpu_setup_exception_stacks has not been called > yet and estack_pages full of crap > > [ 0.157502] stk 0x1008 k 1 begin 0x0 end 0xd000 estack_pages 0xffffffff82014880 ep 0xffffffff82014888 > [ 0.159395] estack_pages[0] = 0x0 > [ 0.160046] estack_pages[1] = 0x5100000001000 > [ 0.160881] estack_pages[2] = 0x0 > [ 0.161530] estack_pages[3] = 0x6100000003000 > [ 0.162343] estack_pages[4] = 0x0 > [ 0.162962] estack_pages[5] = 0x0 > [ 0.163523] estack_pages[6] = 0x0 > [ 0.164065] estack_pages[7] = 0x8100000007000 > [ 0.164978] estack_pages[8] = 0x0 > [ 0.165624] estack_pages[9] = 0x9100000009000 > [ 0.166448] estack_pages[10] = 0x0 > [ 0.167064] estack_pages[11] = 0xa10000000b000 > [ 0.168055] estack_pages[12] = 0x0 Errm. estack_pages is statically initialized and it's an array of:. struct estack_pages { u32 offs; u16 size; u16 type; }; [0,2,4,5,6,8,10,12] are guard pages so 0 is not that crappy at all The rest looks completely valid if you actually decode it proper. e.g. 0x51000 00001000 bit 0-31: 00001000 Offset 0x1000: 1 Page bit 32-47: 1000 Size 0x1000: 1 Page bit 48-63: 5 Type 5: STACK_TYPE_EXCEPTION + ESTACK_DF So, no. This is NOT the problem. But yes, you are right that percpu_setup_exception_stacks() has not yet been called simply because the percpu entry area has not been mapped yet. So lets look at the full context: begin = (unsigned long)__this_cpu_read(cea_exception_stacks); When percpu_setup_exception_stacks() has not been called yet, then begin should be 0. end = begin + sizeof(struct cea_exception_stacks); end should be 0 + sizeof(struct cea_exception_stacks); /* Bail if @stack is outside the exception stack area. */ if (stk < begin || stk >= end) return false; So 'begin <= stk < end' must be true to get to the below: /* Calc page offset from start of exception stacks */ k = (stk - begin) >> PAGE_SHIFT; which gives a valid 'k' no matter what 'begin' is. And obviously 'k' cannot be outside of the array size of estack_pages. /* Lookup the page descriptor */ ep = &estack_pages[k]; Ergo ep must be a valid pointer pointing to the statically allocated and statically initialized estack_pages array. /* Guard page? */ if (!ep->size) How on earth can dereferencing ep crash the machine? return false; That does not make any sense. Surely, we should not even try to decode exception stack when cea_exception_stacks is not yet initialized, but that does not explain anything what you are observing. Thanks, tglx