Received: by 10.213.65.68 with SMTP id h4csp263685imn; Fri, 16 Mar 2018 02:17:02 -0700 (PDT) X-Google-Smtp-Source: AG47ELu1a/5Y7KW4mUC7KNQXu6HK4++C85Mwin3I7gcBBp/IG5ersGXWKU/xnaMTAVvZshkUJDRY X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr1278199plb.115.1521191822540; Fri, 16 Mar 2018 02:17:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521191822; cv=none; d=google.com; s=arc-20160816; b=uaUA1y+wK9jf/PDr8Q1sn0WhhLqjHfkv7FTW5S/547q+cKrKa0iqY92LmcIZR2pGln zxNG9WF3U0wP4KeBsNRmla3pvPeJelQ/G9vkqLXtQ+jPDWujaJT4SiE3UgOXRQcZFIB+ BxycQuaIHmsFoRzXvWEGp+9H+6qHhFr+Yy9tuAjdaEV6i3lDMuwcvmb+9Y7r7A/tmFBf 4NKjcyibXEzkFDARd74dFQHtz3TRrM/VYfMbKJUxnlF7efzH2+l6hVm51Q5UDQlytMIV gJ48Eq82WCduPxTAUKX+hVf50nuiC0MEXmHex+4PoHuIcQgjBP4RAFWxsV9qcRWoC2oM /a4g== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=vsklQ237/bSLHGTm3EcYkz251WlBna9MO8G7vzLV6w0=; b=Dw17Ng6b5XbFs9DCS/NcuV+2iKgNfBGdc4EnW3f4SeLPf7FFTfh9ml+yG9PUku5iDn 7//Fcdzzcg0mbRInx6lQtj2/FhZ/0U2zFS5X9eeaMvXFS9aVWOKJB7xD/aTkCdFA5Qrz zIlaZxf7eGdsNW0Xu9u7Azkru4JRqHk8Q53Zi6xq3qhgoNu4p2Eo/WBRr1vVK4x2IYVs KPYtBXwiQI/8BcTUEI1oUn6pto9UZjG09KZKCkZpuyPN07NOeRiwYhaXbenrwyNp09ci z374kEyH9RlTDiCEUrjoFVcH0g7QvbM/8RH67x/LzkCz4QadiiNBGdES5hNw+cZp91tU Hl+A== 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 a8-v6si5864986plz.320.2018.03.16.02.16.47; Fri, 16 Mar 2018 02:17:02 -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 S1752270AbeCPJP5 (ORCPT + 99 others); Fri, 16 Mar 2018 05:15:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:58767 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750847AbeCPJP4 (ORCPT ); Fri, 16 Mar 2018 05:15:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3CFC9AAB2; Fri, 16 Mar 2018 09:15:54 +0000 (UTC) Date: Fri, 16 Mar 2018 10:15:49 +0100 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: 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?B?Q8OpZHJpYw==?= 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 Message-ID: <20180316101549.31238bdf@naga.suse.cz> In-Reply-To: <20180316151823.2f28d5ea@roar.ozlabs.ibm.com> References: <20180313200108.GA4082@hirez.programming.kicks-ass.net> <20180316151823.2f28d5ea@roar.ozlabs.ibm.com> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, 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. In many cases it is useful to put the barrier after a branch. It allows the compiler to speculate on the computed value at compile time and if it is constrained optimize out the branch. It may also result in the need to include many barriers and less readable code. However, you have probably knowledge of the powerpc implementation of the barrier so if the semantic is actually different then please enlighten me. Thanks Michal