Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3318162imu; Sun, 11 Nov 2018 12:15:04 -0800 (PST) X-Google-Smtp-Source: AJdET5ehkeP4cHC9G82dPr4C65lqi/fIio7AVR7EMq6jzlCABIwTaC1V8ShIZLYFpNG7rm0ItBOq X-Received: by 2002:a63:ed42:: with SMTP id m2mr15195106pgk.147.1541967304641; Sun, 11 Nov 2018 12:15:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541967304; cv=none; d=google.com; s=arc-20160816; b=LSVuQWOeOEnVBGbpaZx7hU/v/PHmjtvN1BkN1ar9giVlDEmzxGtZ0Ms0WxCEftO6hV MPcPQNzawdoV7//U3NfcsIdw2joWW2hsMBDY9IL0CJ8+HI5kFI0sKjuTiGOlk6lHZAuX +Eoeb8DbxbQTX7q+NX4P9gtw07llVksNPypJHYP5l0V6lohCZwsqm8bkc3FyPdKrwesP fOrxrrbvbNYS4qgUmC6FfausUuGFf+cWo72VSv7vnlB+vdDSEnogQeKb8FXo+ReYdroE Lf9GGwjDWAqAKuEta/C8t9g3uda06dObsavjwE6luIp/EIstGly0qpU43pC+PIr2l3tT S9Og== 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; bh=N4pqf1G9QIoAZ+oZhSlXxABwdNS1GocuH07K7yBbCKk=; b=n/io/ehBXk4gOwRunSvQJqJkcBaXd4mIiPcD+Wh5l1xjW2CuOd2T0ODLZ6m8P7jr+l YVI6vsJDo4oBBOrWN7pnGEH4NV18ptDOkqiQxuEStGWc430uDxxf2BaCXo1IYNfTFd+h 0GRNIknFbdhVTcrzj7cTGxAis+FIogzrBO3BR6EHKzobFk0MIEC2w6+pyNYrT8sqELx4 dxuSYOILaSbNTnlArjvIJN/hVxJPtRseiMBofhKCE2AnGE8TeejFTDWHSqBq3gkbDtJ7 UBALI38X4X6uX1z67Sz8ClhUqKlNQE6cDWr2pC+xg+kjIWkthNvIfzj2irZcPszsZw51 MQ4w== 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 k68-v6si13743296pgk.294.2018.11.11.12.14.48; Sun, 11 Nov 2018 12:15:04 -0800 (PST) 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 S1731656AbeKLGD4 (ORCPT + 99 others); Mon, 12 Nov 2018 01:03:56 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:52860 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726816AbeKLGD4 (ORCPT ); Mon, 12 Nov 2018 01:03:56 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvt5-0000l6-Mg; Sun, 11 Nov 2018 19:59:15 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsR-0001VS-07; Sun, 11 Nov 2018 19:58:35 +0000 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, "Michael Ellerman" , "Aneesh Kumar K.V" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 108/366] powerpc/mm/hash: Add missing isync prior to kernel stack SLB switch In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: "Aneesh Kumar K.V" commit 91d06971881f71d945910de128658038513d1b24 upstream. Currently we do not have an isync, or any other context synchronizing instruction prior to the slbie/slbmte in _switch() that updates the SLB entry for the kernel stack. However that is not correct as outlined in the ISA. =46romPower ISA Version 3.0B, Book III, Chapter 11, page 1133: "Changing the contents of ... the contents of SLB entries ... can have the side effect of altering the context in which data addresses and instruction addresses are interpreted, and in which instructions are executed and data accesses are performed. ... These side effects need not occur in program order, and therefore may require explicit synchronization by software. ... The synchronizing instruction before the context-altering instruction ensures that all instructions up to and including that synchronizing instruction are fetched and executed in the context that existed before the alteration." And page 1136: "For data accesses, the context synchronizing instruction before the slbie, slbieg, slbia, slbmte, tlbie, or tlbiel instruction ensures that all preceding instructions that access data storage have completed to a point at which they have reported all exceptions they will cause." We're not aware of any bugs caused by this, but it should be fixed regardless. Add the missing isync when updating kernel stack SLB entry. Signed-off-by: Aneesh Kumar K.V [mpe: Flesh out change log with more ISA text & explanation] Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings --- arch/powerpc/kernel/entry_64.S | 1 + 1 file changed, 1 insertion(+) --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -525,6 +525,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEG * actually hit this code path. */ + isync slbie r6 slbie r6 /* Workaround POWER5 < DD2.1 issue */ slbmte r7,r0