Message ID | 20221130020815.283814-1-Jason@zx2c4.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp682203wrr; Tue, 29 Nov 2022 18:12:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf4kzXe4xH3LsWf47jnPfiXc66PiUoUuzxiTypQ/bXe/CRpXKIO3Zd5JJqIGDe9xVsB1DFCC X-Received: by 2002:a17:906:16d1:b0:7be:893:fea with SMTP id t17-20020a17090616d100b007be08930feamr15486718ejd.468.1669774324023; Tue, 29 Nov 2022 18:12:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669774324; cv=none; d=google.com; s=arc-20160816; b=TqzdIcnh4zSvz/4avnX9fQFenlLLJTEmiSQBcuCT+5yFO/eQdW4hhZSvIlZVox6nsJ wCzDvBSAON3oNlpWYpo55+cRu0sNfh9Y9Cq5HWcJmvkI2/bhXvhWxioZzHED8/dR/IVs A+rKedW22jpZbe2wIA+gS1xYekVuTN1qYa++LvRyGcBJWbVCrz1mIYiLI2SaOKMLYxyM eoqDZ1KH5ms0HyibuyPOgvFfgd3jp/QZHKiL7laN+WlEAehY9UdggNwbjIexdvAhTfy4 KYhL4H7UOQH/12sQ5/HhABRuVqwsopViLJRedMQoNty+g7ii9n9Rdz2u778OkgP3akuY OZ2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=qx27PPQsL8B5UR3meaN6u0WkQxvqKygl6e21SY/4K90=; b=DNXFsMgIWiooZhFwsmd6AOBwq8S4ue8Sa6OCBcGQz/ADu3VwSK1qF0oIcBxqhVCUOJ EPzjg89qFkrhb5jPPnbRC2BXDG3F141L9tGrS8rw0alx/H3ANxjtX71suw11+5VUqfH6 mZPtTIC2c6LJHa7Q537Lx0lZNgYSG7bDNER+Ptd7CsP09KHWpvmiyd0G2U1obWMaex6z +kxOF0aVvj5XRwTwUyMWTyVxdHZclBFnBUioCzBOvUVMGAVAxUdtPXXe3IxQsPMskSEx VSrBRc3kpgavnDU+imJzKK3oUS/lDN+xdoyq8BXClrKtyrpGs/Xq9StlmCPhNBh2CSOo jg3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=SzFBB6kv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id js20-20020a17090797d400b007c040bc168dsi208502ejc.248.2022.11.29.18.11.39; Tue, 29 Nov 2022 18:12:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=SzFBB6kv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230093AbiK3CI1 (ORCPT <rfc822;rbbytesnap@gmail.com> + 99 others); Tue, 29 Nov 2022 21:08:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230117AbiK3CIZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 21:08:25 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E3EB61BBE for <linux-kernel@vger.kernel.org>; Tue, 29 Nov 2022 18:08:24 -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 D961C61975 for <linux-kernel@vger.kernel.org>; Wed, 30 Nov 2022 02:08:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB4D6C43470; Wed, 30 Nov 2022 02:08:22 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="SzFBB6kv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1669774100; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qx27PPQsL8B5UR3meaN6u0WkQxvqKygl6e21SY/4K90=; b=SzFBB6kvF0S7FWPQPSyvgKOElnuPY/k6YToCSxAvEYG6ayB/lCZrlLJoeDSmKMzOWpDOvF +eJ44cerf8wDRfviChonRji1TWeqdFRyzhXKZvEGchTW0sdnGBWe7vUfxAGfZHX/+n8I09 d1L9sHYnivH1GgpRRwhhsfftoV6k250= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 877dbd7b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 30 Nov 2022 02:08:19 +0000 (UTC) From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: linux-kernel@vger.kernel.org Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, Sultan Alsawaf <sultan@kerneltoast.com> Subject: [PATCH] random: align entropy_timer_state to cache line Date: Wed, 30 Nov 2022 03:08:15 +0100 Message-Id: <20221130020815.283814-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750885281752994514?= X-GMAIL-MSGID: =?utf-8?q?1750885281752994514?= |
Series |
random: align entropy_timer_state to cache line
|
|
Commit Message
Jason A. Donenfeld
Nov. 30, 2022, 2:08 a.m. UTC
The theory behind the jitter dance is that multiple things are poking at
the same cache line. This only works, however, if those things are
actually all in the same cache line. Ensure this is the case by aligning
the struct on the stack to the cache line size.
On x86, this indeed aligns the stack struct:
000000000000000c <try_to_generate_entropy>:
{
c: 55 push %rbp
- d: 53 push %rbx
- e: 48 83 ec 38 sub $0x38,%rsp
+ d: 48 89 e5 mov %rsp,%rbp
+ 10: 41 54 push %r12
+ 12: 53 push %rbx
+ 13: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp
+ 17: 48 83 ec 40 sub $0x40,%rsp
Cc: Sultan Alsawaf <sultan@kerneltoast.com>
Fixes: 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hi Jason, On Wed, Nov 30, 2022 at 03:08:15AM +0100, Jason A. Donenfeld wrote: > The theory behind the jitter dance is that multiple things are poking at > the same cache line. This only works, however, if those things are > actually all in the same cache line. Ensure this is the case by aligning > the struct on the stack to the cache line size. > > On x86, this indeed aligns the stack struct: > > 000000000000000c <try_to_generate_entropy>: > { > c: 55 push %rbp > - d: 53 push %rbx > - e: 48 83 ec 38 sub $0x38,%rsp > + d: 48 89 e5 mov %rsp,%rbp > + 10: 41 54 push %r12 > + 12: 53 push %rbx > + 13: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp > + 17: 48 83 ec 40 sub $0x40,%rsp > > Cc: Sultan Alsawaf <sultan@kerneltoast.com> > Fixes: 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > drivers/char/random.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > 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? - Eric
Hi Eric, On Tue, Nov 29, 2022 at 08:55:48PM -0800, Eric Biggers wrote: > Hi Jason, > > On Wed, Nov 30, 2022 at 03:08:15AM +0100, Jason A. Donenfeld wrote: > > The theory behind the jitter dance is that multiple things are poking at > > the same cache line. This only works, however, if those things are > > actually all in the same cache line. Ensure this is the case by aligning > > the struct on the stack to the cache line size. > > > > On x86, this indeed aligns the stack struct: > > > > 000000000000000c <try_to_generate_entropy>: > > { > > c: 55 push %rbp > > - d: 53 push %rbx > > - e: 48 83 ec 38 sub $0x38,%rsp > > + d: 48 89 e5 mov %rsp,%rbp > > + 10: 41 54 push %r12 > > + 12: 53 push %rbx > > + 13: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp > > + 17: 48 83 ec 40 sub $0x40,%rsp > > > > Cc: Sultan Alsawaf <sultan@kerneltoast.com> > > Fixes: 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > > --- > > drivers/char/random.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > 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. Jason
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
On Wed, Nov 30, 2022 at 7:59 PM Eric Biggers <ebiggers@kernel.org> wrote: > > 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... The really pathological one would be ~48, which would just clear those two extra bits. I can't imagine gcc or clang ever deciding to do that. But I guess they could? What would you recommend here? kmalloc'ing it instead? Keeping things as is with ____cacheline_aligned, since this has always been broken, and it's not the end of the world? Something else? Jason
On Wed, Nov 30, 2022 at 08:31:33PM +0100, Jason A. Donenfeld wrote: > On Wed, Nov 30, 2022 at 7:59 PM Eric Biggers <ebiggers@kernel.org> wrote: > > > > 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... > > The really pathological one would be ~48, which would just clear those > two extra bits. I can't imagine gcc or clang ever deciding to do that. > But I guess they could? > > What would you recommend here? kmalloc'ing it instead? Keeping things > as is with ____cacheline_aligned, since this has always been broken, > and it's not the end of the world? Something else? Well, other places in the kernel do the alignment manually: u8 __stack[sizeof(struct entropy_timer_state) + SMP_CACHE_BYTES - 1]; struct entropy_timer_state *stack = (void *)PTR_ALIGN(__stack, SMP_CACHE_BYTES); It's silly, but I'm not aware of a better option. - Eric
Hi Eric, On Wed, Nov 30, 2022 at 8:51 PM Eric Biggers <ebiggers@kernel.org> wrote: > > On Wed, Nov 30, 2022 at 08:31:33PM +0100, Jason A. Donenfeld wrote: > > On Wed, Nov 30, 2022 at 7:59 PM Eric Biggers <ebiggers@kernel.org> wrote: > > > > > > 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... > > > > The really pathological one would be ~48, which would just clear those > > two extra bits. I can't imagine gcc or clang ever deciding to do that. > > But I guess they could? > > > > What would you recommend here? kmalloc'ing it instead? Keeping things > > as is with ____cacheline_aligned, since this has always been broken, > > and it's not the end of the world? Something else? > > Well, other places in the kernel do the alignment manually: > > u8 __stack[sizeof(struct entropy_timer_state) + SMP_CACHE_BYTES - 1]; > struct entropy_timer_state *stack = (void *)PTR_ALIGN(__stack, SMP_CACHE_BYTES); > > It's silly, but I'm not aware of a better option. Well alright then, why not. I'll send a v2. Jason
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; unsigned int i, num_different = 0; unsigned long last = random_get_entropy(); int cpu = -1;