Star64_linux/Documentation/filesystems
Michal Hocko 7550c60798 mm, proc: be more verbose about unstable VMA flags in /proc/<pid>/smaps
Patch series "THP eligibility reporting via proc".

This series of three patches aims at making THP eligibility reporting much
more robust and long term sustainable.  The trigger for the change is a
regression report [2] and the long follow up discussion.  In short the
specific application didn't have good API to query whether a particular
mapping can be backed by THP so it has used VMA flags to workaround that.
These flags represent a deep internal state of VMAs and as such they
should be used by userspace with a great deal of caution.

A similar has happened for [3] when users complained that VM_MIXEDMAP is
no longer set on DAX mappings.  Again a lack of a proper API led to an
abuse.

The first patch in the series tries to emphasise that that the semantic of
flags might change and any application consuming those should be really
careful.

The remaining two patches provide a more suitable interface to address [2]
and provide a consistent API to query the THP status both for each VMA and
process wide as well.  [1]

http://lkml.kernel.org/r/20181120103515.25280-1-mhocko@kernel.org [2]
http://lkml.kernel.org/r/http://lkml.kernel.org/r/alpine.DEB.2.21.1809241054050.224429@chino.kir.corp.google.com
[3] http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz

This patch (of 3):

Even though vma flags exported via /proc/<pid>/smaps are explicitly
documented to be not guaranteed for future compatibility the warning
doesn't go far enough because it doesn't mention semantic changes to those
flags.  And they are important as well because these flags are a deep
implementation internal to the MM code and the semantic might change at
any time.

Let's consider two recent examples:
http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz
: commit e1fb4a0864 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
: removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
: mean time certain customer of ours started poking into /proc/<pid>/smaps
: and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
: flags, the application just fails to start complaining that DAX support is
: missing in the kernel.

http://lkml.kernel.org/r/alpine.DEB.2.21.1809241054050.224429@chino.kir.corp.google.com
: Commit 1860033237 ("mm: make PR_SET_THP_DISABLE immediately active")
: introduced a regression in that userspace cannot always determine the set
: of vmas where thp is ineligible.
: Userspace relies on the "nh" flag being emitted as part of /proc/pid/smaps
: to determine if a vma is eligible to be backed by hugepages.
: Previous to this commit, prctl(PR_SET_THP_DISABLE, 1) would cause thp to
: be disabled and emit "nh" as a flag for the corresponding vmas as part of
: /proc/pid/smaps.  After the commit, thp is disabled by means of an mm
: flag and "nh" is not emitted.
: This causes smaps parsing libraries to assume a vma is eligible for thp
: and ends up puzzling the user on why its memory is not backed by thp.

In both cases userspace was relying on a semantic of a specific VMA flag.
The primary reason why that happened is a lack of a proper interface.
While this has been worked on and it will be fixed properly, it seems that
our wording could see some refinement and be more vocal about semantic
aspect of these flags as well.

Link: http://lkml.kernel.org/r/20181211143641.3503-2-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Paul Oppenheimer <bepvte@gmail.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-12-28 12:11:50 -08:00
..
caching
cifs
configfs
ext4
nfs Olga added support for the NFSv4.2 asynchronous copy protocol. We 2018-10-30 13:03:29 -07:00
9p.txt
adfs.txt
affs.txt
afs.txt
autofs-mount-control.txt
autofs.txt
automount-support.txt
befs.txt
bfs.txt
btrfs.txt
ceph.txt
coda.txt
conf.py
cramfs.txt
dax.txt
debugfs.txt
devpts.txt
directory-locking
dlmfs.txt
dnotify.txt
ecryptfs.txt
efivarfs.txt
exofs.txt
ext2.txt
ext3.txt
f2fs.txt
fiemap.txt
files.txt
fscrypt.rst
fuse-io.txt
fuse.txt
gfs2-glocks.txt
gfs2-uevents.txt
gfs2.txt
hfs.txt
hfsplus.txt
hpfs.txt
index.rst
inotify.txt
isofs.txt
jfs.txt
Locking
locks.txt
mandatory-locking.txt
nilfs2.txt
ntfs.txt
ocfs2-online-filecheck.txt
ocfs2.txt
omfs.txt
orangefs.txt
overlayfs.txt ovl: automatically enable redirect_dir on metacopy=on 2018-11-01 21:31:39 +01:00
path-lookup.md
path-lookup.txt
porting vfs: rework data cloning infrastructure 2018-11-02 09:33:08 -07:00
proc.txt mm, proc: be more verbose about unstable VMA flags in /proc/<pid>/smaps 2018-12-28 12:11:50 -08:00
qnx6.txt
quota.txt
ramfs-rootfs-initramfs.txt
relay.txt
romfs.txt
seq_file.txt
sharedsubtree.txt
spufs.txt
squashfs.txt
sysfs-pci.txt
sysfs-tagging.txt
sysfs.txt
sysv-fs.txt
tmpfs.txt
ubifs-authentication.md
ubifs.txt
udf.txt
ufs.txt
vfat.txt
vfs.txt vfs: enable remap callers that can handle short operations 2018-10-30 10:42:10 +11:00
xfs-delayed-logging-design.txt
xfs-self-describing-metadata.txt
xfs.txt