From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501AbeAQOwT (ORCPT + 1 other); Wed, 17 Jan 2018 09:52:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59806 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753051AbeAQOwQ (ORCPT ); Wed, 17 Jan 2018 09:52:16 -0500 Subject: Re: [PATCH 2/6] s390: implement nospec_[load|ptr] To: Jiri Kosina , Martin Schwidefsky References: <1516182519-10623-1-git-send-email-schwidefsky@de.ibm.com> <1516182519-10623-3-git-send-email-schwidefsky@de.ibm.com> Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Heiko Carstens , Paolo Bonzini , Cornelia Huck , Greg Kroah-Hartman , Marcus Meissner From: Jon Masters Message-ID: Date: Wed, 17 Jan 2018 09:52:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 17 Jan 2018 14:52:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/17/2018 07:41 AM, Jiri Kosina wrote: > On Wed, 17 Jan 2018, Martin Schwidefsky wrote: > >> Implement nospec_load() and nospec_ptr() for s390 with the new >> gmb() barrier between the boundary condition and the load that >> may not be done speculatively. Thanks for the patches, Martin et al. I tested various earlier versions and will run these latest ones through some tests and add a tested by. > FWIW the naming seems to be changing constantly. The latest patchset from > Dan Williams [1] uses ifence_...(). > > [1] lkml.kernel.org/r/151586744180.5820.13215059696964205856.stgit@dwillia2-desk3.amr.corp.intel.com This is getting a little silly. Not to bikeshed this to death, but obviously gmb (what was that ever supposed to stand for, global?) was the wrong name. We favored seb (speculative execution barrier), etc. Still, "ifence"? What is that supposed to mean? That sounds very architecture specific vs. what we're actually trying to ensure, which is that we don't speculatively load a pointer. Jon. -- Computer Architect | Sent from my Fedora powered laptop