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  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]
Date:   Wed, 17 Jun 2020 12:55:24 -0500
From:   Eric Sandeen <>
To:     "Darrick J. Wong" <>
Cc:     "J. Bruce Fields" <>,
        Christoph Hellwig <>,
        Masayoshi Mizuma <>,
        Theodore Ts'o <>,
        Andreas Dilger <>,
        Alexander Viro <>,
        Masayoshi Mizuma <>,,,
        linux-xfs <>
Subject: Re: [PATCH] fs: i_version mntopt gets visible through /proc/mounts

On 6/17/20 12:24 PM, Darrick J. Wong wrote:
> On Wed, Jun 17, 2020 at 12:14:28PM -0500, Eric Sandeen wrote:
>> On 6/17/20 10:58 AM, J. Bruce Fields wrote:
>>> On Wed, Jun 17, 2020 at 01:03:14AM -0700, Christoph Hellwig wrote:
>>>> On Tue, Jun 16, 2020 at 04:21:23PM -0400, Masayoshi Mizuma wrote:
>>>>> From: Masayoshi Mizuma <>
>>>>> /proc/mounts doesn't show 'i_version' even if iversion
>>>>> mount option is set to XFS.
>>>>> iversion mount option is a VFS option, not ext4 specific option.
>>>>> Move the handler to show_sb_opts() so that /proc/mounts can show
>>>>> 'i_version' on not only ext4 but also the other filesystem.
>>>> SB_I_VERSION is a kernel internal flag.  XFS doesn't have an i_version
>>>> mount option.
>>> It probably *should* be a kernel internal flag, but it seems to work as
>>> a mount option too.
>> Not on XFS AFAICT:
>> [600280.685810] xfs: Unknown parameter 'i_version'
> Yeah, because the mount option is 'iversion', not 'i_version'.  Even if

unless you're ext4:

{Opt_i_version, "i_version"},

ok "iversion" is what mount(8) takes and translates into MS_I_VERSION (thanks Darrick)

# strace -vv -emount mount -oloop,iversion fsfile mnt
mount("/dev/loop0", "/tmp/mnt", "xfs", MS_I_VERSION, NULL) = 0

FWIW, mount actually seems to pass what it finds in /proc/mounts back in on remount for ext4:

# strace -vv -emount mount -o remount mnt
mount("/dev/loop0", "/tmp/mnt", 0x55bfcbdca150, MS_REMOUNT|MS_RELATIME, "seclabel,i_version,data=ordered") = 0

but it still looks unhandled on remount.  Perhaps if /proc/mounts exposed
"iversion" (not "i_version") then mount -o remount would DTRT.


> you were going to expose the flag state in /proc/mounts, the text string
> should match the mount option.
>> so we can't be exporting "mount options" for xfs that aren't actually
>> going to be accepted by the filesystem.
>>> By coincidence I've just been looking at a bug report showing that
>>> i_version support is getting accidentally turned off on XFS whenever
>>> userspace does a read-write remount.
>>> Is there someplace in the xfs mount code where it should be throwing out
>> <cc xfs list>
>> XFS doesn't manipulate that flag on remount.  We just turn it on by default
>> for modern filesystem formats:
>>         /* version 5 superblocks support inode version counters. */
>>         if (XFS_SB_VERSION_NUM(&mp->m_sb) == XFS_SB_VERSION_5)
>>                 sb->s_flags |= SB_I_VERSION;
>> Also, this behavior doesn't seem unique to xfs:
>> # mount -o loop,i_version fsfile test_iversion
>> # grep test_iversion /proc/mounts
>> /dev/loop4 /tmp/test_iversion ext4 rw,seclabel,relatime,i_version 0 0
>> # mount -o remount test_iversion
>> # grep test_iversion /proc/mounts
>> /dev/loop4 /tmp/test_iversion ext4 rw,seclabel,relatime 0 0
>> # uname -a
>> Linux <hostname> 5.7.0-rc4+ #7 SMP Wed Jun 10 14:01:34 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
> Probably because do_mount clears it and I guess xfs don't re-enable
> it in any of their remount functions...

Powered by blists - more mailing lists