From: kemal <kmal@cock.li>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next v6 10/10] arm64: entry: Convert to generic entry
Date: Wed, 17 Sep 2025 16:14:04 +0300 [thread overview]
Message-ID: <G3IQ2T.YZ8RX05BU5F81@cock.li> (raw)
In-Reply-To: <886f1357-8d14-bb63-bf46-837bb6922ebd@huawei.com>
On Çrş, Sep 17 2025 at 09:55:35 +08:00:00, Jinjie Ruan
<ruanjinjie@huawei.com> wrote:
> Thank you! I will try to implement arch_syscall_is_vdso_sigreturn() as
> this and test it. By the way, is this for supporting arm64 in wine?
No, I don't even know if arm64 windows binaries do direct
syscalls. This is meant for some other project.
>>
>> 2 - This trick shouldn't be done if the syscall will be catched by
>> SUD:
>> if (scno == NO_SYSCALL)
>> syscall_set_return_value(current, regs, -ENOSYS, 0);
>> As the ABI could be anything.
>>
> This requires discussion with Catalin and Will, which may alter the
> original intent.
Sorry, I didnt read the code carefully, syscall_user_dispatch()
already calls syscall_rollback() which should restore x0 from
orig_x0.
You can test SUD using the selftest, but you need to add these
lines at the end of handle_sigsys() in sud_test.c:
#ifdef __aarch64__
((ucontext_t *)ucontext)->uc_mcontext.regs[0] = (unsigned int)
((ucontext_t *)ucontext)->uc_mcontext.regs[8];
#endif
and you should define TEST_BLOCKED_RETURN in sud_benchmark.c
to make sure arch_syscall_is_vdso_sigreturn works properly
-kemal
>>
next prev parent reply other threads:[~2025-09-17 13:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 8:26 [PATCH -next v6 00/10] arm64: entry: Convert to generic entry Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 01/10] arm64/ptrace: Split report_syscall() into report_syscall_enter/exit() Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 02/10] arm64/ptrace: Refactor syscall_trace_enter/exit() Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 03/10] arm64/ptrace: Refator el0_svc_common() Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 04/10] entry: Extract syscall_exit_to_user_mode_prepare() helper Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 05/10] arm64/ptrace: Handle ptrace_report_syscall_entry() error Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 06/10] arm64/ptrace: Rework secure_computing() in syscall_trace_enter() Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 07/10] arm64/ptrace: Use syscall_get_arguments() heleper Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 08/10] entry: Add arch_ptrace_report_syscall_entry/exit() Jinjie Ruan
2025-09-17 8:27 ` kernel test robot
2025-09-16 8:26 ` [PATCH -next v6 09/10] entry: Add has_syscall_work() helper Jinjie Ruan
2025-09-16 8:26 ` [PATCH -next v6 10/10] arm64: entry: Convert to generic entry Jinjie Ruan
2025-09-16 14:46 ` kemal
2025-09-17 1:55 ` Jinjie Ruan
2025-09-17 13:14 ` kemal [this message]
2025-09-18 9:52 ` kernel test robot
2025-10-10 0:59 ` [PATCH -next v6 00/10] " Jinjie Ruan
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=G3IQ2T.YZ8RX05BU5F81@cock.li \
--to=kmal@cock.li \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ruanjinjie@huawei.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