Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D14BFC636CD for ; Mon, 30 Jan 2023 20:44:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229944AbjA3UoA (ORCPT ); Mon, 30 Jan 2023 15:44:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229953AbjA3Un5 (ORCPT ); Mon, 30 Jan 2023 15:43:57 -0500 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E41283B66E for ; Mon, 30 Jan 2023 12:43:48 -0800 (PST) Received: by angie.orcam.me.uk (Postfix, from userid 500) id AFD6E92009C; Mon, 30 Jan 2023 21:43:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id AC3C492009B; Mon, 30 Jan 2023 20:43:47 +0000 (GMT) Date: Mon, 30 Jan 2023 20:43:47 +0000 (GMT) From: "Maciej W. Rozycki" To: "Jason A. Donenfeld" cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jason, > > Thank you for your input. I've had a look at the function and it seems a > > bit heavyweight compared to a mere single CPU instruction, but I guess why > > not. Do you have any performance figures (in terms of CPU cycles) for the > > usual cases? Offhand I'm not sure how I could benchmark it myself. > > Generally it's very very fast, as most cases wind up being only a > memcpy -- in this case, a single byte copy. So by and large it should > be suitable. It's fast enough now that most networking things are able > to use it. And lots of other places where you'd want really high > performance. So I'd expect it's okay to use here too. And if it is too > slow, we should figure out how to make it faster. But I don't suspect > it'll be too slow. Thank you for your explanation. I have v3 ready for submission; would you mind if I added you with a Suggested-by: tag? Maciej