From: James Smart <James.Smart@emulex.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Bart Van Assche <bvanassche@acm.org>,
Mike Christie <michaelc@cs.wisc.edu>,
"Bryn M. Reeves" <bmr@redhat.com>,
Steffen Maier <maier@linux.vnet.ibm.com>,
linux-scsi@vger.kernel.org, Chad Dupuis <chad.dupuis@qlogic.com>,
Andrew Vasquez <andrew.vasquez@qlogic.com>,
James Bottomley <jbottomley@parallels.com>
Subject: Re: [PATCH] scsi_transport_fc: Make 'port_state' writeable
Date: Fri, 5 Apr 2013 11:14:39 -0400 [thread overview]
Message-ID: <515EEA5F.3010709@emulex.com> (raw)
In-Reply-To: <515D1D2F.7050007@suse.de>
I understand your points. But you will need to contact the different LLD
maintainers to ensure receiving a devloss_tmo_callbk() on an rport they
had not called fc_remote_port_delete() for. I know there's work on my
side to validate it's ok. First glance was ok, but..
-- james s
On 4/4/2013 2:26 AM, Hannes Reinecke wrote:
> On 04/01/2013 11:06 PM, James Smart wrote:
>> I think lpfc survives your rport state change as : part of the lld
>> behavior on the callback, to clean up reference counts, is to abort
>> all i/o that is outstanding to the rport. So the ref checking not
>> only protects lpfc from prematurely freeing a structure (my real
>> concern), but also just happens to abort all i/o. We got lucky.
>>
>> I still believe the I_T_nexus reset is the right way to solve this.
>>
> Yes, but this would be an even more intrusive patch.
> And we would need to implement yet another callback into the LLDDs
> which need to be implemented there, too.
>
> But for this to make any sense we would need to revamp the scsi
> error handler, as the current problem is that error recovery takes
> too long. Adding yet another callback will make the escalation chain
> even longer.
>
> So yeah, in the long run I_T nexus reset is the correct way of doing
> things, but in the short term I would opt to make port_state
> writeable to simulate an I_T nexus reset.
>
> Cheers,
>
> Hannes
next prev parent reply other threads:[~2013-04-05 15:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 15:02 [PATCH] scsi_transport_fc: Make 'port_state' writeable Hannes Reinecke
2013-03-14 18:09 ` Steffen Maier
2013-03-15 11:55 ` Hannes Reinecke
2013-03-15 12:01 ` Bryn M. Reeves
2013-03-15 12:24 ` Bart Van Assche
2013-03-15 12:37 ` Bryn M. Reeves
2013-03-15 12:46 ` Bart Van Assche
2013-03-15 13:28 ` Bryn M. Reeves
2013-03-15 13:41 ` Bart Van Assche
2013-03-15 18:51 ` Mike Christie
2013-03-15 19:13 ` Bart Van Assche
2013-03-15 21:12 ` Mike Christie
2013-03-18 7:09 ` Hannes Reinecke
2013-04-01 21:06 ` James Smart
2013-04-04 6:26 ` Hannes Reinecke
2013-04-05 15:14 ` James Smart [this message]
2013-04-12 14:24 ` Chad Dupuis
2013-03-18 21:54 ` Jeremy Linton
2013-04-01 20:51 ` James Smart
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=515EEA5F.3010709@emulex.com \
--to=james.smart@emulex.com \
--cc=andrew.vasquez@qlogic.com \
--cc=bmr@redhat.com \
--cc=bvanassche@acm.org \
--cc=chad.dupuis@qlogic.com \
--cc=hare@suse.de \
--cc=jbottomley@parallels.com \
--cc=linux-scsi@vger.kernel.org \
--cc=maier@linux.vnet.ibm.com \
--cc=michaelc@cs.wisc.edu \
/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.