From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932197AbbKQS5P (ORCPT ); Tue, 17 Nov 2015 13:57:15 -0500 Received: from mail-yk0-f175.google.com ([209.85.160.175]:34092 "EHLO mail-yk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752119AbbKQS5O (ORCPT ); Tue, 17 Nov 2015 13:57:14 -0500 Date: Tue, 17 Nov 2015 13:57:10 -0500 From: Tejun Heo To: Oleg Nesterov Cc: Jan Kratochvil , Pedro Alves , Andrey Ryabinin , Roland McGrath , LKML Subject: Re: ptrace() hangs on attempt to seize/attach stopped & frozen task Message-ID: <20151117185710.GA22864@mtj.duckdns.org> References: <5640B7F2.70406@virtuozzo.com> <20151109185506.GA22744@redhat.com> <20151109180207.GA28507@mtj.duckdns.org> <20151110202017.GA2976@redhat.com> <20151116184516.GJ18894@mtj.duckdns.org> <20151117193419.GA9993@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151117193419.GA9993@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, Oleg. On Tue, Nov 17, 2015 at 08:34:19PM +0100, Oleg Nesterov wrote: > On 11/16, Tejun Heo wrote: > > > > *** WARNING: THE ATTACHED DOCUMENT(S) CONTAIN MACROS *** > > *** MACROS MAY CONTAIN MALICIOUS CODE *** > > *** Open only if you can verify and trust the sender *** > > *** Please contact infosec@redhat.com if you have questions or concerns ** > > Hmm, infosec@redhat.com doesn't like you. But I dared to open and nothing > happened so far. although perhaps you already own my machine. lol no idea what's going on there but dude you gotta clean up the browsing history. > > Hmmm... It's nasty tho. We're breaking a guaranteed userland behavior > > Perhaps you are right, but I am wondering if it was ever guaranteed. > > What actually annoys me is that now I am almost sure that it was me > who asked you to hide this from user-space, and today I see no reason > for this hack. > > > I'd be a lot more comfortable stating > > that cgroup freezer is currently broken rather than diddling with > > subtle ptrace semantics. > > OK, lets keep this JOBCTL_TRAPPING_BIT. > > But still I would like to know what Pedro thinks... > > Anyway, wait_on_bit(TASK_UNINTERRUPTIBLE) doesn't look good. Do you > see any problem with the change below? Yes, the comment is not clear, > it should be updated, the tracee can clear this bit too. > > And perhaps we can change get_task_state() until freezer gets another state, > > --- x/fs/proc/array.c > +++ x/fs/proc/array.c > @@ -126,6 +126,9 @@ static inline const char *get_task_state > { > unsigned int state = (tsk->state | tsk->exit_state) & TASK_REPORT; > > + if (tsk->flags & PF_FROZEN) > + return "D (frozen)"; > + > BUILD_BUG_ON(1 + ilog2(TASK_REPORT) != ARRAY_SIZE(task_state_array)-1); > > return task_state_array[fls(state)]; Hmm... the only nit is that we'll eventually want to share "T (stopped)" or do "T (frozen)" and switching down the road could be a bit confusing. It shouldn't be a big deal tho. I think I'm mostly reluctant to accomodate the broken behavior of cgroup freezer. > --- x/kernel/ptrace.c > +++ x/kernel/ptrace.c > @@ -364,8 +364,13 @@ unlock_creds: > mutex_unlock(&task->signal->cred_guard_mutex); > out: > if (!retval) { > - wait_on_bit(&task->jobctl, JOBCTL_TRAPPING_BIT, > - TASK_UNINTERRUPTIBLE); > + if (wait_on_bit(&task->jobctl, JOBCTL_TRAPPING_BIT, > + TASK_KILLABLE)) > + /* > + * We will clear JOBCTL_TRAPPING in __ptrace_unlink(), > + * until then nobody can trace this task anyway. > + */ > + retval = -EINTR; Yeah, this looks good to me. Thanks. -- tejun