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] [thread-next>] [day] [month] [year] [list]
Message-ID: <0100019c05067b3b-b9ab2963-ace5-481f-8969-c11f80a74423-000000@email.amazonses.com>
Date: Wed, 28 Jan 2026 14:33:56 +0000
From: John Groves <john@...alactic.com>
To: Joanne Koong <joannelkoong@...il.com>
Cc: John Groves <John@...ves.net>, 
	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 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].

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