Re: [PATCH v13 10/12] famfs: Add runtime operation-permission (opts) framework

[Darrick J. Wong]

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