From: Tom Tucker <tom@opengridcomputing.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Steve Wise <swise@opengridcomputing.com>,
rdreier@cisco.com, mshefty@ichips.intel.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
openib-general@openib.org
Subject: Re: [PATCH v2 4/7] AMSO1100 Memory Management.
Date: Mon, 12 Jun 2006 11:05:49 -0500 [thread overview]
Message-ID: <1150128349.22704.20.camel@trinity.ogc.int> (raw)
In-Reply-To: <20060608011744.1a66e85a.akpm@osdl.org>
On Thu, 2006-06-08 at 01:17 -0700, Andrew Morton wrote:
> On Wed, 07 Jun 2006 15:06:55 -0500
> Steve Wise <swise@opengridcomputing.com> wrote:
>
> >
> > +void c2_free(struct c2_alloc *alloc, u32 obj)
> > +{
> > + spin_lock(&alloc->lock);
> > + clear_bit(obj, alloc->table);
> > + spin_unlock(&alloc->lock);
> > +}
>
> The spinlock is unneeded here.
Good point.
>
>
> What does all the code in this file do, anyway? It looks totally generic
> (and hence inappropriate for drivers/infiniband/hw/amso1100/) and somewhat
> similar to idr trees, perhaps.
>
We mimicked the mthca driver. It may be code that should be replaced
with Linux core services for new drivers. We'll investigate.
> > +int c2_array_set(struct c2_array *array, int index, void *value)
> > +{
> > + int p = (index * sizeof(void *)) >> PAGE_SHIFT;
> > +
> > + /* Allocate with GFP_ATOMIC because we'll be called with locks held. */
> > + if (!array->page_list[p].page)
> > + array->page_list[p].page =
> > + (void **) get_zeroed_page(GFP_ATOMIC);
> > +
> > + if (!array->page_list[p].page)
> > + return -ENOMEM;
>
> This _will_ happen under load. What will the result of that be, in the
> context of thise driver?
A higher level object allocation will fail. In this case, a kernel
application request will fail and the application must handle the error.
>
> This function is incorrectly designed - it should receive a gfp_t argument.
> Because you don't *know* that the caller will always hold a spinlock. And
> GFP_KERNEL is far, far stronger than GFP_ATOMIC.
This service is allocating a page that the adapter will DMA 2B message
indices into.
>
> > +static int c2_alloc_mqsp_chunk(gfp_t gfp_mask, struct sp_chunk **head)
> > +{
> > + int i;
> > + struct sp_chunk *new_head;
> > +
> > + new_head = (struct sp_chunk *) __get_free_page(gfp_mask | GFP_DMA);
>
> Why is __GFP_DMA in there? Unless you've cornered the ISA bus infiniband
> market, it's likely to be wrong.
>
Flag confusion about what GFP_DMA means. We'll revisit this whole
file ...
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-06-12 16:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-07 20:06 [PATCH v2 0/7][RFC] Ammasso 1100 iWARP Driver Steve Wise
2006-06-07 20:06 ` [PATCH v2 1/7] AMSO1100 Low Level Driver Steve Wise
2006-06-07 20:06 ` Steve Wise
2006-06-07 20:06 ` [PATCH v2 2/7] AMSO1100 WR / Event Definitions Steve Wise
2006-06-07 20:06 ` [PATCH v2 3/7] AMSO1100 OpenFabrics Provider Steve Wise
2006-06-07 20:06 ` [PATCH v2 4/7] AMSO1100 Memory Management Steve Wise
2006-06-07 20:06 ` Steve Wise
2006-06-08 8:17 ` Andrew Morton
2006-06-12 16:05 ` Tom Tucker [this message]
2006-06-16 14:20 ` Steve Wise
2006-06-17 3:59 ` Nick Piggin
2006-06-07 20:06 ` [PATCH v2 5/7] AMSO1100 Message Queues Steve Wise
2006-06-07 20:07 ` [PATCH v2 6/7] AMSO1100: Privileged Verbs Queues Steve Wise
2006-06-07 20:07 ` [PATCH v2 7/7] AMSO1100 Makefiles and Kconfig changes Steve Wise
2006-06-07 20:39 ` [PATCH v2 2/7] AMSO1100 WR / Event Definitions Steve Wise
2006-06-07 20:43 ` Roland Dreier
2006-06-07 20:59 ` Steve Wise
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=1150128349.22704.20.camel@trinity.ogc.int \
--to=tom@opengridcomputing.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshefty@ichips.intel.com \
--cc=netdev@vger.kernel.org \
--cc=openib-general@openib.org \
--cc=rdreier@cisco.com \
--cc=swise@opengridcomputing.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.