All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Roman Gushchin <guroan@gmail.com>, Tejun Heo <tj@kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v5 4/7] cgroup: cgroup v2 freezer
Date: Tue, 11 Dec 2018 18:40:39 +0000	[thread overview]
Message-ID: <20181211184033.GA8971@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20181211162632.GB8504@redhat.com>

On Tue, Dec 11, 2018 at 05:26:32PM +0100, Oleg Nesterov wrote:
> On 12/07, Roman Gushchin wrote:
> >
> > Cgroup v2 freezer tries to put tasks into a state similar to jobctl
> > stop. This means that tasks can be killed, ptraced (using
> > PTRACE_SEIZE*), and interrupted. It is possible to attach to
> > a frozen task, get some information (e.g. read registers) and detach.
> 
> I fail to understand how this all supposed to work.
> 
> > @@ -368,6 +369,8 @@ static inline int signal_pending_state(long state, struct task_struct *p)
> >  		return 0;
> >  	if (!signal_pending(p))
> >  		return 0;
> > +	if (unlikely(cgroup_task_frozen(p) && p->jobctl == JOBCTL_TRAP_FREEZE))
> > +		return __fatal_signal_pending(p);
> 
> I think I will never agree with this change ;) and I don't think it actually helps.

See below.

> 
> > +void cgroup_enter_frozen(void)
> > +{
> > +	if (!current->frozen) {
> > +		spin_lock_irq(&css_set_lock);
> > +		current->frozen = true;
> > +		cgroup_inc_frozen_cnt(task_dfl_cgroup(current), false, true);
> > +		spin_unlock_irq(&css_set_lock);
> > +	}
> > +
> > +	__set_current_state(TASK_INTERRUPTIBLE);
> > +	schedule();
> 
> So once again, suppose it races with PTRACE_INTERRUPT, or SIGSTOP, or something
> else which should be handled by get_signal() before do_freezer_trap().
> 
> If (say) PTRACE_INTERRUPT comes before schedule it will be lost. Otherwise
> the frozen task will react. This can't be right. Or I am totally confused.

Why?
PTRACE_INTERRUPT will set JOBCTL_TRAP_STOP, so signal_pending_state()
will return true, schedule() will return immediately, and we'll handle the trap.

> 
> Perhaps you can split this patch? start with cgroup_enter_frozen() using
> TASK_KILLABLE, then teach it to handle ptrace/stop/etc? I think this way it
> would be simpler to discuss the necessary changes and document what exactly
> are you trying to do.
> 
> and btw.... what about suspend? try_to_freeze_tasks() will obviously fail
> if there is a ->frozen thread?

I have to think a bit more here, but something like this will probably work:

diff --git a/kernel/freezer.c b/kernel/freezer.c
index b162b74611e4..590ac4d10b02 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -134,7 +134,7 @@ bool freeze_task(struct task_struct *p)
                return false;
 
        spin_lock_irqsave(&freezer_lock, flags);
-       if (!freezing(p) || frozen(p)) {
+       if (!freezing(p) || frozen(p) || cgroup_task_frozen()) {
                spin_unlock_irqrestore(&freezer_lock, flags);
                return false;
        }

--

If the task is already frozen by the cgroup freezer, we don't have to do
anything additionally.

Thanks!

  reply	other threads:[~2018-12-11 18:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 20:15 [PATCH v5 0/7] freezer for cgroup v2 Roman Gushchin
2018-12-07 20:15 ` [PATCH v5 1/7] cgroup: rename freezer.c into legacy_freezer.c Roman Gushchin
2018-12-07 20:15 ` [PATCH v5 2/7] cgroup: implement __cgroup_task_count() helper Roman Gushchin
2018-12-07 20:15 ` [PATCH v5 3/7] cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock Roman Gushchin
2018-12-07 20:15 ` [PATCH v5 4/7] cgroup: cgroup v2 freezer Roman Gushchin
2018-12-11 16:26   ` Oleg Nesterov
2018-12-11 18:40     ` Roman Gushchin [this message]
2018-12-12 17:49       ` Oleg Nesterov
2018-12-18  1:28         ` Roman Gushchin
2018-12-18 17:12           ` Oleg Nesterov
2018-12-18 20:27             ` Roman Gushchin
2018-12-20 16:16               ` Oleg Nesterov
2018-12-20 21:43                 ` Roman Gushchin
2018-12-07 20:15 ` [PATCH v5 5/7] kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy() Roman Gushchin
2018-12-07 20:15   ` Roman Gushchin
2018-12-07 20:15   ` guroan
2018-12-07 20:15 ` [PATCH v5 6/7] kselftests: cgroup: add freezer controller self-tests Roman Gushchin
2018-12-07 20:15   ` Roman Gushchin
2018-12-07 20:15   ` guroan
2018-12-07 20:15 ` [PATCH v5 7/7] cgroup: document cgroup v2 freezer interface Roman Gushchin

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=20181211184033.GA8971@tower.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=guroan@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=tj@kernel.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.