- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
by Li Lingfeng 14 Apr '26

14 Apr '26

From: Jeff Layton <jlayton(a)kernel.org> mainline inclusion from mainline-v7.0-rc5 commit 5133b61aaf437e5f25b1b396b14242a6bb0508e2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14128 CVE: CVE-2026-31402 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)kernel.org Reported-by: Nicholas Carlini <npc(a)anthropic.com> Tested-by: Nicholas Carlini <npc(a)anthropic.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/nfs4xdr.c [Commit 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.") add mapping for status.] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 9 +++++++-- fs/nfsd/state.h | 17 ++++++++++++----- 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 821c0ad5baa0..b8976c2f17fe 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -5233,9 +5233,14 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) int len = xdr->buf->len - post_err_offset; so->so_replay.rp_status = op->status; - so->so_replay.rp_buflen = len; - read_bytes_from_xdr_buf(xdr->buf, post_err_offset, + if (len <= NFSD4_REPLAY_ISIZE) { + so->so_replay.rp_buflen = len; + read_bytes_from_xdr_buf(xdr->buf, + post_err_offset, so->so_replay.rp_buf, len); + } else { + so->so_replay.rp_buflen = 0; + } } status: /* Note that op->status is already in network byte order: */ diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h index 0e4f98b41364..f398effabeef 100644 --- a/fs/nfsd/state.h +++ b/fs/nfsd/state.h @@ -395,11 +395,18 @@ struct nfs4_client_reclaim { struct xdr_netobj cr_princhash; }; -/* A reasonable value for REPLAY_ISIZE was estimated as follows: - * The OPEN response, typically the largest, requires - * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + 8(verifier) + - * 4(deleg. type) + 8(deleg. stateid) + 4(deleg. recall flag) + - * 20(deleg. space limit) + ~32(deleg. ace) = 112 bytes +/* + * REPLAY_ISIZE is sized for an OPEN response with delegation: + * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + + * 8(verifier) + 4(deleg. type) + 8(deleg. stateid) + + * 4(deleg. recall flag) + 20(deleg. space limit) + + * ~32(deleg. ace) = 112 bytes + * + * Some responses can exceed this. A LOCK denial includes the conflicting + * lock owner, which can be up to 1024 bytes (NFS4_OPAQUE_LIMIT). Responses + * larger than REPLAY_ISIZE are not cached in rp_ibuf; only rp_status is + * saved. Enlarging this constant increases the size of every + * nfs4_stateowner. */ #define NFSD4_REPLAY_ISIZE 112 -- 2.52.0

2 1

[PATCH OLK-5.10 0/2] Fix CVE-2026-23271
by Luo Gengkun 14 Apr '26

14 Apr '26

Luo Gengkun (1): perf: Fix Wdeclaration-after-statement Peter Zijlstra (1): perf: Fix __perf_event_overflow() vs perf_remove_from_context() race kernel/events/core.c | 57 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/5] arm64/ras: Firmware-first SEI error handling with ESB synchronization
by Wupeng Ma 14 Apr '26

14 Apr '26

This series introduces firmware-first RAS (Reliability, Availability, and Serviceability) error handling for ARM64 SEI (Synchronous External Interrupt) errors, with support for ESB (Error Synchronization Barrier) synchronization. The implementation includes: - Boot parameter to enable/disable ESB synchronization for SEI - Entry code patching to use ESB instruction for SEI handling - Vendor-specific SEI error handling via APEI/GHES - Sysctl interface for runtime control of vendor SEI handling Liao Chang (1): arm64/entry: Add support to synchronize SEI at the exception boundary Wupeng Ma (3): ACPI/APEI/arm64: add vendor SEI handling for firmware-first RAS ACPI: APEI: add runtime switch for HiSilicon vendor SEI handling arm64: openeuler_defconfig: enable CONFIG_ARM64_SYNC_SEI by default Zheng Chuan (1): arm64: Add boot parameter to control ESB for SEI synchronization .../admin-guide/kernel-parameters.txt | 8 + Documentation/admin-guide/sysctl/kernel.rst | 27 +++ arch/arm64/Kconfig | 14 ++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/acpi.h | 2 + arch/arm64/include/asm/setup.h | 9 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/arm64_sync_sei.c | 45 +++++ arch/arm64/kernel/entry.S | 44 +++++ arch/arm64/kernel/traps.c | 15 ++ arch/arm64/kernel/xcall/entry.S | 2 + drivers/acpi/apei/apei-internal.h | 2 + drivers/acpi/apei/ghes-vendor-info.c | 186 +++++++++++++++++- drivers/acpi/apei/ghes.c | 5 + 14 files changed, 360 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/kernel/arm64_sync_sei.c -- 2.43.0

2 6

[PATCH OLK-6.6 0/4] Introduce xSched dmem
by Liu Kai 14 Apr '26

14 Apr '26

Introduce xSched dmem Alexander Pavlenko (2): xSched/dmem: introduce xsched_dmem_alloc() xSched/dmem: introduce xsched_dmem_free() Liu Kai (2): xSched/dmem: add support for XPU devices to register/unregister dmem regions xSched/dmem: introduce xsched_dmem_cleanup() include/linux/cgroup_dmem.h | 2 - include/linux/xsched.h | 14 ++ include/uapi/linux/xsched/xcu_vstream.h | 9 + kernel/xsched/Makefile | 1 + kernel/xsched/core.c | 3 + kernel/xsched/dmem.c | 226 ++++++++++++++++++++++++ kernel/xsched/vstream.c | 99 +++++++++++ 7 files changed, 352 insertions(+), 2 deletions(-) create mode 100644 kernel/xsched/dmem.c -- 2.34.1

2 5

[PATCH OLK-6.6] fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error
by Zizhi Wo 14 Apr '26

14 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8926 -------------------------------- [BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 [ 51.115408] handle_mm_fault+0x24c/0x570 [ 51.115958] do_user_addr_fault+0x226/0xa50 ... Crash analysis showed the file involved was an AIO ring file. [CAUSE] PARENT process CHILD process t=0 io_setup(1, &ctx) [access ctx addr] fork() io_destroy vm_munmap // not affect child vma percpu_ref_put ... put_aio_ring_file t=1 [access ctx addr] // pagefault ... __do_fault filemap_fault max_idx = DIV_ROUND_UP t=2 truncate_setsize truncate_pagecache t=3 filemap_get_folio // no folio __filemap_get_folio(FGP_CREAT, ...) filemap_read_folio(xxx->read_folio) At t=0, the parent process calls io_setup and then fork. The child process gets its own VMA but without any PTEs. The parent then calls io_destroy. Before i_size is truncated to 0, at t=1 the child process accesses this AIO ctx address and triggers a pagefault. After the max_idx check passes, at t=2 the parent calls truncate_setsize and truncate_pagecache. At t=3 the child fails to obtain the folio, falls into the "page_not_uptodate" path, and hits this problem because AIO does not implement "read_folio". [Fix] Fix this by marking the AIO ring buffer VMA with VM_DONTCOPY so that fork()'s dup_mmap() skips it entirely. This is the correct semantic because: 1) The child's ioctx_table is already reset to NULL by mm_init_aio() during fork(), so the child has no AIO context and no way to perform any AIO operations on this mapping. 2) The AIO ring VMA is only meaningful in conjunction with its associated kioctx, which is never inherited across fork(). So child process with no AIO context has no legitimate reason to access the ring buffer. Delivering SIGSEGV on such an erroneous access is preferable to a kernel crash. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index c3614193d749..8b27c02db8a6 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -392,11 +392,11 @@ static const struct vm_operations_struct aio_ring_vm_ops = { #endif }; static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma) { - vm_flags_set(vma, VM_DONTEXPAND); + vm_flags_set(vma, VM_DONTEXPAND | VM_DONTCOPY); vma->vm_ops = &aio_ring_vm_ops; return 0; } static const struct file_operations aio_ring_fops = { -- 2.39.2

2 1

[PATCH OLK-5.10] fs: aio: set VMA_DONTCOPY_BIT in mmap to fix NULL-pointer-dereference error
by Zizhi Wo 14 Apr '26

14 Apr '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8927 -------------------------------- [BUG] Recently, our internal syzkaller testing uncovered a null pointer dereference issue: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 51.111664] filemap_read_folio+0x25/0xe0 [ 51.112410] filemap_fault+0xad7/0x1250 [ 51.113112] __do_fault+0x4b/0x460 [ 51.113699] do_pte_missing+0x5bc/0x1db0 [ 51.114250] ? __pte_offset_map+0x23/0x170 [ 51.114822] __handle_mm_fault+0x9f8/0x1680 [ 51.115408] handle_mm_fault+0x24c/0x570 [ 51.115958] do_user_addr_fault+0x226/0xa50 ... Crash analysis showed the file involved was an AIO ring file. [CAUSE] PARENT process CHILD process t=0 io_setup(1, &ctx) [access ctx addr] fork() io_destroy vm_munmap // not affect child vma percpu_ref_put ... put_aio_ring_file t=1 [access ctx addr] // pagefault ... __do_fault filemap_fault max_idx = DIV_ROUND_UP t=2 truncate_setsize truncate_pagecache t=3 filemap_get_folio // no folio __filemap_get_folio(FGP_CREAT, ...) filemap_read_folio(xxx->read_folio) At t=0, the parent process calls io_setup and then fork. The child process gets its own VMA but without any PTEs. The parent then calls io_destroy. Before i_size is truncated to 0, at t=1 the child process accesses this AIO ctx address and triggers a pagefault. After the max_idx check passes, at t=2 the parent calls truncate_setsize and truncate_pagecache. At t=3 the child fails to obtain the folio, falls into the "page_not_uptodate" path, and hits this problem because AIO does not implement "read_folio". [Fix] Fix this by marking the AIO ring buffer VMA with VM_DONTCOPY so that fork()'s dup_mmap() skips it entirely. This is the correct semantic because: 1) The child's ioctx_table is already reset to NULL by mm_init_aio() during fork(), so the child has no AIO context and no way to perform any AIO operations on this mapping. 2) The AIO ring VMA is only meaningful in conjunction with its associated kioctx, which is never inherited across fork(). So child process with no AIO context has no legitimate reason to access the ring buffer. Delivering SIGSEGV on such an erroneous access is preferable to a kernel crash. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/aio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/aio.c b/fs/aio.c index 78aaeaf35436..4ab74699cd3d 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -366,11 +366,11 @@ static const struct vm_operations_struct aio_ring_vm_ops = { #endif }; static int aio_ring_mmap(struct file *file, struct vm_area_struct *vma) { - vma->vm_flags |= VM_DONTEXPAND; + vma->vm_flags |= VM_DONTEXPAND | VM_DONTCOPY; vma->vm_ops = &aio_ring_vm_ops; return 0; } static const struct file_operations aio_ring_fops = { -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] *** Fix CVE-2026-23271 ***
by Luo Gengkun 14 Apr '26

