All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: Karen Xie <kxie@chelsio.com>
Cc: open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org,
	James.Bottomley@HansenPartnership.com
Subject: Re: [PATCH 2/2 2.6.29-rc] cxgb3i - add handling of chip reset
Date: Wed, 25 Feb 2009 11:21:52 -0600	[thread overview]
Message-ID: <49A57E30.7010001@cs.wisc.edu> (raw)
In-Reply-To: <200902250128.n1P1SJOD007746@localhost.localdomain>

Karen Xie wrote:
> [PATCH 2/2 2.6.29-rc] cxgb3i - add support of chip reset
> 
> From: Karen Xie <kxie@chelsio.com>
> 
> The cxgb3 driver would reset the chip due to an EEH event or a fatal error
> and notifies the upper layer modules (iscsi, rdma).
> Upon receiving the notification the cxgb3i driver would 
> - close all the iscsi tcp connections and mark the associated sessions as
>   failed due to connection error,
> - re-initialize its offload functions,
> - re-initialize the chip's ddp functions.
> 
> The iscsi error recovery mechanism will re-establish the tcp connection after
> reset. 
> 
> This patch requires the the following cxgb3 patch in the linux-next git tree
> (http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=cb0bc205959bf8c60acae9c71f3da0597e756f8e).
> 


>  
>  static inline int ddp_find_unused_entries(struct cxgb3i_ddp_info *ddp,
> @@ -439,14 +444,15 @@ EXPORT_SYMBOL_GPL(cxgb3i_ddp_tag_reserve);
>   * @tag: ddp tag
>   * ddp cleanup for a given ddp tag and release all the resources held
>   */
> -void cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32 tag)
> +int cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32 tag)
>  {
>  	struct cxgb3i_ddp_info *ddp = tdev->ulp_iscsi;
>  	u32 idx;
> +	int err = -EINVAL;
>  
>  	if (!ddp) {
>  		ddp_log_error("release ddp tag 0x%x, ddp NULL.\n", tag);
> -		return;
> +		return err;
>  	}
>  
>  	idx = (tag >> PPOD_IDX_SHIFT) & ddp->idx_mask;
> @@ -457,17 +463,26 @@ void cxgb3i_ddp_tag_release(struct t3cdev *tdev, u32 tag)
>  		if (!gl) {
>  			ddp_log_error("release ddp 0x%x, idx 0x%x, gl NULL.\n",
>  				      tag, idx);
> -			return;
> +			return err;
>  		}
>  		npods = (gl->nelem + PPOD_PAGES_MAX - 1) >> PPOD_PAGES_SHIFT;
> +		if (!npods) {
> +			ddp_log_error("release ddp 0x%x, 0x%x, gl elem %u.\n",
> +				      tag, idx, gl->nelem);
> +			return err;
> +		}
>  		ddp_log_debug("ddp tag 0x%x, release idx 0x%x, npods %u.\n",
>  			      tag, idx, npods);
> -		clear_ddp_map(ddp, idx, npods);
> +		if (clear_ddp_map(ddp, tag, idx, npods) == npods)
> +			err = 0;
>  		ddp_unmark_entries(ddp, idx, npods);
>  		cxgb3i_ddp_release_gl(gl, ddp->pdev);


If this fails, do we leak this memory?

When is ddp_release called? Would it be called to clean up in situati 
this could fail?


> +/**
> + * cxgb3i_adapter_remove - release all the resources held and cleanup any
> + *	h/w settings

The docbook comment for the function description should only be one 
line. I think you did this in some other places.


>  
> -void cxgb3i_conn_closing(struct s3_conn *c3cn)
> +void cxgb3i_conn_closing(struct s3_conn *c3cn, int error)
>  {
>  	struct iscsi_conn *conn;
>  
>  	read_lock(&c3cn->callback_lock);
>  	conn = c3cn->user_data;
> -	if (conn && c3cn->state != C3CN_STATE_ESTABLISHED)
> -		iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
> +	if (conn && c3cn->state != C3CN_STATE_ESTABLISHED) {
> +		if (error)
> +			iscsi_session_failure(conn->session,
> +						ISCSI_ERR_CONN_FAILED);
> +		else
> +			iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
> +	}
>  	read_unlock(&c3cn->callback_lock);


If you have a ref to the conn, you can just use iscsi_conn_failure here. 
I thought when you got the pci error event you were just going to use 
the host session iter and loop over the session and fail them.



  reply	other threads:[~2009-02-25 17:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-25  1:28 [PATCH 2/2 2.6.29-rc] cxgb3i - add handling of chip reset Karen Xie
2009-02-25 17:21 ` Mike Christie [this message]
2009-02-25 18:00   ` Karen Xie
2009-02-25 17:29 ` Mike Christie
2009-02-25 18:06   ` Karen Xie

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=49A57E30.7010001@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=kxie@chelsio.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=open-iscsi@googlegroups.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.