linux-kernel - inconsistent behavior of MS_RELATIME F

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>] [day] [month] [year] [list]

Date:	Thu, 26 May 2011 10:44:14 -0700
From:	Dave Rawks <dave@...dora.com>
To:	linux-kernel@...r.kernel.org
Subject: inconsistent behavior of MS_RELATIME F_FLAG

	I've been trying to figure this out for the past few days and I'm at a
loss as to what exactly the expected behavior of the MS_RELATIME bit in
F_FLAG is supposed to reflect when I stat a mounted filesystem. The
comments in fs.h state that the MS_RELATIME flag is one of the
filesystem independent flags available in the regular 32 bit F_FLAG
mask. However observationally I notice that /proc/mounts indicates that
relatime is set even on mount which return 0 for the relatime bit when
stat'd.

For instance:

/etc/fstab:
>/dev/sda3 /var            ext3    defaults        0       2

/proc/mounts:
> /dev/sda3 /var ext3 rw,relatime,errors=continue,data=ordered 0 0

yet when I stat the filesystem (excuse my python):

> >>> import os,statvfs
> >>> os.statvfs('/var')[statvfs.F_FLAG]
> 4096
> >>> 4096 & (1<<21)
> 0


>From a quick search back through the list archive, I see that the
default atime behavior has been a contentious subject at times, but I'm
left wondering how we came to a state where apparently relatime is the
default but the normal programmatic way of interrogating the mount's
state does not reflect that.

Any insight would be greatly appreciated. Also, this is my first post to
lkml so I apologize in advance if I've asked in the wrong place.

-Dave Rawks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/