From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CFFC13A9DA0; Tue, 31 Mar 2026 11:10:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774955403; cv=none; b=NCeOFJcBqMrnKXqYCRuYKSeYo1OxSeMnIOFyZ81YO+BJ43/S4MzJc1Nyvuqgl2A7xBPhIO+hjekBTnK+uDw7FEq1koZq7JindJuL+oMYsoUvifr8/KpVyy2DRd0MLUmfuMsQ2IgEXiu4Sv+stapMzKdHhZ5pSGl/PL4qTi0d+a4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774955403; c=relaxed/simple; bh=PDWhGehAABN8rZbTQc6/iHY+Fw7ehaTfDPUfEMfwNaQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JshWqNYVhV7UE+K+4uOxueTJZDdtHmsW+F9n9Hftn8yLC7+ShC/tC7v8QqbUJNUWF8UiqTba6qK5cNybqSZcLLuWnKjdEDwAZshiJBMy7zXNkWh/UfrxFEd5hUjco7oU9Yw9Dx4IWUPV/AcqXla7FANmCqRXmTSDhAnXaTDYOAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=OwSLQ5an; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="OwSLQ5an" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3DC8C19423; Tue, 31 Mar 2026 11:10:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1774955403; bh=PDWhGehAABN8rZbTQc6/iHY+Fw7ehaTfDPUfEMfwNaQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OwSLQ5anPWht8L1EHMnGFakuwXsBF7dBLc1G+emOsOvAa7ipwlzn5QvM9o7dJajXW ilEpiLAAbQmRaQR+imI0GHj3Dau+2JauPxTV2ntY6hWi75Nrrf21FXfZ2GZwdDGf15 m9HJNWhgwZIjcjaktcafv+a3+LNfpBSGaa1hIOvM= Date: Tue, 31 Mar 2026 13:10:00 +0200 From: Greg Kroah-Hartman To: Huacai Chen Cc: Sasha Levin , Huacai Chen , Xuerui Wang , stable@vger.kernel.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, Xi Ruoyao Subject: Re: [PATCH for 6.6] LoongArch: vDSO: Emit GNU_EH_FRAME correctly Message-ID: <2026033148-expletive-many-cd82@gregkh> References: <20260330100133.3955364-1-chenhuacai@loongson.cn> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260330100133.3955364-1-chenhuacai@loongson.cn> On Mon, Mar 30, 2026 at 06:01:33PM +0800, Huacai Chen wrote: > From: Xi Ruoyao > > commit e4878c37f6679fdea91b27a0f4e60a871f0b7bad upstream. > > With -fno-asynchronous-unwind-tables and --no-eh-frame-hdr (the default > of the linker), the GNU_EH_FRAME segment (specified by vdso.lds.S) is > empty. This is not valid, as the current DWARF specification mandates > the first byte of the EH frame to be the version number 1. It causes > some unwinders to complain, for example the ClickHouse query profiler > spams the log with messages: > > clickhouse-server[365854]: libunwind: unsupported .eh_frame_hdr > version: 127 at 7ffffffb0000 > > Here "127" is just the byte located at the p_vaddr (0, i.e. the > beginning of the vDSO) of the empty GNU_EH_FRAME segment. Cross- > checking with /proc/365854/maps has also proven 7ffffffb0000 is the > start of vDSO in the process VM image. > > In LoongArch the -fno-asynchronous-unwind-tables option seems just a > MIPS legacy, and MIPS only uses this option to satisfy the MIPS-specific > "genvdso" program, per the commit cfd75c2db17e ("MIPS: VDSO: Explicitly > use -fno-asynchronous-unwind-tables"). IIRC it indicates some inherent > limitation of the MIPS ELF ABI and has nothing to do with LoongArch. So > we can simply flip it over to -fasynchronous-unwind-tables and pass > --eh-frame-hdr for linking the vDSO, allowing the profilers to unwind the > stack for statistics even if the sample point is taken when the PC is in > the vDSO. > > However simply adjusting the options above would exploit an issue: when > the libgcc unwinder saw the invalid GNU_EH_FRAME segment, it silently > falled back to a machine-specific routine to match the code pattern of > rt_sigreturn() and extract the registers saved in the sigframe if the > code pattern is matched. As unwinding from signal handlers is vital for > libgcc to support pthread cancellation etc., the fall-back routine had > been silently keeping the LoongArch Linux systems functioning since > Linux 5.19. But when we start to emit GNU_EH_FRAME with the correct > format, fall-back routine will no longer be used and libgcc will fail > to unwind the sigframe, and unwinding from signal handlers will no > longer work, causing dozens of glibc test failures. To make it possible > to unwind from signal handlers again, it's necessary to code the unwind > info in __vdso_rt_sigreturn via .cfi_* directives. > > The offsets in the .cfi_* directives depend on the layout of struct > sigframe, notably the offset of sigcontext in the sigframe. To use the > offset in the assembly file, factor out struct sigframe into a header to > allow asm-offsets.c to output the offset for assembly. > > To work around a long-term issue in the libgcc unwinder (the pc is > unconditionally substracted by 1: doing so is technically incorrect for > a signal frame), a nop instruction is included with the two real > instructions in __vdso_rt_sigreturn in the same FDE PC range. The same > hack has been used on x86 for a long time. > > Cc: stable@vger.kernel.org > Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") > Signed-off-by: Xi Ruoyao > Signed-off-by: Huacai Chen > --- Does not apply cleanly on the latest 6.12.y queue :(