linux-kernel - Re: [PATCH 05/19] vfs: Introduce a non-repeating system-unique superblock ID [ver #16]

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: <626759.1582202733@warthog.procyon.org.uk>
Date:   Thu, 20 Feb 2020 12:45:33 +0000
From:   David Howells <dhowells@...hat.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     dhowells@...hat.com, viro@...iv.linux.org.uk, raven@...maw.net,
        mszeredi@...hat.com, christian@...uner.io,
        linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/19] vfs: Introduce a non-repeating system-unique superblock ID [ver #16]

Darrick J. Wong <darrick.wong@...cle.com> wrote:

> Ahah, this is what the f_sb_id field is for.  I noticed a few patches
> ago that it was in a header file but was never set.
> 
> I'm losing track of which IDs do what...
> 
> * f_fsid is that old int[2] thing that we used for statfs.  It sucks but
>   we can't remove it because it's been in statfs since the beginning of
>   time.
> 
> * f_fs_name is a string coming from s_type, which is the name of the fs
>   (e.g. "XFS")?
> 
> * f_fstype comes from s_magic, which (for XFS) is 0x58465342.
> 
> * f_sb_id is basically an incore u64 cookie that one can use with the
>   mount events thing that comes later in this patchset?
> 
> * FSINFO_ATTR_VOLUME_ID comes from s_id, which tends to be the block
>   device name (at least for local filesystems)
> 
> * FSINFO_ATTR_VOLUME_UUID comes from s_uuid, which some filesystems fill
>   in at mount time.
> 
> * FSINFO_ATTR_VOLUME_NAME is ... left to individual filesystems to
>   implement, and (AFAICT) can be the label that one uses for things
>   like: "mount LABEL=foo /home" ?
> 
> Assuming I got all of that right, can we please capture what all of
> these "IDs" mean in the documentation?

Basically, yes.  Would it help if I:

 (1) Put the ID generation into its own patch, first.

 (2) Put the notification counter patches right after that.

 (3) Renamed the fields a bit, say:

	f_fsid		-> fsid
	f_fs_name	-> filesystem_name
	f_fstype	-> filesystem_magic
	f_sb_id		-> superblock_id
	f_dev_*		-> backing_dev_*

David