mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>,
	catalin.marinas@arm.com, will@kernel.org, oleg@redhat.com,
	tglx@linutronix.de, peterz@infradead.org, luto@kernel.org,
	shuah@kernel.org, kees@kernel.org, wad@chromium.org,
	charlie@rivosinc.com, akpm@linux-foundation.org, ldv@strace.io,
	macro@orcam.me.uk, deller@gmx.de, mark.rutland@arm.com,
	efault@gmx.de, song@kernel.org, mbenes@suse.cz,
	ryan.roberts@arm.com, ada.coupriediaz@arm.com,
	anshuman.khandual@arm.com, broonie@kernel.org,
	pengcan@kylinos.cn, dvyukov@google.com, kmal@cock.li,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v8 11/12] arm64: entry: Convert to generic entry
Date: Fri, 28 Nov 2025 14:32:00 +0100	[thread overview]
Message-ID: <8c55c2a1-995e-44a1-8d48-b7d794f5176f@arm.com> (raw)
In-Reply-To: <bfdd914c-4c3a-9af7-d530-f57f3532c3d5@huawei.com>

On 28/11/2025 04:34, Jinjie Ruan wrote:
>
> On 2025/11/27 21:31, Kevin Brodsky wrote:
>> On 26/11/2025 08:14, Jinjie Ruan wrote:
>>> Currently, x86, Riscv, Loongarch use the generic entry which makes
>>> maintainers' work easier and codes more elegant. arm64 has already
>>> switched to the generic IRQ entry, so completely convert arm64 to use
>>> the generic entry infrastructure from kernel/entry/*.
>>>
>>> The changes are below:
>>>  - Remove TIF_SYSCALL_* flag, _TIF_WORK_MASK, _TIF_SYSCALL_WORK,
>> _TIF_WORK_MASK is now removed in patch 1.
>>
>>>    and remove has_syscall_work(), as _TIF_SYSCALL_WORK is equal with
>>>    SYSCALL_WORK_ENTER.
>>>
>>> [...]
>>>
>>> +static __always_inline void arch_ptrace_report_syscall_exit(struct pt_regs *regs,
>>> +							    int step)
>>> +{
>>> +	unsigned long saved_reg;
>>> +	int regno;
>>> +
>>> +	saved_reg = ptrace_save_reg(regs, PTRACE_SYSCALL_EXIT, &regno);
>>> +	if (!step) {
>> A difference I noticed here is that the generic report_single_step()
>> always returns false if SYSCALL_EMU is set. I don't know if the
>> combination of SYSCALL_EMU and SINGLESTEP is meaningful, but if it is
>> then I think that's a behaviour change.
> commit 64eb35f701f0 ("ptrace: Migrate TIF_SYSCALL_EMU to use
> SYSCALL_WORK flag") has changed the following code:
>
> Therefore, the original logic returns false in these cases for
> report_single_step() :
>
> - Only _TIF_SYSCALL_EMU is set.
>
> - Both _TIF_SINGLESTEP and _TIF_SYSCALL_EMU are set.
>
> - Neither TIF_SINGLESTEP nor _TIF_SYSCALL_EMU is set;
>
>
>     #define SYSEMU_STEP    (_TIF_SINGLESTEP | _TIF_SYSCALL_EMU)
>
>     static inline bool report_single_step(unsigned long ti_work)
>     {
>        return (ti_work & SYSEMU_STEP) == _TIF_SINGLESTEP;
>     }

The code did look different before this commit, but AFAICT it was
functionally equivalent w.r.t. SYSEMU / SINGLESTEP.

> I think the "returns false if SYSCALL_EMU is set" behaviour is correct
> according to the Man's Manual, both PTRACE_SYSEMU and
> PTRACE_SYSEMU_SINGLESTEP need to report the syscal only once on syscall
> entry.
>
>     “For PTRACE_SYSEMU, continue and stop on entry to the next
>       system call, which will not be executed.  See the
>       documentation on syscall-stops below.  For
>       PTRACE_SYSEMU_SINGLESTEP, do the same but also singlestep
>       if not a system call. “

That seems sensible (based on my very limited understanding of SYSEMU),
nevertheless it is not what arm64 currently does AFAIU. To follow the
same logic as the rest, this change should be made in a separate patch.

> Link:https://man7.org/linux/man-pages/man2/ptrace.2.html
>
>>> [...]
>>>
>>>  #define TIF_UPROBE		5	/* uprobe breakpoint or singlestep */
>>>  #define TIF_MTE_ASYNC_FAULT	6	/* MTE Asynchronous Tag Check Fault */
>>>  #define TIF_NOTIFY_SIGNAL	7	/* signal notifications exist */
>>> -#define TIF_SYSCALL_TRACE	8	/* syscall trace active */
>>> -#define TIF_SYSCALL_AUDIT	9	/* syscall auditing */
>>> -#define TIF_SYSCALL_TRACEPOINT	10	/* syscall tracepoint for ftrace */
>>> -#define TIF_SECCOMP		11	/* syscall secure computing */
>>> -#define TIF_SYSCALL_EMU		12	/* syscall emulation active */
>>> +#define TIF_SECCOMP		11      /* syscall secure computing */
>>> +#define TIF_SYSCALL_EMU		12      /* syscall emulation active */
>> These seem to have reappeared in v8 for some reason?
> v8 add "ARCH_SYSCALL_WORK_EXIT" to be defined as "SECCOMP | SYSCALL_EMU"
>   to keep the arm64 behaviour unchanged as mentioned in v7.

Ah then that is where the issue is, I missed that: surely switching to
generic entry means that we are using SYSCALL_WORK_BIT_* rather than
TIF_* for all these flags?

- Kevin

  reply	other threads:[~2025-11-28 13:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26  7:14 [PATCH v8 00/12] arm64: entry: Convert to Generic Entry Jinjie Ruan
2025-11-26  7:14 ` [PATCH v8 01/12] arm64: Remove unused _TIF_WORK_MASK Jinjie Ruan
2025-11-27 13:27   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 02/12] arm64/ptrace: Split report_syscall() Jinjie Ruan
2025-11-27 13:28   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 03/12] arm64/ptrace: Refactor syscall_trace_enter/exit() Jinjie Ruan
2025-11-27 13:28   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 04/12] arm64: ptrace: Move rseq_syscall() before audit_syscall_exit() Jinjie Ruan
2025-11-27 13:28   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 05/12] arm64: syscall: Rework el0_svc_common() Jinjie Ruan
2025-11-27 13:29   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 06/12] arm64/ptrace: Return early for ptrace_report_syscall_entry() error Jinjie Ruan
2025-11-27 13:29   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 07/12] arm64/ptrace: Expand secure_computing() in place Jinjie Ruan
2025-11-27 13:29   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 08/12] arm64/ptrace: Use syscall_get_arguments() heleper Jinjie Ruan
2025-11-27 13:30   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 09/12] entry: Split syscall_exit_to_user_mode_work() for arch reuse Jinjie Ruan
2025-11-26  7:14 ` [PATCH v8 10/12] entry: Add arch_ptrace_report_syscall_entry/exit() Jinjie Ruan
2025-11-27 13:30   ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 11/12] arm64: entry: Convert to generic entry Jinjie Ruan
2025-11-27 13:31   ` Kevin Brodsky
2025-11-28  3:34     ` Jinjie Ruan
2025-11-28 13:32       ` Kevin Brodsky [this message]
2025-11-29  1:23         ` Jinjie Ruan
2025-12-01 10:17           ` Kevin Brodsky
2025-11-26  7:14 ` [PATCH v8 12/12] selftests: sud_test: Support aarch64 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=8c55c2a1-995e-44a1-8d48-b7d794f5176f@arm.com \
    --to=kevin.brodsky@arm.com \
    --cc=ada.coupriediaz@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=charlie@rivosinc.com \
    --cc=deller@gmx.de \
    --cc=dvyukov@google.com \
    --cc=efault@gmx.de \
    --cc=kees@kernel.org \
    --cc=kmal@cock.li \
    --cc=ldv@strace.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=oleg@redhat.com \
    --cc=pengcan@kylinos.cn \
    --cc=peterz@infradead.org \
    --cc=ruanjinjie@huawei.com \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wad@chromium.org \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®