[PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

When servicing the GETDEVICEINFO call from an NFS client, the NFS server
creates a SCSI persistent reservation on the target device using the
reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
device access so that only hosts registered with a reservation key can
perform read or write operations. Any unregistered initiator is completely
blocked, including standard SCSI commands such as READCAPACITY.

As a result, if an NFS client reboots or a new client attempts to
access the device, its SCSI driver issues a READCAPACITY command before
registering a key. This command fails with a Reservation Conflict error
since the initiator is not yet registered. Consequently, the client
detects the SCSI device size as zero.

When it subsequently receives a LAYOUTGET reply, it finds the device
openable but with a size of zero, so it falls back to performing I/O
through the MDS instead of directly accessing the block device.

To resolve this, the patch changes the persistent reservation type from
PR_EXCLUSIVE_ACCESS_REG_ONLY to PR_WRITE_EXCLUSIVE_REG_ONLY. With this
reservation type, registered initiators retain full read and write access,
but unregistered initiators are now permitted to issue read commands
(including READCAPACITY) while still being blocked from write operations.

Allowing unregistered reads prevents reservation conflicts on READCAPACITY,
ensuring the device size can be properly discovered by clients. This
enables direct I/O to the SCSI block device after client reboot or new
client addition, rather than unnecessarily reverting to the MDS.

Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
---
 fs/nfsd/blocklayout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/blocklayout.c b/fs/nfsd/blocklayout.c
index fde5539cf6a6..ab7903d584a6 100644
--- a/fs/nfsd/blocklayout.c
+++ b/fs/nfsd/blocklayout.c
@@ -291,7 +291,7 @@ nfsd4_block_get_device_info_scsi(struct super_block *sb,
 	}
 
 	ret = ops->pr_reserve(sb->s_bdev, NFSD_MDS_PR_KEY,
-			PR_EXCLUSIVE_ACCESS_REG_ONLY, 0);
+			PR_WRITE_EXCLUSIVE_REG_ONLY, 0);
 	if (ret) {
 		pr_err("pNFS: failed to reserve device %s.\n",
 			sb->s_id);
-- 
2.47.3

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Benjamin Coddington]

Hi Dai,

On 30 Sep 2025, at 12:28, Dai Ngo wrote:

> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
> creates a SCSI persistent reservation on the target device using the
> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
> device access so that only hosts registered with a reservation key can
> perform read or write operations. Any unregistered initiator is completely
> blocked, including standard SCSI commands such as READCAPACITY.

SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
nexus, no matter the state of the reservation on the LU.

Is it possible that your SCSI implementation might be out of the spec?  Also
possible that SBC-4 has been updated, I haven't been following the SCSI
specification updates..

Ben

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

Hi Ben,

On 9/30/25 12:15 PM, Benjamin Coddington wrote:
> Hi Dai,
>
> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>
>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>> creates a SCSI persistent reservation on the target device using the
>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>> device access so that only hosts registered with a reservation key can
>> perform read or write operations. Any unregistered initiator is completely
>> blocked, including standard SCSI commands such as READCAPACITY.
> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
> nexus, no matter the state of the reservation on the LU.
>
> Is it possible that your SCSI implementation might be out of the spec?  Also
> possible that SBC-4 has been updated, I haven't been following the SCSI
> specification updates..
>
> Ben

I don't have access to SBC-4 spec, t10.org does not allow guest access
to their docs. Can you please share the content of table 13 here?

I found the "SCSI Commands Reference Manual" from Seagate. Below is
a description of the reservation type, apologize for the format due to
copy & paste from the doc. Based on this table, code 6h (Exclusive
Access - Registrant only) seems to state media-access commands (I assume
READ_CAPACITY is included) are only allowed for registered I_T nexuses.

I'll continue to research for the official definition of the Reservation
type.

Thanks,
-Dai



----------------------------------------------------------------------------------------------------------


Table 82 Persistent reservation type codes


