On 4/16/21 4:12 PM, Kashyap Desai wrote:
>>> + if (host_tag >= MPI3MR_HOSTTAG_DEVRMCMD_MIN &&
>>> + host_tag <= MPI3MR_HOSTTAG_DEVRMCMD_MAX) {
>>> + idx = host_tag - MPI3MR_HOSTTAG_DEVRMCMD_MIN;
>>> + return &mrioc->dev_rmhs_cmds[idx];
>>> + }
>>>
>>> return NULL;
>>> }
>>
>> Looks like this hunk is misdirected, and should be moved to the device
>> handling patch ...
>
> Hannes -
> I missed to reply to this thread. I have handled this in V2. I am
> planning to post V3 soon.
>
>>
>> Hmm. This looks a bit unfortunate.
>> You are reserving just one tag for task management commands, which is
>> okay for device and target reset (as there we're running in single-step
>> mode and will only ever need one tag), but it's certainly not okay for
>> task abort, which is issued in-line and as such can occur for _every_
>> command.
>>
>> So I guess you'll need to rethink you tag allocation strategy here.
>
> Agree with you Hannes. Currently we are looking for a stable interface and
> improvement in upcoming driver updates.
>
Alternatively you could drop task abort (in favour of doing a task set
abort/lun reset); that way your current tag allocation strategy would
work and we can think of command abort later.
Which will be even more of an issue once my patchset for private
commands in SCSI goes in (note to self: resend); there are other drivers
which will suffer from precisely this issue, too.
I'll be reviewing the other patches shortly.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions Germany GmbH, 90409 Nürnberg
GF: F. Imendörffer, HRB 36809 (AG Nürnberg)
