[sparkzky]

Problem

OverlayFS never implemented FileSystem::map_pages, so the default implementation panicked:

map_pages() has not yet been implemented for filesystem: OverlayFS

• in user fault context the panic parked the whole machine
  (do_page_fault → handle_mm_fault → do_fault → OverlayFS::map_pages);
• in syscall context the panic was swallowed by catch_unwind and surfaced as
  disk I/O error: operation not supported (sqlite: SQLITE_IOERR_WRITE, sysErrno=95).

Both sqlite's WAL -shm mapping and JVM/kafka startup (which mmap files from the
container overlay) hit this path.

Root cause

OverlayFS keeps no page cache of its own: OvlInode::page_cache() is None, and file
data pages belong to the upper/lower backing inode. mmap_effective_file() normally
rebinds the VMA to the backing file, but a shared mapping can still stay bound to the
overlay file (e.g. when the descriptor was closed and private_data became Unused,
while POSIX keeps the mapping valid).

Changes

File	Change
mm/fault.rs	factor filemap_map_pages into a cache-owner parametrised helper; add filemap_map_pages_for_inode
overlayfs/fs.rs	implement map_pages: peel MountFSInode projections to the OvlInode, resolve the current real data inode, map its pages; unresolvable inodes return SIGBUS with a diagnostic instead of panicking
vfs/mount/mod.rs	add read-only VfsDentry::inode() accessor used by that peel

Verification

• make kernel passes; cargo +nightly-2026-02-24 fmt --all -- --check clean.
• DragonOS + 16 OCManager containers: container-local sqlite performs repeated inserts in
  both WAL and DELETE modes, kafka/msg-etl start successfully, no map_pages panic.

[fslongjin]

Reviewed against current master and Linux 6.6.139, including an independent subagent review. Skipping this PR because the original premise no longer matches the mmap path.

address_space.rs calls mmap_effective_file for file mappings before VMA creation; OverlayFS returns the actual backing Arc<File>. The VMA retains that file after the descriptor closes. This matches Linux ovl_mmap, which uses vma_set_file(vma, realfile). Closing the descriptor does not turn an existing VMA into an overlay-inode mapping.

The proposed fallback selects current_realdata_inode() on each fault-around, allowing a copy-up to switch backing in an existing mapping. It also only handles cached pages through map_pages: cache misses still reach OverlayFS's default SIGBUS fault handler, and shared writes lack the matching page_mkwrite implementation. Thus it is not a complete or architecturally consistent fix even if an overlay-bound VMA were possible.

Please retain the fixed backing-file lifetime design. Any remaining panic on current master needs a reproducer tracing where a VMA bypasses that binding. No changes have been pushed and this PR has not been merged.

[sparkzky]

Agreed, closing. Verified on current master (45754bdc) by booting the OCManager disk in QEMU snapshot mode with a master kernel: no map_pages() has not yet been implemented for filesystem: OverlayFS panic occurs, which matches your point that the VMA keeps the backing Arc<File>. The panic we reported reproduces only on the port branch, whose mm/overlay paths differ from master; it will be re-checked after the port is rebased, and any remaining case will be filed with a reproducer that shows where a VMA bypasses mmap_effective_file (plus the missing cache-miss and page_mkwrite handling you called out).

[sparkzky]

Reworked per the review; please take another look (force-pushed, 1ad2ac7b).

The previous patch tried to serve faults from the overlay inode and is gone. The new patch keeps the fixed backing-file lifetime design and only closes the two gaps around it:

1. mmap_effective_file(): when the overlay file no longer carries overlay private data (a shared mapping outlived its descriptor → EBADF), open the current real inode with the original access flags and return that file, so the VMA still binds a real backing file. The real inode is resolved once, at mapping creation — no per-fault lookup, so a copy-up cannot move an existing mapping.
2. OverlayFS::map_pages(): if a mapping nevertheless reaches it, return VM_FAULT_SIGBUS with a single diagnostic instead of the trait default panic (a panic here parks the machine in user-fault context and turns into EOPNOTSUPP in syscall context).

No page mapping from the overlay inode, no changes to fault-around or page_mkwrite, and the normal path is unchanged.

Status of the reproducer you asked for: on current master (45754bdc) we could not reproduce the panic (16-container OCManager boot + shared-mmap probe on both overlay and an ext4 bind mount). It only reproduces on the port branch, which does not have the later VFS/overlay commits (e.g. #2446/#2449/#2452) that master has. So this PR is now the defensive half only; if you prefer, I can keep it as a SIGBUS-instead-of-panic hardening and drop gap 1 — tell me which shape you want and I will adjust.

[sparkzky]

Behaviour check for the reworked patch (1ad2ac7b), in the environment where the panic actually occurred:

• port branch, old map_pages implementation removed, new mmap_effective_file + defensive map_pages applied;
• master's ENOTSUP fallback also present (our branch had been missing it);
• 16-container OCManager boot: 16/16 Up, no page fault on a mapping bound to the overlay inode diagnostic, container-local sqlite and three assets/add calls all succeed.

So keeping the VMA on a real backing file is sufficient in practice; the page-mapping approach from the first revision is gone.