From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from mail-wm0-f66.google.com ([74.125.82.66]:38358 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752365AbeB1KXi (ORCPT
        <rfc822;stable@vger.kernel.org>); Wed, 28 Feb 2018 05:23:38 -0500
Received: by mail-wm0-f66.google.com with SMTP id z9so3971723wmb.3
        for <stable@vger.kernel.org>; Wed, 28 Feb 2018 02:23:38 -0800 (PST)
From: Jan Glauber <jglauber@cavium.com>
Date: Wed, 28 Feb 2018 11:23:35 +0100
To: Will Deacon <will.deacon@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Marc Zyngier <marc.zyngier@arm.com>,
        Greg KH <gregkh@linuxfoundation.org>, stable@vger.kernel.org,
        Catalin Marinas <catalin.marinas@arm.com>,
        Nicolas Dechesne <nicolas.dechesne@linaro.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH -stable] arm64: mm: don't write garbage into TTBR1_EL1
 register
Message-ID: <20180228102335.GA6619@wintermute>
References: <20180223182902.24873-1-ard.biesheuvel@linaro.org>
 <20180224083424.GC9681@kroah.com>
 <CAKv+Gu9rZEAk1RMUEk=7XCVVkLQ-chDu7GTGArCG0YeYcmx52w@mail.gmail.com>
 <20180226113050.GE8736@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180226113050.GE8736@arm.com>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

On Mon, Feb 26, 2018 at 11:30:50AM +0000, Will Deacon wrote:
> Damnit, sorry again. I changed the argument order of phys_to_ttbr along
> the way, so must've confused myself during the backporting exercise. It's
> also one of those things that will lead to potential TLB corruption in rare
> circumstances where the junk in TTBR1 ends up giving a valid translation,
> so it didn't crop up in my testing. How did Nicolas see this? The bug
> report I saw didn't look related.

FWIW, we've been hitting this bug with a distribution backport on
ThunderX2 on every boot. Due to bad luck there was a non-zero value
in TTBR1 that crashed the kernel immediately and dropped us to firmware.

--Jan