netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan O'Sullivan <bos@pathscale.com>
To: Steve Wise <swise@opengridcomputing.com>
Cc: rdreier@cisco.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [openib-general] [PATCH  04/13] Connection Manager
Date: Fri, 17 Nov 2006 10:07:52 -0800	[thread overview]
Message-ID: <455DFA78.9090401@pathscale.com> (raw)
In-Reply-To: <20061116035847.22635.87333.stgit@dell3.ogc.int>

Steve Wise wrote:

> +static void release_tid(struct t3cdev *tdev, u32 hwtid, struct sk_buff *skb)
> +{
> +	struct cpl_tid_release *req;
> +
> +	skb = get_skb(skb, sizeof *req, GFP_KERNEL);
> +	if (!skb) {
> +		return;
> +	}

Style micronit: no curlies for single-statement blocks.

> +void __free_ep(struct iwch_ep_common *epc)
> +{
> +	PDBG("%s ep %p, &refcnt %p state %s, refcnt %d\n",
> +	     __FUNCTION__, epc, &epc->refcnt,
> +	     states[state_read(epc)], atomic_read(&epc->refcnt));
> +
> +	if (atomic_read(&epc->refcnt) == 1) {
> +		goto out;
> +	}
> +	if (!atomic_dec_and_test(&epc->refcnt)) {
> +		return;
> +	}
> +out:
> +	PDBG("free ep %p\n", epc);
> +	kfree(epc);
> +}

Whatever you're trying to do with refcounting and atomics here looks 
extremely dodgy and race-prone to me.  Why are you using atomic ops in 
such a scary manner, instead of just slapping a spinlock around this?

Anyway, please drop this atomic refcounting stuff and use embedded krefs 
instead.  You're tunnelling into a bug mine.

By the way, it would be more consistent with normal kernel naming 
conventions to name these refcount-diddling routines ep_get and ep_put, 
since __ep_free doesn't actually free an object unless it feels like it.

> +int __init iwch_cm_init(void)
> +{
> +	skb_queue_head_init(&rxq);
> +
> +	workq = create_singlethread_workqueue("iw_cxgb3");
> +	if (!workq)
> +		return -ENOMEM;
> +
> +	/*
> +	 * All upcalls from the T3 Core go to sched() to 
> +	 * schedule the processing on a work queue.
> +	 */
> +	t3c_handlers[CPL_ACT_ESTABLISH] = sched;
> +	t3c_handlers[CPL_ACT_OPEN_RPL] = sched;
> +	t3c_handlers[CPL_RX_DATA] = sched;
> +	t3c_handlers[CPL_TX_DMA_ACK] = sched;
> +	t3c_handlers[CPL_ABORT_RPL_RSS] = sched;
> +	t3c_handlers[CPL_ABORT_RPL] = sched;
> +	t3c_handlers[CPL_PASS_OPEN_RPL] = sched;
> +	t3c_handlers[CPL_CLOSE_LISTSRV_RPL] = sched;
> +	t3c_handlers[CPL_PASS_ACCEPT_REQ] = sched;
> +	t3c_handlers[CPL_PASS_ESTABLISH] = sched;
> +	t3c_handlers[CPL_PEER_CLOSE] = sched;
> +	t3c_handlers[CPL_CLOSE_CON_RPL] = sched;
> +	t3c_handlers[CPL_ABORT_REQ_RSS] = sched;
> +	t3c_handlers[CPL_RDMA_TERMINATE] = sched;
> +	t3c_handlers[CPL_RDMA_EC_STATUS] = sched;
> +
> +	/*
> +	 * These are the real handlers that are called from a 
> +	 * work queue.
> +	 */
> +	work_handlers[CPL_ACT_ESTABLISH] = act_establish;
> +	work_handlers[CPL_ACT_OPEN_RPL] = act_open_rpl;
> +	work_handlers[CPL_RX_DATA] = rx_data;
> +	work_handlers[CPL_TX_DMA_ACK] = tx_ack;
> +	work_handlers[CPL_ABORT_RPL_RSS] = abort_rpl;
> +	work_handlers[CPL_ABORT_RPL] = abort_rpl;
> +	work_handlers[CPL_PASS_OPEN_RPL] = pass_open_rpl;
> +	work_handlers[CPL_CLOSE_LISTSRV_RPL] = close_listsrv_rpl;
> +	work_handlers[CPL_PASS_ACCEPT_REQ] = pass_accept_req;
> +	work_handlers[CPL_PASS_ESTABLISH] = pass_establish;
> +	work_handlers[CPL_PEER_CLOSE] = peer_close;
> +	work_handlers[CPL_ABORT_REQ_RSS] = peer_abort;
> +	work_handlers[CPL_CLOSE_CON_RPL] = close_con_rpl;
> +	work_handlers[CPL_RDMA_TERMINATE] = terminate;
> +	work_handlers[CPL_RDMA_EC_STATUS] = ec_status;
> +	return 0;
> +}

This seems mighty peculiar.  Why aren't you keeping this stuff in 
structs, instead of faking up structs via arrays?

	<b

  reply	other threads:[~2006-11-17 18:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16  3:58 [PATCH 00/13] Chelsio T3 RDMA Driver Steve Wise
2006-11-16  3:58 ` [PATCH 01/13] Linux RDMA Core Changes Steve Wise
2006-11-16 19:41   ` Roland Dreier
2006-11-16  3:58 ` [PATCH 02/13] Device Discovery and ULLD Linkage Steve Wise
2006-11-17 17:53   ` [openib-general] " Bryan O'Sullivan
2006-11-17 17:59     ` Steve Wise
2006-11-16  3:58 ` [PATCH 03/13] Provider Methods and Data Structures Steve Wise
2006-11-16  3:58 ` [PATCH 04/13] Connection Manager Steve Wise
2006-11-17 18:07   ` Bryan O'Sullivan [this message]
2006-11-17 18:26     ` [openib-general] " Steve Wise
2006-11-16  3:58 ` [PATCH 05/13] Queue Pairs Steve Wise
2006-11-16  3:58 ` [PATCH 06/13] Completion Queues Steve Wise
2006-11-16  3:59 ` [PATCH 07/13] Async Event Handler Steve Wise
2006-11-16  3:59 ` [PATCH 08/13] Memory Registration Steve Wise
2006-11-16  3:59 ` [PATCH 09/13] Core WQE/CQE Types Steve Wise
2006-11-17  4:45   ` Roland Dreier
2006-11-17 17:02     ` Steve Wise
2006-11-17 18:19   ` [openib-general] " Bryan O'Sullivan
2006-11-17 18:32     ` Steve Wise
2006-11-17 18:45       ` Bryan O'Sullivan
2006-11-16  3:59 ` [PATCH 10/13] Core HAL Steve Wise
2006-11-16  3:59 ` [PATCH 11/13] Core Resource Allocation Steve Wise
2006-11-17 16:54   ` Roland Dreier
2006-11-17 17:25     ` Steve Wise
2006-11-17 20:37       ` Roland Dreier
2006-11-16  3:59 ` [PATCH 12/13] Core Debug functions Steve Wise
2006-11-16  3:59 ` [PATCH 13/13] Kconfig/Makefile 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=455DFA78.9090401@pathscale.com \
    --to=bos@pathscale.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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).