]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
NFSD: Track SCSI Persistent Registration Fencing per Client with xarray
authorDai Ngo <dai.ngo@oracle.com>
Mon, 19 Jan 2026 15:41:26 +0000 (10:41 -0500)
committerChuck Lever <chuck.lever@oracle.com>
Mon, 30 Mar 2026 01:25:09 +0000 (21:25 -0400)
commita0ed7975de5e47091ab16aaece75d1b64c5709e7
treebbea150397fb5a309626d3dfa733d0bf3e7bdf07
parent7b546bd89975cfbd60d4b86f2d1a3b6be5f9e558
NFSD: Track SCSI Persistent Registration Fencing per Client with xarray

When a client holding pNFS SCSI layouts becomes unresponsive, the
server revokes access by preempting the client's SCSI persistent
reservation key. A layout recall is issued for each layout the
client holds; if the client fails to respond, each recall triggers
a fence operation. The first preempt for a given device succeeds
and removes the client's key registration. Subsequent preempts for
the same device fail because the key is no longer registered.

Update the NFS server to handle SCSI persistent registration
fencing on a per-client and per-device basis by utilizing an
xarray associated with the nfs4_client structure.

Each xarray entry is indexed by the dev_t of a block device
registered by the client. The entry maintains a flag indicating
whether this device has already been fenced for the corresponding
client.

When the server issues a persistent registration key to a client,
it creates a new xarray entry at the dev_t index with the fenced
flag initialized to 0.

Before performing a fence via nfsd4_scsi_fence_client, the server
checks the corresponding entry using the device's dev_t. If the
fenced flag is already set, the fence operation is skipped;
otherwise, the flag is set to 1 and fencing proceeds.

The xarray is destroyed when the nfs4_client is released in
__destroy_client.

Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
fs/nfsd/blocklayout.c
fs/nfsd/nfs4state.c
fs/nfsd/state.h