Messages in this thread | | | Date | Fri, 8 Apr 2022 22:06:30 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on PREEMPT_RT. |
| |
On Fri, Apr 08, 2022 at 02:40:42PM -0500, Eric W. Biederman wrote: > Peter Zijlstra <peterz@infradead.org> writes: > > > On Thu, Apr 07, 2022 at 05:50:39PM -0500, Eric W. Biederman wrote: > > >> Given that fundamentally TASK_WAKEKILL must be added in ptrace_stop and > >> removed in ptrace_attach I don't see your proposed usage of jobctl helps > >> anything fundamental. > >> > >> I suspect somewhere there is a deep trade-off between complicating > >> the scheduler to have a very special case for what is now > >> TASK_RTLOCK_WAIT, and complicating the rest of the code with having > >> TASK_RTLOCK_WAIT in __state and the values that should be in state > >> stored somewhere else. > > > > The thing is; ptrace is a special case. I feel very strongly we should > > not complicate the scheduler/wakeup path for something that 'never' > > happens. > > I was going to comment that I could not understand how the saved_state > mechanism under PREEMPT_RT works. Then I realized that wake_up_process > and wake_up_state call try_to_wake_up which calls ttwu_state_match which > modifies saved_state.
Correct.
> The options appear to be that either ptrace_freeze_traced modifies > __state/state to remove TASK_KILLABLE. Or that something clever happens > in ptrace_freeze_traced that guarantees the task does not wake > up. Something living in kernel/sched/* like wait_task_inactive.
The code I posted in the parent will attempt to strip (and re-instate) WAKEKILL from __state and then saved_state, all under pi_lock.
I think that preserves the current constraints.
> I can imagine adding add a loop around freezable_schedule in > ptrace_stop. That does something like: > > do { > freezable_schedule(); > } while (current->jobctl & JOBCTL_PTRACE_FREEZE);
I'm not entirely sure where you're headin with this; but my goal is to get rid of freezable_*() everything.
I'll ponder if wait_task_inactive() can simplify things..
> What ptrace_freeze_traced and ptrace_unfreeze_traced fundamentally need > is that the process to not do anything interesting, so that the tracer > process can modify the process and it's task_struct.
Agreed, I understand this need. I think I've done this, but I'll centrainly look hard at it again Monday -- the weekend hopefully clearing my brain of preconceptions enough so that I can see my own code a-fresh.
Anyway, my current set lives here:
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=sched/wip.freezer
I meant to post earlier today, but stuff got in between and I've not even done build-tests yet :/
| |