14 Apr '26

Luo Gengkun (1): perf: Fix Wdeclaration-after-statement Peter Zijlstra (1): perf: Fix __perf_event_overflow() vs perf_remove_from_context() race kernel/events/core.c | 57 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
by Xia Fukun 14 Apr '26

14 Apr '26

From: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> stable inclusion from stable-v6.6.130 commit 11a87dd5df428a4b79a84d2790cac7f3c73f1f0d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14101 CVE: CVE-2026-23461 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 752a6c9596dd25efd6978a73ff21f3b592668f4a ] After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del(). This can lead to use-after-free and list corruption bugs, as reported by syzbot. Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure. Reported-by: syzbot+14b6d57fb728e27ce23c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=14b6d57fb728e27ce23c Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Signed-off-by: Shaurya Rane <ssrane_b23(a)ee.vjti.ac.in> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- net/bluetooth/l2cap_core.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 76c52d18b9b2..09ef1ccc6960 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -1686,17 +1686,15 @@ static void l2cap_info_timeout(struct work_struct *work) int l2cap_register_user(struct l2cap_conn *conn, struct l2cap_user *user) { - struct hci_dev *hdev = conn->hcon->hdev; int ret; /* We need to check whether l2cap_conn is registered. If it is not, we - * must not register the l2cap_user. l2cap_conn_del() is unregisters - * l2cap_conn objects, but doesn't provide its own locking. Instead, it - * relies on the parent hci_conn object to be locked. This itself relies - * on the hci_dev object to be locked. So we must lock the hci device - * here, too. */ + * must not register the l2cap_user. l2cap_conn_del() unregisters + * l2cap_conn objects under conn->lock, and we use the same lock here + * to protect access to conn->users and conn->hchan. + */ - hci_dev_lock(hdev); + mutex_lock(&conn->lock); if (!list_empty(&user->list)) { ret = -EINVAL; @@ -1717,16 +1715,14 @@ int l2cap_register_user(struct l2cap_conn *conn, struct l2cap_user *user) ret = 0; out_unlock: - hci_dev_unlock(hdev); + mutex_unlock(&conn->lock); return ret; } EXPORT_SYMBOL(l2cap_register_user); void l2cap_unregister_user(struct l2cap_conn *conn, struct l2cap_user *user) { - struct hci_dev *hdev = conn->hcon->hdev; - - hci_dev_lock(hdev); + mutex_lock(&conn->lock); if (list_empty(&user->list)) goto out_unlock; @@ -1735,7 +1731,7 @@ void l2cap_unregister_user(struct l2cap_conn *conn, struct l2cap_user *user) user->remove(conn, user); out_unlock: - hci_dev_unlock(hdev); + mutex_unlock(&conn->lock); } EXPORT_SYMBOL(l2cap_unregister_user); -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] xSched dmem
by Liu Kai 14 Apr '26