Code Name Description

0h Obsolete


1h

Write

Exclusive

Access Restrictions: Some commands (e.g., media-access write commands) 
are only

allowed for the persistent reservation holder (see SPC-5).

Persistent Reservation Holder: There is only one persistent reservation 
holder.


2h Obsolete


3h

Exclusive

Access

Access Restrictions: Some commands (e.g., media-access commands) are 
only allowed for

the persistent reservation holder (see SPC-5).

Persistent Reservation Holder: There is only one persistent reservation 
holder.


4h Obsolete


5h

Write Exclusive –

Registrants

Only

Access Restrictions: Some commands (e.g., media-access write commands) 
are only

allowed for registered I_T nexuses.

Persistent Reservation Holder: There is only one persistent reservation 
holder (see SPC-5).


6h

Exclusive Access –

Registrants

Only

Access Restrictions: Some commands (e.g., media-access commands) are 
only allowed for

registered I_T nexuses.

Persistent Reservation Holder: There is only one persistent reservation 
holder (see SPC-5).


7h

Write Exclusive –

All

Registrants

Access Restrictions: Some commands (e.g., media-access write commands) 
are only

allowed for registered I_T nexuses.

Persistent Reservation Holder: Each registered I_T nexus is a persistent 
reservation holder

(see SPC-5).


8h

Exclusive Access –

All

Registrants

Access Restrictions: Some commands (e.g., media-access commands) are 
only allowed for

registered I_T nexuses.

Persistent Reservation Holder: Each registered I_T nexus is a persistent 
reservation holder

(see SPC-5).


9h - Fh Reserved

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Benjamin Coddington]

On 30 Sep 2025, at 17:41, Dai Ngo wrote:

> Hi Ben,
>
> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>> Hi Dai,
>>
>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>
>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>> creates a SCSI persistent reservation on the target device using the
>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>> device access so that only hosts registered with a reservation key can
>>> perform read or write operations. Any unregistered initiator is completely
>>> blocked, including standard SCSI commands such as READCAPACITY.
>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>> nexus, no matter the state of the reservation on the LU.
>>
>> Is it possible that your SCSI implementation might be out of the spec?  Also
>> possible that SBC-4 has been updated, I haven't been following the SCSI
>> specification updates..
>>
>> Ben
>
> I don't have access to SBC-4 spec, t10.org does not allow guest access
> to their docs. Can you please share the content of table 13 here?

The document's licensing prohibits me from doing this, I'm sorry to report.
I have a single-user copy that prohibits me from copying or transmitting any
part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:

https://webstore.ansi.org/standards/incits/incits5712025

The reason your patch caught my eye was because we'd previously fixed the
same problem in the SCSI LIO target.

Ben

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

On 10/1/25 3:54 AM, Benjamin Coddington wrote:
> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>
>> Hi Ben,
>>
>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>> Hi Dai,
>>>
>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>
>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>>> creates a SCSI persistent reservation on the target device using the
>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>> device access so that only hosts registered with a reservation key can
>>>> perform read or write operations. Any unregistered initiator is completely
>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>>> nexus, no matter the state of the reservation on the LU.
>>>
>>> Is it possible that your SCSI implementation might be out of the spec?  Also
>>> possible that SBC-4 has been updated, I haven't been following the SCSI
>>> specification updates..
>>>
>>> Ben
>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>> to their docs. Can you please share the content of table 13 here?
> The document's licensing prohibits me from doing this, I'm sorry to report.
> I have a single-user copy that prohibits me from copying or transmitting any
> part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:
>
> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$
>
> The reason your patch caught my eye was because we'd previously fixed the
> same problem in the SCSI LIO target.

Thank you Ben, I'll get the spec from the ANSI webstore.

-Dai

>
> Ben
>

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Christoph Hellwig]

On Wed, Oct 01, 2025 at 10:36:47AM -0700, Dai Ngo wrote:
> Thank you Ben, I'll get the spec from the ANSI webstore.

