linux-toradex.git/drivers/scsi/libfc, branch v2.6.32.2

[SCSI] libfc: don't swap OX_ID and RX_ID when sending BA_RJT

2009-09-10T17:08:03+00:00

I saw an lport debug message from the exchange manager saying:
"lport  70500: Received response for out of range oxid:ffff"

A trace showed this was a BA_RJT sent due to an incoming ABTS
which arrived on an unknown exchange.  So, the sender of the
BA_RJT was in error, but in this case, both the initiator and
responder were the same machine.

The OX_ID and RX_ID should not have been reversed in this case.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: send GPN_ID in reaction to single-port RSCNs.

2009-09-10T17:08:03+00:00

When an RSCN indicates changes to individual remote ports,
don't blindly log them out and then back in.  Instead, determine
whether they're still in the directory, by doing GPN_ID.

If that is successful, call login, which will send ADISC and reverify,
otherwise, call logoff.  Perhaps we should just delete the rport,
not send LOGO, but it seems safer.

Also, fix a possible issue where if a mix of records in the RSCN
cause us to queue disc_ports for disc_single and then we decide
to do full rediscovery, we leak memory for those disc_ports queued.

So, go through the list of disc_ports even if doing full discovery.
Free the disc_ports in any case.  If any of the disc_single() calls
return error, do a full discovery.

The ability to fill in GPN_ID requests was added to fc_ct_fill().
For this, it needs the FC_ID to be passed in as an arg.
The did parameter for fc_elsct_send() is used for that, since the
actual D_DID will always be 0xfffffc for all CT requests so far.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: fix handling of incoming Discover Address (ADISC) requests

2009-09-10T17:08:02+00:00

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 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: use ADISC to verify rport login state

2009-09-10T17:08:02+00:00

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 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: LOGO response code had extraeous enter_rtv

2009-09-10T17:08:01+00:00

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 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: re-login to remote ports that send us LOGO

2009-09-10T17:08:01+00:00

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 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: fix rport error handling for login-required and invalid ops

2009-09-10T17:08:00+00:00

When receiving an ELS request, if the request isn't recognized,
the unsupported operation error should be given even if the port
is not found or not logged in.

Also, the LOGO request shouldn't give the login-required explanation.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: correctly handle incoming PLOGI request.

2009-09-10T17:08:00+00:00

libfc receives PLOGIs from switches which are trying to discover what
kind of devices are present, and from other initiators to find out
if we're a target.

As an initiator, some argue we don't need to handle incoming PLOGI
requests, and we currently reject them from unknown remote ports,
but accept them is we're in the middle of a PLOGI to the remote port.

For eventual target implementations, we want to handle them always.

For incoming PLOGI, don't fail if the rport_priv doesn't exist.
Just create it and go become READY without going through PRLI.  If
PRLI occurs, then our roles will be set and we'll become READY again.

Also, allow incoming PRLI in RTV state.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: improve debug messages for ELS response handlers

2009-09-10T17:07:59+00:00

Improve lport and rport debug messages to indicate whether
the response is LS_ACC, LS_RJT, closed, or timeout.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley

[SCSI] libfc: fix: rport_recv_req needs disc_mutex when calling rport_lookup

2009-09-10T17:07:59+00:00

The rport_lookup function must be called while holding the disc_mutex.
Otherwise, the rdata could be deleted just after that by another thread.

All callers now check the state after grabbing the rdata rp_mutex.
Even though rport_lookup skips ports in DELETE state, it does that
without holding the rdata rp_mutex, so that the state may change.

Signed-off-by: Joe Eykholt 
Signed-off-by: Robert Love 
Signed-off-by: James Bottomley