14 Apr '26

xSched dmem Liu Kai (2): xSched/cgroup: prevent to init xse when xcu cgroup is disabled xSched: remove redundant lookup in alloc_ctx_from_vstream to enforce allocation semantics include/linux/xsched.h | 2 ++ kernel/xsched/cgroup.c | 2 +- kernel/xsched/core.c | 3 +++ kernel/xsched/vstream.c | 4 ---- 4 files changed, 6 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
by Li Lingfeng 14 Apr '26

14 Apr '26

From: Jeff Layton <jlayton(a)kernel.org> stable inclusion from stable-v6.6.130 commit 8afb437ea1f70cacb4bbdf11771fb5c4d720b965 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14128 CVE: CVE-2026-31402 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5133b61aaf437e5f25b1b396b14242a6bb0508e2 ] The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)kernel.org Reported-by: Nicholas Carlini <npc(a)anthropic.com> Tested-by: Nicholas Carlini <npc(a)anthropic.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> [ replaced `op_status_offset + XDR_UNIT` with existing `post_err_offset` variable ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 9 +++++++-- fs/nfsd/state.h | 17 ++++++++++++----- 2 files changed, 19 insertions(+), 7 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 3eff780fd8da..3c9d19321df5 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -5420,9 +5420,14 @@ nfsd4_encode_operation(struct nfsd4_compoundres *resp, struct nfsd4_op *op) int len = xdr->buf->len - post_err_offset; so->so_replay.rp_status = op->status; - so->so_replay.rp_buflen = len; - read_bytes_from_xdr_buf(xdr->buf, post_err_offset, + if (len <= NFSD4_REPLAY_ISIZE) { + so->so_replay.rp_buflen = len; + read_bytes_from_xdr_buf(xdr->buf, + post_err_offset, so->so_replay.rp_buf, len); + } else { + so->so_replay.rp_buflen = 0; + } } status: *p = op->status; diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h index 5da7785609b0..d1450fe7e2b9 100644 --- a/fs/nfsd/state.h +++ b/fs/nfsd/state.h @@ -430,11 +430,18 @@ struct nfs4_client_reclaim { struct xdr_netobj cr_princhash; }; -/* A reasonable value for REPLAY_ISIZE was estimated as follows: - * The OPEN response, typically the largest, requires - * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + 8(verifier) + - * 4(deleg. type) + 8(deleg. stateid) + 4(deleg. recall flag) + - * 20(deleg. space limit) + ~32(deleg. ace) = 112 bytes +/* + * REPLAY_ISIZE is sized for an OPEN response with delegation: + * 4(status) + 8(stateid) + 20(changeinfo) + 4(rflags) + + * 8(verifier) + 4(deleg. type) + 8(deleg. stateid) + + * 4(deleg. recall flag) + 20(deleg. space limit) + + * ~32(deleg. ace) = 112 bytes + * + * Some responses can exceed this. A LOCK denial includes the conflicting + * lock owner, which can be up to 1024 bytes (NFS4_OPAQUE_LIMIT). Responses + * larger than REPLAY_ISIZE are not cached in rp_ibuf; only rp_status is + * saved. Enlarging this constant increases the size of every + * nfs4_stateowner. */ #define NFSD4_REPLAY_ISIZE 112 -- 2.52.0

2 1