public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
	Sasha Levin <sashal@kernel.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	Xuerui Wang <kernel@xen0n.name>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	loongarch@lists.linux.dev
Subject: Re: [PATCH for 6.6] LoongArch: vDSO: Emit GNU_EH_FRAME correctly
Date: Tue, 31 Mar 2026 14:05:23 +0200	[thread overview]
Message-ID: <2026033143-gumball-handcraft-5656@gregkh> (raw)
In-Reply-To: <42ab19d20e572c61587728350b5f1ca900632322.camel@xry111.site>

On Tue, Mar 31, 2026 at 07:58:15PM +0800, Xi Ruoyao wrote:
> On Tue, 2026-03-31 at 13:10 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Mar 30, 2026 at 06:01:33PM +0800, Huacai Chen wrote:
> > > From: Xi Ruoyao <xry111@xry111.site>
> > > 
> > > 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 <xry111@xry111.site>
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > 
> > Does not apply cleanly on the latest 6.12.y queue :(
> 
> This is for 6.6.  Maybe your agent is malfunctioning?

Sorry, that was me malfunctioning, I meant to say this failed for 6.6.y:

	Applying loongarch-vdso-emit-gnu_eh_frame-correctly.patch to linux-6.6.y
	Applying patch loongarch-vdso-emit-gnu_eh_frame-correctly.patch
	patching file arch/loongarch/include/asm/linkage.h
	patching file arch/loongarch/include/asm/sigframe.h
	patching file arch/loongarch/kernel/asm-offsets.c
	patching file arch/loongarch/kernel/signal.c
	Hunk #2 succeeded at 72 with fuzz 2 (offset 21 lines).
	patching file arch/loongarch/vdso/Makefile
	Hunk #1 succeeded at 24 (offset -1 lines).
	Hunk #2 FAILED at 36.
	1 out of 2 hunks FAILED -- rejects in file arch/loongarch/vdso/Makefile
	patching file arch/loongarch/vdso/sigreturn.S
	Patch loongarch-vdso-emit-gnu_eh_frame-correctly.patch does not apply (enforce with -f)

too many kernel branches...

thanks,

greg k-h

  reply	other threads:[~2026-03-31 12:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 10:01 [PATCH for 6.6] LoongArch: vDSO: Emit GNU_EH_FRAME correctly Huacai Chen
2026-03-31 11:10 ` Greg Kroah-Hartman
2026-03-31 11:58   ` Xi Ruoyao
2026-03-31 12:05     ` Greg Kroah-Hartman [this message]
2026-03-31 16:34       ` [PATCH 6.6.y] " Xi Ruoyao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026033143-gumball-handcraft-5656@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=chenhuacai@loongson.cn \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox