Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1270466

Re: ptrace() hangs on attempt to seize/attach stopped & frozen task

From Tejun Heo <tj@kernel.org>
Newsgroups linux.kernel
Subject Re: ptrace() hangs on attempt to seize/attach stopped & frozen task
Date 2015-11-16 19:50 +0100
Message-ID <qvx0J-2t2-7@gated-at.bofh.it> (permalink)
References <qsWoF-89v-3@gated-at.bofh.it> <qsYTw-18Q-9@gated-at.bofh.it> <qsZ3e-1rz-45@gated-at.bofh.it> <qtmM9-MK-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello, Oleg.

Sorry about the delay.

On Tue, Nov 10, 2015 at 09:20:17PM +0100, Oleg Nesterov wrote:
> > We simply need to reimplement cgroup freezer so that its userland
> > visible state is well defined (most likely jobctl stop).  Right now,
> > it's allowing userland to trigger "stuck somewhere in the kernel"
> > condition, so interactions with frozen tasks are naturally broken.
> 
> I agree, the freezer is not perfect, and it needs changes.
> 
> Still I think this needs a fix in ptrace code. At least we should not
> wait in TASK_UNINTERRUPTIBLE state.
> 
> And perhaps we can simply remove this logic? I forgot why do we hide this
> STOPPED -> RUNNING -> TRACED transition from the attaching thread. But the
> vague feeling tells me that we discussed this before and perhaps it was me
> who suggested to avoid the user-visible change when you introduced this
> transition...

Heh, it was too long ago for me to remember much. :)

> Anyway, now I do not understand why do we want to hide it. Lets consider
> the following "test-case",
> 
> 	void test(int pid)
> 	{
> 		kill(pid, SIGSTOP);
> 		waitpid(pid, NULL, WSTOPPED);
> 
> 		ptrace(PTRACE_ATTACH-OR-PTRACE_SEIZE, pid, 0,0);
> 
> 		assert(ptrace(PTRACE_DETACH, pid, 0,0) == 0);
> 	}
> 
> Yes, it will fail if we remove JOBCTL_TRAPPING. But it can equally fail
> if SIGCONT comes before ATTACH, so perhaps we do not really care?
> 
> Jan, Pedro, do you think the patch below can break gdb somehow? With this
> patch you can never assume that waitpid(WNOHANG) or ptrace(WHATEVER) will
> succeed right after PTRACE_ATTACH/PTRACE_SEIZE, even if you know that the
> tracee was TASK_STOPPED before attach.
> 
> Tejun, do you see any reason to keep JOBCTL_TRAPPING?

Hmmm... It's nasty tho.  We're breaking a guaranteed userland behavior
to mask a deficiency (IMHO it's an outright bug) in a different
subsystem.  The problem here is that cgroup-frozen threads become
un-runnable on a running system and it doesn't make sense to me to
work around that from all the affected places rather than fixing it at
the source especially if that involves breaking a known supported
userland behavior.  This isn't different from the frozen processes
failing to respond to SIGKILL.  I'd be a lot more comfortable stating
that cgroup freezer is currently broken rather than diddling with
subtle ptrace semantics.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

ptrace() hangs on attempt to seize/attach stopped & frozen task Andrey Ryabinin <aryabinin@virtuozzo.com> - 2015-11-09 16:20 +0100
  Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Oleg Nesterov <oleg@redhat.com> - 2015-11-09 19:00 +0100
    Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Tejun Heo <tj@kernel.org> - 2015-11-09 19:10 +0100
      Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Oleg Nesterov <oleg@redhat.com> - 2015-11-10 20:30 +0100
        Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Tejun Heo <tj@kernel.org> - 2015-11-16 19:50 +0100
          Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Oleg Nesterov <oleg@redhat.com> - 2015-11-17 19:40 +0100
            Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Tejun Heo <tj@kernel.org> - 2015-11-17 20:00 +0100
            Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Pedro Alves <palves@redhat.com> - 2015-11-19 18:00 +0100
              Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Oleg Nesterov <oleg@redhat.com> - 2015-11-19 18:50 +0100
                Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Pedro Alves <palves@redhat.com> - 2015-11-19 19:10 +0100
    Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Oleg Nesterov <oleg@redhat.com> - 2015-11-10 20:30 +0100
  [PATCH 2/2] ptrace: task_stopped_code(ptrace => true) can't see  TASK_STOPPED task Oleg Nesterov <oleg@redhat.com> - 2015-11-19 19:50 +0100
    Re: [PATCH 2/2] ptrace: task_stopped_code(ptrace => true) can't see  TASK_STOPPED task Tejun Heo <tj@kernel.org> - 2015-11-24 00:20 +0100
  [PATCH 1/2] ptrace: make wait_on_bit(JOBCTL_TRAPPING_BIT) in  ptrace_attach() killable Oleg Nesterov <oleg@redhat.com> - 2015-11-19 19:50 +0100
    Re: [PATCH 1/2] ptrace: make wait_on_bit(JOBCTL_TRAPPING_BIT) in  ptrace_attach() killable Tejun Heo <tj@kernel.org> - 2015-11-24 00:10 +0100
  [PATCH 0/2] (Was: ptrace() hangs on attempt to seize/attach  stopped & frozen task) Oleg Nesterov <oleg@redhat.com> - 2015-11-19 19:50 +0100

csiph-web