On 6/9/2015 6:29 AM, Brian King wrote:
Pulled out going to sleep in the queuecommand path.
udelay doesn't sleep, its a busy wait, so you can still use it in queuecommand,
just don't spend too much time, and its probably better to udelay then to
just re-read in a tight loop.
Thanks for the clarification. Will update in the next patch (v6).
This was the optimization to avoid the MMIO for both threads. The other thread that raced should do the atomic set of afu->room to a positive value.
Let's take the simpler scenario of just one thread.
Let's start with afu->room = 1
We call atomic64_dec_if_positive, which results in afu->room going to zero and 0 being returned,
so we go into the if leg.
If afu->room is zero every time we read it from the adapter and we exhaust our retries,
we return SCSI_MLQUEUE_HOST_BUSY. However, the next time we enter cxlflash_send_cmd,
since afu->cmd is now 0, it will no longer get decremented, but the return value will
be -1, so we'll go down the else if leg. We'll never get into the if leg again to
re-read afu->room from the AFU. The simplest fix might just be to set afu->room = 1
if you ever leave the if leg without having room.
Good suggestion. Will atomic64_set(&afu->room, 1), if we exhaust retries
in both legs.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
