[PATCH] nvmet_fc: prevent new io rqsts in possible isr completions
Sagi Grimberg
sagi at grimberg.me
Thu Mar 1 04:04:03 PST 2018
Hi James,
> When a bio completion calls back into the transport for a
> back-end io device, the request completion path can free
> the transport io job structure allowing it to be reused for
> other operations.
Is this true doe something that is not aborted?
> The transport has a defer_rcv queue which
> holds temporary cmd rcv ops while waitng for io job structures.
> when the job frees, if there's a cmd waiting, it is picked up
> and submitted for processing, which can call back out to the
> bio path if it's a read. Unfortunately, what is unknown is the
> context of the original bio done call, and it may be in a state
> (softirq) that is not compatible with submitting the new bio in
> the same calling sequence. This is especially true when using
> scsi back-end devices as scsi is in softirq when it makes the
> done call.
>
> Correct by scheduling the io to be started via workq rather
> than calling the start new io path inline to the original bio
> done path.
Isn't free_iod called for every rsp completion? Is triggering defer_work
unconditionally the optimal approach? In other words, won't that yield
extra overhead in the "normal" case?
More information about the Linux-nvme
mailing list