CVE-2026-89667: nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache

In the Linux kernel, the following vulnerability has been resolved:

nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache

The shrinker, GC worker, and fsnotify/lease callbacks can unhash an nfsdfile from the rhashtable and then call nfsdfiledisposelistdelayed() to move it to the per-net dispose list. If nfsdfilecacheshutdownnet() runs concurrently, its rhashtable walk misses the already-unhashed file, and its drain of the per-net dispose list can run before the file has been queued. The file then sits on the per-net list with no thread to drain it, leaking both the file and its associated state.

The GC worker and shrinker already hold nfsdgclock while walking the LRU, but in the original code they release it before calling nfsdfiledisposelistdelayed(). The fsnotify/lease path (nfsdfilecloseinode) has no synchronization at all.

Fix this by:

1. Widening nfsdgclock in both nfsdfilegc() and nfsdfilelruscan() to cover the nfsdfiledisposelistdelayed() call.

2. Wrapping nfsdfilecloseinode() in nfsdgclock so that all three callers of nfsdfiledisposelistdelayed() hold the lock.

3. Adding a spinlock/unlock(nfsdgclock) barrier in nfsdfilecacheshutdownnet() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained.

All operations inside the lock are non-sleeping (rhashtable lookups, atomic bit/refcount ops, list moves, svcwakeup), so the spinlock is appropriate.