You can also downloaded the last draft form t10.org, which is always
technical identication, but does not have the official blessing.

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

On 10/2/25 11:45 PM, Christoph Hellwig wrote:
> On Wed, Oct 01, 2025 at 10:36:47AM -0700, Dai Ngo wrote:
>> Thank you Ben, I'll get the spec from the ANSI webstore.
> You can also downloaded the last draft form t10.org, which is always
> technical identication, but does not have the official blessing.

Thank you, Mike! A colleague has shared all of the SCSI specifications with me.

-Dai

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

On 10/1/25 10:36 AM, Dai Ngo wrote:
>
> On 10/1/25 3:54 AM, Benjamin Coddington wrote:
>> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>>
>>> Hi Ben,
>>>
>>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>>> Hi Dai,
>>>>
>>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>>
>>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS 
>>>>> server
>>>>> creates a SCSI persistent reservation on the target device using the
>>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>>> device access so that only hosts registered with a reservation key 
>>>>> can
>>>>> perform read or write operations. Any unregistered initiator is 
>>>>> completely
>>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any 
>>>> I_T
>>>> nexus, no matter the state of the reservation on the LU.
>>>>
>>>> Is it possible that your SCSI implementation might be out of the 
>>>> spec?  Also
>>>> possible that SBC-4 has been updated, I haven't been following the 
>>>> SCSI
>>>> specification updates..
>>>>
>>>> Ben
>>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>>> to their docs. Can you please share the content of table 13 here?
>> The document's licensing prohibits me from doing this, I'm sorry to 
>> report.
>> I have a single-user copy that prohibits me from copying or 
>> transmitting any
>> part or whole.  Looks like you can get SBC-5 from the ANSI webstore 
>> for $60:
>>
>> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$ 
>>
>>
>> The reason your patch caught my eye was because we'd previously fixed 
>> the
>> same problem in the SCSI LIO target.
>
> Thank you Ben, I'll get the spec from the ANSI webstore.

You're right Ben! The SBC-4 spec says read capacity is allowed in this
case.

The problem was caused by the DS was running an older version of the
kernel that did not have your fix:

28c58f8a0947f scsi: target: Enable READ CAPACITY for PR EARO

This fix did not include the SERVICE_ACTION_IN_16 with Service Action
READ_CAPACITY. However, the Linux client tries SERVICE_ACTION_IN_16
three times then switches to READ CAPACITY (0x25).

Thank you for pointing this out.

-Dai

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Benjamin Coddington]

On 7 Oct 2025, at 11:59, Dai Ngo wrote:

> On 10/1/25 10:36 AM, Dai Ngo wrote:
>>
>> On 10/1/25 3:54 AM, Benjamin Coddington wrote:
>>> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>>>
>>>> Hi Ben,
>>>>
>>>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>>>> Hi Dai,
>>>>>
>>>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>>>
>>>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>>>>> creates a SCSI persistent reservation on the target device using the
>>>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>>>> device access so that only hosts registered with a reservation key can
>>>>>> perform read or write operations. Any unregistered initiator is completely
>>>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>>>>> nexus, no matter the state of the reservation on the LU.
>>>>>
>>>>> Is it possible that your SCSI implementation might be out of the spec?  Also
>>>>> possible that SBC-4 has been updated, I haven't been following the SCSI
>>>>> specification updates..
>>>>>
>>>>> Ben
>>>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>>>> to their docs. Can you please share the content of table 13 here?
>>> The document's licensing prohibits me from doing this, I'm sorry to report.
>>> I have a single-user copy that prohibits me from copying or transmitting any
>>> part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:
>>>
>>> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$
>>>
>>> The reason your patch caught my eye was because we'd previously fixed the
>>> same problem in the SCSI LIO target.
>>
>> Thank you Ben, I'll get the spec from the ANSI webstore.
>
> You're right Ben! The SBC-4 spec says read capacity is allowed in this
> case.
>
> The problem was caused by the DS was running an older version of the
> kernel that did not have your fix:
>
> 28c58f8a0947f scsi: target: Enable READ CAPACITY for PR EARO
>
> This fix did not include the SERVICE_ACTION_IN_16 with Service Action
> READ_CAPACITY. However, the Linux client tries SERVICE_ACTION_IN_16
> three times then switches to READ CAPACITY (0x25).
>
> Thank you for pointing this out.

Would you be willing to test this patch for SERVICE_ACTION_IN_16?

From d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f Mon Sep 17 00:00:00 2001
Message-ID: <d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f.1759869410.git.bcodding@redhat.com>
From: Benjamin Coddington <bcodding@redhat.com>
Date: Tue, 7 Oct 2025 16:34:37 -0400
Subject: [PATCH] scsi: target: Fixup two more cases for PR EARO

Allow READ_CAPACITY_16 and REPORT_REFERALS for SERVICE_ACTION_IN_16
in the SCSI target driver.

Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
---
 drivers/target/target_core_pr.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index 83e172c92238..0b6803754422 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -465,6 +465,13 @@ static int core_scsi3_pr_seq_non_holder(struct se_cmd *cmd, u32 pr_reg_type,
                        return -EINVAL;
                }
                break;
+       case SERVICE_ACTION_IN_16:
+               switch (cdb[1] & 0x1f) {
+               case SAI_READ_CAPACITY_16:
+               case SAI_REPORT_REFERRALS:
+                       ret = 0;
+               }
+               break;
        case ACCESS_CONTROL_IN:
        case ACCESS_CONTROL_OUT:
        case INQUIRY:
-- 
2.50.1

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

On 10/7/25 1:37 PM, Benjamin Coddington wrote:
> On 7 Oct 2025, at 11:59, Dai Ngo wrote:
>
>> On 10/1/25 10:36 AM, Dai Ngo wrote:
>>> On 10/1/25 3:54 AM, Benjamin Coddington wrote:
>>>> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>>>>
>>>>> Hi Ben,
>>>>>
>>>>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>>>>> Hi Dai,
>>>>>>
>>>>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>>>>
>>>>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>>>>>> creates a SCSI persistent reservation on the target device using the
>>>>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>>>>> device access so that only hosts registered with a reservation key can
>>>>>>> perform read or write operations. Any unregistered initiator is completely
>>>>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>>>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>>>>>> nexus, no matter the state of the reservation on the LU.
>>>>>>
>>>>>> Is it possible that your SCSI implementation might be out of the spec?  Also
>>>>>> possible that SBC-4 has been updated, I haven't been following the SCSI
>>>>>> specification updates..
>>>>>>
>>>>>> Ben
>>>>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>>>>> to their docs. Can you please share the content of table 13 here?
>>>> The document's licensing prohibits me from doing this, I'm sorry to report.
>>>> I have a single-user copy that prohibits me from copying or transmitting any
>>>> part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:
>>>>
>>>> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$
>>>>
>>>> The reason your patch caught my eye was because we'd previously fixed the
>>>> same problem in the SCSI LIO target.
>>> Thank you Ben, I'll get the spec from the ANSI webstore.
>> You're right Ben! The SBC-4 spec says read capacity is allowed in this
>> case.
>>
>> The problem was caused by the DS was running an older version of the
>> kernel that did not have your fix:
>>
>> 28c58f8a0947f scsi: target: Enable READ CAPACITY for PR EARO
>>
>> This fix did not include the SERVICE_ACTION_IN_16 with Service Action
>> READ_CAPACITY. However, the Linux client tries SERVICE_ACTION_IN_16
>> three times then switches to READ CAPACITY (0x25).
>>
>> Thank you for pointing this out.
> Would you be willing to test this patch for SERVICE_ACTION_IN_16?
>
>  From d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f Mon Sep 17 00:00:00 2001
> Message-ID: <d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f.1759869410.git.bcodding@redhat.com>
> From: Benjamin Coddington <bcodding@redhat.com>
> Date: Tue, 7 Oct 2025 16:34:37 -0400
> Subject: [PATCH] scsi: target: Fixup two more cases for PR EARO
>
> Allow READ_CAPACITY_16 and REPORT_REFERALS for SERVICE_ACTION_IN_16
> in the SCSI target driver.
>
> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
> ---
>   drivers/target/target_core_pr.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
> index 83e172c92238..0b6803754422 100644
> --- a/drivers/target/target_core_pr.c
> +++ b/drivers/target/target_core_pr.c
> @@ -465,6 +465,13 @@ static int core_scsi3_pr_seq_non_holder(struct se_cmd *cmd, u32 pr_reg_type,
>                          return -EINVAL;
>                  }
>                  break;
> +       case SERVICE_ACTION_IN_16:
> +               switch (cdb[1] & 0x1f) {
> +               case SAI_READ_CAPACITY_16:
> +               case SAI_REPORT_REFERRALS:
> +                       ret = 0;
> +               }
> +               break;
>          case ACCESS_CONTROL_IN:
>          case ACCESS_CONTROL_OUT:
>          case INQUIRY:

