netfs_clear_stale_isize(9)

📦 version 7.3.1, in nixpkgs unstable

💅 netfs_clear_stale_isize 💅

okay so this is a page out of the Kernel API Manual, bestie — literally kernel-internal stuff, iykyk. buckle up 🎀

✨ NAME ✨

netfs_clear_stale_isize — bestie, it clears stale pagecache data that's chilling inside a hole you're about to create 🧹💖

🌸 SYNOPSIS 🌸

int netfs_clear_stale_isize (struct inode *inode , uoff_t from , uoff_t
to , bool nowait , bool exclusive );

🦋 ARGUMENTS 🦋

  • inode — the inode we're doing all this to. main character fr.
  • from — the base of the hole that's gonna be made.
  • to — the top of the hole that's gonna be made.
  • nowait — set it to true and instead of blocking you get -EAGAIN back. no waiting around, periodt.
  • exclusive — set it to true when the caller is holding i_rwsem exclusively for the resize. it's giving "i have the lock, trust me" energy 👑

💜 DESCRIPTION 💜

okay so the whole vibe: zero out any data left sitting in the pagecache inside the [from, to) hole — you do it by writing through an mmap — so that data doesn't get exposed as file content once the file gets extended. gross otherwise 😭

And here's the smart part: only the uptodate folio straddling from can even hold such data, because pages wholly beyond the EOF literally can't be faulted in. so the zeroing is limited to that one folio, slay. and the folio gets zeroed rather than dropped so that a concurrent extending write can't lose data. protecting the data, we love to see it 🫶

Now, exclusive — this is the part where you gotta pay attention:

  • if exclusive is false, from gets re-read from i_size and used to clamp the zeroed range. that's for callers that might be racing with another writer also extending the file (eg. multiple buffered writes extending the same file under a shared i_rwsem). shared lock chaos, love that for them.
  • if exclusive is true, that's for callers holding i_rwsem exclusively across the whole resize who have already updated i_size to to. in that case staleness is decided from the folio's dirty state instead 🕵️‍♀️ because no genuine concurrent buffered writer can be racing, a lockless stat adopting a server-confirmed size mid-resize has no data behind it and never dirties the folio — so it literally can't fool this check into skipping the zeroing the way it could fool the exclusive false clamp. not today, bestie 💀
and real talk: pagecache_isize_extended can't be reused here. nope. it's keyed on a sub-page block size (which is a total no-op when the block size is >= PAGE_SIZE, like on network filesystems), it runs after i_size is updated, it can't honour nowait, and it doesn't wait for writeback. 🙈 so keep the two in sync if either one gets changed, fr fr.

🔥 RETURN 🔥

  • 0 on success — we ate 💅
  • -EAGAIN if nowait is set and the folio is mapped or under writeback and so can't be cleaned without blocking. can't clean it without blocking, so it says no thanks.

🌈 SEE ALSO 🌈

Kernel file ./fs/netfs/misc.c, plus the whole squad:

✨ anyway bestie that's the whole page 🎀 this little icon lives in ./fs/netfs, dated October 2026, and it's still waving at you as netfs_clear_stale_isize(9) 💖 mwah, go clear some stale isize, ily 🦋

📦 where this page comes from