linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: "H. Peter Anvin" <hpa@zytor.com>, Jens Remus <jremus@linux.ibm.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
	"Xin Li" <xin@zytor.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"James Morse" <james.morse@arm.com>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Kees Cook" <kees@kernel.org>, "Nam Cao" <namcao@linutronix.de>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Perry Yuan" <perry.yuan@amd.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Thomas Huth" <thuth@redhat.com>,
	"Uros Bizjak" <ubizjak@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-sgx@vger.kernel.org, x86@kernel.org,
	"Indu Bhagat" <indu.bhagat@oracle.com>,
	"Claudiu Zissulescu-Ianculescu"
	<claudiu.zissulescu-ianculescu@oracle.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH v4.1 06/10] x86/entry/vdso32: remove open-coded DWARF in sigreturn.S
Date: Tue, 10 Feb 2026 12:45:53 +0800	[thread overview]
Message-ID: <0ee773dea213f6efbdac03009ee80f350b17c949.camel@xry111.site> (raw)
In-Reply-To: <29D95765-BD93-451D-8FD8-54250ADE1DEB@zytor.com>

On Mon, 2026-02-09 at 20:15 -0800, H. Peter Anvin wrote:
> On February 9, 2026 7:11:25 PM PST, Xi Ruoyao <xry111@xry111.site> wrote:
> > On Mon, 2026-02-02 at 19:57 -0800, H. Peter Anvin wrote:
> > > That hack dates back from before the signal frame extension. It is no
> > > longer necessary.
> > 
> > Unfortunately at least it seems libgcc unwinder does not handle the
> > signal frame extension properly.  The code reads:
> > 
> >  fde = _Unwind_Find_FDE (context->ra + _Unwind_IsSignalFrame (context) - 1, 
> >                          &context->bases);
> >  if (fde == NULL)
> >    {    
> > #ifdef MD_FALLBACK_FRAME_STATE_FOR
> >      /* Couldn't find frame unwind info for this function.  Try a
> >         target-specific fallback mechanism.  This will necessarily
> >         not provide a personality routine or LSDA.  */
> >      return MD_FALLBACK_FRAME_STATE_FOR (context, fs); 
> > #else
> >      return _URC_END_OF_STACK;
> > #endif
> >    }    
> > 
> >  fs->pc = context->bases.func;
> > 
> >  cie = get_cie (fde);
> >  insn = extract_cie_info (cie, context, fs); 
> > 
> > Thus, it indeed attempts to avoid subtracting 1 for a signal frame, but
> > ... _Unwind_IsSignalFrame (context) actually extracts a flag in context
> > which will only be raised up by extract_cie_info.
> > 
> > Or am I missing something here?
> > 
> 
> Oh, good grief...
> 
> How does this possibly work on non-x86 platforms?

