Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
changed the type of the ELF hash table entries to 64bit on s390x.
However the *GNU* hash tables entries are always 32bit.
The "bucket" pointer is shared between both hash algorithms.
On s390x the GNU algorithm assigns and dereferences this pointer to a
64bit value as a pointer to a 32bit value, leading to compiler warnings and
runtime crashes.

Introduce a new dedicated "gnu_bucket" pointer which is used by the GNU hash.

Fixes: e0746bde6f82 ("selftests/vDSO: support DT_GNU_HASH")
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v2:
- Fix wording around the width of pointers vs the pointed-to values
- Link to v1: https://lore.kernel.org/r/20250213-selftests-vdso-s390-gnu-hash-v1-1-ace3bcc940a3@linutronix.de
---
 tools/testing/selftests/vDSO/parse_vdso.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/vDSO/parse_vdso.c b/tools/testing/selftests/vDSO/parse_vdso.c
index 2fe5e983cb22f1ed066d0310a54f6aef2ed77ed8..f89d052c730eb43eea28d69ca27b56e897503e16 100644
--- a/tools/testing/selftests/vDSO/parse_vdso.c
+++ b/tools/testing/selftests/vDSO/parse_vdso.c
@@ -53,7 +53,7 @@ static struct vdso_info
 	/* Symbol table */
 	ELF(Sym) *symtab;
 	const char *symstrings;
-	ELF(Word) *gnu_hash;
+	ELF(Word) *gnu_hash, *gnu_bucket;
 	ELF_HASH_ENTRY *bucket, *chain;
 	ELF_HASH_ENTRY nbucket, nchain;
 
@@ -185,8 +185,8 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
 		/* The bucket array is located after the header (4 uint32) and the bloom
 		 * filter (size_t array of gnu_hash[2] elements).
 		 */
-		vdso_info.bucket = vdso_info.gnu_hash + 4 +
-				   sizeof(size_t) / 4 * vdso_info.gnu_hash[2];
+		vdso_info.gnu_bucket = vdso_info.gnu_hash + 4 +
+				       sizeof(size_t) / 4 * vdso_info.gnu_hash[2];
 	} else {
 		vdso_info.nbucket = hash[0];
 		vdso_info.nchain = hash[1];
@@ -268,11 +268,11 @@ void *vdso_sym(const char *version, const char *name)
 	if (vdso_info.gnu_hash) {
 		uint32_t h1 = gnu_hash(name), h2, *hashval;
 
-		i = vdso_info.bucket[h1 % vdso_info.nbucket];
+		i = vdso_info.gnu_bucket[h1 % vdso_info.nbucket];
 		if (i == 0)
 			return 0;
 		h1 |= 1;
-		hashval = vdso_info.bucket + vdso_info.nbucket +
+		hashval = vdso_info.gnu_bucket + vdso_info.nbucket +
 			  (i - vdso_info.gnu_hash[1]);
 		for (;; i++) {
 			ELF(Sym) *sym = &vdso_info.symtab[i];

---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250213-selftests-vdso-s390-gnu-hash-7206671abc85

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

On Mon, Feb 17, 2025 at 02:04:18PM +0100, Thomas Weißschuh wrote:
> Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
> changed the type of the ELF hash table entries to 64bit on s390x.
> However the *GNU* hash tables entries are always 32bit.
> The "bucket" pointer is shared between both hash algorithms.
--
> On s390x the GNU algorithm assigns and dereferences this pointer to a
> 64bit value as a pointer to a 32bit value, leading to compiler warnings and
> runtime crashes.

I would rephrase it as follows:

On s390, this caused the GNU hash algorithm to access its 32-bit entries as if they
were 64-bit, triggering compiler warnings (assignment between "Elf64_Xword *" and
"Elf64_Word *") and runtime crashes.

And take it via s390 tree.

Shuah, if you don't mind, may I get your Acked-by?

Thank you!

> Introduce a new dedicated "gnu_bucket" pointer which is used by the GNU hash.
> 
> Fixes: e0746bde6f82 ("selftests/vDSO: support DT_GNU_HASH")
> Reviewed-by: Jens Remus <jremus@linux.ibm.com>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> Changes in v2:
> - Fix wording around the width of pointers vs the pointed-to values
> - Link to v1: https://lore.kernel.org/r/20250213-selftests-vdso-s390-gnu-hash-v1-1-ace3bcc940a3@linutronix.de
> ---
>  tools/testing/selftests/vDSO/parse_vdso.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

On Tue, Feb 18, 2025 at 12:52:31AM +0100, Vasily Gorbik wrote:
> On Mon, Feb 17, 2025 at 02:04:18PM +0100, Thomas Weißschuh wrote:
> > Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
> > changed the type of the ELF hash table entries to 64bit on s390x.
> > However the *GNU* hash tables entries are always 32bit.
> > The "bucket" pointer is shared between both hash algorithms.
> --
> > On s390x the GNU algorithm assigns and dereferences this pointer to a
> > 64bit value as a pointer to a 32bit value, leading to compiler warnings and
> > runtime crashes.
> 
> I would rephrase it as follows:
> 
> On s390, this caused the GNU hash algorithm to access its 32-bit entries as if they
> were 64-bit, triggering compiler warnings (assignment between "Elf64_Xword *" and
> "Elf64_Word *") and runtime crashes.
> 
> And take it via s390 tree.
> 
> Shuah, if you don't mind, may I get your Acked-by?

Hello Shuah,

friendly ping. Could you please respond with "Acked-by" if you don’t
mind me taking this patch via the s390 tree? Or let me know if you plan
to take it via your tree.

Thank you!

On 2/26/25 12:37, Vasily Gorbik wrote:
> On Tue, Feb 18, 2025 at 12:52:31AM +0100, Vasily Gorbik wrote:
>> On Mon, Feb 17, 2025 at 02:04:18PM +0100, Thomas Weißschuh wrote:
>>> Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
>>> changed the type of the ELF hash table entries to 64bit on s390x.
>>> However the *GNU* hash tables entries are always 32bit.
>>> The "bucket" pointer is shared between both hash algorithms.
>> --
>>> On s390x the GNU algorithm assigns and dereferences this pointer to a
>>> 64bit value as a pointer to a 32bit value, leading to compiler warnings and
>>> runtime crashes.
>>
>> I would rephrase it as follows:
>>
>> On s390, this caused the GNU hash algorithm to access its 32-bit entries as if they
>> were 64-bit, triggering compiler warnings (assignment between "Elf64_Xword *" and
>> "Elf64_Word *") and runtime crashes.
>>
>> And take it via s390 tree.
>>
>> Shuah, if you don't mind, may I get your Acked-by?
> 
> Hello Shuah,
> 
> friendly ping. Could you please respond with "Acked-by" if you don’t
> mind me taking this patch via the s390 tree? Or let me know if you plan
> to take it via your tree.
> 
> Thank you!

Yes. Please take this through s390 tree.

Acked-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah