linux-toradex.git/drivers/scsi/cxlflash, branch v4.9.95

scsi: cxlflash: Fix context reference tracking on detach

2016-09-14T16:47:42+00:00

Commit 888baf069f49 ("scsi: cxlflash: Add kref to context") introduced a
kref to the context. In particular, the detach routine was updated to
use the kref services for managing the removal and destruction of a
context.

As part of this change, the tracking mechanism internal to the detach
handler was refactored. This introduced a bug that can cause the
tracking state to be lost. This can lead to a situation where exclusive
access to a context is prematurely [and unknowingly] relinquished for
the executing thread.

To remedy, only update the tracking state when the kref operation
indicates the context was removed.

Fixes: 888baf069f49 ("scsi: cxlflash: Add kref to context")
Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Refactor WWPN setup

2016-09-14T16:47:03+00:00

Commit 964497b3bf3f ("cxlflash: Remove dual port online dependency")
logically removed the ability for the WWPN setup routine afu_set_wwpn()
to return a non-success value. This routine can safely be made a void to
simplify the code as there is no longer a need to report a failure.

Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Improve EEH recovery time

2016-09-14T16:46:20+00:00

When an EEH occurs during device initialization, the port timeout logic
can cause excessive delays as MMIO reads will fail. Depending on where
they are experienced, these delays can lead to a prolonged reset,
causing an unnecessary triggering of other timeout logic in the SCSI
stack or user applications.

To expedite recovery, the port timeout logic is updated to decay the
timeout at a much faster rate when in the presence of a likely EEH
frozen event.

Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Fix to avoid EEH and host reset collisions

2016-09-14T16:45:06+00:00

The EEH reset handler is ignorant to the current state of the driver
when processing a frozen event and initiating a device reset. This can
be an issue if an EEH event occurs while a user or stack initiated reset
is executing. More specifically, if an EEH occurs while the SCSI host
reset handler is active, the reset initiated by the EEH thread will
likely collide with the host reset thread. This can leave the device in
an inconsistent state, or worse, cause a system crash.

As a remedy, the EEH handler is updated to evaluate the device state and
take appropriate action (proceed, wait, or disconnect host). The host
reset handler is also updated to handle situations where an EEH occurred
during a host reset. In such situations, the host reset handler will
delay reporting back a success to give the EEH reset an opportunity to
complete.

Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Remove the device cleanly in the system shutdown path

2016-09-09T11:34:58+00:00

Commit 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards") was recently introduced to notify the AFU when a system is going
down. Due to the position of the cxlflash driver in the device stack,
cxlflash devices are _always_ removed during a reboot/shutdown. This can
lead to a crash if the cxlflash shutdown hook is invoked _after_ the
shutdown hook for the owning virtual PHB. Furthermore, the current
implementation of shutdown/remove hooks for cxlflash are not tolerant to
being invoked when the device is not enabled. This can also lead to a
crash in situations where the remove hook is invoked after the device
has been removed via the vPHBs shutdown hook. An example of this
scenario would be an EEH reset failure while a reboot/shutdown is in
progress.

To solve both problems, the shutdown hook for cxlflash is updated to
simply remove the device. This path already includes the AFU
notification and thus this solution will continue to perform the
original intent. At the same time, the remove hook is updated to protect
against being called when the device is not enabled.

Fixes: 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards")
Signed-off-by: Uma Krishnan 
Acked-by: Matthew R. Ochs 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Scan host only after the port is ready for I/O

2016-09-09T11:34:18+00:00

When a port link is established, the AFU sends a 'link up' interrupt.
After the link is up, corresponding initialization steps are performed
on the card. Following that, when the card is ready for I/O, the AFU
sends 'login succeeded' interrupt. Today, cxlflash invokes
scsi_scan_host() upon receipt of both interrupts.

SCSI commands sent to the port prior to the 'login succeeded' interrupt
will fail with 'port not available' error. This is not desirable.
Moreover, when async_scan is active for the host, subsequent scan calls
are terminated with error. Due to this, the scsi_scan_host() call
performed after 'login succeeded' interrupt could portentially return
error and the devices may not be scanned properly.

To avoid this problem, scsi_scan_host() should be called only after the
'login succeeded' interrupt.

Signed-off-by: Uma Krishnan 
Acked-by: Matthew R. Ochs 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Remove adapter file descriptor cache

2016-08-24T02:23:52+00:00

The adapter file descriptor was previously cached within the kernel for
a given context in order to support performing a close on behalf of an
application. This is no longer needed as applications are now required
to perform a close on the adapter file descriptor.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
Acked-by: Manoj N. Kumar 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Transition to application close model

2016-08-24T02:23:41+00:00

Caching the adapter file descriptor and performing a close on behalf of
an application is a poor design. This is due to the fact that once a
file descriptor in installed, it is free to be altered without the
knowledge of the cxlflash driver. This can lead to inconsistencies
between the application and kernel. Furthermore, the nature of the
former design is more exploitable and thus should be abandoned.

To support applications performing a close on the adapter file that is
associated with a context, a new flag is introduced to the user API to
indicate to applications that they are responsible for the close
following the cleanup (detach) of a context. The documentation is also
updated to reflect this change in behavior.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
Acked-by: Manoj N. Kumar 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Add kref to context

2016-08-19T02:41:36+00:00

Currently, context user references are tracked via the list of LUNs that
have attached to the context. While convenient, this is not intuitive
without a deep study of the code and is inconsistent with the existing
reference tracking patterns within the kernel. This design choice can
lead to future bug injection.

To improve code comprehension and better protect against future bugs,
add explicit reference counting to contexts and migrate the context
removal code to the kref release handler.

Inspired-by: Al Viro 
Signed-off-by: Matthew R. Ochs 
Acked-by: Manoj N. Kumar 
Signed-off-by: Martin K. Petersen

scsi: cxlflash: Cache owning adapter within context

2016-08-19T02:40:27+00:00

The context removal routine requires access to the owning adapter
structure to reset the context within the AFU as part of the tear down
sequence. In order to support kref adoption, the owning adapter must be
accessible from the release handler. As the kref framework only provides
the kref reference as the sole parameter, another means is needed to
derive the owning adapter.

As a remedy, the owning adapter reference is saved off within the
context during initialization.

Signed-off-by: Matthew R. Ochs 
Acked-by: Manoj N. Kumar 
Signed-off-by: Martin K. Petersen