TMPfs inode corruption

tmpfs is a temporary file storage paradigm implemented in many Unix-like operating systems. 

A few months ago I got a report from a service owner that their service was crashing when trying to access certain files stored in tmpfs. This service provides a way to do things like builds on niche architectures/platforms, and as part of that retrieves and stores a large cache of required files for the requisite job in /dev/shm, preventing needing them to fetch for other jobs with the same dependencies.

As part of this lifecycle, this service stores a mapping from each file's inode number to its own metadata relevant to the data retrieved. Simple enough, and on the face of it this seems fine: generally the contract the kernel provides is that as long as the device, inode number, and generation are the same, this is guaranteed to point to the same data during the lifetime of the kernel.

After quite a bit of back and forth, my patches in "tmpfs: per-superblock i_ino support" and "tmpfs: support 64-bit inums per-sb" were merged into kernel 5.9. In essence, the patches move tmpfs' inode allocation away from the get_next_ino shared pool, in favour of our own superblock-based system, and add support for 64-bit inodes using the inode64 tmpfs mount option (or allow having it on by default by enabling CONFIG_TMPFS_INODE64 when compiling the kernel). We now use ino_t everywhere, and for legacy users we simply emulate the old behaviour by doing manual wraparounds when we reach UINT_MAX. This also allows us to catch these cases when they happen and print a warning for the system administrator to act on, suggesting to move to inode64.

Full Version


It is intended to appear as a mounted file system, but data is stored in volatile memory instead of a persistent storage device.