> On Sep 25, 2015, at 4:10 PM, Brian King <brk...@linux.vnet.ibm.com> wrote:
> On 09/24/2015 02:42 PM, Matthew R. Ochs wrote:
>> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
>> index ab11ee6..325ba31 100644
>> --- a/drivers/scsi/cxlflash/main.c
>> +++ b/drivers/scsi/cxlflash/main.c
>> @@ -496,6 +496,7 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
>> struct scsi_cmnd *scp)
>> struct cxlflash_cfg *cfg = (struct cxlflash_cfg *)host->hostdata;
>> struct afu *afu = cfg->afu;
>> struct device *dev = &cfg->dev->dev;
>> + enum cxlflash_state state;
>> struct afu_cmd *cmd;
>> u32 port_sel = scp->device->channel + 1;
>> int nseg, i, ncount;
>> @@ -525,7 +526,11 @@ static int cxlflash_queuecommand(struct Scsi_Host
>> *host, struct scsi_cmnd *scp)
>> }
>> spin_unlock_irqrestore(&cfg->tmf_slock, lock_flags);
>>
>> - switch (cfg->state) {
>> + mutex_lock(&cfg->mutex);
>> + state = cfg->state;
>> + mutex_unlock(&cfg->mutex);
>
> You can't grab a mutex in queuecommand, since it can sleep and queuecommand
> can be called from soft irq context.
>
> Also, I'm not sure what to think about this patch in general. Obviously state
> can change immediately after
> you drop the mutex, and according to Documentation/memory-barriers.txt,
> memory operations after the unlock can
> occur before the unlock occurs. Is this a problem?
You bring up some good points.
I'm going to remove this patch from the set and rework it.
-matt
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
