• James Smart's avatar
    nvme: expand nvmf_check_if_ready checks · bb06ec31
    James Smart authored
    The nvmf_check_if_ready() checks that were added are very simplistic.
    As such, the routine allows a lot of cases to fail ios during windows
    of reset or re-connection. In cases where there are not multi-path
    options present, the error goes back to the callee - the filesystem
    or application. Not good.
    
    The common routine was rewritten and calling syntax slightly expanded
    so that per-transport is_ready routines don't need to be present.
    The transports now call the routine directly. The routine is now a
    fabrics routine rather than an inline function.
    
    The routine now looks at controller state to decide the action to
    take. Some states mandate io failure. Others define the condition where
    a command can be accepted.  When the decision is unclear, a generic
    queue-or-reject check is made to look for failfast or multipath ios and
    only fails the io if it is so marked. Otherwise, the io will be queued
    and wait for the controller state to resolve.
    
    Admin commands issued via ioctl share a live admin queue with commands
    from the transport for controller init. The ioctls could be intermixed
    with the initialization commands. It's possible for the ioctl cmd to
    be issued prior to the controller being enabled. To block this, the
    ioctl admin commands need to be distinguished from admin commands used
    for controller init. Added a USERCMD nvme_req(req)->rq_flags bit to
    reflect this division and set it on ioctls requests.  As the
    nvmf_check_if_ready() routine is called prior to nvme_setup_cmd(),
    ensure that commands allocated by the ioctl path (actually anything
    in core.c) preps the nvme_req(req) before starting the io. This will
    preserve the USERCMD flag during execution and/or retry.
    Signed-off-by: default avatarJames Smart <james.smart@broadcom.com>
    Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.e>
    Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    bb06ec31
loop.c 18 KB