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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome