On Sat, Aug 22, 2026 at 12:18:58AM -0400, Gregory Price wrote: > On Fri, Aug 21, 2026 at 05:07:28PM -0700, Darrick J. Wong wrote: > > > > But what prevents a malicious program that is /not/ the famfs client > > software but has CAP_SYS_ADMIN from doing that? > > > > Such a program can already unmount famfs, rebind the device to > device_dax, and mmap the whole range directly. MAP_CREATE isn't > handing it reach it didn't have.
Thinking about this a little more -- some random root process that accidentally tries to create/modify a directory tree on a famfs mount will just end up with fmap-less files that won't work for IO or mmapping. That's dorky, but I think you're right that it's no big deal. A bigger question I just thought of is sharing cxlmem between files (aka reflink). Is that allowed? I could see a theoretical usecase for programs A and B wanting to share some cxlmem for communication or heartbeats whilst having their own /a and /b files for their private memory. Probably you'd just create a /common file to do that and not map the same cxlmem page into /a and /b, right? But having said that, the fsdax code /can/ support sharing between files, so I wonder if famfs is prepared either (a) to enable that sharing or (b) reject a mapping that would overlap with an existing mapping? Things will go very badly in the kernel if famfs doesn't set up the dax_folio state correctly. --D
