lkml.org 
[lkml]   [2024]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval_t to avoid split locks
From
On 4/1/24 09:57, Javier Pello wrote:
> -typedef u64 pteval_t;
> -typedef u64 pmdval_t;
> -typedef u64 pudval_t;
> -typedef u64 p4dval_t;
> -typedef u64 pgdval_t;
> -typedef u64 pgprotval_t;
> +/*
> + * Variables of these types are subject to atomic compare-and-exchange
> + * operations, so they have to be properly aligned to avoid split locks.
> + */
> +typedef u64 pteval_t __aligned(8);
> +typedef u64 pmdval_t __aligned(8);
> +typedef u64 pudval_t __aligned(8);
> +typedef u64 p4dval_t __aligned(8);
> +typedef u64 pgdval_t __aligned(8);
> +typedef u64 pgprotval_t __aligned(8);

First of all, how is it that you're running a PAE kernel on new, 64-bit
hardware? That's rather odd.

The case that you're hitting is actually an on-stack pmd_t. The fun
part is that it's not shared and doesn't even _need_ atomics. I think
it's just using pmd_populate() because it's convenient.

I'd honestly much rather just disable split lock support in 32-bit
builds than mess with this stuff. You really shouldn't be running
32-but kernels on this hardware.

\
 
 \ /
  Last update: 2024-05-27 16:18    [W:0.042 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site