From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: a.p.zijlstra@chello.nl, rjw@sisk.pl, pavel@ucw.cz,
len.brown@intel.com, mingo@elte.hu, akpm@linux-foundation.org,
suresh.b.siddha@intel.com, lucas.demarchi@profusion.mobi,
linux-pm@vger.kernel.org, rusty@rustcorp.com.au,
vatsa@linux.vnet.ibm.com, ashok.raj@intel.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
rdunlap@xenotime.net
Subject: Re: [PATCH v3 0/3] CPU hotplug, Freezer: Fix bugs in CPU hotplug call path
Date: Fri, 21 Oct 2011 21:09:54 +0530 [thread overview]
Message-ID: <4EA1924A.9060403@linux.vnet.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1110211038050.2131-100000@iolanthe.rowland.org>
Hi Alan,
On 10/21/2011 08:12 PM, Alan Stern wrote:
> On Fri, 21 Oct 2011, Srivatsa S. Bhat wrote:
>
>> When using the CPU hotplug infrastructure to offline/online CPUs, the cpu_up()
>> and cpu_down() functions are used, which internally call _cpu_up() and
>> _cpu_down() with the second argument *always* set to 0. The second argument
>> is "tasks_frozen", which should be correctly set to 1 when tasks have been
>> frozen, even when the freezing of tasks may be due to an event unrelated
>> to CPU hotplug, such as a suspend operation in progress, in which case the
>> freezer subsystem freezes all the freezable tasks.
>>
>> Not giving the correct value for the 'tasks_frozen' argument can potentially
>> lead to a lot of issues since this will send wrong notifications via the
>> notifier mechanism leading to the execution of inappropriate code by the
>> callbacks registered for the notifiers. That is, instead of CPU_ONLINE_FROZEN
>> and CPU_DEAD_FROZEN notifications, it results in CPU_ONLINE and CPU_DEAD
>> notifications to be sent all the time, irrespective of the actual state of
>> the system (i.e., whether tasks are frozen or not).
>>
>> This patch introduces a flag to indicate whether the tasks are frozen are not
>> (by any event) and modifies cpu_up() and cpu_down() functions to check the
>> value of this flag and accordingly call _cpu_up() and _cpu_down() respectively
>> by supplying the correct value as the second argument based on the state of
>> the system. This in turn means that the correct notifications are sent, thus
>> ensuring that all the registered callbacks do the right thing.
>
> That doesn't make any sense. If tasks were frozen then the task
> calling _cpu_up() or _cpu_down() would be frozen too, and therefore
> wouldn't be able to make the call.
>
I can't believe I missed such an obvious thing!
I must have been carried away while thinking about the race between freezer
and CPU hotplug. Thanks for pointing this out.
>> Additionally, to ensure that the tasks are not frozen or thawed by the freezer
>> subsystem while the registered callbacks are running, this patch adds a few
>> notifications in the freezer which is then hooked onto by the CPU hotplug
>> code, to avoid this race.
>
> That's more sensible. Freezing or thawing tasks isn't instantaneous.
> It's possible that _cpu_up() or _cpu_down() could be called while some
> tasks were frozen and others were still running.
>
> If you're careful to prevent this from happening then there's no reason
> to change the tasks_frozen argument. It should never be anything but
> 0 in this situation.
>
Agreed. So patch 1 becomes unnecessary. Patch 2 implements the needed
synchronization.
I'll fix the code (also incorporating your point that PM_POST_FREEZE and
PM_THAW_PREPARE are unnecessary) and repost.
Thank you for the review.
--
Regards,
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Linux Technology Center,
IBM India Systems and Technology Lab
prev parent reply other threads:[~2011-10-21 15:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-21 12:24 [PATCH v3 0/3] CPU hotplug, Freezer: Fix bugs in CPU hotplug call path Srivatsa S. Bhat
2011-10-21 12:24 ` [PATCH v3 1/3] CPU hotplug, Freezer: Don't hardcode 'tasks_frozen' argument in _cpu_*() Srivatsa S. Bhat
2011-10-21 12:25 ` [PATCH v3 2/3] CPU hotplug, Freezer: Synchronize CPU hotplug and freezer Srivatsa S. Bhat
2011-10-21 14:43 ` Alan Stern
2011-10-21 12:25 ` [PATCH v3 3/3] PM, Freezer, Docs: Update documentation about the new freezer notifiers Srivatsa S. Bhat
2011-10-21 14:42 ` [PATCH v3 0/3] CPU hotplug, Freezer: Fix bugs in CPU hotplug call path Alan Stern
2011-10-21 15:39 ` Srivatsa S. Bhat [this message]
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=4EA1924A.9060403@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=ashok.raj@intel.com \
--cc=len.brown@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lucas.demarchi@profusion.mobi \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=rdunlap@xenotime.net \
--cc=rjw@sisk.pl \
--cc=rusty@rustcorp.com.au \
--cc=stern@rowland.harvard.edu \
--cc=suresh.b.siddha@intel.com \
--cc=vatsa@linux.vnet.ibm.com \
/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.