All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:19:12 +0200	[thread overview]
Message-ID: <20190419151912.GA12152@redhat.com> (raw)
In-Reply-To: <20190405174708.1010-5-guro@fb.com>

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(&current->sighand->siglock);
> +		recalc_sigpending();
> +		spin_unlock_irq(&current->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(&current->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.


  reply	other threads:[~2019-04-19 18:54 UTC|newest]

Thread overview: 33+ 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 [this message]
2019-04-19 16:08     ` Oleg Nesterov
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   ` Roman Gushchin
2019-04-05 17:47   ` guroan
2019-04-05 17:47 ` [PATCH v10 6/9] kselftests: cgroup: add freezer controller self-tests Roman Gushchin
2019-04-05 17:47   ` Roman Gushchin
2019-04-05 17:47   ` guroan
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=20190419151912.GA12152@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 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.