From: Oleg Nesterov <oleg@redhat.com>
To: Roman Gushchin <guroan@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
kernel-team@fb.com, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH v10 4/9] cgroup: cgroup v2 freezer
Date: Fri, 19 Apr 2019 18:08:06 +0200 [thread overview]
Message-ID: <20190419160806.GA12790@redhat.com> (raw)
In-Reply-To: <20190419151912.GA12152@redhat.com>
Anyway, I do not want to delay this feature. Even if I am right we can
cleanup this code later. I see nothing really wrong, so no objections
from me. Sorry for delay.
On 04/19, Oleg Nesterov wrote:
>
> On 04/05, Roman Gushchin wrote:
> >
> > +void cgroup_leave_frozen(bool always_leave)
> > +{
> > + struct cgroup *cgrp;
> > +
> > + spin_lock_irq(&css_set_lock);
> > + cgrp = task_dfl_cgroup(current);
> > + if (always_leave || !test_bit(CGRP_FREEZE, &cgrp->flags)) {
> > + cgroup_dec_frozen_cnt(cgrp);
> > + cgroup_update_frozen(cgrp);
> > + WARN_ON_ONCE(!current->frozen);
> > + current->frozen = false;
> > + }
> > + spin_unlock_irq(&css_set_lock);
> > +
> > + if (unlikely(current->frozen)) {
> > + /*
> > + * If the task remained in the frozen state,
> > + * make sure it won't reach userspace without
> > + * entering the signal handling loop.
> > + */
> > + spin_lock_irq(¤t->sighand->siglock);
> > + recalc_sigpending();
> > + spin_unlock_irq(¤t->sighand->siglock);
>
> I still can't understand this logic.
>
> Once again, suppose we race with CGRP_FREEZE. If JOBCTL_TRAP_FREEZE is already
> set then signal_pending() must be already T and we do not need recalc_sigpending?
> If JOBCTL_TRAP_FREEZE is not set yet, how can recalc_sigpending() help?
>
> > +static void cgroup_freeze_task(struct task_struct *task, bool freeze)
> > +{
> > + unsigned long flags;
> > +
> > + /* If the task is about to die, don't bother with freezing it. */
> > + if (!lock_task_sighand(task, &flags))
> > + return;
> > +
> > + if (freeze) {
> > + task->jobctl |= JOBCTL_TRAP_FREEZE;
> > + signal_wake_up(task, false);
> > + } else {
> > + task->jobctl &= ~JOBCTL_TRAP_FREEZE;
> > + wake_up_process(task);
>
> wake_up_interruptible() ?
>
> > static int ptrace_signal(int signr, kernel_siginfo_t *info)
> > {
> > /*
> > @@ -2442,6 +2483,10 @@ bool get_signal(struct ksignal *ksig)
> > ksig->info.si_signo = signr = SIGKILL;
> > sigdelset(¤t->pending.signal, SIGKILL);
> > recalc_sigpending();
> > + current->jobctl &= ~JOBCTL_TRAP_FREEZE;
> > + spin_unlock_irq(&sighand->siglock);
> > + if (unlikely(cgroup_task_frozen(current)))
> > + cgroup_leave_frozen(true);
>
> Oh, and another leave_frozen below...
>
> I feel this must be simplified somehow, but nothing comes to my mind right now.
>
> > + /*
> > + * If the task is leaving the frozen state, let's update
> > + * cgroup counters and reset the frozen bit.
> > + */
> > + if (unlikely(cgroup_task_frozen(current))) {
> > spin_unlock_irq(&sighand->siglock);
> > + cgroup_leave_frozen(true);
> > goto relock;
> > }
>
> afaics cgroup_leave_frozen(false) makes more sense here.
>
> Oleg.
next prev parent reply other threads:[~2019-04-19 16:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 17:46 [PATCH v10 0/9] freezer for cgroup v2 Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 1/9] cgroup: rename freezer.c into legacy_freezer.c Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 2/9] cgroup: implement __cgroup_task_count() helper Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 3/9] cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 4/9] cgroup: cgroup v2 freezer Roman Gushchin
2019-04-19 15:19 ` Oleg Nesterov
2019-04-19 16:08 ` Oleg Nesterov [this message]
2019-04-19 16:36 ` Roman Gushchin
2019-04-19 16:11 ` Roman Gushchin
2019-04-19 16:26 ` Oleg Nesterov
2019-04-19 16:56 ` Roman Gushchin
2019-04-20 10:58 ` Oleg Nesterov
2019-04-22 22:11 ` Roman Gushchin
2019-04-24 15:46 ` Oleg Nesterov
2019-04-24 22:06 ` Roman Gushchin
2019-04-26 17:40 ` Oleg Nesterov
2019-04-24 16:02 ` Oleg Nesterov
2019-04-24 22:10 ` Roman Gushchin
2019-04-26 17:30 ` Oleg Nesterov
2019-04-05 17:47 ` [PATCH v10 5/9] kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy() Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 6/9] kselftests: cgroup: add freezer controller self-tests Roman Gushchin
2019-07-16 14:48 ` Naresh Kamboju
2019-07-17 0:49 ` Roman Gushchin
2019-07-17 8:56 ` Naresh Kamboju
2019-07-18 18:19 ` Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 7/9] cgroup: make TRACE_CGROUP_PATH irq-safe Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 8/9] cgroup: add tracing points for cgroup v2 freezer Roman Gushchin
2019-04-05 17:47 ` [PATCH v10 9/9] cgroup: document cgroup v2 freezer interface Roman Gushchin
2019-04-19 18:29 ` [PATCH v10 0/9] freezer for cgroup v2 Tejun Heo
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=20190419160806.GA12790@redhat.com \
--to=oleg@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=guroan@gmail.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--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 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).