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=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 1F30AC43464 for ; Fri, 18 Sep 2020 07:43:31 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 904BF208DB for ; Fri, 18 Sep 2020 07:43:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1FJu5eG6"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="uBFyBBgc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 904BF208DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7fCxqHC57IGlEm2n09OUQQsNLCqu0jlvVY4K8bO3goQ=; b=1FJu5eG6zlEkpC64WdzMEtApl a2HxVdlPa8anLPHWFcTn+mbDwpsnEWsf9vpGkr2v2kNb5M9sZbd60d3UXpO3JQop8EGRPLasSJeOO Ni0Jls26yE4qMv4aKR9rZOx7L98F7LGDqoUarm1n0I8IuArkqQ722PXGCm2ol25wUKht6WpVL26KK yeONMNTFQZO3Jn2RrlDRw4nK8+Y+E3UfsX6T9ENnzaEBOlyPCDdjUw+kGNXB0d0fNPjYx1QeqfwEO AmIvWirsCoNf1DBdIqRCvecQcJ48anqAAcdYYrpqRsrxljax2ggS31AcgMEAPgeE2byLA3yAT2YHt H1XgpZmwg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJB23-00069S-Jy; Fri, 18 Sep 2020 07:42:11 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJB21-00068o-DW for linux-arm-kernel@lists.infradead.org; Fri, 18 Sep 2020 07:42:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ew17vDuZPSlSjcmFdTTXihsIsUVYPRVr+Bu5mG1RN78=; b=uBFyBBgcW0QETnetcGA9Xaumm zyiZ8lH8bD8O3vgyciGLv13LS44b3OsymTaEVIWdFXS8h7J5PvXfXjl2t3RzxH2y5KIozGqZml2bH 8mAKHqn1xaeJVwDu3eXYzq2Q677i0HLH3hTTyPQed01mMqsLf/Db2g8gDJk7tTgDX+gwYk8xJAsm4 Y08NKL8WPrFElyWXw4ZSHEA3lQsTU42hNKqYSHJRwm1FOOdqTPE/z+7BvhNeGHSDwqNwIBdnETle/ MP+KOkGBdIVVxY3+7EbCZhqWxdAUZdgS6q73eKMfFVpcWJjGveyWCWvttH6V5AS4KR/gyEosEc1JD kasjReAPg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35122) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJB1x-0006k0-FO; Fri, 18 Sep 2020 08:42:05 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kJB1v-0006a6-OE; Fri, 18 Sep 2020 08:42:03 +0100 Date: Fri, 18 Sep 2020 08:42:03 +0100 From: Russell King - ARM Linux admin To: Arnd Bergmann Subject: Re: [PATCH 2/9] ARM: traps: use get_kernel_nofault instead of set_fs() Message-ID: <20200918074203.GU1551@shell.armlinux.org.uk> References: <20200907153701.2981205-1-arnd@arndb.de> <20200907153701.2981205-3-arnd@arndb.de> <20200908061528.GB13930@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200918_034209_483929_4026B472 X-CRM114-Status: GOOD ( 25.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , Dmitry Safonov <0x7f454c46@gmail.com>, Linus Walleij , linux- , "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Christoph Hellwig , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 17, 2020 at 07:29:37PM +0200, Arnd Bergmann wrote: > On Tue, Sep 8, 2020 at 8:15 AM Christoph Hellwig wrote: > > > > > +static void dump_mem(const char *, const char *, unsigned long, unsigned long, bool kernel_mode); > > > > This adds a pointlessly long line. > > Fixed. > > > And looking at the code I don't see why the argument is even needed. > > > > dump_mem() currently does an unconditional set_fs(KERNEL_DS), so it > > should always use get_kernel_nofault. > > I had looked at > > if (!user_mode(regs) || in_interrupt()) { > dump_mem(KERN_EMERG, "Stack: ", regs->ARM_sp, > THREAD_SIZE + (unsigned > long)task_stack_page(tsk), kernel_mode); > > which told me that there should be at least some code path ending up in > __die() that has in_interrupt() set but comes from user mode. > > In this case, the memory to print would be a user pointer and cannot be > accessed by get_kernel_nofault() (but could be accessed with > "set_fs(KERNEL_DS); __get_user()"). > > I looked through the history now and the only code path I could > find that would arrive here this way is from bad_mode(), indicating > that there is probably a hardware bug or the contents of *regs are > corrupted. Yes, that's correct. It isn't something entirely theoretical, although we never see it now, it used to happen in the distant past due to saved regs corruption. If bad_mode() ever gets called, all bets are off and we're irrecoverably crashing. Note that in that case, while user_mode(regs) may return true or false, regs->ARM_sp and regs->ARM_lr are always the SVC mode stack and return address after regs has been stacked, and not the expected values for the parent context (which we have most likely long since destroyed.) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel