Re: [PATCH v3 2/6] syscall.h: add syscall_set_arguments() and syscall_set_return_value()

"Dmitry V. Levin" writes: > On Thu, Jan 30, 2025 at 09:33:03AM +0100, Sven Schnelle wrote: >> "Dmitry V. Levin" writes: >> >> > These functions are going to be needed on all HAVE_ARCH_TRACEHOOK >> > architectures to implement PTRACE_SET_SYSC

Re: [PATCH v3 2/6] syscall.h: add syscall_set_arguments() and syscall_set_return_value()

"Dmitry V. Levin" writes: > These functions are going to be needed on all HAVE_ARCH_TRACEHOOK > architectures to implement PTRACE_SET_SYSCALL_INFO API. > > This partially reverts commit 7962c2eddbfe ("arch: remove unused > function syscall_set_arguments()") by reusing some of old > syscall_set_ar

Re: [PATCH 3/6] syscall.h: introduce syscall_set_nr()

"Dmitry V. Levin" writes: > Similar to syscall_set_arguments() that complements > syscall_get_arguments(), introduce syscall_set_nr() > that complements syscall_get_nr(). > > syscall_set_nr() is going to be needed along with > syscall_set_arguments() on all HAVE_ARCH_TRACEHOOK > architectures to

Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping

Linus Torvalds writes: > On Mon, 2 Sept 2024 at 13:49, Andrew Morton wrote: >> >> uprobe_clear_state() is a pretty simple low-level thing. Side-effects >> seem unlikely? > > I think uprobe_clear_state() should be removed from fork.c entirely, > made 'static', and then we'd have > > area

Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping

Nathan Chancellor writes: > Hi Michael, > > On Mon, Aug 12, 2024 at 06:26:02PM +1000, Michael Ellerman wrote: >> Add an optional close() callback to struct vm_special_mapping. It will >> be used, by powerpc at least, to handle unmapping of the VDSO. >> >> Although support for unmapping the VDSO w

Re: [PATCH 4/5] kbuild: unify vdso_install rules

et from arch/arm64/Makefile. > > vdso-install-$(CONFIG_COMPAT_VDSO) += > arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so > > This will rename vdso.so.dbg to vdso32.so during installation. If such > architectures change their implementation so that the file names match, > thi

Re: [PATCH v4 12/12] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

Peter Zijlstra writes: > On Wed, Jul 06, 2022 at 09:58:55AM +0200, Sven Schnelle wrote: > >> >> [ 86.218551] kill_chi-3438056d 79990141us : ptrace_stop: >> >> JOBCTL_TRACED already set, state=0 <-- valid combination of flags? >> &g

Re: [PATCH v4 12/12] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

Hi Peter, Peter Zijlstra writes: > On Tue, Jul 05, 2022 at 07:28:49PM +0200, Sven Schnelle wrote: >> Sven Schnelle writes: > >> I think there's a race in ptrace_check_attach(). It first calls >> ptrace_freeze_task(), which checks whether JOBCTL_TRACED is set.

Re: [PATCH v4 12/12] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

Sven Schnelle writes: > Steven Rostedt writes: > >> On Tue, 21 Jun 2022 17:15:47 +0200 >> Alexander Gordeev wrote: >> >>> So I assume (checked actually) the return 0 below from kernel/sched/core.c: >>> wait_task_inactive() is where it bail

Re: [PATCH v4 12/12] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

Hi, Steven Rostedt writes: > On Tue, 21 Jun 2022 17:15:47 +0200 > Alexander Gordeev wrote: > >> So I assume (checked actually) the return 0 below from kernel/sched/core.c: >> wait_task_inactive() is where it bails out: >> >> 3303 while (task_running(rq, p)) { >> 3304