linux-toradex.git/drivers/scsi/libfc, branch v3.10.78

libfc: extend ex_lock to protect all of fc_seq_send

2013-05-10T17:19:23+00:00

This warning was reported recently:

WARNING: at drivers/scsi/libfc/fc_exch.c:478 fc_seq_send+0x14f/0x160 [libfc]()
(Not tainted)
Hardware name: ProLiant DL120 G7
Modules linked in: tcm_fc target_core_iblock target_core_file target_core_pscsi
target_core_mod configfs dm_round_robin dm_multipath 8021q garp stp llc bnx2fc
cnic uio fcoe libfcoe libfc scsi_transport_fc scsi_tgt autofs4 sunrpc
pcc_cpufreq ipv6 hpilo hpwdt e1000e microcode iTCO_wdt iTCO_vendor_support
serio_raw shpchp ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi
ata_generic ata_piix hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
scsi_wait_scan]
Pid: 5464, comm: target_completi Not tainted 2.6.32-272.el6.x86_64 #1
Call Trace:
 [] ? warn_slowpath_common+0x87/0xc0
 [] ? warn_slowpath_null+0x1a/0x20
 [] ? fc_seq_send+0x14f/0x160 [libfc]
 [] ? ft_queue_status+0x16e/0x210 [tcm_fc]
 [] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod]
 [] ? target_complete_ok_work+0x106/0x4b0 [target_core_mod]
 [] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod]
 [] ? worker_thread+0x170/0x2a0
 [] ? autoremove_wake_function+0x0/0x40
 [] ? worker_thread+0x0/0x2a0
 [] ? kthread+0x96/0xa0
 [] ? child_rip+0xa/0x20
 [] ? kthread+0x0/0xa0
 [] ? child_rip+0x0/0x20

It occurs because fc_seq_send can have multiple contexts executing within it at
the same time, and fc_seq_send doesn't consistently use the ep->ex_lock that
protects this structure.  Because of that, its possible for one context to clear
the INIT bit in the ep->esb_state field while another checks it, leading to the
above stack trace generated by the WARN_ON in the function.

We should probably undertake the effort to convert access to the fc_exch
structures to use rcu, but that a larger work item.  To just fix this specific
issue, we can just extend the ex_lock protection through the entire fc_seq_send
path

Signed-off-by: Neil Horman 
Reported-by: Gris Ge 
CC: Robert Love 
Signed-off-by: Robert Love

libfc: Correct check for initiator role

2013-05-10T17:19:22+00:00

The service_params field is being checked against the symbol
FC_RPORT_ROLE_FCP_INITIATOR where it really should be checked
against FCP_SPPF_INIT_FCN.

Signed-off-by: Mark Rustad 
Tested-by: Jack Morgan 
Signed-off-by: Robert Love

libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}

2013-03-25T23:03:03+00:00

Split discovery initialization in code that is setup once (fcoe_disc_init)
and code that can be re-configured (fcoe_disc_config).

Signed-off-by: Robert Love 
Tested-by: Jack Morgan 
Reviewed-by: Bhanu Prakash Gollapudi

libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery layer initialization

2013-03-25T23:01:10+00:00

Currently libfcoe is doing some libfc discovery layer initialization outside of
libfc. This patch moves this code into libfc and sets up a split in discovery
(one time) initialization code and (re-configurable) settings that will come in
the next patch.

Signed-off-by: Robert Love 
Tested-by: Jack Morgan 
Reviewed-by: Bhanu Prakash Gollapudi

libfc: XenServer fails to mount root filesystem.

2013-02-15T17:33:27+00:00

schedule_delayed_work() is using msec instead of jiffies. On PLOGI
reject from target, remote port retry is scheduled @ 20 sec instead
of 2sec(FC_DEF_E_D_TOV).
XenServer dom0 kernel is configured with CONFIG_HZ=100Hz

Signed-off-by: Krishna Mohan 
Signed-off-by: Robert Love

libfc, libfcoe, fcoe: Convert debug_logging macros to pr_info

2012-12-14T18:38:55+00:00

Convert libfc, libfcoe and fcoe's debug_logging macros
to use pr_info() instead of printk(KERN_INFO, ...). checkpatch.pl
now complains about this, so convert libfcoe to preferred
method.

Signed-off-by: Robert Love 
Tested-by: Marcus Dennis

libfc: fix REC handling

2012-12-04T18:16:38+00:00

Currently fc_fcp_timeout doesn't check FC_RP_FLAGS_REC_SUPPORTED
flag first, this prevents REC request ever going out at all
to the target having REC support. So this patches fixes the
fc_fcp_timeout by checking FC_RP_FLAGS_REC_SUPPORTED flag first.

The changed order won't cause any issue during clearing
FC_RP_FLAGS_REC_SUPPORTED on failed IO with target not supporting
FC_RP_FLAGS_REC_SUPPORTED, since retry on failed IO would succeed.

Signed-off-by: Vasu Dev 
Tested-by: Ross Brattain 
Signed-off-by: Robert Love

[SCSI] libfc: fix lun reset failure bugs in fc_fcp_resp handling of FCP_RSP_INFO

2012-10-07T10:52:55+00:00

In LUN RESET testing involving NetApp targets, it is observed that LUN
RESET is failing. The fc_fcp_resp() is not completing the completion
for the LUN RESET task since fc_fcp_resp assumes that the FCP_RSP_INFO
is 8 bytes with the 4 byte reserved field, where in case of NetApp targets
the FCP_RSP to LUN RESET only has 4 bytes of FCP_RSP_INFO. This leads
fc_fcp_resp to error out w/o completing the task completion, eventually
causing LUN RESET to be escalated to host reset, which is not very nice.

Per FCP-3 r04, clause 9.5.15 and Table 23, the FCP_RSP_INFO field can be either
4 bytes or 8 bytes, with the last 4 bytes as "Reserved (if any)". Therefore it
is valid to have 4 bytes FCP_RSP_INFO like some of the NetApp targets behave.
Fixing this by validating the FCP_RSP_INFO against both the two spec allowed
length.

Reported-by: Frank Zhang 
Signed-off-by: Yi Zou 
Tested-by: Ross Brattain 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: fix sending REC after FCP_RESP is received

2012-07-20T07:58:56+00:00

This is exposed in the case the FCP_DATA frames somehow got lost and fc_fcp got
the FCP_RSP, in fc_fcp_recv_resp(), since xfer_len is less than the expected_len
it resets the the timer to wait to 2 more jiffies in case the data frames are
already queued locally. However, for target does not support REC, it would just
send RJT w/ ELS_RJT_UNSUP. The rec response handler thus only clears the rport
flag for not doing REC later, but does not do fcp_io_complete() on the
associated fsp.

The fix is just check status of FCP_RSP being received already, i.e. using the
FC_SRB_RCV_STATUS flag, in fc_fcp_timeout before start sending REC. We should
have waited long enough if there is truely data frames queued locally.

Signed-off-by: Yi Zou 
Tested-by: Ross Brattain 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: fix retries with FDMI lport states

2012-07-20T07:58:56+00:00

The FC-GS-3 sepc requires to wait for least 3 times R_A_TOV per
sec 4.6.1 "If the Requesting_CT does not receive a Response
CT_IU from the Responding_CT within three times R_A_TOV,
it shall consider this to be a protocol error."

This means added four new states with management server
could add significant delay with multiple retries
on default 12 second timeout(3 * R_A_TOV), so instead
just skip these states on very first timeout on any of
these states to not stuck with states for such longer
period.

Signed-off-by: Vasu Dev 
Tested-by: Marcus Dennis 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley