fsnotify: Fix checkpoint failure for inotify watches on overlayfs

[ankimaha-sys]

Summary

Fix CRIU checkpoint failure when dumping inotify watches on files backed by overlayfs, as seen on OpenShift 4.18 with .NET 8 container workloads.

Error before fix:

fsnotify: Handle 0x34c:0x1961af5a cannot be opened
Error (criu/fsnotify.c:284): fsnotify: Can't dump that handle

Root cause: In alloc_openable(), suitable_mount_found is only set after open_by_handle_at() succeeds. On overlayfs, the mount with matching s_dev is found, but open_by_handle_at() fails because overlayfs does not reliably support file handle decoding (depends on kernel config and nfs_export mount option). Since suitable_mount_found stays 0, the function returns ERR_NO_MOUNT, sending check_open_handle() to the fault path where irmap_lookup() also fails because its hint directories don't cover container filesystem paths.

Changes

1. Move suitable_mount_found = 1 in alloc_openable() to before the open_by_handle_at() attempt, so the mount is correctly reported as found even when handle decoding fails.

2. Add overlayfs-specific path resolution in check_open_handle(): When ERR_NO_PATH_IN_MOUNT is returned and the mount is overlayfs, scan the overlay mount tree for the matching inode using a new scan_dir_for_inode() helper function.

3. Add scan_dir_for_inode() helper: Recursive directory scanner that finds a file by (s_dev, i_ino) within a mount tree. Respects mount boundaries (won't cross devices), limits recursion depth to 32, and doesn't follow symlinks.

Test plan

• Build CRIU with the patch on a Fedora/RHEL system
• Create a container (podman/CRI-O) with overlayfs storage driver
• Run a workload that creates inotify watches (e.g. .NET FileSystemWatcher)
• Checkpoint the container with criu dump or kubelet checkpoint API
• Verify checkpoint succeeds without Can't dump that handle error
• Verify existing fsnotify tests still pass (make test / zdtm fsnotify tests)

Fixes: https://issues.redhat.com/browse/OCPBUGS-87023

Made with Cursor

[adrianreber]

Looks like what I did a couple of days ago #3043 😉

[ankimaha-sys]

Thanks for the heads up @adrianreber! I arrived at the same fix independently — good to know we're aligned on the approach.

I've updated this PR to be more complete:

• Bumped scan depth to 64 (matching your approach)
• Added entry count tracking with a warning after 10,000 entries
• Added a ZDTM test (inotify_overlayfs) that mounts an overlay, creates an inotify watch, checkpoints/restores, and verifies events still work

Happy to close this in favour of #3043 if you prefer, or if there's anything useful here you'd like to cherry-pick, feel free. Either way — glad this is getting fixed!

[rst0git]

@ankimaha-sys Thanks for working on this! I went ahead and merged #3043