Re: [PATCH v5] cxlflash: Base support for IBM CXL Flash Adapter

[Manoj Kumar <manoj@linux.vnet.ibm.com>]

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.