From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E24B226E6E1 for ; Wed, 26 Nov 2025 18:08:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764180487; cv=none; b=FRD8zZJJtWJYUH90ppn38SlWSuD86X/hkIHhVlGZ3x4ZfCblaSsGm/X1EVQ/ZU0v/oHmw4DiRfLNsB/v04ExnhET+jhA8XGo+OvTLI5+RQ2XJhxpPcHMVsFbn1sd9VQT1eHPYY/jTlU9rFTDORclFaFTgHCf+mHOMmpIMNN/Cx8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764180487; c=relaxed/simple; bh=UOfVoAvwVfkMv0CkBNziqO3DoB+DwhfACrlo+JZQuoY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ueWXMF4kVAFWFywa+v1RILOjwI32ui/gJHFKEUKqQ/ODHxdjJhvi+dhQKLjTksPQoymOV18osmHgcpXqY+M2Dqt32s6m/KzXMhLe9PMz2UT/ruKr2N3rM8/8KrWPak7miJtzYr4TDF98RqFbtPx+9BwYJj5q+WumUtXrQ6KaKvM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zZefXdB+; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=QCeZYUwS; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zZefXdB+"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="QCeZYUwS" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764180482; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UOfVoAvwVfkMv0CkBNziqO3DoB+DwhfACrlo+JZQuoY=; b=zZefXdB+fpMdDPg9Gu5WI7TqNDb16+k0KrO46bEcrfK7+LVNyWrVwEAdA5EEDFnDmU3MpA Arc1xTGoeezX25iOa1FiNgbsjm845HdTvVVJ4t4XC7VO+jAF6pBtW59NMxAhAeaczqkqjB uXy+yo7XnBD5gB4e7GWt1gmutb6Gv1Kk2BJKEKyV0tKfZ/2yWPuEXnAggH+offKLXKLH0K Ef/T+e1buNX3TVWBnGX3XWMeMjqzbaO6lTjsxW3WAxNEHtRAbnGycCBY9OmtNbH2X9yJJu eLa1NyiVo0lku3OUH4luCkxPbCM5RyQgrAaOTTZzKU0Axu/Dlag8+VIBe+yL5w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764180482; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UOfVoAvwVfkMv0CkBNziqO3DoB+DwhfACrlo+JZQuoY=; b=QCeZYUwSxXm50lT7nXzkgoAtKDC2/KZC/bOdFGOpzIkce8rYL8Oeq91HYukJ2ahWxRwfCV DpomQsAw8n71FfDA== To: =?utf-8?B?6K645L2z5Yev?= , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti Subject: Re: [PATCH] riscv: fix KUnit test_kprobes crash when building with Clang In-Reply-To: <875xax5eq8.fsf@yellow.woof> References: <738dd4e2.ff73.19a7cd7b4d5.Coremail.xujiakai2025@iscas.ac.cn> <875xax5eq8.fsf@yellow.woof> Date: Wed, 26 Nov 2025 19:08:01 +0100 Message-ID: <875xawwttq.fsf@yellow.woof> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nam Cao writes: > =E8=AE=B8=E4=BD=B3=E5=87=AF writes: >> Clang misaligns the test_kprobes_addresses and test_kprobes_functions >> arrays, or does not export local labels by default. Both can cause >> kmalloc_array() allocation errors and KUnit failures. >> >> This patch fixes the issue by: >> - Adding .section .rodata to explicitly place arrays in the read-only da= ta segment. >> - Adding .align 3 to align arrays to 8 bytes. >> - Adding .globl to probe labels to ensure symbols are visible. > > We do not have to make it exactly the same as building with GCC, right? > Only moving the arrays to .rodata seems sufficient to fix the issue, but > I cannot explain why yet. > > What I observed is that with CONFIG_RELOCATABLE=3Dy, the kernel's > .rela.dyn section, which holds the relocation entries for the two > arrays, have incorrect addresses (they are all incorrectly offset by 6 > bytes for my build). The kernel uses these relocation information to > fill the arrays during boot, and fill them at wrong addresses. > > I smell a linker problem, but more investigation needed... I sent my findings to LLVM folks: https://github.com/llvm/llvm-project/issues/168308#issuecomment-3582596694 I suspect linker problem. But let's see what LLVM people think. Nam