The patch worked fine for READ_CAPACITY_16.

The REPORT_REFERRALS got a Check Condition with sense code 0x2000
(Invalid command Operation code), whether there is a PR or not,
because the SCSI target does not support Referrals as reported by
'sg_vpd' command.

Thanks for doing this, Ben.

-Dai

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Benjamin Coddington]

On 9 Oct 2025, at 13:43, Dai Ngo wrote:

> On 10/7/25 1:37 PM, Benjamin Coddington wrote:
>> On 7 Oct 2025, at 11:59, Dai Ngo wrote:
>>
>>> On 10/1/25 10:36 AM, Dai Ngo wrote:
>>>> On 10/1/25 3:54 AM, Benjamin Coddington wrote:
>>>>> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>>>>>
>>>>>> Hi Ben,
>>>>>>
>>>>>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>>>>>> Hi Dai,
>>>>>>>
>>>>>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>>>>>
>>>>>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>>>>>>> creates a SCSI persistent reservation on the target device using the
>>>>>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>>>>>> device access so that only hosts registered with a reservation key can
>>>>>>>> perform read or write operations. Any unregistered initiator is completely
>>>>>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>>>>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>>>>>>> nexus, no matter the state of the reservation on the LU.
>>>>>>>
>>>>>>> Is it possible that your SCSI implementation might be out of the spec?  Also
>>>>>>> possible that SBC-4 has been updated, I haven't been following the SCSI
>>>>>>> specification updates..
>>>>>>>
>>>>>>> Ben
>>>>>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>>>>>> to their docs. Can you please share the content of table 13 here?
>>>>> The document's licensing prohibits me from doing this, I'm sorry to report.
>>>>> I have a single-user copy that prohibits me from copying or transmitting any
>>>>> part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:
>>>>>
>>>>> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$
>>>>>
>>>>> The reason your patch caught my eye was because we'd previously fixed the
>>>>> same problem in the SCSI LIO target.
>>>> Thank you Ben, I'll get the spec from the ANSI webstore.
>>> You're right Ben! The SBC-4 spec says read capacity is allowed in this
>>> case.
>>>
>>> The problem was caused by the DS was running an older version of the
>>> kernel that did not have your fix:
>>>
>>> 28c58f8a0947f scsi: target: Enable READ CAPACITY for PR EARO
>>>
>>> This fix did not include the SERVICE_ACTION_IN_16 with Service Action
>>> READ_CAPACITY. However, the Linux client tries SERVICE_ACTION_IN_16
>>> three times then switches to READ CAPACITY (0x25).
>>>
>>> Thank you for pointing this out.
>> Would you be willing to test this patch for SERVICE_ACTION_IN_16?
>>
>>  From d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f Mon Sep 17 00:00:00 2001
>> Message-ID: <d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f.1759869410.git.bcodding@redhat.com>
>> From: Benjamin Coddington <bcodding@redhat.com>
>> Date: Tue, 7 Oct 2025 16:34:37 -0400
>> Subject: [PATCH] scsi: target: Fixup two more cases for PR EARO
>>
>> Allow READ_CAPACITY_16 and REPORT_REFERALS for SERVICE_ACTION_IN_16
>> in the SCSI target driver.
>>
>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>> ---
>>   drivers/target/target_core_pr.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
>> index 83e172c92238..0b6803754422 100644
>> --- a/drivers/target/target_core_pr.c
>> +++ b/drivers/target/target_core_pr.c
>> @@ -465,6 +465,13 @@ static int core_scsi3_pr_seq_non_holder(struct se_cmd *cmd, u32 pr_reg_type,
>>                          return -EINVAL;
>>                  }
>>                  break;
>> +       case SERVICE_ACTION_IN_16:
>> +               switch (cdb[1] & 0x1f) {
>> +               case SAI_READ_CAPACITY_16:
>> +               case SAI_REPORT_REFERRALS:
>> +                       ret = 0;
>> +               }
>> +               break;
>>          case ACCESS_CONTROL_IN:
>>          case ACCESS_CONTROL_OUT:
>>          case INQUIRY:
>
> The patch worked fine for READ_CAPACITY_16.
>
> The REPORT_REFERRALS got a Check Condition with sense code 0x2000
> (Invalid command Operation code), whether there is a PR or not,
> because the SCSI target does not support Referrals as reported by
> 'sg_vpd' command.
>
> Thanks for doing this, Ben.
>
> -Dai

