• James Smart's avatar
    nvmet_fc: Rework target side abort handling · a97ec51b
    James Smart authored
    target transport:
    ----------------------
    There are cases when there is a need to abort in-progress target
    operations (writedata) so that controller termination or errors can
    clean up. That can't happen currently as the abort is another target
    op type, so it can't be used till the running one finishes (and it may
    not).  Solve by removing the abort op type and creating a separate
    downcall from the transport to the lldd to request an io to be aborted.
    
    The transport will abort ios on queue teardown or io errors. In general
    the transport tries to call the lldd abort only when the io state is
    idle. Meaning: ops that transmit data (readdata or rsp) will always
    finish their transmit (or the lldd will see a state on the
    link or initiator port that fails the transmit) and the done call for
    the operation will occur. The transport will wait for the op done
    upcall before calling the abort function, and as the io is idle, the
    io can be cleaned up immediately after the abort call; Similarly, ios
    that are not waiting for data or transmitting data must be in the nvmet
    layer being processed. The transport will wait for the nvmet layer
    completion before calling the abort function, and as the io is idle,
    the io can be cleaned up immediately after the abort call; As for ops
    that are waiting for data (writedata), they may be outstanding
    indefinitely if the lldd doesn't see a condition where the initiatior
    port or link is bad. In those cases, the transport will call the abort
    function and wait for the lldd's op done upcall for the operation, where
    it will then clean up the io.
    
    Additionally, if a lldd receives an ABTS and matches it to an outstanding
    request in the transport, A new new transport upcall was created to abort
    the outstanding request in the transport. The transport expects any
    outstanding op call (readdata or writedata) will completed by the lldd and
    the operation upcall made. The transport doesn't act on the reported
    abort (e.g. clean up the io) until an op done upcall occurs, a new op is
    attempted, or the nvmet layer completes the io processing.
    
    fcloop:
    ----------------------
    Updated to support the new target apis.
    On fcp io aborts from the initiator, the loopback context is updated to
    NULL out the half that has completed. The initiator side is immediately
    called after the abort request with an io completion (abort status).
    On fcp io aborts from the target, the io is stopped and the initiator side
    sees it as an aborted io. Target side ops, perhaps in progress while the
    initiator side is done, continue but noop the data movement as there's no
    structure on the initiator side to reference.
    
    patch also contains:
    ----------------------
    Revised lpfc to support the new abort api
    
    commonized rsp buffer syncing and nulling of private data based on
    calling paths.
    
    errors in op done calls don't take action on the fod. They're bad
    operations which implies the fod may be bad.
    Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
    Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
    a97ec51b
lpfc_nvmet.c 62.2 KB