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

["John Groves" <john@groves.net>]

On Sat, Aug 22, 2026, at 12:40 PM, Darrick J. Wong wrote:
> 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. 

Gregory is right, but also: this is possible with fuse too, since the log
needs to be played into a tree that the fuse server consumes - in order
to avoid searching the log (order n) on every lookup. 

> 
> 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.

I've had users do that, and yes it's dorky but NBD.  It can be locked
down tighter by turning off FAMFS_OPT_CREATE except during 
log play etc., but the main thing is "don't do that: it won't harm the 
system, but it also it won't do what you want".

'famfs fsck' finds those, and the famfs cli can clean them up.

> 
> 
> 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?

Famfs doesn't support reflinks - I don't think there's a use case.

There is a pcq.c and libpcq.c in the famfs user space specifically for
using file pairs as producer/consumer queues - one file contains the
fields written by the producer, the other contains the fields written
by the consumer. This use case works great, but without cache-coherent
cxl memory (which is coming but not here yet AFAIK) libpcq has to verify
message sequence numbers and checksums to avoid reading messages 
from stale cache lines (i.e. loaded before valid).

I do have CI that creates cross linked files, which are detected by 
'famfs fsck'. 

> 
> 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
> 

Last I checked, if cross linked files get created (as test_errors.sh in my
smoke test suite does), you trigger a WARN_ONCE from dax,
but otherwise it does no harm to the system.

Thanks,
John