Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2291896imm; Thu, 7 Jun 2018 08:17:17 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJeAYjFkSBn49pnoLmeR/QLitLTkslw/+mnrEd1XX0VYbmz4/6sVZcXujybuCYYoWqZMTRn X-Received: by 2002:a63:931c:: with SMTP id b28-v6mr1929214pge.167.1528384637264; Thu, 07 Jun 2018 08:17:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528384637; cv=none; d=google.com; s=arc-20160816; b=hbhM06pDnTiGCNt/fX7CbJh7BgjU70EgftX5X3eXUYuQMw72qS0KIP6Hvan0uNrzlj 5g7S1M+lk/R9jALoxpEjMk0IgmceO9vzvsXPrmlp2EngKwfiXiTN5UOhqu35Fhdgc3g8 IO/0/NhqQl6AFzfG4ze9A81wF4c6KNlC5pFP2Q03/vKhhKqfSIZzPChKXd5ts+G/GaJU yIT90sbk2NIPGeMqlSG+dYM2/RFsLj2va7/yqkGw7ku99eh+qVeCgBxTn6ZyQw4nlSpJ nSvnyUjxCiAlsvRj0W52ZKxID6lmVPqdGrsIBmrHJOt9ul040bQKTv1OSH5OOW41n+Tp e+YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=aZ4JQYkxbA//reREg1D+xOq74Uetz1Qu797iDSZPNvQ=; b=M3muLTXnDpeGMEhP5NZqH4gdksEHBYlEBf2wuvCCCdV4BSreg1dx0XxVbjPK4IYRFQ POzMEageW7UHXkPztQ3pBrRbembsqwJAZXapPUQmvHIM9dN8+UGDNJSjCTSuie+NhzMy TXkT0Guuw5hwGAt6e5MqchZfi4oCRA+7q4J0J0SeJP87gS4EOsFeagmgSYBHnuUVh/eP UUuSzBfGCT2w8ox2xhLiyTWFrEh5rjpt+RE5m1nZgveqiEwbuWAkB8GOqBWzLkvQ3GMJ 4nvMPU5qaOMpiGhnIuUh5z48pmqqN/mhDruvvUvr/DINKILbTuMJdj2auTg7QXh+FxGq rSbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o16-v6si20737661pgv.240.2018.06.07.08.17.02; Thu, 07 Jun 2018 08:17:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964850AbeFGPBw (ORCPT + 99 others); Thu, 7 Jun 2018 11:01:52 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41411 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964837AbeFGPBt (ORCPT ); Thu, 7 Jun 2018 11:01:49 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvba-0005Zx-KI; Thu, 07 Jun 2018 15:09:34 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb8-00035s-Tl; Thu, 07 Jun 2018 15:09:06 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Laura Abbott" , "Will Deacon" , "James Morse" , "Catalin Marinas" , "Ard Biesheuvel" , "Mark Rutland" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 265/410] arm64: remove __die()'s stack dump In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Mark Rutland commit c5bc503cbeee8586395aa541d2b53c69c3dd6930 upstream. Our __die() implementation tries to dump the stack memory, in addition to a backtrace, which is problematic. For contemporary 16K stacks, this can be a lot of data, which can take a long time to dump, and can push other useful context out of the kernel's printk ringbuffer (and/or a user's scrollback buffer on an attached console). Additionally, the code implicitly assumes that the SP is on the task's stack, and tries to dump everything between the SP and the highest task stack address. When the SP points at an IRQ stack (or is corrupted), this makes the kernel attempt to dump vast amounts of VA space. With vmap'd stacks, this may result in erroneous accesses to peripherals. This patch removes the memory dump, leaving us to rely on the backtrace, and other means of dumping stack memory such as kdump. Signed-off-by: Mark Rutland Reviewed-by: Will Deacon Tested-by: Laura Abbott Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: James Morse [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- arch/arm64/kernel/traps.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -206,8 +206,6 @@ static int __die(const char *str, int er TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), thread + 1); if (!user_mode(regs) || in_interrupt()) { - dump_mem(KERN_EMERG, "Stack: ", regs->sp, - THREAD_SIZE + (unsigned long)task_stack_page(tsk)); dump_backtrace(regs, tsk); dump_instr(KERN_EMERG, regs); }