From: Nathan Lynch <ntl@pobox.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6 v5] Kernel DLPAR Infrastructure
Date: Wed, 28 Oct 2009 22:59:13 -0500 [thread overview]
Message-ID: <1256788753.6279.165.camel@localhost.localdomain> (raw)
In-Reply-To: <1256785731.26770.38.camel@pasglop>
On Thu, 2009-10-29 at 14:08 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-28 at 15:53 -0500, Nathan Fontenot wrote:
> > + struct device_node *dn;
> > + struct device_node *first_dn = NULL;
> > + struct device_node *last_dn = NULL;
> > + struct property *property;
> > + struct property *last_property = NULL;
> > + struct cc_workarea *ccwa;
> > + int cc_token;
> > + int rc;
> > +
> > + cc_token = rtas_token("ibm,configure-connector");
> > + if (cc_token == RTAS_UNKNOWN_SERVICE)
> > + return NULL;
> > +
> > + spin_lock(&workarea_lock);
> > +
> > + ccwa = (struct cc_workarea *)&workarea[0];
> > + ccwa->drc_index = drc_index;
> > + ccwa->zero = 0;
>
> Popping a free page with gfp (or just kmalloc'ing 4K) would avoid the
> need for the lock too.
Not kmalloc -- the alignment of the buffer isn't guaranteed when
slub/slab debug is on, and iirc the work area needs to be 4K-aligned.
__get_free_page should be fine, I think.
next prev parent reply other threads:[~2009-10-29 4:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-28 20:47 [PATCH 0/6 v5] Kernel handling of Dynamic Logical Partitioning Nathan Fontenot
2009-10-28 20:53 ` [PATCH 1/6 v5] Kernel DLPAR Infrastructure Nathan Fontenot
2009-10-29 3:08 ` Benjamin Herrenschmidt
2009-10-29 3:59 ` Nathan Lynch [this message]
2009-11-02 16:27 ` Nathan Fontenot
2009-11-02 16:40 ` Grant Likely
2009-11-02 16:47 ` Nathan Fontenot
2009-11-02 16:56 ` Grant Likely
2009-10-28 20:54 ` [PATCH 2/6 v5] Move of_drconf_cell to prom.h Nathan Fontenot
2009-10-28 20:55 ` [PATCH 3/6 v5] Memory probe/release files Nathan Fontenot
2009-10-29 3:13 ` Benjamin Herrenschmidt
2009-11-02 16:14 ` Nathan Fontenot
2009-10-28 20:57 ` [PATCH 4/6 v5] Memory DLPAR Handling Nathan Fontenot
2009-11-05 18:51 ` Roland Dreier
2009-10-28 20:58 ` [PATCH 5/6 v5] CPU probe/release files Nathan Fontenot
2009-10-29 3:25 ` Benjamin Herrenschmidt
2009-12-18 14:33 ` Andreas Schwab
2009-12-18 16:24 ` Nathan Fontenot
2009-12-18 17:29 ` Andreas Schwab
2009-12-19 8:46 ` Benjamin Herrenschmidt
2009-12-19 10:11 ` Andreas Schwab
2009-12-22 2:17 ` Nathan Fontenot
2009-10-28 20:59 ` [PATCH 6/6 v5] CPU DLPAR Handling Nathan Fontenot
2009-10-29 3:26 ` Benjamin Herrenschmidt
2009-11-02 16:15 ` 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=1256788753.6279.165.camel@localhost.localdomain \
--to=ntl@pobox.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.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).