On ARM64 the vdso does not have eh_frame_hdr at all, on LoongArch
eh_frame_hdr is empty (note that an ampty en_frame_hdr is actually buggy
and I'm trying to fix it), so _Unwind_Find_FDE returns NULL and libgcc
falls back to MD_FALLBACK_FRAME_STATE_FOR, which handles the sigreturn
trampoline using some machine-dependant logic.

On RISC-V things are more theatrical: the sigreturn trampoline happens
to be at the beginning of the vdso .text section, so after subtracting 1
from the PC, the result is out of the .text section and so not in any
FDE.  Thus _Unwind_Find_FDE returns NULL and libgcc again falls back to
MD_FALLBACK_FRAME_STATE_FOR.

If the RISC-V sigreturn trampoline was not the first in .text,
subtracting 1 would cause the PC to be in the FDE of the previous
function and then _Unwind_Find_FDE would return that FDE, then RISC-V
would have some big trouble.

I've not taken a serious look at other architectures yet.

-- 
Xi Ruoyao <xry111@xry111.site>


  reply	other threads:[~2026-02-10  4:46 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16 21:25 [PATCH v4 00/10] x86/entry/vdso: clean up the vdso build, vdso updates H. Peter Anvin
2025-12-16 21:25 ` [PATCH v4 01/10] x86/entry/vdso: rename vdso_image_* to vdso*_image H. Peter Anvin
2025-12-16 21:25 ` [PATCH v4 02/10] x86/entry/vdso: move vdso2c to arch/x86/tools H. Peter Anvin
2025-12-16 21:25 ` [PATCH v4 03/10] x86/entry/vdso: refactor the vdso build H. Peter Anvin
2025-12-16 21:25 ` [PATCH v4 04/10] x86/entry/vdso32: don't rely on int80_landing_pad for adjusting ip H. Peter Anvin
2025-12-16 21:25 ` [PATCH v4 05/10] x86/entry/vdso32: remove SYSCALL_ENTER_KERNEL macro in sigreturn.S H. Peter Anvin
2025-12-16 21:26 ` [PATCH v4 06/10] x86/entry/vdso32: remove open-coded DWARF " H. Peter Anvin
2025-12-16 21:26 ` [PATCH v4 07/10] x86/entry/vdso: include GNU_PROPERTY and GNU_STACK PHDRs H. Peter Anvin
2025-12-18  2:16   ` Brian Gerst
2025-12-18  6:56     ` Brian Gerst
2025-12-16 21:26 ` [PATCH v4 08/10] x86/vdso: abstract out vdso system call internals H. Peter Anvin
2026-01-06 18:09   ` Uros Bizjak
2025-12-16 21:26 ` [PATCH v4 09/10] x86/cpufeature: replace X86_FEATURE_SYSENTER32 with X86_FEATURE_SYSFAST32 H. Peter Anvin
2025-12-16 21:26 ` [PATCH v4 10/10] x86/entry/vdso32: when using int $0x80, use it directly H. Peter Anvin
2026-01-06 21:18 ` [PATCH v4.1 00/10] x86/entry/vdso: clean up the vdso build, vdso updates H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 01/10] x86/entry/vdso: rename vdso_image_* to vdso*_image H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 02/10] x86/entry/vdso: move vdso2c to arch/x86/tools H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 03/10] x86/entry/vdso: refactor the vdso build H. Peter Anvin
2026-01-16  3:58     ` Chris Mason
2026-01-06 21:18   ` [PATCH v4.1 04/10] x86/entry/vdso32: don't rely on int80_landing_pad for adjusting ip H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 05/10] x86/entry/vdso32: remove SYSCALL_ENTER_KERNEL macro in sigreturn.S H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 06/10] x86/entry/vdso32: remove open-coded DWARF " H. Peter Anvin
2026-02-02 17:02     ` Jens Remus
2026-02-03  3:57       ` H. Peter Anvin
2026-02-10  3:11         ` Xi Ruoyao
2026-02-10  4:15           ` H. Peter Anvin
2026-02-10  4:45             ` Xi Ruoyao [this message]
2026-02-10  4:53               ` H. Peter Anvin
2026-02-10  4:51           ` H. Peter Anvin
2026-02-10  4:56             ` Xi Ruoyao
2026-02-10  5:24               ` H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 07/10] x86/entry/vdso: include GNU_PROPERTY and GNU_STACK PHDRs H. Peter Anvin
2026-01-07 12:10     ` Andrew Cooper
2026-01-06 21:18   ` [PATCH v4.1 08/10] x86/vdso: abstract out vdso system call internals H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 09/10] x86/cpufeature: replace X86_FEATURE_SYSENTER32 with X86_FEATURE_SYSFAST32 H. Peter Anvin
2026-01-06 21:18   ` [PATCH v4.1 10/10] x86/entry/vdso32: when using int $0x80, use it directly H. Peter Anvin
2026-01-15  7:00   ` [PATCH v4.1 00/10] x86/entry/vdso: clean up the vdso build, vdso updates Thorsten Leemhuis
2026-01-15 15:00     ` H. Peter Anvin

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=0ee773dea213f6efbdac03009ee80f350b17c949.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=Jason@zx2c4.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=claudiu.zissulescu-ianculescu@oracle.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=indu.bhagat@oracle.com \
    --cc=james.morse@arm.com \
    --cc=jarkko@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=jremus@linux.ibm.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namcao@linutronix.de \
    --cc=oleg@redhat.com \
    --cc=perry.yuan@amd.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=thuth@redhat.com \
    --cc=tytso@mit.edu \
    --cc=ubizjak@gmail.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /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