On 2022-05-18 17:49:50 [-0500], Eric W. Biederman wrote:
> After this set of changes only cgroup_enter_frozen should remain a
> stumbling block for PREEMPT_RT in the ptrace_stop path.
Yes, I can confirm that. I have no systemd-less system at hand which
means I can't boot a kernel without CGROUP su
On 2022-05-18 17:49:50 [-0500], Eric W. Biederman wrote:
>
> For ptrace_stop to work on PREEMT_RT no spinlocks can be taken once
> ptrace_freeze_traced has completed successfully. Which fundamentally
> means the lock dance of dropping siglock and grabbing tasklist_lock does
> not work on PREEMPT_
On 2022-05-18 20:26:05 [-0700], Kyle Huey wrote:
> Is there a git branch somewhere I can pull to test this? It doesn't apply
> cleanly to Linus's tip.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
ptrace_stop-cleanup-for-v5.19
> - Kyle
Sebastian
_
On 2022-05-10 09:26:36 [-0500], Eric W. Biederman wrote:
> Does anyone else have any comments on this patchset?
>
> If not I am going to apply this to a branch and get it into linux-next.
Looks good I guess.
Be aware that there will be clash due to
https://lore.kernel.org/all/1649240981-11024
On 2022-05-05 13:26:41 [-0500], Eric W. Biederman wrote:
> After ptrace_freeze_traced succeeds it is known that the the tracee
the
> has a __state value of __TASK_TRACED and that no __ptrace_unlink will
> happen because the tracer is waiting f
On 2022-05-04 17:40:56 [-0500], Eric W. Biederman wrote:
> 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
i
On 2022-04-29 16:46:59 [-0500], Eric W. Biederman wrote:
>
> 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.
PRE
On 2022-04-29 16:48:37 [-0500], Eric W. Biederman wrote:
Needs
From: Peter Zijlstra (Intel)
at the top.
> 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 nowh
On 2022-04-29 16:48:35 [-0500], Eric W. Biederman wrote:
> In ptrace_stop a ptrace_unlink or SIGKILL can occur either after
> siglock is dropped or after tasklist_lock is dropped. At either point
> the result can be that ptrace will continue and not stop at schedule.
>
> This means that there are
On 2022-04-29 16:48:32 [-0500], Eric W. Biederman wrote:
> Stop playing with tsk->__state to remove TASK_WAKEKILL while a ptrace
> command is executing.
>
> Instead TASK_WAKEKILL from the definition of TASK_TRACED, and
> implemention a new jobctl flag TASK_PTRACE_FROZEN. This new This new
Instea
On 2022-04-29 16:48:27 [-0500], Eric W. Biederman wrote:
> The function send_signal_locked does more than __group_send_sig_info so
> replace it.
This might be easier to understand:
__group_send_sig_info() is just a wrapper around send_signal_locked()
with a special pid_type.
Replace
On 2022-04-29 16:48:26 [-0500], Eric W. Biederman wrote:
> Rename send_signal send_signal_locked and make to make
s@to make@@
> it usable outside of signal.c.
>
> Signed-off-by: "Eric W. Biederman"
Sebastian
___
linux-um mailing list
linux-um@lists.
On 2022-04-26 17:52:07 [-0500], Eric W. Biederman wrote:
> The functions ptrace_stop and do_signal_stop have to drop siglock
> and grab tasklist_lock because the parent/child relation ship
> is guarded by siglock and not siglock.
"is guarded by tasklist_lock and not siglock." ?
> Simplify things
13 matches
Mail list logo
