Received: by 10.213.65.68 with SMTP id h4csp392585imn; Fri, 16 Mar 2018 06:29:55 -0700 (PDT) X-Google-Smtp-Source: AG47ELvUCjtXI+cyX5iIHpfVrcbzY+mVTMmutQ4TNdwqMHPIKiqQTzLi+6ZrVhQBBfjcCrac0I98 X-Received: by 10.99.119.78 with SMTP id s75mr1522492pgc.238.1521206995010; Fri, 16 Mar 2018 06:29:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521206994; cv=none; d=google.com; s=arc-20160816; b=UbM1JudZBXzCagkAyPN9fkqZ1aAyDgMmTYzJoH6WWvuZK41l8l4Gk1HI4NwRbzXoJA wVl6Nf0mGUc15at2TZKjDIiTJKae7FDsVk8rw6uebqfKa8hffyb6Zwu1EfdziMDG3VyN BIq5cDQI5vv5UX7QvM6Uwknu9kkVdh3dswNy1HqeKvb1+Z8drUYLbpgHe8TftMU6wUvy CP/x3mJMQOdj2xQtPm2QtsmIAjUawNoePqMPFEH4i7bn4YIeCIqFK3ti7RpvgWDHBcy8 bohFN9uvk3cV/BjU0K6Uqd5SBK+P66xhRILW01qvQ2ecRdjiWUXO/rGM6zuFw0toCI5x t1TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :arc-authentication-results; bh=9vV5EN+5xm9mUEBsnK/1MjJFm97cG7WNQJxQu+IMvTQ=; b=TFWfHFcJncjg6UgEk6igdqkFrqGYSZ1Eva5SdOL+zoYP5+ChXhZsx2lp2w0DQ9Od0X /1AF7t9B3OYci78Sgg/kbuySxK1c4drae9V0cJ20jsnmI30bYRRFUicJ2PUzqBMyjEor LNPLGDhqCrfWsti75w5tN+guDXTnemwwpU9Eo71uv+lO7/Lp1yTo3fpO790uhMtp5/c6 /AqC/ZRdk9M//5a26PVg+LpPIvQiY+P7Atz6NNbqcNO5TqJtolU8Mr4QPt4I3SYReZny G8618YN2GDJ2bL19NR/bQpmW/txVTH0SRv8S+umBoZUvW1o00A4dLcc1hrysnv/bQ26T 6WPA== 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 v189si4980565pgb.374.2018.03.16.06.29.40; Fri, 16 Mar 2018 06:29:54 -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 S1752522AbeCPN2r convert rfc822-to-8bit (ORCPT + 99 others); Fri, 16 Mar 2018 09:28:47 -0400 Received: from ozlabs.org ([103.22.144.67]:50119 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbeCPN2q (ORCPT ); Fri, 16 Mar 2018 09:28:46 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 402mWJ4vZWz9sPk; Sat, 17 Mar 2018 00:28:44 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Michal =?utf-8?Q?Such=C3=A1nek?= , Nicholas Piggin Cc: Kate Stewart , Madhavan Srinivasan , Mahesh Salgaonkar , Al Viro , Paul Mackerras , Michael Neuling , "Bryant G. Ly" , "Naveen N. Rao" , Daniel Axtens , =?utf-8?Q?C=C3=A9dric?= Le Goater , David Gibson , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Masami Hiramatsu , Andrew Donnellan , Philippe Ombredanne , Joe Perches , Oliver O'Halloran , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "Tobin C. Harding" Subject: Re: [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry In-Reply-To: <20180316101549.31238bdf@naga.suse.cz> References: <20180313200108.GA4082@hirez.programming.kicks-ass.net> <20180316151823.2f28d5ea@roar.ozlabs.ibm.com> <20180316101549.31238bdf@naga.suse.cz> Date: Sat, 17 Mar 2018 00:28:42 +1100 Message-ID: <873710i1yt.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, Thanks for working on this series in the absence of any documentation. Michal Suchánek writes: > On Fri, 16 Mar 2018 15:18:23 +1000 > Nicholas Piggin wrote: > >> On Thu, 15 Mar 2018 20:15:52 +0100 >> Michal Suchanek wrote: >> >> > On powerpc syscall entry is done in assembly so patch in an explicit >> > barrier_nospec. >> >> Same comment as Linus for this -- the barriers are before the branch >> here, so is it possible the branch instruction can be speculative >> while the index is used to load the syscall table? > > As far as I understand barriers they separate code before the barrier > and code after the barrier. > > So inserting barrier_nospec after cmpldi means that the result of the > cmpldi has to be known before any instruction following barrier_nospec > that depends on the result can be executed. That would make sense, but I don't think that's how the barrier's been defined. I don't have a formal spec for it (yet), but what I do have indicates it only orders older branches vs future instructions. > However, you have probably knowledge of the powerpc implementation of > the barrier so if the semantic is actually different then please > enlighten me. We have some knowledge, but only some :) It's not necessarily implemented the same way on each chip revision, so it's not entirely clear what the formal semantics will be vs what we are seeing in current implementations. But I think it's safe to say it should always go after the branch that might be speculatively executed. Will try and get some better documentation for you. cheers