From: Nathan Fontenot <nfont@austin.ibm.com>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org, Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH] Make cpu hotplug driver lock part of ppc_md
Date: Wed, 23 Dec 2009 08:48:54 -0600 [thread overview]
Message-ID: <4B322DD6.60801@austin.ibm.com> (raw)
In-Reply-To: <1261520982.17348.8.camel@concordia>
Michael Ellerman wrote:
> On Tue, 2009-12-22 at 08:45 -0600, Nathan Fontenot wrote:
>> The recently introduced cpu_hotplug_driver_lock used to serialize
>> cpu hotplug operations, namely for the pseries platform, causes a build
>> issue for other platforms. The base cpu hotplug code attempts
>> to take this lock, but it may not be needed for all platforms. This patch
>> moves the lock/unlock routines to be part of the ppc_md structure
>> so that platforms needing the lock can take it. This also makes the
>> previous cpu_hotplug_driver_lock, defined in pseries code, pseries specific.
>>
>> The past failure without this patch was seen when building pmac and may
>> be present in other platform builds. The error is included below for reference.
>>
>> drivers/built-in.o: In function `.store_online':
>> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
>> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
>> make: *** [.tmp_vmlinux1] Error 1
>
> Why does the pmac code /not/ need a lock? And would it be harmless if it
> was locked too?
The intention of the cpu_hotplug_driver_locks to add additional serialization
during cpu hotplug operations. For pseries this is used during DLPAR of cpu
operations so that cpu hotplug actions cannot be initiated whiloe a DLPAR
operation is in flight. For example, during DLPAR add we take the lock while
acquiring the cpu from firmware and updating the device tree with the new
cpu information, after which we hotplug add the cpu to the system.
There is nothing harmless about taking the lock on all platforms, I was just
trying to avoid taking the lock if the additional serialization is not needed.
>
> If so, you could just make the mutex available to all powerpc code, and
> rename it, and then we wouldn't need all this jiggery pokery just to
> take & release a lock.
I can make the lock available to all powerpc code and not go through the
ppc_md struct, it makes no difference to me personally. Of course this would
make all that fun pokery jiggery go away :)
-Nathan
next prev parent reply other threads:[~2009-12-23 14:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-22 14:45 [PATCH] Make cpu hotplug driver lock part of ppc_md Nathan Fontenot
2009-12-22 22:29 ` Michael Ellerman
2009-12-23 14:48 ` Nathan Fontenot [this message]
2009-12-23 22:29 ` Michael Ellerman
2010-01-12 2:23 ` Benjamin Herrenschmidt
2010-01-12 19:34 ` Nathan Fontenot
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=4B322DD6.60801@austin.ibm.com \
--to=nfont@austin.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
--cc=schwab@linux-m68k.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;
as well as URLs for NNTP newsgroup(s).