[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f61ded41-b1b8-4d0b-aff0-df7e0f5bab0d@efficios.com>
Date: Tue, 18 Mar 2025 10:50:58 -0400
From: Michael Jeanson <mjeanson@...icios.com>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra <peterz@...radead.org>, "Paul E. McKenney"
<paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
Aishwarya.TCV@....com, Paolo Bonzini <pbonzini@...hat.com>,
kvm@...r.kernel.org
Subject: Re: [PATCH] rseq/selftests: ensure the rseq abi TLS is actually 1024
bytes
On 2025-03-18 10:01, Mark Brown wrote:
> On Tue, Mar 11, 2025 at 03:21:45PM -0400, Michael Jeanson wrote:
>
>> Adding the aligned(1024) attribute to the definition of __rseq_abi did
>> not increase its size to 1024, for this attribute to impact the size of
>> __rseq_abi it would need to be added to the declaration of 'struct
>> rseq_abi'. We only want to increase the size of the TLS allocation to
>> ensure registration will succeed with future extended ABI. Use a union
>> with a dummy member to ensure we allocate 1024 bytes.
>
> This is in today's -next and breaks the build of the KVM selftests:
>
> In file included from rseq_test.c:24:
> /home/broonie/git/bisect/usr/include/linux/rseq.h:62:1: error: use of 'rseq' with tag type that does not match previous declaration
> 62 | struct rseq {
> | ^
> ./../rseq/rseq.c:78:7: note: previous use is here
> 78 | union rseq {
> | ^
> In file included from rseq_test.c:24:
> /home/broonie/git/bisect/usr/include/linux/rseq.h:62:8: error: redefinition of 'rseq'
> 62 | struct rseq {
> | ^
> ./../rseq/rseq.c:78:7: note: previous definition is here
> 78 | union rseq {
> | ^
>
> since unlike the rseq tests the KVM rseq test includes the UAPI header
> for rseq which the padded union conflicts with.
Oh, I missed that, we need a more unique name for the union.
I'm unfamiliar with the workflow of linux-next, should I send a V2 of
the current patch, or a new one that applies on top?
Thanks,
Michael
Powered by blists - more mailing lists