From: Tejun Heo <tj@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: rjw@sisk.pl, linux-kernel@vger.kernel.org, lizefan@huawei.com,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/7] freezer: add missing mb's to freezer_count() and freezer_should_skip()
Date: Mon, 22 Oct 2012 17:13:17 -0400 [thread overview]
Message-ID: <20121022211317.GD5951@atj.dyndns.org> (raw)
In-Reply-To: <20121022174404.GA21553@redhat.com>
Hello, Oleg.
On Mon, Oct 22, 2012 at 07:44:04PM +0200, Oleg Nesterov wrote:
> > static inline void freezer_count(void)
> > {
> > current->flags &= ~PF_FREEZER_SKIP;
> > + /*
> > + * If freezing is in progress, the following paired with smp_mb()
> > + * in freezer_should_skip() ensures that either we see %true
> > + * freezing() or freezer_should_skip() sees !PF_FREEZER_SKIP.
> > + */
> > + smp_mb();
> > try_to_freeze();
>
> I agree, this looks like a bug fix.
Yeah, and this isn't dangerous at all. I'll ping -stable.
> > -static inline int freezer_should_skip(struct task_struct *p)
> > +static inline bool freezer_should_skip(struct task_struct *p)
> > {
> > - return !!(p->flags & PF_FREEZER_SKIP);
> > + /*
> > + * The following smp_mb() paired with the one in freezer_count()
> > + * ensures that either freezer_count() sees %true freezing() or we
> > + * see cleared %PF_FREEZER_SKIP and return %false. This makes it
> > + * impossible for a task to slip frozen state testing after
> > + * clearing %PF_FREEZER_SKIP.
> > + */
> > + smp_mb();
> > + return p->flags & PF_FREEZER_SKIP;
> > }
>
> I am not sure we really need smp_mb() here. Speaking of cgroup_freezer,
> it seems that a single mb() after "->state = CGROUP_FREEZING" should be
> enough.
Hmmm... I agree pairing there would work too.
> But even if I am right, I agree that it looks better in freezer_should_skip()
> and this is more robust.
But, yeah, performance implications at this level are almost
completely irrelavent here and I think pairing freezer_should_skip()
is easier to read.
> So I think the patch is fine and fixes the bug.
Awesome.
> We probably have another similar race. If ptrace_stop()->may_ptrace_stop()
> returns false, the task does
>
> __set_current_state(TASK_RUNNING);
> // no mb in between
> try_to_freeze();
>
> And this can race with task_is_stopped_or_traced() check in the same way.
> (of course this is only theoretical).
>
> do_signal_stop() is probably fine, we can rely on ->siglock.
Hmm.... Guess we should drop __ from set_current_state. I wonder
whether we should just add mb to freezing()? What do you think?
Thanks.
--
tejun
next prev parent reply other threads:[~2012-10-22 21:13 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 22:28 [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Tejun Heo
2012-10-16 22:28 ` [PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set Tejun Heo
2012-10-17 8:28 ` Li Zefan
2012-10-18 1:25 ` Li Zefan
2012-10-21 19:11 ` Oleg Nesterov
2012-10-21 19:22 ` Tejun Heo
2012-10-22 18:04 ` Oleg Nesterov
2012-10-22 21:16 ` Tejun Heo
2012-10-23 15:51 ` Oleg Nesterov
2012-10-24 19:04 ` Tejun Heo
2012-10-25 17:42 ` Oleg Nesterov
2012-12-20 5:25 ` Herton Ronaldo Krzesinski
2012-12-28 21:22 ` [PATCH] cgroup: remove unused dummy cgroup_fork_callbacks() Tejun Heo
2012-10-16 22:28 ` [PATCH 2/7] freezer: add missing mb's to freezer_count() and freezer_should_skip() Tejun Heo
2012-10-22 17:44 ` Oleg Nesterov
2012-10-22 21:13 ` Tejun Heo [this message]
2012-10-23 15:39 ` Oleg Nesterov
2012-10-24 18:57 ` Tejun Heo
2012-10-25 16:39 ` [PATCH 0/1] (Was: freezer: add missing mb's to freezer_count() and freezer_should_skip()) Oleg Nesterov
2012-10-25 16:39 ` [PATCH 1/1] freezer: change ptrace_stop/do_signal_stop to use freezable_schedule() Oleg Nesterov
2012-10-25 17:18 ` Tejun Heo
2012-10-25 17:34 ` Oleg Nesterov
2012-10-25 17:36 ` Tejun Heo
2012-10-26 17:45 ` [PATCH v2 0/1] " Oleg Nesterov
2012-10-26 17:46 ` [PATCH v2 1/1] " Oleg Nesterov
2012-10-26 17:52 ` Tejun Heo
2012-10-26 18:01 ` Oleg Nesterov
2012-10-26 21:14 ` Rafael J. Wysocki
2012-10-26 21:29 ` Rafael J. Wysocki
2012-10-26 21:29 ` Tejun Heo
2012-10-28 0:16 ` Rafael J. Wysocki
2012-10-27 22:22 ` Ben Hutchings
2012-10-28 13:45 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 3/7] cgroup_freezer: make it official that writes to freezer.state don't fail Tejun Heo
2012-10-16 22:28 ` [PATCH 4/7] cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks Tejun Heo
2012-10-22 18:34 ` Oleg Nesterov
2012-10-22 21:18 ` Tejun Heo
2012-10-23 15:55 ` Oleg Nesterov
2012-10-24 19:06 ` Tejun Heo
2012-10-25 17:12 ` [PATCH 0/1] (Was: cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks) Oleg Nesterov
2012-10-25 17:12 ` [PATCH 1/1] freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD Oleg Nesterov
2012-10-25 17:20 ` Tejun Heo
2012-10-25 17:37 ` Oleg Nesterov
2012-10-25 17:37 ` Tejun Heo
2012-10-25 20:13 ` Rafael J. Wysocki
2012-10-16 22:28 ` [PATCH 5/7] cgroup_freezer: allow moving tasks in and out of a frozen cgroup Tejun Heo
2012-10-22 19:25 ` Oleg Nesterov
2012-10-22 21:25 ` Tejun Heo
2012-10-23 16:14 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 6/7] cgroup_freezer: prepare update_if_frozen() for locking change Tejun Heo
2012-10-16 22:28 ` [PATCH 7/7] cgroup_freezer: don't use cgroup_lock_live_group() Tejun Heo
2012-10-17 19:16 ` [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Matt Helsley
2012-10-18 21:14 ` Tejun Heo
2012-10-18 22:21 ` Matt Helsley
2012-10-18 22:35 ` Tejun Heo
2012-10-18 23:47 ` Matt Helsley
2012-10-19 0:01 ` Tejun Heo
2012-10-19 1:29 ` Matt Helsley
2012-10-19 20:02 ` Tejun Heo
2012-10-19 16:54 ` Rafael J. Wysocki
2012-10-19 20:04 ` Tejun Heo
2012-10-21 19:18 ` Oleg Nesterov
2012-10-21 19:24 ` 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=20121022211317.GD5951@atj.dyndns.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=oleg@redhat.com \
--cc=rjw@sisk.pl \
--cc=stable@vger.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
Powered by JetHome