2013-04-11 20:34:43 +08:00
|
|
|
/* Internal procfs definitions
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
|
* Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
|
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/proc_fs.h>
|
2013-04-11 20:34:43 +08:00
|
|
|
#include <linux/proc_ns.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/atomic.h>
|
2013-02-28 09:03:15 +08:00
|
|
|
#include <linux/binfmts.h>
|
2017-02-09 01:51:30 +08:00
|
|
|
#include <linux/sched/coredump.h>
|
2017-02-06 17:57:33 +08:00
|
|
|
#include <linux/sched/task.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
struct ctl_table_header;
|
|
|
|
|
struct mempolicy;
|
2007-02-14 16:34:12 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/*
|
|
|
|
|
* This is not completely implemented yet. The idea is to
|
|
|
|
|
* create an in-memory tree (like the actual /proc filesystem
|
|
|
|
|
* tree) of these proc_dir_entries, so that we can dynamically
|
|
|
|
|
* add new files to /proc.
|
|
|
|
|
*
|
2014-12-11 07:45:01 +08:00
|
|
|
* parent/subdir are used for the directory structure (every /proc file has a
|
|
|
|
|
* parent, but "subdir" is empty for all non-directory entries).
|
|
|
|
|
* subdir_node is used to build the rb tree "subdir" of the parent.
|
2013-04-11 20:34:43 +08:00
|
|
|
*/
|
|
|
|
|
struct proc_dir_entry {
|
|
|
|
|
unsigned int low_ino;
|
|
|
|
|
umode_t mode;
|
|
|
|
|
nlink_t nlink;
|
|
|
|
|
kuid_t uid;
|
|
|
|
|
kgid_t gid;
|
|
|
|
|
loff_t size;
|
|
|
|
|
const struct inode_operations *proc_iops;
|
|
|
|
|
const struct file_operations *proc_fops;
|
2014-12-11 07:45:01 +08:00
|
|
|
struct proc_dir_entry *parent;
|
|
|
|
|
struct rb_root subdir;
|
|
|
|
|
struct rb_node subdir_node;
|
2013-04-11 20:34:43 +08:00
|
|
|
void *data;
|
|
|
|
|
atomic_t count; /* use count */
|
|
|
|
|
atomic_t in_use; /* number of callers into module in progress; */
|
|
|
|
|
/* negative -> it's going away RSN */
|
|
|
|
|
struct completion *pde_unload_completion;
|
|
|
|
|
struct list_head pde_openers; /* who did ->open, but not ->release */
|
|
|
|
|
spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
|
|
|
|
|
u8 namelen;
|
|
|
|
|
char name[];
|
2016-10-28 16:22:25 +08:00
|
|
|
} __randomize_layout;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
union proc_op {
|
|
|
|
|
int (*proc_get_link)(struct dentry *, struct path *);
|
|
|
|
|
int (*proc_show)(struct seq_file *m,
|
|
|
|
|
struct pid_namespace *ns, struct pid *pid,
|
|
|
|
|
struct task_struct *task);
|
|
|
|
|
};
|
2006-06-26 15:25:55 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
struct proc_inode {
|
2011-05-25 08:12:48 +08:00
|
|
|
struct pid *pid;
|
2016-09-02 05:42:02 +08:00
|
|
|
unsigned int fd;
|
2013-04-11 20:34:43 +08:00
|
|
|
union proc_op op;
|
|
|
|
|
struct proc_dir_entry *pde;
|
|
|
|
|
struct ctl_table_header *sysctl;
|
|
|
|
|
struct ctl_table *sysctl_entry;
|
2017-07-06 21:41:06 +08:00
|
|
|
struct hlist_node sysctl_inodes;
|
2014-11-01 23:10:28 +08:00
|
|
|
const struct proc_ns_operations *ns_ops;
|
2013-04-11 20:34:43 +08:00
|
|
|
struct inode vfs_inode;
|
2016-10-28 16:22:25 +08:00
|
|
|
} __randomize_layout;
|
2011-05-25 08:12:48 +08:00
|
|
|
|
2013-04-13 01:03:36 +08:00
|
|
|
/*
|
|
|
|
|
* General functions
|
|
|
|
|
*/
|
|
|
|
|
static inline struct proc_inode *PROC_I(const struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
return container_of(inode, struct proc_inode, vfs_inode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct proc_dir_entry *PDE(const struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
return PROC_I(inode)->pde;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void *__PDE_DATA(const struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
return PDE(inode)->data;
|
|
|
|
|
}
|
2006-01-08 17:04:16 +08:00
|
|
|
|
2006-06-26 15:25:56 +08:00
|
|
|
static inline struct pid *proc_pid(struct inode *inode)
|
2006-06-26 15:25:55 +08:00
|
|
|
{
|
2006-06-26 15:25:56 +08:00
|
|
|
return PROC_I(inode)->pid;
|
2006-06-26 15:25:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct task_struct *get_proc_task(struct inode *inode)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-06-26 15:25:56 +08:00
|
|
|
return get_pid_task(proc_pid(inode), PIDTYPE_PID);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2017-01-03 05:23:11 +08:00
|
|
|
void task_dump_owner(struct task_struct *task, mode_t mode,
|
|
|
|
|
kuid_t *ruid, kgid_t *rgid);
|
2012-08-23 18:43:24 +08:00
|
|
|
|
2014-08-09 05:21:25 +08:00
|
|
|
static inline unsigned name_to_int(const struct qstr *qstr)
|
2012-08-23 18:43:24 +08:00
|
|
|
{
|
2014-08-09 05:21:25 +08:00
|
|
|
const char *name = qstr->name;
|
|
|
|
|
int len = qstr->len;
|
2012-08-23 18:43:24 +08:00
|
|
|
unsigned n = 0;
|
|
|
|
|
|
|
|
|
|
if (len > 1 && *name == '0')
|
|
|
|
|
goto out;
|
|
|
|
|
while (len-- > 0) {
|
|
|
|
|
unsigned c = *name++ - '0';
|
|
|
|
|
if (c > 9)
|
|
|
|
|
goto out;
|
|
|
|
|
if (n >= (~0U-9)/10)
|
|
|
|
|
goto out;
|
|
|
|
|
n *= 10;
|
|
|
|
|
n += c;
|
|
|
|
|
}
|
|
|
|
|
return n;
|
|
|
|
|
out:
|
|
|
|
|
return ~0U;
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-12 08:08:50 +08:00
|
|
|
/*
|
2013-04-11 20:34:43 +08:00
|
|
|
* Offset of the first process in the /proc root directory..
|
2013-04-12 08:08:50 +08:00
|
|
|
*/
|
2013-04-11 20:34:43 +08:00
|
|
|
#define FIRST_PROCESS_ENTRY 256
|
2013-04-12 08:08:50 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/* Worst case buffer size needed for holding an integer. */
|
|
|
|
|
#define PROC_NUMBUF 13
|
2008-07-25 16:48:29 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/*
|
|
|
|
|
* array.c
|
|
|
|
|
*/
|
|
|
|
|
extern const struct file_operations proc_tid_children_operations;
|
2009-04-08 01:19:18 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
extern int proc_tid_stat(struct seq_file *, struct pid_namespace *,
|
|
|
|
|
struct pid *, struct task_struct *);
|
|
|
|
|
extern int proc_tgid_stat(struct seq_file *, struct pid_namespace *,
|
|
|
|
|
struct pid *, struct task_struct *);
|
|
|
|
|
extern int proc_pid_status(struct seq_file *, struct pid_namespace *,
|
|
|
|
|
struct pid *, struct task_struct *);
|
|
|
|
|
extern int proc_pid_statm(struct seq_file *, struct pid_namespace *,
|
|
|
|
|
struct pid *, struct task_struct *);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* base.c
|
|
|
|
|
*/
|
|
|
|
|
extern const struct dentry_operations pid_dentry_operations;
|
statx: Add a system call to make enhanced file info available
Add a system call to make extended file information available, including
file creation and some attribute flags where available through the
underlying filesystem.
The getattr inode operation is altered to take two additional arguments: a
u32 request_mask and an unsigned int flags that indicate the
synchronisation mode. This change is propagated to the vfs_getattr*()
function.
Functions like vfs_stat() are now inline wrappers around new functions
vfs_statx() and vfs_statx_fd() to reduce stack usage.
========
OVERVIEW
========
The idea was initially proposed as a set of xattrs that could be retrieved
with getxattr(), but the general preference proved to be for a new syscall
with an extended stat structure.
A number of requests were gathered for features to be included. The
following have been included:
(1) Make the fields a consistent size on all arches and make them large.
(2) Spare space, request flags and information flags are provided for
future expansion.
(3) Better support for the y2038 problem [Arnd Bergmann] (tv_sec is an
__s64).
(4) Creation time: The SMB protocol carries the creation time, which could
be exported by Samba, which will in turn help CIFS make use of
FS-Cache as that can be used for coherency data (stx_btime).
This is also specified in NFSv4 as a recommended attribute and could
be exported by NFSD [Steve French].
(5) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
Dilger] (AT_STATX_DONT_SYNC).
(6) Heavyweight stat: Force a netfs to go to the server, even if it thinks
its cached attributes are up to date [Trond Myklebust]
(AT_STATX_FORCE_SYNC).
And the following have been left out for future extension:
(7) Data version number: Could be used by userspace NFS servers [Aneesh
Kumar].
Can also be used to modify fill_post_wcc() in NFSD which retrieves
i_version directly, but has just called vfs_getattr(). It could get
it from the kstat struct if it used vfs_xgetattr() instead.
(There's disagreement on the exact semantics of a single field, since
not all filesystems do this the same way).
(8) BSD stat compatibility: Including more fields from the BSD stat such
as creation time (st_btime) and inode generation number (st_gen)
[Jeremy Allison, Bernd Schubert].
(9) Inode generation number: Useful for FUSE and userspace NFS servers
[Bernd Schubert].
(This was asked for but later deemed unnecessary with the
open-by-handle capability available and caused disagreement as to
whether it's a security hole or not).
(10) Extra coherency data may be useful in making backups [Andreas Dilger].
(No particular data were offered, but things like last backup
timestamp, the data version number and the DOS archive bit would come
into this category).
(11) Allow the filesystem to indicate what it can/cannot provide: A
filesystem can now say it doesn't support a standard stat feature if
that isn't available, so if, for instance, inode numbers or UIDs don't
exist or are fabricated locally...
(This requires a separate system call - I have an fsinfo() call idea
for this).
(12) Store a 16-byte volume ID in the superblock that can be returned in
struct xstat [Steve French].
(Deferred to fsinfo).
(13) Include granularity fields in the time data to indicate the
granularity of each of the times (NFSv4 time_delta) [Steve French].
(Deferred to fsinfo).
(14) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
Note that the Linux IOC flags are a mess and filesystems such as Ext4
define flags that aren't in linux/fs.h, so translation in the kernel
may be a necessity (or, possibly, we provide the filesystem type too).
(Some attributes are made available in stx_attributes, but the general
feeling was that the IOC flags were to ext[234]-specific and shouldn't
be exposed through statx this way).
(15) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
Michael Kerrisk].
(Deferred, probably to fsinfo. Finding out if there's an ACL or
seclabal might require extra filesystem operations).
(16) Femtosecond-resolution timestamps [Dave Chinner].
(A __reserved field has been left in the statx_timestamp struct for
this - if there proves to be a need).
(17) A set multiple attributes syscall to go with this.
===============
NEW SYSTEM CALL
===============
The new system call is:
int ret = statx(int dfd,
const char *filename,
unsigned int flags,
unsigned int mask,
struct statx *buffer);
The dfd, filename and flags parameters indicate the file to query, in a
similar way to fstatat(). There is no equivalent of lstat() as that can be
emulated with statx() by passing AT_SYMLINK_NOFOLLOW in flags. There is
also no equivalent of fstat() as that can be emulated by passing a NULL
filename to statx() with the fd of interest in dfd.
Whether or not statx() synchronises the attributes with the backing store
can be controlled by OR'ing a value into the flags argument (this typically
only affects network filesystems):
(1) AT_STATX_SYNC_AS_STAT tells statx() to behave as stat() does in this
respect.
(2) AT_STATX_FORCE_SYNC will require a network filesystem to synchronise
its attributes with the server - which might require data writeback to
occur to get the timestamps correct.
(3) AT_STATX_DONT_SYNC will suppress synchronisation with the server in a
network filesystem. The resulting values should be considered
approximate.
mask is a bitmask indicating the fields in struct statx that are of
interest to the caller. The user should set this to STATX_BASIC_STATS to
get the basic set returned by stat(). It should be noted that asking for
more information may entail extra I/O operations.
buffer points to the destination for the data. This must be 256 bytes in
size.
======================
MAIN ATTRIBUTES RECORD
======================
The following structures are defined in which to return the main attribute
set:
struct statx_timestamp {
__s64 tv_sec;
__s32 tv_nsec;
__s32 __reserved;
};
struct statx {
__u32 stx_mask;
__u32 stx_blksize;
__u64 stx_attributes;
__u32 stx_nlink;
__u32 stx_uid;
__u32 stx_gid;
__u16 stx_mode;
__u16 __spare0[1];
__u64 stx_ino;
__u64 stx_size;
__u64 stx_blocks;
__u64 __spare1[1];
struct statx_timestamp stx_atime;
struct statx_timestamp stx_btime;
struct statx_timestamp stx_ctime;
struct statx_timestamp stx_mtime;
__u32 stx_rdev_major;
__u32 stx_rdev_minor;
__u32 stx_dev_major;
__u32 stx_dev_minor;
__u64 __spare2[14];
};
The defined bits in request_mask and stx_mask are:
STATX_TYPE Want/got stx_mode & S_IFMT
STATX_MODE Want/got stx_mode & ~S_IFMT
STATX_NLINK Want/got stx_nlink
STATX_UID Want/got stx_uid
STATX_GID Want/got stx_gid
STATX_ATIME Want/got stx_atime{,_ns}
STATX_MTIME Want/got stx_mtime{,_ns}
STATX_CTIME Want/got stx_ctime{,_ns}
STATX_INO Want/got stx_ino
STATX_SIZE Want/got stx_size
STATX_BLOCKS Want/got stx_blocks
STATX_BASIC_STATS [The stuff in the normal stat struct]
STATX_BTIME Want/got stx_btime{,_ns}
STATX_ALL [All currently available stuff]
stx_btime is the file creation time, stx_mask is a bitmask indicating the
data provided and __spares*[] are where as-yet undefined fields can be
placed.
Time fields are structures with separate seconds and nanoseconds fields
plus a reserved field in case we want to add even finer resolution. Note
that times will be negative if before 1970; in such a case, the nanosecond
fields will also be negative if not zero.
The bits defined in the stx_attributes field convey information about a
file, how it is accessed, where it is and what it does. The following
attributes map to FS_*_FL flags and are the same numerical value:
STATX_ATTR_COMPRESSED File is compressed by the fs
STATX_ATTR_IMMUTABLE File is marked immutable
STATX_ATTR_APPEND File is append-only
STATX_ATTR_NODUMP File is not to be dumped
STATX_ATTR_ENCRYPTED File requires key to decrypt in fs
Within the kernel, the supported flags are listed by:
KSTAT_ATTR_FS_IOC_FLAGS
[Are any other IOC flags of sufficient general interest to be exposed
through this interface?]
New flags include:
STATX_ATTR_AUTOMOUNT Object is an automount trigger
These are for the use of GUI tools that might want to mark files specially,
depending on what they are.
Fields in struct statx come in a number of classes:
(0) stx_dev_*, stx_blksize.
These are local system information and are always available.
(1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time, stx_ino,
stx_size, stx_blocks.
These will be returned whether the caller asks for them or not. The
corresponding bits in stx_mask will be set to indicate whether they
actually have valid values.
If the caller didn't ask for them, then they may be approximated. For
example, NFS won't waste any time updating them from the server,
unless as a byproduct of updating something requested.
If the values don't actually exist for the underlying object (such as
UID or GID on a DOS file), then the bit won't be set in the stx_mask,
even if the caller asked for the value. In such a case, the returned
value will be a fabrication.
Note that there are instances where the type might not be valid, for
instance Windows reparse points.
(2) stx_rdev_*.
This will be set only if stx_mode indicates we're looking at a
blockdev or a chardev, otherwise will be 0.
(3) stx_btime.
Similar to (1), except this will be set to 0 if it doesn't exist.
=======
TESTING
=======
The following test program can be used to test the statx system call:
samples/statx/test-statx.c
Just compile and run, passing it paths to the files you want to examine.
The file is built automatically if CONFIG_SAMPLES is enabled.
Here's some example output. Firstly, an NFS directory that crosses to
another FSID. Note that the AUTOMOUNT attribute is set because transiting
this directory will cause d_automount to be invoked by the VFS.
[root@andromeda ~]# /tmp/test-statx -A /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:26 Inode: 1703937 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Attributes: 0000000000001000 (-------- -------- -------- -------- -------- -------- ---m---- --------)
Secondly, the result of automounting on that directory.
[root@andromeda ~]# /tmp/test-statx /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:27 Inode: 2 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-02-01 00:46:22 +08:00
|
|
|
extern int pid_getattr(const struct path *, struct kstat *, u32, unsigned int);
|
2013-04-11 20:34:43 +08:00
|
|
|
extern int proc_setattr(struct dentry *, struct iattr *);
|
2016-11-11 05:18:28 +08:00
|
|
|
extern struct inode *proc_pid_make_inode(struct super_block *, struct task_struct *, umode_t);
|
2013-04-11 20:34:43 +08:00
|
|
|
extern int pid_revalidate(struct dentry *, unsigned int);
|
|
|
|
|
extern int pid_delete_dentry(const struct dentry *);
|
2013-05-17 00:07:31 +08:00
|
|
|
extern int proc_pid_readdir(struct file *, struct dir_context *);
|
2013-04-11 20:34:43 +08:00
|
|
|
extern struct dentry *proc_pid_lookup(struct inode *, struct dentry *, unsigned int);
|
|
|
|
|
extern loff_t mem_lseek(struct file *, loff_t, int);
|
2013-04-04 07:07:30 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/* Lookups */
|
2013-06-15 15:15:20 +08:00
|
|
|
typedef int instantiate_t(struct inode *, struct dentry *,
|
2013-04-11 20:34:43 +08:00
|
|
|
struct task_struct *, const void *);
|
2013-05-17 00:07:31 +08:00
|
|
|
extern bool proc_fill_cache(struct file *, struct dir_context *, const char *, int,
|
2013-04-11 20:34:43 +08:00
|
|
|
instantiate_t, struct task_struct *, const void *);
|
2009-04-08 01:19:18 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/*
|
|
|
|
|
* generic.c
|
|
|
|
|
*/
|
|
|
|
|
extern struct dentry *proc_lookup(struct inode *, struct dentry *, unsigned int);
|
|
|
|
|
extern struct dentry *proc_lookup_de(struct proc_dir_entry *, struct inode *,
|
|
|
|
|
struct dentry *);
|
2013-05-17 00:07:31 +08:00
|
|
|
extern int proc_readdir(struct file *, struct dir_context *);
|
|
|
|
|
extern int proc_readdir_de(struct proc_dir_entry *, struct file *, struct dir_context *);
|
2009-04-08 01:19:18 +08:00
|
|
|
|
2009-12-16 08:45:39 +08:00
|
|
|
static inline struct proc_dir_entry *pde_get(struct proc_dir_entry *pde)
|
|
|
|
|
{
|
|
|
|
|
atomic_inc(&pde->count);
|
|
|
|
|
return pde;
|
|
|
|
|
}
|
2013-04-11 20:34:43 +08:00
|
|
|
extern void pde_put(struct proc_dir_entry *);
|
2009-04-08 01:19:18 +08:00
|
|
|
|
2015-05-12 05:44:25 +08:00
|
|
|
static inline bool is_empty_pde(const struct proc_dir_entry *pde)
|
|
|
|
|
{
|
|
|
|
|
return S_ISDIR(pde->mode) && !pde->proc_iops;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-08 01:19:18 +08:00
|
|
|
/*
|
2013-04-11 20:34:43 +08:00
|
|
|
* inode.c
|
2009-04-08 01:19:18 +08:00
|
|
|
*/
|
2013-04-11 20:34:43 +08:00
|
|
|
struct pde_opener {
|
|
|
|
|
struct file *file;
|
|
|
|
|
struct list_head lh;
|
2016-12-13 08:45:17 +08:00
|
|
|
bool closing;
|
2013-04-11 20:34:43 +08:00
|
|
|
struct completion *c;
|
|
|
|
|
};
|
2015-02-22 11:16:11 +08:00
|
|
|
extern const struct inode_operations proc_link_inode_operations;
|
2010-03-08 08:41:34 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
extern const struct inode_operations proc_pid_link_inode_operations;
|
2010-03-08 08:41:34 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
extern void proc_init_inodecache(void);
|
2016-12-13 08:45:32 +08:00
|
|
|
void set_proc_pid_nlink(void);
|
2013-04-11 20:34:43 +08:00
|
|
|
extern struct inode *proc_get_inode(struct super_block *, struct proc_dir_entry *);
|
2016-06-10 04:32:10 +08:00
|
|
|
extern int proc_fill_super(struct super_block *, void *data, int flags);
|
2013-04-11 20:34:43 +08:00
|
|
|
extern void proc_entry_rundown(struct proc_dir_entry *);
|
2010-03-08 08:41:34 +08:00
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/*
|
|
|
|
|
* proc_namespaces.c
|
|
|
|
|
*/
|
2010-03-08 08:41:34 +08:00
|
|
|
extern const struct inode_operations proc_ns_dir_inode_operations;
|
|
|
|
|
extern const struct file_operations proc_ns_dir_operations;
|
|
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
/*
|
|
|
|
|
* proc_net.c
|
|
|
|
|
*/
|
|
|
|
|
extern const struct file_operations proc_net_operations;
|
|
|
|
|
extern const struct inode_operations proc_net_inode_operations;
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_NET
|
|
|
|
|
extern int proc_net_init(void);
|
|
|
|
|
#else
|
|
|
|
|
static inline int proc_net_init(void) { return 0; }
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* proc_self.c
|
|
|
|
|
*/
|
2013-03-30 07:27:05 +08:00
|
|
|
extern int proc_setup_self(struct super_block *);
|
2013-04-12 09:29:19 +08:00
|
|
|
|
2014-07-31 18:10:50 +08:00
|
|
|
/*
|
|
|
|
|
* proc_thread_self.c
|
|
|
|
|
*/
|
|
|
|
|
extern int proc_setup_thread_self(struct super_block *);
|
|
|
|
|
extern void proc_thread_self_init(void);
|
|
|
|
|
|
2013-04-12 09:29:19 +08:00
|
|
|
/*
|
2013-04-11 20:34:43 +08:00
|
|
|
* proc_sysctl.c
|
2013-04-12 09:29:19 +08:00
|
|
|
*/
|
2013-04-11 20:34:43 +08:00
|
|
|
#ifdef CONFIG_PROC_SYSCTL
|
|
|
|
|
extern int proc_sys_init(void);
|
2017-02-10 15:35:02 +08:00
|
|
|
extern void proc_sys_evict_inode(struct inode *inode,
|
|
|
|
|
struct ctl_table_header *head);
|
2013-04-11 20:34:43 +08:00
|
|
|
#else
|
|
|
|
|
static inline void proc_sys_init(void) { }
|
2017-02-10 15:35:02 +08:00
|
|
|
static inline void proc_sys_evict_inode(struct inode *inode,
|
|
|
|
|
struct ctl_table_header *head) { }
|
2013-04-11 20:34:43 +08:00
|
|
|
#endif
|
2013-04-12 09:29:19 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* proc_tty.c
|
|
|
|
|
*/
|
|
|
|
|
#ifdef CONFIG_TTY
|
|
|
|
|
extern void proc_tty_init(void);
|
|
|
|
|
#else
|
|
|
|
|
static inline void proc_tty_init(void) {}
|
|
|
|
|
#endif
|
2013-04-11 20:34:43 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* root.c
|
|
|
|
|
*/
|
|
|
|
|
extern struct proc_dir_entry proc_root;
|
2016-06-10 04:32:10 +08:00
|
|
|
extern int proc_parse_options(char *options, struct pid_namespace *pid);
|
2013-04-11 20:34:43 +08:00
|
|
|
|
|
|
|
|
extern void proc_self_init(void);
|
|
|
|
|
extern int proc_remount(struct super_block *, int *, char *);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* task_[no]mmu.c
|
|
|
|
|
*/
|
mm: add /proc/pid/smaps_rollup
/proc/pid/smaps_rollup is a new proc file that improves the performance
of user programs that determine aggregate memory statistics (e.g., total
PSS) of a process.
Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.
smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all of
the real-smaps VMAs. Using a common format for smaps_rollup and smaps
allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.
By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a large
process's potentially very numerous memory mappings. For sampling
system_server's PSS in Android, we measured a 12x speedup, representing
a savings of several hundred milliseconds.
One alternative to a new per-process proc file would have been including
PSS information in /proc/pid/status. We considered this option but
thought that PSS would be too expensive (by a few orders of magnitude)
to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.
The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for each
VMA. In this way, summation happens automatically. We let seq_file
walk over the VMAs just as it does for regular smaps and just emit
nothing to the seq_file until we hit the last VMA.
Benchmarks:
using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system
using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system
We're using the PSS samples we collect asynchronously for
system-management tasks like fine-tuning oom_adj_score, memory use
tracking for debugging, application-level memory-use attribution, and
deciding whether we want to kill large processes during system idle
maintenance windows. Android has been using PSS for these purposes for
a long time; as the average process VMA count has increased and and
devices become more efficiency-conscious, PSS-collection inefficiency
has started to matter more. IMHO, it'd be a lot safer to optimize the
existing PSS-collection model, which has been fine-tuned over the years,
instead of changing the memory tracking approach entirely to work around
smaps-generation inefficiency.
Tim said:
: There are two main reasons why Android gathers PSS information:
:
: 1. Android devices can show the user the amount of memory used per
: application via the settings app. This is a less important use case.
:
: 2. We log PSS to help identify leaks in applications. We have found
: an enormous number of bugs (in the Android platform, in Google's own
: apps, and in third-party applications) using this data.
:
: To do this, system_server (the main process in Android userspace) will
: sample the PSS of a process three seconds after it changes state (for
: example, app is launched and becomes the foreground application) and about
: every ten minutes after that. The net result is that PSS collection is
: regularly running on at least one process in the system (usually a few
: times a minute while the screen is on, less when screen is off due to
: suspend). PSS of a process is an incredibly useful stat to track, and we
: aren't going to get rid of it. We've looked at some very hacky approaches
: using RSS ("take the RSS of the target process, subtract the RSS of the
: zygote process that is the parent of all Android apps") to reduce the
: accounting time, but it regularly overestimated the memory used by 20+
: percent. Accordingly, I don't think that there's a good alternative to
: using PSS.
:
: We started looking into PSS collection performance after we noticed random
: frequency spikes while a phone's screen was off; occasionally, one of the
: CPU clusters would ramp to a high frequency because there was 200-300ms of
: constant CPU work from a single thread in the main Android userspace
: process. The work causing the spike (which is reasonable governor
: behavior given the amount of CPU time needed) was always PSS collection.
: As a result, Android is burning more power than we should be on PSS
: collection.
:
: The other issue (and why I'm less sure about improving smaps as a
: long-term solution) is that the number of VMAs per process has increased
: significantly from release to release. After trying to figure out why we
: were seeing these 200-300ms PSS collection times on Android O but had not
: noticed it in previous versions, we found that the number of VMAs in the
: main system process increased by 50% from Android N to Android O (from
: ~1800 to ~2700) and varying increases in every userspace process. Android
: M to N also had an increase in the number of VMAs, although not as much.
: I'm not sure why this is increasing so much over time, but thinking about
: ASLR and ways to make ASLR better, I expect that this will continue to
: increase going forward. I would not be surprised if we hit 5000 VMAs on
: the main Android process (system_server) by 2020.
:
: If we assume that the number of VMAs is going to increase over time, then
: doing anything we can do to reduce the overhead of each VMA during PSS
: collection seems like the right way to go, and that means outputting an
: aggregate statistic (to avoid whatever overhead there is per line in
: writing smaps and in reading each line from userspace).
Link: http://lkml.kernel.org/r/20170812022148.178293-1-dancol@google.com
Signed-off-by: Daniel Colascione <dancol@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:25:08 +08:00
|
|
|
struct mem_size_stats;
|
2013-04-11 20:34:43 +08:00
|
|
|
struct proc_maps_private {
|
2014-10-10 06:25:51 +08:00
|
|
|
struct inode *inode;
|
2013-04-11 20:34:43 +08:00
|
|
|
struct task_struct *task;
|
2014-10-10 06:25:26 +08:00
|
|
|
struct mm_struct *mm;
|
mm: add /proc/pid/smaps_rollup
/proc/pid/smaps_rollup is a new proc file that improves the performance
of user programs that determine aggregate memory statistics (e.g., total
PSS) of a process.
Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.
smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all of
the real-smaps VMAs. Using a common format for smaps_rollup and smaps
allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.
By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a large
process's potentially very numerous memory mappings. For sampling
system_server's PSS in Android, we measured a 12x speedup, representing
a savings of several hundred milliseconds.
One alternative to a new per-process proc file would have been including
PSS information in /proc/pid/status. We considered this option but
thought that PSS would be too expensive (by a few orders of magnitude)
to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.
The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for each
VMA. In this way, summation happens automatically. We let seq_file
walk over the VMAs just as it does for regular smaps and just emit
nothing to the seq_file until we hit the last VMA.
Benchmarks:
using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system
using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system
We're using the PSS samples we collect asynchronously for
system-management tasks like fine-tuning oom_adj_score, memory use
tracking for debugging, application-level memory-use attribution, and
deciding whether we want to kill large processes during system idle
maintenance windows. Android has been using PSS for these purposes for
a long time; as the average process VMA count has increased and and
devices become more efficiency-conscious, PSS-collection inefficiency
has started to matter more. IMHO, it'd be a lot safer to optimize the
existing PSS-collection model, which has been fine-tuned over the years,
instead of changing the memory tracking approach entirely to work around
smaps-generation inefficiency.
Tim said:
: There are two main reasons why Android gathers PSS information:
:
: 1. Android devices can show the user the amount of memory used per
: application via the settings app. This is a less important use case.
:
: 2. We log PSS to help identify leaks in applications. We have found
: an enormous number of bugs (in the Android platform, in Google's own
: apps, and in third-party applications) using this data.
:
: To do this, system_server (the main process in Android userspace) will
: sample the PSS of a process three seconds after it changes state (for
: example, app is launched and becomes the foreground application) and about
: every ten minutes after that. The net result is that PSS collection is
: regularly running on at least one process in the system (usually a few
: times a minute while the screen is on, less when screen is off due to
: suspend). PSS of a process is an incredibly useful stat to track, and we
: aren't going to get rid of it. We've looked at some very hacky approaches
: using RSS ("take the RSS of the target process, subtract the RSS of the
: zygote process that is the parent of all Android apps") to reduce the
: accounting time, but it regularly overestimated the memory used by 20+
: percent. Accordingly, I don't think that there's a good alternative to
: using PSS.
:
: We started looking into PSS collection performance after we noticed random
: frequency spikes while a phone's screen was off; occasionally, one of the
: CPU clusters would ramp to a high frequency because there was 200-300ms of
: constant CPU work from a single thread in the main Android userspace
: process. The work causing the spike (which is reasonable governor
: behavior given the amount of CPU time needed) was always PSS collection.
: As a result, Android is burning more power than we should be on PSS
: collection.
:
: The other issue (and why I'm less sure about improving smaps as a
: long-term solution) is that the number of VMAs per process has increased
: significantly from release to release. After trying to figure out why we
: were seeing these 200-300ms PSS collection times on Android O but had not
: noticed it in previous versions, we found that the number of VMAs in the
: main system process increased by 50% from Android N to Android O (from
: ~1800 to ~2700) and varying increases in every userspace process. Android
: M to N also had an increase in the number of VMAs, although not as much.
: I'm not sure why this is increasing so much over time, but thinking about
: ASLR and ways to make ASLR better, I expect that this will continue to
: increase going forward. I would not be surprised if we hit 5000 VMAs on
: the main Android process (system_server) by 2020.
:
: If we assume that the number of VMAs is going to increase over time, then
: doing anything we can do to reduce the overhead of each VMA during PSS
: collection seems like the right way to go, and that means outputting an
: aggregate statistic (to avoid whatever overhead there is per line in
: writing smaps and in reading each line from userspace).
Link: http://lkml.kernel.org/r/20170812022148.178293-1-dancol@google.com
Signed-off-by: Daniel Colascione <dancol@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:25:08 +08:00
|
|
|
struct mem_size_stats *rollup;
|
2013-04-11 20:34:43 +08:00
|
|
|
#ifdef CONFIG_MMU
|
|
|
|
|
struct vm_area_struct *tail_vma;
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
|
struct mempolicy *task_mempolicy;
|
|
|
|
|
#endif
|
2016-10-28 16:22:25 +08:00
|
|
|
} __randomize_layout;
|
2013-04-11 20:34:43 +08:00
|
|
|
|
2014-10-10 06:25:24 +08:00
|
|
|
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
|
|
|
|
|
|
2013-04-11 20:34:43 +08:00
|
|
|
extern const struct file_operations proc_pid_maps_operations;
|
|
|
|
|
extern const struct file_operations proc_tid_maps_operations;
|
|
|
|
|
extern const struct file_operations proc_pid_numa_maps_operations;
|
|
|
|
|
extern const struct file_operations proc_tid_numa_maps_operations;
|
|
|
|
|
extern const struct file_operations proc_pid_smaps_operations;
|
mm: add /proc/pid/smaps_rollup
/proc/pid/smaps_rollup is a new proc file that improves the performance
of user programs that determine aggregate memory statistics (e.g., total
PSS) of a process.
Android regularly "samples" the memory usage of various processes in
order to balance its memory pool sizes. This sampling process involves
opening /proc/pid/smaps and summing certain fields. For very large
processes, sampling memory use this way can take several hundred
milliseconds, due mostly to the overhead of the seq_printf calls in
task_mmu.c.
smaps_rollup improves the situation. It contains most of the fields of
/proc/pid/smaps, but instead of a set of fields for each VMA,
smaps_rollup instead contains one synthetic smaps-format entry
representing the whole process. In the single smaps_rollup synthetic
entry, each field is the summation of the corresponding field in all of
the real-smaps VMAs. Using a common format for smaps_rollup and smaps
allows userspace parsers to repurpose parsers meant for use with
non-rollup smaps for smaps_rollup, and it allows userspace to switch
between smaps_rollup and smaps at runtime (say, based on the
availability of smaps_rollup in a given kernel) with minimal fuss.
By using smaps_rollup instead of smaps, a caller can avoid the
significant overhead of formatting, reading, and parsing each of a large
process's potentially very numerous memory mappings. For sampling
system_server's PSS in Android, we measured a 12x speedup, representing
a savings of several hundred milliseconds.
One alternative to a new per-process proc file would have been including
PSS information in /proc/pid/status. We considered this option but
thought that PSS would be too expensive (by a few orders of magnitude)
to collect relative to what's already emitted as part of
/proc/pid/status, and slowing every user of /proc/pid/status for the
sake of readers that happen to want PSS feels wrong.
The code itself works by reusing the existing VMA-walking framework we
use for regular smaps generation and keeping the mem_size_stats
structure around between VMA walks instead of using a fresh one for each
VMA. In this way, summation happens automatically. We let seq_file
walk over the VMAs just as it does for regular smaps and just emit
nothing to the seq_file until we hit the last VMA.
Benchmarks:
using smaps:
iterations:1000 pid:1163 pss:220023808
0m29.46s real 0m08.28s user 0m20.98s system
using smaps_rollup:
iterations:1000 pid:1163 pss:220702720
0m04.39s real 0m00.03s user 0m04.31s system
We're using the PSS samples we collect asynchronously for
system-management tasks like fine-tuning oom_adj_score, memory use
tracking for debugging, application-level memory-use attribution, and
deciding whether we want to kill large processes during system idle
maintenance windows. Android has been using PSS for these purposes for
a long time; as the average process VMA count has increased and and
devices become more efficiency-conscious, PSS-collection inefficiency
has started to matter more. IMHO, it'd be a lot safer to optimize the
existing PSS-collection model, which has been fine-tuned over the years,
instead of changing the memory tracking approach entirely to work around
smaps-generation inefficiency.
Tim said:
: There are two main reasons why Android gathers PSS information:
:
: 1. Android devices can show the user the amount of memory used per
: application via the settings app. This is a less important use case.
:
: 2. We log PSS to help identify leaks in applications. We have found
: an enormous number of bugs (in the Android platform, in Google's own
: apps, and in third-party applications) using this data.
:
: To do this, system_server (the main process in Android userspace) will
: sample the PSS of a process three seconds after it changes state (for
: example, app is launched and becomes the foreground application) and about
: every ten minutes after that. The net result is that PSS collection is
: regularly running on at least one process in the system (usually a few
: times a minute while the screen is on, less when screen is off due to
: suspend). PSS of a process is an incredibly useful stat to track, and we
: aren't going to get rid of it. We've looked at some very hacky approaches
: using RSS ("take the RSS of the target process, subtract the RSS of the
: zygote process that is the parent of all Android apps") to reduce the
: accounting time, but it regularly overestimated the memory used by 20+
: percent. Accordingly, I don't think that there's a good alternative to
: using PSS.
:
: We started looking into PSS collection performance after we noticed random
: frequency spikes while a phone's screen was off; occasionally, one of the
: CPU clusters would ramp to a high frequency because there was 200-300ms of
: constant CPU work from a single thread in the main Android userspace
: process. The work causing the spike (which is reasonable governor
: behavior given the amount of CPU time needed) was always PSS collection.
: As a result, Android is burning more power than we should be on PSS
: collection.
:
: The other issue (and why I'm less sure about improving smaps as a
: long-term solution) is that the number of VMAs per process has increased
: significantly from release to release. After trying to figure out why we
: were seeing these 200-300ms PSS collection times on Android O but had not
: noticed it in previous versions, we found that the number of VMAs in the
: main system process increased by 50% from Android N to Android O (from
: ~1800 to ~2700) and varying increases in every userspace process. Android
: M to N also had an increase in the number of VMAs, although not as much.
: I'm not sure why this is increasing so much over time, but thinking about
: ASLR and ways to make ASLR better, I expect that this will continue to
: increase going forward. I would not be surprised if we hit 5000 VMAs on
: the main Android process (system_server) by 2020.
:
: If we assume that the number of VMAs is going to increase over time, then
: doing anything we can do to reduce the overhead of each VMA during PSS
: collection seems like the right way to go, and that means outputting an
: aggregate statistic (to avoid whatever overhead there is per line in
: writing smaps and in reading each line from userspace).
Link: http://lkml.kernel.org/r/20170812022148.178293-1-dancol@google.com
Signed-off-by: Daniel Colascione <dancol@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-07 07:25:08 +08:00
|
|
|
extern const struct file_operations proc_pid_smaps_rollup_operations;
|
2013-04-11 20:34:43 +08:00
|
|
|
extern const struct file_operations proc_tid_smaps_operations;
|
|
|
|
|
extern const struct file_operations proc_clear_refs_operations;
|
|
|
|
|
extern const struct file_operations proc_pagemap_operations;
|
|
|
|
|
|
|
|
|
|
extern unsigned long task_vsize(struct mm_struct *);
|
|
|
|
|
extern unsigned long task_statm(struct mm_struct *,
|
|
|
|
|
unsigned long *, unsigned long *,
|
|
|
|
|
unsigned long *, unsigned long *);
|
|
|
|
|
extern void task_mem(struct seq_file *, struct mm_struct *);
|