From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301AbbC0I7w (ORCPT ); Fri, 27 Mar 2015 04:59:52 -0400 Received: from mail.skyhub.de ([78.46.96.112]:44398 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752655AbbC0I7t (ORCPT ); Fri, 27 Mar 2015 04:59:49 -0400 Date: Fri, 27 Mar 2015 09:57:59 +0100 From: Borislav Petkov To: Andy Lutomirski Cc: Denys Vlasenko , X86 ML , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] x86/asm/entry/64: better check for canonical address Message-ID: <20150327085758.GA18912@pd.tnic> References: <1427373731-13056-1-git-send-email-dvlasenk@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2015 at 11:45:19AM -0700, Andy Lutomirski wrote: > I suspect that the two added ALU ops are free for all practical > purposes, and the performance of this path isn't *that* critical. > > If anyone is running with vsyscall=native because they need the > performance, then this would be a big win. Otherwise I don't have a > real preference. Anyone else have any thoughts here? > > Let me just run through the math quickly to make sure I believe all the numbers: > > Canonical addresses either start with 17 zeros or 17 ones. > > In the old code, we checked that the top (64-47) = 17 bits were all > zero. We did this by shifting right by 47 bits and making sure that > nothing was left. > > In the new code, we're shifting left by (64 - 48) = 16 bits and then > signed shifting right by the same amount, this propagating the 17th > highest bit to all positions to its left. If we get the same value we > started with, then we're good to go. > > So it looks okay to me. > > IOW, the new code extends the optimization correctly to one more case > (native vsyscalls or the really weird corner case of returns to > emulated vsyscalls, although that should basically never happen) at > the cost of two probably-free ALU ops. If we're going to apply this, I'd like this text in the commit message please. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --