[v3,0/4] block/scsi/nvme: Add error codes for PR ops

Message

Mike Christie Nov. 22, 2022, 3:25 a.m. UTC

The following patches were made over Linus's tree and allow the PR/pr_ops
users to handle errors without having to know the device type and also
for SCSI handle devices that require the sense code. Currently, we return
a -Exyz type of error code if the PR call fails before the drivers can
send the command and a device specific error code if it's queued. The
problem is that the callers don't always know the device type so they
can't check for specific errors like reservation conflicts, or transport
errors or invalid operations.

These patches add common error codes which callers can check for.

v3:
- Rework nvme_sc_to_pr_err so it returns directly instead of using a
local variable. Also do the same for scsi's converter.

v2:
- Drop PR_STS_OP_NOT_SUPP and PR_STS_OP_INVALID.
- Drop dependence on scsi_exeucte patchset and include status_byte
patch in this patchset.
- Check for all nvme path errors with nvme_is_path_error.

Comments

Martin K. Petersen Nov. 26, 2022, 2:48 a.m. UTC | #1

Mike,

> The following patches were made over Linus's tree and allow the
> PR/pr_ops users to handle errors without having to know the device
> type and also for SCSI handle devices that require the sense
> code. Currently, we return a -Exyz type of error code if the PR call
> fails before the drivers can send the command and a device specific
> error code if it's queued. The problem is that the callers don't
> always know the device type so they can't check for specific errors
> like reservation conflicts, or transport errors or invalid operations.
>
> These patches add common error codes which callers can check for.

This looks OK to me. Not sure which tree makes the most sense to funnel
this through?

Acked-by: Martin K. Petersen <[e-mail]>

Chaitanya Kulkarni Nov. 29, 2022, 4:18 a.m. UTC | #2

On 11/25/22 18:48, Martin K. Petersen wrote:
> 
> Mike,
> 
>> The following patches were made over Linus's tree and allow the
>> PR/pr_ops users to handle errors without having to know the device
>> type and also for SCSI handle devices that require the sense
>> code. Currently, we return a -Exyz type of error code if the PR call
>> fails before the drivers can send the command and a device specific
>> error code if it's queued. The problem is that the callers don't
>> always know the device type so they can't check for specific errors
>> like reservation conflicts, or transport errors or invalid operations.
>>
>> These patches add common error codes which callers can check for.
> 
> This looks OK to me. Not sure which tree makes the most sense to funnel
> this through?
> 
> Acked-by: Martin K. Petersen <[e-mail]>
> 

perhaps a block tree since it has block/scsi/nvme ?

-ck

Christoph Hellwig Nov. 29, 2022, 1:28 p.m. UTC | #3

On Tue, Nov 29, 2022 at 04:18:19AM +0000, Chaitanya Kulkarni wrote:
> > Acked-by: Martin K. Petersen <[e-mail]>
> > 
> 
> perhaps a block tree since it has block/scsi/nvme ?

I think Mike has SCSI work that builds on top of this, and reservations
ar originally a SCSI feature.  But either block or scsi is fine with
me.

Jens Axboe Nov. 29, 2022, 2 p.m. UTC | #4

On 11/29/22 6:28 AM, [e-mail] wrote:
> On Tue, Nov 29, 2022 at 04:18:19AM +0000, Chaitanya Kulkarni wrote:
>>> Acked-by: Martin K. Petersen <[e-mail]>
>>>
>>
>> perhaps a block tree since it has block/scsi/nvme ?
> 
> I think Mike has SCSI work that builds on top of this, and reservations
> ar originally a SCSI feature.  But either block or scsi is fine with
> me.

I'm fine with scsi or block, I'm assuming we won't have any
conflicts from this on the block/nvme side?

If we're doing block just let me know and I can queue it up.

Mike Christie Nov. 29, 2022, 9:31 p.m. UTC | #5

On 11/29/22 8:00 AM, Jens Axboe wrote:
> On 11/29/22 6:28 AM, [e-mail] wrote:
>> On Tue, Nov 29, 2022 at 04:18:19AM +0000, Chaitanya Kulkarni wrote:
>>>> Acked-by: Martin K. Petersen <[e-mail]>
>>>>
>>>
>>> perhaps a block tree since it has block/scsi/nvme ?
>>
>> I think Mike has SCSI work that builds on top of this, and reservations
>> ar originally a SCSI feature.  But either block or scsi is fine with
>> me.
> 
> I'm fine with scsi or block, I'm assuming we won't have any
> conflicts from this on the block/nvme side?

This patchset has no conflicts with anyone's trees right now.

I have more patchsets that also touch the block, scsi and nvme
layers that build on this set. The future patches are more
heavy on the scsi side if that makes a difference.

> 
> If we're doing block just let me know and I can queue it up.
>

Martin K. Petersen Dec. 1, 2022, 3:28 a.m. UTC | #6

Mike,

> This patchset has no conflicts with anyone's trees right now.
>
> I have more patchsets that also touch the block, scsi and nvme
> layers that build on this set. The future patches are more
> heavy on the scsi side if that makes a difference.

OK. I merged this series into 6.2/scsi-staging. There really weren't any
non-SCSI changes except for the NVMe tweak.