lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJnrk1Y6HayeS-C3sOEOc_CgaS_K=SedZNpHASAXAkgZyp3Xsg@mail.gmail.com>
Date: Wed, 28 Jan 2026 10:54:26 -0800
From: Joanne Koong <joannelkoong@...il.com>
To: john@...ves.net
Cc: Miklos Szeredi <miklos@...redi.hu>, Dan Williams <dan.j.williams@...el.com>, 
	Bernd Schubert <bschubert@....com>, Alison Schofield <alison.schofield@...el.com>, 
	John Groves <jgroves@...ron.com>, John Groves <jgroves@...tmail.com>, 
	Jonathan Corbet <corbet@....net>, Vishal Verma <vishal.l.verma@...el.com>, 
	Dave Jiang <dave.jiang@...el.com>, Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>, 
	Alexander Viro <viro@...iv.linux.org.uk>, David Hildenbrand <david@...nel.org>, 
	Christian Brauner <brauner@...nel.org>, "Darrick J . Wong" <djwong@...nel.org>, 
	Randy Dunlap <rdunlap@...radead.org>, Jeff Layton <jlayton@...nel.org>, 
	Amir Goldstein <amir73il@...il.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
	Stefan Hajnoczi <shajnocz@...hat.com>, Josef Bacik <josef@...icpanda.com>, 
	Bagas Sanjaya <bagasdotme@...il.com>, James Morse <james.morse@....com>, 
	Fuad Tabba <tabba@...gle.com>, Sean Christopherson <seanjc@...gle.com>, Shivank Garg <shivankg@....com>, 
	Ackerley Tng <ackerleytng@...gle.com>, Gregory Price <gourry@...rry.net>, 
	Aravind Ramesh <arramesh@...ron.com>, Ajay Joshi <ajayjoshi@...ron.com>, 
	"venkataravis@...ron.com" <venkataravis@...ron.com>, 
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>, 
	"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH V5 09/19] famfs_fuse: magic.h: Add famfs magic numbers

On Wed, Jan 28, 2026 at 6:33 AM John Groves <john@...alactic.com> wrote:
>
> On 26/01/27 01:55PM, Joanne Koong wrote:
> > On Fri, Jan 16, 2026 at 11:52 AM John Groves <john@...alactic.com> wrote:
> > >
> > > From: John Groves <john@...ves.net>
> > >
> > > Famfs distinguishes between its on-media and in-memory superblocks. This
> > > reserves the numbers, but they are only used by the user space
> > > components of famfs.
> > >
> > > Signed-off-by: John Groves <john@...ves.net>
> > > ---
> > >  include/uapi/linux/magic.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> > > index 638ca21b7a90..712b097bf2a5 100644
> > > --- a/include/uapi/linux/magic.h
> > > +++ b/include/uapi/linux/magic.h
> > > @@ -38,6 +38,8 @@
> > >  #define OVERLAYFS_SUPER_MAGIC  0x794c7630
> > >  #define FUSE_SUPER_MAGIC       0x65735546
> > >  #define BCACHEFS_SUPER_MAGIC   0xca451a4e
> > > +#define FAMFS_SUPER_MAGIC      0x87b282ff
> > > +#define FAMFS_STATFS_MAGIC      0x87b282fd
> >
> > Could you explain why this needs to be added to uapi? If they are used
> > only by userspace, does it make more sense for these constants to live
> > in the userspace code instead?
> >
> > Thanks,
> > Joanne
>
> Hi Joanne,
>
> I think this is where it belongs; one function of uapi/linux/magic.h is as
> a "registry" of magic numbers, which do need to be unique because they're
> the first step of recognizing what is on a device.
>
> This is a well-established ecosystem with block devices. Blkid / libblkid
> scan block devices and keep a database of what devices exist and what
> appears to be on them. When one adds a magic number that applies to block
> devices, one sends a patch to util-linux (where blkid lives) to add ability
> to recognize your media format (which IIRC includes the second recognition
> step - if the magic # matches, verify the superblock checksum).
>
> For character dax devices the ecosystem isn't really there yet, but the
> pattern is the same - and still makes sense.
>
> Also, 2 years ago in the very first public famfs patch set (pre-fuse),
> Christian Brauner told me they belong here [1].

Hi John,

Thanks for the context. I was under the impression include/uapi/ was
only for constants the kernel exposes as part of its ABI. If I'm
understanding it correctly, FAMFS_SUPER_MAGIC is used purely as an
on-disk format marker for identification by userspace tools. Why
doesn't having the magic number defined in the equivalent of
blkid/libblkid for dax devices and defined/used in the famfs
server-side implementation suffice for that purpose? I'm asking in
part because it seems like a slippery slope to me where any fuse
server could make the same argument in the future that their magic
constant should be added to uapi.

For Christian's comment, my understanding was that with the pre-fuse
patchset, it did need to be in uapi because the kernel explicitly set
sb->s_magic to it, but with famfs now going through fuse, sb->s_magic
uses FUSE_SUPER_MAGIC.

Thanks,
Joanne

>
> But if the consensus happens to have moved since then, NP...
>
> Regards,
> John
>
> [1] https://lore.kernel.org/linux-fsdevel/20240227-kiesgrube-couch-77ee2f6917c7@brauner/
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