#
f90377ab |
| 20-Jul-2010 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: provide space for LLD after remote port structure
Add pre-zeroed space after the allocation for fc_rport_priv for use by the lower-level driver.
This is primarily for VN2VN FIP mode,
[SCSI] libfc: provide space for LLD after remote port structure
Add pre-zeroed space after the allocation for fc_rport_priv for use by the lower-level driver.
This is primarily for VN2VN FIP mode, but could be used in other ways someday.
The space required is specified in lport->rport_priv_size.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
42e90414 |
| 20-Jul-2010 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: convert rport lookup to be RCU safe
To allow LLD to do lookups on rports without grabbing a mutex, make them RCU-safe. The caller of lport->tt.rport_lookup will have the choice of hol
[SCSI] libfc: convert rport lookup to be RCU safe
To allow LLD to do lookups on rports without grabbing a mutex, make them RCU-safe. The caller of lport->tt.rport_lookup will have the choice of holding disc_mutex or the rcu_read_lock().
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.35-rc5, v2.6.35-rc4, v2.6.35-rc3 |
|
#
f034260d |
| 11-Jun-2010 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: fix indefinite rport restart
Remote ports were restarting indefinitely after getting rejects in PRLI.
Fix by adding a counter of restarts and limiting that with the port login retry l
[SCSI] libfc: fix indefinite rport restart
Remote ports were restarting indefinitely after getting rejects in PRLI.
Fix by adding a counter of restarts and limiting that with the port login retry limit as well.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
4b2164d4 |
| 11-Jun-2010 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: Fix remote port restart problem
This patch somewhat combines two fixes to remote port handing in libfc.
The first problem was that rport work could be queued on a deleted and freed rp
[SCSI] libfc: Fix remote port restart problem
This patch somewhat combines two fixes to remote port handing in libfc.
The first problem was that rport work could be queued on a deleted and freed rport. This is handled by not resetting rdata->event ton NONE if the rdata is about to be deleted.
However, that fix led to the second problem, described by Bhanu Gollapudi, as follows: > Here is the sequence of events. T1 is first LOGO receive thread, T2 is > fc_rport_work() scheduled by T1 and T3 is second LOGO receive thread and > T4 is fc_rport_work scheduled by T3. > > 1. (T1)Received 1st LOGO in state Ready > 2. (T1)Delete port & enter to RESTART state. > 3. (T1)schdule event_work, since event is RPORT_EV_NONE. > 4. (T1)set event = RPORT_EV_LOGO > 5. (T1)Enter RESTART state as disc_id is set. > 6. (T2)remember to PLOGI, and set event = RPORT_EV_NONE > 6. (T3)Received 2nd LOGO > 7. (T3)Delete Port & enter to RESTART state. > 8. (T3)schedule event_work, since event is RPORT_EV_NONE. > 9. (T3)Enter RESTART state as disc_id is set. > 9. (T3)set event = RPORT_EV_LOGO > 10.(T2)work restart, enter PLOGI state and issues PLOGI > 11.(T4)Since state is not RESTART anymore, restart is not set, and the > event is not reset to RPORT_EV_NONE. (current event is RPORT_EV_LOGO). > 12. Now, PLOGI succeeds and fc_rport_enter_ready() will not schedule > event_work, and hence the rport will never be created, eventually losing > the target after dev_loss_tmo.
So, the problem here is that we were tracking the desire for the rport be restarted by state RESTART, which was otherwise equivalent to DELETE. A contributing factor is that we dropped the lock between steps 6 and 10 in thread T2, which allows the state to change, and we didn't completely re-evaluate then.
This is hopefully corrected by the following minor redesign:
Simplify the rport restart logic by making the decision to restart after deleting the transport rport. That decision is based on a new STARTED flag that indicates fc_rport_login() has been called and fc_rport_logoff() has not been called since then. This replaces the need for the RESTART state.
Only restart if the rdata is still in DELETED state and only if it still has the STARTED flag set.
Also now, since we clear the event code much later in the work thread, allow for the possibility that the rport may have become READY again via incoming PLOGI, and if so, queue another event to handle that.
In the problem scenario, the second LOGO received will cause the LOGO event to occur again.
Reported-by: Bhanu Gollapudi <bprakash@broadcom.com> Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
f8fc6c2c |
| 11-Jun-2010 |
Bhanu Prakash Gollapudi <bprakash@broadcom.com> |
[SCSI] libfc: Handle unsolicited PRLO request
Resubmitting after incorporating Joe's review comment.
Unsolicited PRLO request is now handled by sending LS_ACC, and then relogin to the remote port i
[SCSI] libfc: Handle unsolicited PRLO request
Resubmitting after incorporating Joe's review comment.
Unsolicited PRLO request is now handled by sending LS_ACC, and then relogin to the remote port if an N-port login session exists for that remote port.
Note that this patch should be applied on top of Joe Eykholt's "Fix remote port restart problem" patch.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
618461c0 |
| 11-Jun-2010 |
Bhanu Prakash Gollapudi <bprakash@broadcom.com> |
[SCSI] libfc: Honor LS_ACC response codes for PRLI
As per FC-LS Rev 1.62 table 46, response codes are handled as follows:
1. If the Req executed is true, PRLI is accepted. 2. If Req executed is not
[SCSI] libfc: Honor LS_ACC response codes for PRLI
As per FC-LS Rev 1.62 table 46, response codes are handled as follows:
1. If the Req executed is true, PRLI is accepted. 2. If Req executed is not set, if resp code is 5, PRLI is not retried and port is logged out. 3. If resp code is anything apart from 1 or 5, PRLI is retired upto max retry count.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
292e40b9 |
| 11-Jun-2010 |
Bhanu Prakash Gollapudi <bprakash@broadcom.com> |
[SCSI] libfc: Retry a rejected PRLI request
Retry upto max_rport_retry_count when a target responds with LS_RJT for a PRLI request.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Si
[SCSI] libfc: Retry a rejected PRLI request
Retry upto max_rport_retry_count when a target responds with LS_RJT for a PRLI request.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
732bee7a |
| 11-Jun-2010 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
fix typos concerning "hierarchy"
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
Revision tags: v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3, v2.6.34-rc2 |
|
#
a2f6a024 |
| 12-Mar-2010 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: recode incoming PRLI handling
Reduce indentation in fc_rport_recv_prli_req() using gotos. Also add payload length checks.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by
[SCSI] libfc: recode incoming PRLI handling
Reduce indentation in fc_rport_recv_prli_req() using gotos. Also add payload length checks.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
5a0e3ad6 |
| 24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being included when bu
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files.
2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files.
3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
show more ...
|
Revision tags: v2.6.34-rc1, v2.6.33 |
|
#
5b7a381e |
| 16-Feb-2010 |
Hugh Daschbach <hdasch@broadcom.com> |
[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.
Both PLOGI and RTV response processing conditionally scale e_d_tov, but use different scaling factors. The scaling factor is cor
[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.
Both PLOGI and RTV response processing conditionally scale e_d_tov, but use different scaling factors. The scaling factor is correct in RTV response processing. Bring PLOGI e_d_tov scaling in line with RTV common service parameter inspection.
Signed-off-by: Hugh Daschbach <hdasch@broadcom.com> Acked-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.33-rc8, v2.6.33-rc7, v2.6.33-rc6, v2.6.33-rc5 |
|
#
3b709150 |
| 21-Jan-2010 |
Hugh Daschbach <hdasch@broadcom.com> |
[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.
Both PLOGI and RTV response processing conditionally scale e_d_tov, but use different scaling factors. The scaling factor is cor
[SCSI] libfc: Fix e_d_tov ns -> ms scaling factor in PLOGI response.
Both PLOGI and RTV response processing conditionally scale e_d_tov, but use different scaling factors. The scaling factor is correct in RTV response processing. Bring PLOGI e_d_tov scaling in line with RTV common service parameter inspection.
Signed-off-by: Hugh Daschbach <hdasch@broadcom.com> Acked-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.33-rc4, v2.6.33-rc3, v2.6.33-rc2, v2.6.33-rc1 |
|
#
5543c72e |
| 10-Dec-2009 |
Abhijeet Joglekar <abjoglek@cisco.com> |
[SCSI] libfc: remote port gets stuck in restart state without really restarting
We ran into a scenario where a remote port goes into RESTART state, but never gets added to scsi transport. The runnin
[SCSI] libfc: remote port gets stuck in restart state without really restarting
We ran into a scenario where a remote port goes into RESTART state, but never gets added to scsi transport. The running vmcore showed the following: a) Port was in RESTART state b) rdata->event was STOP c) no work gets scheduled for the remote work to fc_rport_work
After this point, shut/no-shut of the remote port did not cause the port to get re-discovered. The port would move betwen DELETE and RESTART states, but the event would always be STOP, no work would get scheduled to fc_rport_work and the port would not get added to scsi_transport.
The problem is that rdata->event is not set to NONE after a port is restarted. After this point, no more work gets scheduled for the remote port since new work is scheduled only if rdata->event is non-NONE. So, the event and state keep changing, but fc_rport_work does not get scheduled to actually handle the event.
Here's a transition of states that explains the above observation:
) Port is first in READY State, event is NONE
2) RSCN on shut, port goes to DELETED, event is stop
3) Before fc_rport_work runs, RSCN on no-shut, port goes to RESTART, event is still STOP
4) fc_rport_work gets scheduled, removes the port from transport, sees state as RESTART, begins the PLOGI state machine, event remains as STOP (event NOT changed to NONE, this is the bug)
5) Plogi state machine completes, port state goes to READY, event goes to READY, but no work is scheduled since event was STOP (non-NONE) before. Fc_rport_work is not scheduled, port remains in READY state, but is not added to transport.
Things are broken at this point. Libfc rport is ready, but no transport rport created.
6) now a shut causes port state to change to DELETE, event to change to STOP, no work gets scheduled
7) no-shut causes port state to change to RESTART, event remains at STOP, no work gets scheduled
(6) and (7) now get repeated everytime we do shut/no-shut. No way to get out of this state. Fcc reset does not help too.
Only way to get out is to load/unload module.
Fix is to set rdata->event to NONE while processing the STOP/LOGO/FAILED events, inside the discovery and rport locks.
Signed-off-by: Abhijeet Joglekar <abjoglek@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.32 |
|
#
63e27fb8 |
| 20-Nov-2009 |
Yi Zou <yi.zou@intel.com> |
[SCSI] libfc: add support of receiving ELS_RLS
Upon receiving ELS_RLS, send the Link Error Status Block (LESB) back.
Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.lo
[SCSI] libfc: add support of receiving ELS_RLS
Upon receiving ELS_RLS, send the Link Error Status Block (LESB) back.
Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.32-rc8, v2.6.32-rc7 |
|
#
b94f8951 |
| 03-Nov-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc fcoe: increase ELS and CT timeouts
The FC-LS spec. says ELS timeouts should be 2 x R_A_TOV. The FC-GS spec. says CT timeouts should be 3 x R_A_TOV.
We've been using E_D_TOV for both of
[SCSI] libfc fcoe: increase ELS and CT timeouts
The FC-LS spec. says ELS timeouts should be 2 x R_A_TOV. The FC-GS spec. says CT timeouts should be 3 x R_A_TOV.
We've been using E_D_TOV for both of those.
Change for all ELS and CT requests except FLOGI, which we leave at 2 seconds (using E_D_TOV). One could argue that R_A_TOV is locally determined until after FLOGI succeeds.
This does change FLOGI for vports which becomes FDISC. This does not change the REC/SRR timeout which is 2 seconds.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
3a3b42bf |
| 03-Nov-2009 |
Robert Love <robert.w.love@intel.com> |
[SCSI] libfc: Formatting cleanups across libfc
This patch makes a variety of cleanup changes to all libfc files.
This patch adds kernel-doc headers to all functions lacking them and attempts to bet
[SCSI] libfc: Formatting cleanups across libfc
This patch makes a variety of cleanup changes to all libfc files.
This patch adds kernel-doc headers to all functions lacking them and attempts to better format existing headers. It also add kernel-doc headers to structures.
This patch ensures that the current naming conventions for local ports, remote ports and remote port private data is upheld in the following manner.
struct instance (i.e. variable name) -------------------------------------------------- fc_lport lport fc_rport rport fc_rport_libfc_priv rpriv fc_rport_priv rdata
I also renamed dns_rp and ptp_rp to dns_rdata and ptp_rdata respectively.
I used emacs 'indent-region' and 'tabify' on all libfc files to correct spacing alignments.
I feel sorry for anyone attempting to review this patch.
Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
8866a5d9 |
| 03-Nov-2009 |
Robert Love <robert.w.love@intel.com> |
[SCSI] libfc: Add libfc/fc_libfc.[ch] for libfc internal routines
include/scsi/libfc.h is currently loaded with common code shared between libfc's sub-modules as well as shared between libfc and fco
[SCSI] libfc: Add libfc/fc_libfc.[ch] for libfc internal routines
include/scsi/libfc.h is currently loaded with common code shared between libfc's sub-modules as well as shared between libfc and fcoe. Previous patches attempted to move out non-common code. This patch creates two files for common libfc routines that will not be shared with fcoe, fnic or any other LLDs.
Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.32-rc6 |
|
#
b4a9c7ed |
| 21-Oct-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: fix free of fc_rport_priv with timer pending
Timer crashes were caused by freeing a struct fc_rport_priv with a timer pending, causing the timer facility list to be corrupted. This wa
[SCSI] libfc: fix free of fc_rport_priv with timer pending
Timer crashes were caused by freeing a struct fc_rport_priv with a timer pending, causing the timer facility list to be corrupted. This was during FC uplink flap tests with a lot of targets.
After discovery, we were doing an PLOGI on an rdata that was in DELETE state but not yet removed from the lookup list. This moved the rdata from DELETE state to PLOGI state. If the PLOGI exchange allocation failed and needed to be retried, the timer scheduling could race with the free being done by fc_rport_work().
When fc_rport_login() is called on a rport in DELETE state, move it to a new state RESTART. In fc_rport_work, when handling a LOGO, STOPPED or FAILED event, look for restart state. In the RESTART case, don't take the rdata off the list and after the transport remote port is deleted and exchanges are reset, re-login to the remote port.
Note that the new RESTART state also corrects a problem we had when re-discovering a port that had moved to DELETE state. In that case, a new rdata was created, but the old rdata would do an exchange manager reset affecting the FC_ID for both the new rdata and old rdata. With the new state, the new port isn't logged into until after any old exchanges are reset.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
8f550f93 |
| 21-Oct-2009 |
Chris Leech <christopher.leech@intel.com> |
[SCSI] libfc: fix memory corruption caused by double frees and bad error handling
I was running into several different panics under stress, which I traced down to a few different possible slab corru
[SCSI] libfc: fix memory corruption caused by double frees and bad error handling
I was running into several different panics under stress, which I traced down to a few different possible slab corruption issues in error handling paths. I have not yet looked into why these exchange sends fail, but with these fixes my test system is much more stable under stress than before.
fc_elsct_send() could fail and either leave the passed in frame intact (failure in fc_ct/els_fill) or the frame could have been freed if the failure was is fc_exch_seq_send(). The caller had no way of knowing, and there was a potential double free in the error handling in fc_fcp_rec().
Make fc_elsct_send() always free the frame before returning, and remove the fc_frame_free() call in fc_fcp_rec().
While fc_exch_seq_send() did always consume the frame, there were double free bugs in the error handling of fc_fcp_cmd_send() and fc_fcp_srr() as well.
Numerous calls to error handling routines (fc_disc_error(), fc_lport_error(), fc_rport_error_retry() ) were passing in a frame pointer that had already been freed in the case of an error. I have changed the call sites to pass in a NULL pointer, but there may be more appropriate error codes to use.
Question: Why do these error routines take a frame pointer anyway? I understand passing in a pointer encoded error to the response handlers, but the error routines take no action on a valid pointer and should never be called that way.
Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
473e2856 |
| 21-Oct-2009 |
Robert Love <robert.w.love@intel.com> |
[SCSI] libfc, fcoe: Don't EXPORT_SYMBOLS unnecessarily
These are a few functions that were not used by other modules. They did not need to be exported so this patch removes the EXPORT_SYMBOLS call f
[SCSI] libfc, fcoe: Don't EXPORT_SYMBOLS unnecessarily
These are a few functions that were not used by other modules. They did not need to be exported so this patch removes the EXPORT_SYMBOLS call for each.
Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
85b5893c |
| 21-Oct-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: fix typo in retry check on received PRLI
A received Fibre Channel ELS PRLI request contains a bit that indicates whether the remote port supports certain retry processing sequences. T
[SCSI] libfc: fix typo in retry check on received PRLI
A received Fibre Channel ELS PRLI request contains a bit that indicates whether the remote port supports certain retry processing sequences. The test for this bit was somehow coded to use multiply instead of AND!
This case would apply only for target mode operation, and it is unlikely to be noticed as an initiator.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
Revision tags: v2.6.32-rc5, v2.6.32-rc4, v2.6.32-rc3, v2.6.32-rc1, v2.6.32-rc2, v2.6.31, v2.6.31-rc9, v2.6.31-rc8 |
|
#
8abbe3a4 |
| 25-Aug-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: fix handling of incoming Discover Address (ADISC) requests
The local port facility has been replying to ADISC requests without looking to see if the remote port is logged in. This is
[SCSI] libfc: fix handling of incoming Discover Address (ADISC) requests
The local port facility has been replying to ADISC requests without looking to see if the remote port is logged in. This is incorrect. An ADISC request requires PLOGI first. It should be rejected if the sending remote port is not logged in.
This is like other incoming requests that require login, all of which should be handled in the remote port module.
Move the ADISC request handling from fc_lport.c to fc_rport.c.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
370c3bd0 |
| 25-Aug-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: use ADISC to verify rport login state
When rport_login is called on an rport that is already thought to be logged in, use ADISC. If that fails, redo PLOGI. This is less disruptive aft
[SCSI] libfc: use ADISC to verify rport login state
When rport_login is called on an rport that is already thought to be logged in, use ADISC. If that fails, redo PLOGI. This is less disruptive after fabric changes that don't affect the state of the target.
Implement the sending of ADISC via fc_els_fill.
Add ADISC state to the rport state machine. This is entered from READY and returns to READY after successful completion. If it fails, the rport is either logged off and deleted or re-does PLOGI.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
68a1750b |
| 25-Aug-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: LOGO response code had extraeous enter_rtv
fc_rport_logo_resp() had a call to fc_rport_enter_rtv() if the LOGO was accepted. This must've been a copy/paste mistake, but it didn't matt
[SCSI] libfc: LOGO response code had extraeous enter_rtv
fc_rport_logo_resp() had a call to fc_rport_enter_rtv() if the LOGO was accepted. This must've been a copy/paste mistake, but it didn't matter since we don't stay in the LOGO state long enough to hit this code.
Change fc_rport_logo_resp() to just enter the delete state no matter what.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|
#
feab4ae7 |
| 25-Aug-2009 |
Joe Eykholt <jeykholt@cisco.com> |
[SCSI] libfc: re-login to remote ports that send us LOGO
After a quick link flap, a target was seen to send us a LOGO. Apparently, it saw an RSCN reporting that we had dropped out of the fabric afte
[SCSI] libfc: re-login to remote ports that send us LOGO
After a quick link flap, a target was seen to send us a LOGO. Apparently, it saw an RSCN reporting that we had dropped out of the fabric after we had logged back into it.
This is likely in larger fabrics (more than 2 FC switches) after a quick link flap at the initiator. Each link transition causes an port-specific RSCN to the target. After the link comes back up, the initiator successfully discovers and does a PLOGI to the target before the target sees the first RSCN reporting the initiator is gone, and it sends a LOGO. The target may see a subsequent RSCN saying the port is back, but probably wouldn't send a PLOGI and leaves it up to the initiator to re-login.
An RSCN can be delayed by the switches due to software layers but a PLOGI is forwarded in hardware causing the PLOGI to beat the RSCN.
If a remote port is in the discovered set and sends a LOGO, re-login to it.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
show more ...
|