From: Oleg Nesterov <oleg@redhat.com>
To: Roman Gushchin <guro@fb.com>
Cc: Roman Gushchin <guroan@gmail.com>, Tejun Heo <tj@kernel.org>,
Kernel Team <Kernel-team@fb.com>,
"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v10 4/9] cgroup: cgroup v2 freezer
Date: Sat, 20 Apr 2019 12:58:38 +0200 [thread overview]
Message-ID: <20190420105838.GA17468@redhat.com> (raw)
In-Reply-To: <20190419165600.GC23357@tower.DHCP.thefacebook.com>
On 04/19, Roman Gushchin wrote:
>
> > > >
> > > > wake_up_interruptible() ?
> > >
> > > Wait_up_interruptible() is supposed to work with a workqueue,
> > > but here there is nothing like this. Probably, I didn't understand your idea.
> > > Can you, please, elaborate a bit more?
> >
> > Not sure I understand... We need to wake up the task if it sleeps in
> > do_freezer_trap(), right? do_freezer_trap() uses TASK_INTERRUPTIBLE, so
> > why can't wake_up_interruptible() == __wake_up(TASK_INTERRUPTIBLE) work?
>
> Right, but __wake_up is supposed to wake threads blocked on a waitqueue:
Ugh sorry ;) of course I meant wake_up_state(task, TASK_INTERRUPTIBLE).
> > > > > + 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.
> > >
> > > Why? I don't see any reasons why the task should remain in the frozen
> > > state after this point.
> >
> > But cgroup_leave_frozen(false) will equally clear ->frozen if !CGRP_FREEZE ?
> > OTOH, if CGRP_FREEZE is set again, why do we need to clear ->frozen?
>
> Hm, it might work too, but I'm not sure I like it more. IMO, the best option
> is to have a single cgroup_leave_frozen(true) in signal.c, it's just simpler.
> If a user changed the desired state of cgroup twice, there is no need to avoid
> state transitions. Or maybe I don't see it yet.
Then why do we need cgroup_leave_frozen(false) in wait_for_vfork_done() ? How
does it differ from get_signal() ?
If nothing else. Suppose that wait_for_vfork_done() calls leave(false) and this
races with freezer, CGRP_FREEZE is already set but JOBCTL_TRAP_FREEZE is not.
This sets TIF_SIGPENDING to ensure the task won't return to user mode, thus it
calls get_signal().
get_signal() doesn't see JOBCTL_TRAP_FREEZE, it notices ->frozen == T and does
cgroup_leave_frozen(true) which clears ->frozen.
Then the task calls dequeue_signal(), clears TIF_SIGPENDING and returns to user
mode?
Oleg.
next prev parent reply other threads:[~2019-04-20 10:58 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
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 [this message]
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=20190420105838.GA17468@redhat.com \
--to=oleg@redhat.com \
--cc=Kernel-team@fb.com \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=guroan@gmail.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.