Thanks for the test.  I'll send this to the target list, and will add your
Tested-by unless you'd rather it withheld.

Ben

Re: [PATCH 1/1] NFSD: Fix SCSI reservation conflict causing pNFS client to revert I/O to MDS

[Dai Ngo]

On 10/9/25 12:46 PM, Benjamin Coddington wrote:
> On 9 Oct 2025, at 13:43, Dai Ngo wrote:
>
>> On 10/7/25 1:37 PM, Benjamin Coddington wrote:
>>> On 7 Oct 2025, at 11:59, Dai Ngo wrote:
>>>
>>>> On 10/1/25 10:36 AM, Dai Ngo wrote:
>>>>> On 10/1/25 3:54 AM, Benjamin Coddington wrote:
>>>>>> On 30 Sep 2025, at 17:41, Dai Ngo wrote:
>>>>>>
>>>>>>> Hi Ben,
>>>>>>>
>>>>>>> On 9/30/25 12:15 PM, Benjamin Coddington wrote:
>>>>>>>> Hi Dai,
>>>>>>>>
>>>>>>>> On 30 Sep 2025, at 12:28, Dai Ngo wrote:
>>>>>>>>
>>>>>>>>> When servicing the GETDEVICEINFO call from an NFS client, the NFS server
>>>>>>>>> creates a SCSI persistent reservation on the target device using the
>>>>>>>>> reservation type PR_EXCLUSIVE_ACCESS_REG_ONLY. This setting restricts
>>>>>>>>> device access so that only hosts registered with a reservation key can
>>>>>>>>> perform read or write operations. Any unregistered initiator is completely
>>>>>>>>> blocked, including standard SCSI commands such as READCAPACITY.
>>>>>>>> SBC-4, table 13 shows that READ CAPACITY should be allowed from any I_T
>>>>>>>> nexus, no matter the state of the reservation on the LU.
>>>>>>>>
>>>>>>>> Is it possible that your SCSI implementation might be out of the spec?  Also
>>>>>>>> possible that SBC-4 has been updated, I haven't been following the SCSI
>>>>>>>> specification updates..
>>>>>>>>
>>>>>>>> Ben
>>>>>>> I don't have access to SBC-4 spec, t10.org does not allow guest access
>>>>>>> to their docs. Can you please share the content of table 13 here?
>>>>>> The document's licensing prohibits me from doing this, I'm sorry to report.
>>>>>> I have a single-user copy that prohibits me from copying or transmitting any
>>>>>> part or whole.  Looks like you can get SBC-5 from the ANSI webstore for $60:
>>>>>>
>>>>>> https://urldefense.com/v3/__https://webstore.ansi.org/standards/incits/incits5712025__;!!ACWV5N9M2RV99hQ!N4FtetrpMVBPf88WPTlz6EuwsK0kPhNqw04MXvtXGUwMzzAf0NPkCYhL5HYx32ZZVogW2MKS0Jr8P8M$
>>>>>>
>>>>>> The reason your patch caught my eye was because we'd previously fixed the
>>>>>> same problem in the SCSI LIO target.
>>>>> Thank you Ben, I'll get the spec from the ANSI webstore.
>>>> You're right Ben! The SBC-4 spec says read capacity is allowed in this
>>>> case.
>>>>
>>>> The problem was caused by the DS was running an older version of the
>>>> kernel that did not have your fix:
>>>>
>>>> 28c58f8a0947f scsi: target: Enable READ CAPACITY for PR EARO
>>>>
>>>> This fix did not include the SERVICE_ACTION_IN_16 with Service Action
>>>> READ_CAPACITY. However, the Linux client tries SERVICE_ACTION_IN_16
>>>> three times then switches to READ CAPACITY (0x25).
>>>>
>>>> Thank you for pointing this out.
>>> Would you be willing to test this patch for SERVICE_ACTION_IN_16?
>>>
>>>   From d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f Mon Sep 17 00:00:00 2001
>>> Message-ID: <d7fa5d5f593dcfe39b7456dd6f23eb042fb2636f.1759869410.git.bcodding@redhat.com>
>>> From: Benjamin Coddington <bcodding@redhat.com>
>>> Date: Tue, 7 Oct 2025 16:34:37 -0400
>>> Subject: [PATCH] scsi: target: Fixup two more cases for PR EARO
>>>
>>> Allow READ_CAPACITY_16 and REPORT_REFERALS for SERVICE_ACTION_IN_16
>>> in the SCSI target driver.
>>>
>>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>>> ---
>>>    drivers/target/target_core_pr.c | 7 +++++++
>>>    1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
>>> index 83e172c92238..0b6803754422 100644
>>> --- a/drivers/target/target_core_pr.c
>>> +++ b/drivers/target/target_core_pr.c
>>> @@ -465,6 +465,13 @@ static int core_scsi3_pr_seq_non_holder(struct se_cmd *cmd, u32 pr_reg_type,
>>>                           return -EINVAL;
>>>                   }
>>>                   break;
>>> +       case SERVICE_ACTION_IN_16:
>>> +               switch (cdb[1] & 0x1f) {
>>> +               case SAI_READ_CAPACITY_16:
>>> +               case SAI_REPORT_REFERRALS:
>>> +                       ret = 0;
>>> +               }
>>> +               break;
>>>           case ACCESS_CONTROL_IN:
>>>           case ACCESS_CONTROL_OUT:
>>>           case INQUIRY:
>> The patch worked fine for READ_CAPACITY_16.
>>
>> The REPORT_REFERRALS got a Check Condition with sense code 0x2000
>> (Invalid command Operation code), whether there is a PR or not,
>> because the SCSI target does not support Referrals as reported by
>> 'sg_vpd' command.
>>
>> Thanks for doing this, Ben.
>>
>> -Dai
> Thanks for the test.  I'll send this to the target list, and will add your
> Tested-by unless you'd rather it withheld.

Please feel free to add me as a Tested-by tag.

Thanks,
-Dai