Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391AbeAEAYS (ORCPT + 1 other); Thu, 4 Jan 2018 19:24:18 -0500 Received: from mail-ot0-f196.google.com ([74.125.82.196]:45384 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751339AbeAEAYQ (ORCPT ); Thu, 4 Jan 2018 19:24:16 -0500 X-Google-Smtp-Source: ACJfBov9UJboaGzflXyNxGTzOffpqGX7wTvHHBlFWAig26RnnKndmZUGFdPSS4J4l6ruyw/HckWliPN0ABdw2/1GznM= MIME-Version: 1.0 In-Reply-To: References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <20180104192648.GA10427@amd> <20180104225515.13a40f0f@alans-desktop> From: Dan Williams Date: Thu, 4 Jan 2018 16:24:14 -0800 Message-ID: Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier To: Linus Torvalds Cc: Alan Cox , Pavel Machek , Julia Lawall , Linux Kernel Mailing List , Mark Rutland , linux-arch@vger.kernel.org, Peter Zijlstra , Greg KH , Thomas Gleixner , Elena Reshetova , Alan Cox , Dan Carpenter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 4, 2018 at 3:06 PM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 2:55 PM, Alan Cox wrote: >> >> How do you ensure that the CPU doesn't speculate j < _m ? ~0 : 0 pick the >> wrong mask and then reference base[] ? > > .. yeah, that's exactly where we want to make sure that the compiler > uses a select or 'setb'. > > That's what gcc does for me in testing: > > xorl %eax, %eax > setbe %al > negq %rax > > but yes, we'd need to guarantee it somehow. > > Presumably that is where we end up having some arch-specific stuff. > Possibly there is some gcc builtin. I wanted to avoid actually writing > architecture-specific asm. > >> Anding with a constant works because the constant doesn't get speculated >> and nor does the and with a constant, but you've got a whole additional >> conditional path in your macro. > > Absolutely. Think of it as an example, not "the solution". > > It's also possible that x86 'lfence' really is so fast that it doesn't > make sense to try to do this. Agner Fog claims that it's single-cycle > (well, except for P4, surprise, surprise), but I suspect that his > timings are simply for 'lfence' in a loop or something. Which may not > show the real cost of actually halting things until they are stable. > > Also, maybe that __fcheck_files() pattern where getting a NULL pointer > happens to be the right thing for out-of-range is so unusual as to be > useless, and most people end up having to have that limit check for > other reasons anyway. This potential barrier avoidance optimization technique is something that could fit in the nospec_{ptr,load,array_load} interface that Mark defined for ARM, and is constructed around a proposed compiler builtin. Although, lfence is not a full serializing instruction, so before we spend too much effort trying to kill it we should measure how bad it is in practice in these paths. At this point I'll go ahead with rewriting the osb() patches into using Mark's nospec_* accessors plus the if_nospec macro. We can kill the barrier in if_nospec once we are sure the compiler will always "Do the Right Thing" with the array_access() approach, and can otherwise make the array_access() approach the 'best-effort' default fallback.