On 03/05/2022 18:56, Evan Green wrote:
> Hi Guilherme,
> [...]
>> Do you agree with that, or prefer really a parameter in
>> gsmi_shutdown_reason() ? I'll follow your choice =)
>
> I'm fine with either, thanks for the link. Mostly I want to make sure
> other paths to gsmi_shutdown_reason() aren't
On 05/03, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > But why is it bad if the tracee doesn't sleep in schedule ? If it races
> > with SIGKILL. I still can't understand this.
> >
> > Yes, wait_task_inactive() can fail, so you need to remove WARN_ON_ONCE()
> > in 11/12.
>
> >
> > Why i
Oleg Nesterov writes:
> On 05/03, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > But why is it bad if the tracee doesn't sleep in schedule ? If it races
>> > with SIGKILL. I still can't understand this.
>> >
>> > Yes, wait_task_inactive() can fail, so you need to remove WARN_ON_ONC
"Eric W. Biederman" writes:
> Oleg Nesterov writes:
>
>> On 05/03, Eric W. Biederman wrote:
>>>
>>> Oleg Nesterov writes:
>>>
>>> > But why is it bad if the tracee doesn't sleep in schedule ? If it races
>>> > with SIGKILL. I still can't understand this.
>>> >
>>> > Yes, wait_task_inactive() ca
On Wed, Apr 27, 2022 at 07:49:01PM -0300, Guilherme G. Piccoli wrote:
> Many other place in the kernel prefer the latter, so let's keep
> it consistent in MIPS code as well. Also, removes a useless header.
>
> Cc: Thomas Bogendoerfer
> Signed-off-by: Guilherme G. Piccoli
> ---
> arch/mips/sgi-i
On 04/05/2022 17:32, Thomas Bogendoerfer wrote:
> [...]
>
> applied to mips-next.
>
> Thomas.
>
Thanks a bunch Thomas =)
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
The states TASK_STOPPED and TASK_TRACE are special in they can not
handle spurious wake-ups. This plus actively depending upon and
changing the value of tsk->__state causes problems for PREEMPT_RT and
Peter's freezer rewrite.
There are a lot of details we have to get right to sort out the
techn
Rename send_signal and __send_signal to send_signal_locked and
__send_signal_locked to make send_signal usable outside of
signal.c.
Signed-off-by: "Eric W. Biederman"
---
include/linux/signal.h | 2 ++
kernel/signal.c| 24
2 files changed, 14 insertions(+), 12 d
The function __group_send_sig_info is just a light wrapper around
send_signal_locked with one parameter fixed to a constant value. As
the wrapper adds no real value update the code to directly call the
wrapped function.
Signed-off-by: "Eric W. Biederman"
---
drivers/tty/tty_jobctrl.c | 4 +
User mode linux is the last user of the PT_DTRACE flag. Using the flag to
indicate
single stepping is a little confusing and worse changing tsk->ptrace without
locking
could potentionally cause problems.
So use a thread info flag with a better name instead of flag in tsk->ptrace.
Remove the de
xtensa is the last user of the PT_SINGLESTEP flag. Changing tsk->ptrace in
user_enable_single_step and user_disable_single_step without locking could
potentiallly cause problems.
So use a thread info flag instead of a flag in tsk->ptrace. Use TIF_SINGLESTEP
that xtensa already had defined but un
The distinction is that assert_spin_locked() checks if the lock is
held *by*anyone* whereas lockdep_assert_held() asserts the current
context holds the lock. Also, the check goes away if you build
without lockdep.
Suggested-by: Peter Zijlstra
Link:
https://lkml.kernel.org/r/Ympr/+PX4XgT/u...@hi
The last remaining implementation of arch_ptrace_attach is ia64's
ptrace_attach_sync_user_rbs which was added at the end of 2007 in
commit aa91a2e90044 ("[IA64] Synchronize RBS on PTRACE_ATTACH").
Reading the comments and examining the code ptrace_attach_sync_user_rbs
has the sole purpose of savin
The current implementation of PTRACE_KILL is buggy and has been for
many years as it assumes it's target has stopped in ptrace_stop. At a
quick skim it looks like this assumption has existed since ptrace
support was added in linux v1.0.
While PTRACE_KILL has been deprecated we can not remove it a
Long ago and far away there was a BUG_ON at the start of ptrace_stop
that did "BUG_ON(!(current->ptrace & PT_PTRACED));" [1]. The BUG_ON
had never triggered but examination of the code showed that the BUG_ON
could actually trigger. To complement removing the BUG_ON an attempt
to better handle the
Stop playing with tsk->__state to remove TASK_WAKEKILL while a ptrace
command is executing.
Instead remove TASK_WAKEKILL from the definition of TASK_TRACED, and
implemention a new jobctl flag TASK_PTRACE_FROZEN. This new flag is
set in jobctl_freeze_task and cleared when ptrace_stop is awoken or
Make code analysis simpler and future changes easier by
always taking siglock in ptrace_resume.
Signed-off-by: "Eric W. Biederman"
---
kernel/ptrace.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 83ed28262708..36a5b7a0
From: Peter Zijlstra
Currently ptrace_stop() / do_signal_stop() rely on the special states
TASK_TRACED and TASK_STOPPED resp. to keep unique state. That is, this
state exists only in task->__state and nowhere else.
There's two spots of bother with this:
- PREEMPT_RT has task->saved_state which
18 matches
Mail list logo
