LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Qian Cai <cai@lca.pw>, "tj@kernel.org" <tj@kernel.org>,
	"lizefan@huawei.com" <lizefan@huawei.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: ptrace warning due to "cgroup: get rid of cgroup_freezer_frozen_exit()"
Date: Wed, 8 May 2019 18:03:12 +0000	[thread overview]
Message-ID: <20190508180307.GA25433@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20190508152536.GA17058@redhat.com>

Hello, Oleg!

On Wed, May 08, 2019 at 05:25:36PM +0200, Oleg Nesterov wrote:
> On 05/07, Roman Gushchin wrote:
> >
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -2484,9 +2484,6 @@ bool get_signal(struct ksignal *ksig)
> >                 sigdelset(&current->pending.signal, SIGKILL);
> >                 recalc_sigpending();
> >                 current->jobctl &= ~JOBCTL_TRAP_FREEZE;
> 
> just noticed... perhaps it makes more sense to clear JOBCTL_TRAP_FREEZE
> before recalc_sigpending(). Or simply not clear it at all, see below.

Agree, we don't need to clear it, because there is no way back for the task
at this moment, only exiting. I'm dropping this line.

> 
> > -               spin_unlock_irq(&sighand->siglock);
> > -               if (unlikely(cgroup_task_frozen(current)))
> > -                       cgroup_leave_frozen(true);
> >                 goto fatal;
> >         }
> >  
> > @@ -2608,8 +2605,10 @@ bool get_signal(struct ksignal *ksig)
> >                         continue;
> >                 }
> >  
> > -               spin_unlock_irq(&sighand->siglock);
> >         fatal:
> > +               spin_unlock_irq(&sighand->siglock);
> > +               if (unlikely(cgroup_task_frozen(current)))
> > +                       cgroup_leave_frozen(true);
> 
> Yes, ptrace_signal() can return a fatal signal... and in this case we do not
> clear JOBCTL_TRAP_FREEZE. This doesn't look consistent with the code above.

The same here.

> 
> 
> 
> I can only repeat that somehow we need to cleanup/improve the whole logic.
> 
> Say, a traced task reports syscall-enter. ptrace_stop() does enter_frozen().
> The cgroup can become CGRP_FROZEN after that. Now the debugger does PTRACE_CONT,
> the frozen task actually starts the syscall. Obviously not good.
> 
> Heh, and if this syscall is sys_exit or sys_exit_group we can hit the same
> warning.

Ok, I totally agree, but let's fix this noisy WARN_ON() for now,
to have some time to think about the rest.

I believe this will fix it for now:
https://github.com/rgushchin/linux/commit/3f65507e407c81d3cdf4a9145f36a8d0f755ca04

Please, let me know if you have any concerns here, otherwise I'll ask Tejun to
pull it asap.

Thank you for looking into it!

Roman

      reply	other threads:[~2019-05-08 18:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07 20:04 Qian Cai
2019-05-07 21:37 ` Roman Gushchin
2019-05-08 13:10   ` Qian Cai
2019-05-08 15:25   ` Oleg Nesterov
2019-05-08 18:03     ` Roman Gushchin [this message]

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=20190508180307.GA25433@tower.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=cai@lca.pw \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    --subject='Re: ptrace warning due to "cgroup: get rid of cgroup_freezer_frozen_exit()"' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).