NAS-141072 / 26.04 / Sync 6.12 with release branch#272
Merged
Conversation
Original Linux code allocated memory on every link up and freed on every link down. It may be a problem to allocate several MBs of physically contiguous memory on a running system. To workaround that, speculatively pre-allocate it on boot and then reallocate only if remote host requests different parameters, which should be very rare. (cherry picked from commit 0852db2)
When nfsd_cross_mnt() crosses into a mounted ZFS snapshot but rqst_exp_get_by_name() fails to resolve the sub-export (-ENOENT), the error is silently converted to success and the automount stub dentry is returned to the caller. The stub has simple_dir_operations and its file handle is encoded with gen=1 (snapshot is mounted). This 44-byte gen=1 handle becomes a permanent trap: zfsctl_snapdir_vget() sees gen=1 matching d_mountpoint=true, returns the stub inode, and READDIR returns NFS4_OK with zero entries. The client caches this empty result indefinitely since there is no error signal to trigger re-resolution. The empty directory persists until change_info4 updates (e.g., manual snapshot creation on the server). For zfs_snapdir exports, return -ESTALE instead of silently falling back to the automount stub. This causes the client to re-resolve via LOOKUP. Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> (cherry picked from commit 3ab428e)
When nfsd_cross_mnt() sets LOOKUP_AUTOMOUNT for a snapdir entry and follow_down() returns with the path unchanged, the automount was attempted and failed (EISDIR from zfsctl_snapshot_mount). The existing code treats this as "mountpoint in some other namespace" and returns success with the ctldir stub dentry. This stub has simple_dir_operations and produces a 44-byte file handle that returns empty READDIR (NFS4_OK, zero entries) with no error signal for the client to trigger re-resolution. This can happen transiently when zfs_suspend_fs races with mount helper after the z_teardown_lock deadlock fix (openzfs/zfs#18415) Return ESTALE for snapdir entries so the client retries via LOOKUP, which re-triggers the automount. Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> (cherry picked from commit c026341)
bugclerk
changed the title
yocalebo
approved these changes
May 15, 2026
amotin
approved these changes
May 15, 2026
|
This PR has been merged and conversations have been locked. |
Member
Author
|
time 00:20 |
|
Time tracking added. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since
truenas/linux-6.12was unmaintained, there were a couple of commits that are part of the release branch but not intruenas/linux-6.12. It was kind of a mess, but this should sync both.