From mboxrd@z Thu Jan 1 00:00:00 1970 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 4937FC4321E for ; Wed, 30 Nov 2022 18:59:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229612AbiK3S7K (ORCPT ); Wed, 30 Nov 2022 13:59:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229840AbiK3S7E (ORCPT ); Wed, 30 Nov 2022 13:59:04 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A80BF54446 for ; Wed, 30 Nov 2022 10:59:03 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 43EC261D41 for ; Wed, 30 Nov 2022 18:59:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DCF1C433C1; Wed, 30 Nov 2022 18:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669834742; bh=3TD1S3j9pGxF2WpgRYYO4Ir4fNQvcwgiHdn38dgmJmo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IBKlEJWVE64uTEoiocu6EdVYn+nHHv5GLr/eSq1E0BoTx2zhNrMxlde8mWA4/CEE9 tSkXF4g6jdhw3GJh2aEwaTzQzTlQBVZkZb9WPeubQ44OxfQYDsgQG6AdvfKxAD4/Ay t5g1gME4rzxlwwXNpg9eUkgiSNExMfgLL0zpdsAp1WhwkQxNM0GJ7b2mQB1HeOiQiB qe5lmQ189cKLjBmn0uHie/PziNW8xfQ5zgMfKVaCmOsbxUrR/xLJqH9QmfJifCkqF8 eSATxDTOTsS0+8/Nyf7VyIspTP2LL0WF95CXRoWvoc1Oyq1amPo/X1cLDcMI7GWaKx q26s2gbTrTxUA== Date: Wed, 30 Nov 2022 18:59:01 +0000 From: Eric Biggers To: "Jason A. Donenfeld" Cc: linux-kernel@vger.kernel.org, Sultan Alsawaf Subject: Re: [PATCH] random: align entropy_timer_state to cache line Message-ID: References: <20221130020815.283814-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 30, 2022 at 11:04:23AM +0100, Jason A. Donenfeld wrote: > > > diff --git a/drivers/char/random.c b/drivers/char/random.c > > > index 67558b95d531..2494e08c76d8 100644 > > > --- a/drivers/char/random.c > > > +++ b/drivers/char/random.c > > > @@ -1262,7 +1262,7 @@ static void __cold entropy_timer(struct timer_list *timer) > > > static void __cold try_to_generate_entropy(void) > > > { > > > enum { NUM_TRIAL_SAMPLES = 8192, MAX_SAMPLES_PER_BIT = HZ / 15 }; > > > - struct entropy_timer_state stack; > > > + struct entropy_timer_state stack ____cacheline_aligned; > > > > Several years ago, there was a whole thing about how __attribute__((aligned)) to > > more than 8 bytes doesn't actually work on stack variables in the kernel on x86, > > because the kernel only keeps the stack 8-byte aligned but gcc assumes it is > > 16-byte aligned. See > > https://lore.kernel.org/linux-crypto/20170110143340.GA3787@gondor.apana.org.au/T/#t > > > > IIRC, nothing was done about it at the time. > > > > Has that been resolved in the intervening years? > > Maybe things are different for ____cacheline_aligned, which is 64 bytes. > Reading that thread, it looks like it was a case of trying to align the > stack to 16 bytes, but gcc assumed 16 bytes already while the kernel > only gave it 8. So gcc didn't think it needed to emit any code to align > it. Here, though, it's 64, and gcc certainly isn't assuming 64-byte > stack alignment. > > Looking at the codegen, gcc appears to doing `rsp = (rsp & ~63) - 64`, > which appears correct. Well, if gcc thinks the stack is already 16-byte aligned, then it would be perfectly within its rights to do 'rsp = (rsp & ~47) - 64', right? You probably don't want to be relying on an implementation detail of gcc codegen... - Eric