All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: [GIT PULL]
Date: Fri, 03 Jun 2022 14:20:38 -0500	[thread overview]
Message-ID: <87bkv97dvd.fsf@email.froward.int.ebiederm.org> (raw)


Linus,

Please pull the ptrace_stop-cleanup-for-v5.19 tag from the git tree:

  git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git ptrace_stop-cleanup-for-v5.19
  HEAD: 31cae1eaae4fd65095ad6a3659db467bc3c2599e sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

While looking at the ptrace problems with PREEMPT_RT and the problems
of Peter Zijlstra was encountering with ptrace in his freezer rewrite
I identified some cleanups to ptrace_stop that make sense on their own
and move make resolving the other problems much simpler.

The biggest issue is the habbit of the ptrace code to change task->__state
from the tracer to suppress TASK_WAKEKILL from waking up the tracee.  No
other code in the kernel does that and it is straight forward to update
signal_wake_up and friends to make that unnecessary.

Peter's task freezer sets frozen tasks to a new state TASK_FROZEN and
then it stores them by calling "wake_up_state(t, TASK_FROZEN)" relying
on the fact that all stopped states except the special stop states can
tolerate spurious wake up and recover their state.

The state of stopped and traced tasked is changed to be stored in
task->jobctl as well as in task->__state.  This makes it possible for
the freezer to recover tasks in these special states, as well as
serving as a general cleanup.  With a little more work in that
direction I believe TASK_STOPPED can learn to tolerate spurious wake
ups and become an ordinary stop state.

The TASK_TRACED state has to remain a special state as the registers for
a process are only reliably available when the process is stopped in
the scheduler.  Fundamentally ptrace needs acess to the saved
register values of a task.

There are bunch of semi-random ptrace related cleanups that were found
while looking at these issues.

One cleanup that deserves to be called out is from commit 57b6de08b5f6
("ptrace: Admit ptrace_stop can generate spuriuos SIGTRAPs").  This
makes a change that is technically user space visible, in the handling
of what happens to a tracee when a tracer dies unexpectedly.
According to our testing and our understanding of userspace nothing
cares that spurious SIGTRAPs can be generated in that case.

The entire discussion can be found at:
  https://lkml.kernel.org/r/87a6bv6dl6.fsf_-_@email.froward.int.ebiederm.org

Eric W. Biederman (11):
      signal: Rename send_signal send_signal_locked
      signal: Replace __group_send_sig_info with send_signal_locked
      ptrace/um: Replace PT_DTRACE with TIF_SINGLESTEP
      ptrace/xtensa: Replace PT_SINGLESTEP with TIF_SINGLESTEP
      ptrace: Remove arch_ptrace_attach
      signal: Use lockdep_assert_held instead of assert_spin_locked
      ptrace: Reimplement PTRACE_KILL by always sending SIGKILL
      ptrace: Document that wait_task_inactive can't fail
      ptrace: Admit ptrace_stop can generate spuriuos SIGTRAPs
      ptrace: Don't change __state
      ptrace: Always take siglock in ptrace_resume

Peter Zijlstra (1):
      sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state

 arch/ia64/include/asm/ptrace.h    |   4 --
 arch/ia64/kernel/ptrace.c         |  57 ----------------
 arch/um/include/asm/thread_info.h |   2 +
 arch/um/kernel/exec.c             |   2 +-
 arch/um/kernel/process.c          |   2 +-
 arch/um/kernel/ptrace.c           |   8 +--
 arch/um/kernel/signal.c           |   4 +-
 arch/x86/kernel/step.c            |   3 +-
 arch/xtensa/kernel/ptrace.c       |   4 +-
 arch/xtensa/kernel/signal.c       |   4 +-
 drivers/tty/tty_jobctrl.c         |   4 +-
 include/linux/ptrace.h            |   7 --
 include/linux/sched.h             |  10 ++-
 include/linux/sched/jobctl.h      |   8 +++
 include/linux/sched/signal.h      |  20 ++++--
 include/linux/signal.h            |   3 +-
 kernel/ptrace.c                   |  87 ++++++++---------------
 kernel/sched/core.c               |   5 +-
 kernel/signal.c                   | 140 +++++++++++++++++---------------------
 kernel/time/posix-cpu-timers.c    |   6 +-
 20 files changed, 140 insertions(+), 240 deletions(-)

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

p.s.  My apologies this is coming in so late, everyone in my house has
been sick.

             reply	other threads:[~2022-06-03 19:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 19:20 Eric W. Biederman [this message]
2022-06-03 19:27 ` [GIT PULL] ptrace_stop cleanups for v5.19 Eric W. Biederman
2022-06-03 23:25 ` [GIT PULL] pr-tracker-bot
  -- strict thread matches above, loose matches on Subject: below --
2022-08-09 13:27 David Howells
2022-08-09 17:29 ` pr-tracker-bot
2021-12-23 19:55 Eric W. Biederman
2021-12-23 19:55 ` Eric W. Biederman
2019-02-11 20:48 Kevin Hilman
2019-02-11 20:48 ` Kevin Hilman
2019-02-11 20:56 ` Kevin Hilman
2019-02-11 20:56   ` Kevin Hilman
2018-05-08 13:38 Frederic Weisbecker
2016-04-12 18:34 David Howells
2015-07-15 11:51 Tero Kristo
2015-07-15 21:05 ` Stephen Boyd
2012-06-18 20:48 Roland Stigge
2012-06-30 23:29 ` Olof Johansson
2012-07-01 15:40   ` Roland Stigge
2012-07-02 16:25     ` Olof Johansson
2012-04-10 19:05 Stephen Warren
2012-04-10 21:29 ` Mark Brown
2012-03-13  4:56 [git pull] Jesse Barnes
2011-12-19 11:29 [GIT PULL] Sascha Hauer
2011-12-20  5:33 ` Olof Johansson
2011-02-11 13:40 Ted Ts'o
2011-02-12  0:33 ` Linus Torvalds
2011-02-12  0:33   ` Linus Torvalds
2011-02-12  1:41   ` Eric Sandeen
2011-02-12  1:41     ` Eric Sandeen
2011-02-12 13:28   ` Ted Ts'o
2010-09-10 12:52 Nicolas Ferre
2010-09-10 12:52 ` Nicolas Ferre
2010-09-10 13:16 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-10 13:16   ` Jean-Christophe PLAGNIOL-VILLARD
2010-03-03  3:09 Frederic Weisbecker
2007-10-23  9:43 Haavard Skinnemoen

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=87bkv97dvd.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.