nfsd_filp_close(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– nfsd_filp_close(9) β€” Kernel API Manual πŸ’–

okay bestie, we're in the nfsd_filp_close(9) page and it's giving "close this file, but synchronously" energy. Let's go. 🫢

🌸 NAME 🌸

nfsd_filp_close β€” close a file synchronously. periodt. ✨

πŸ¦‹ SYNOPSIS πŸ¦‹

void nfsd_filp_close (struct file *fp );

πŸŽ€ ARGUMENTS πŸŽ€

  • fp β€” the file to close. that's the whole argument, no cap πŸ’…

πŸ’… DESCRIPTION πŸ’…

okay so nfsd_filp_close is similar in behaviour to filp_close. the iconic difference? if this is the final close on the file, that finalisation happens immediately instead of being handed over to a work_queue, which is what happens with filp_close. The way that's a whole vibe. πŸ’–

When a user-space process closes a file β€” even when it's using filp_close β€” the finalisation happens before returning to userspace, so it's effectively synchronous. But when a kernel thread uses file_close, on the other hand, the handling is completely asynchronous. 😭

That means any cost imposed by that finalisation is not imposed on the nfsd thread, and nfsd could potentially close files more quickly than the work queue finalises the close. and that would lead to unbounded growth in the queue. not slay. πŸ’€

In some contexts it is not safe to synchronously wait for close finalisation (see the comment for __fput_sync), but nfsd does not match those contexts. In particular, it does not, at the time that this function is called, hold any locks, and no finalisation of any file, socket, or device driver would have any cause to wait for nfsd to make progress. no cap, that's the safety context. 🧚

πŸ”₯ SEE ALSO πŸ”₯


source/version: ./fs/nfsd Β· date: October 2026 Β· page: nfsd_filp_close(9) β€” mwah, go close that file synchronously bestie πŸ’‹

πŸ“¦ where this page comes from