linux.git/fs/proc, branch v4.0-rc2

procfs: fix race between symlink removals and traversals

2015-02-22T16:43:12+00:00

use_pde()/unuse_pde() in ->follow_link()/->put_link() resp.

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2015-02-17T22:56:45+00:00

Pull misc VFS updates from Al Viro:
 "This cycle a lot of stuff sits on topical branches, so I'll be sending
  more or less one pull request per branch.

  This is the first pile; more to follow in a few.  In this one are
  several misc commits from early in the cycle (before I went for
  separate branches), plus the rework of mntput/dput ordering on umount,
  switching to use of fs_pin instead of convoluted games in
  namespace_unlock()"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  switch the IO-triggering parts of umount to fs_pin
  new fs_pin killing logics
  allow attaching fs_pin to a group not associated with some superblock
  get rid of the second argument of acct_kill()
  take count and rcu_head out of fs_pin
  dcache: let the dentry count go down to zero without taking d_lock
  pull bumping refcount into ->kill()
  kill pin_put()
  mode_t whack-a-mole: chelsio
  file->f_path.dentry is pinned down for as long as the file is open...
  get rid of lustre_dump_dentry()
  gut proc_register() a bit
  kill d_validate()
  ncpfs: get rid of d_validate() nonsense
  selinuxfs: don't open-code d_genocide()

vmcore: fix PT_NOTE n_namesz, n_descsz overflow issue

2015-02-17T22:34:52+00:00

When updating PT_NOTE header size (ie.  p_memsz), an overflow issue
happens with the following bogus note entry:

  n_namesz = 0xFFFFFFFF
  n_descsz = 0x0
  n_type   = 0x0

This kind of note entry should be dropped during updating p_memsz.  But
because n_namesz is 32bit, after (n_namesz + 3) & (~3), it's overflow to
0x0, the note entry size looks sane and reserved.

When userspace (eg.  crash utility) is trying to access such bogus note,
it could lead to an unexpected behavior (eg.  crash utility segment fault
because it's reading bogus address).

The source of bogus note hasn't been identified yet.  At least we could
drop the bogus note so user space wouldn't be surprised.

Signed-off-by: WANG Chao 
Cc: Dave Anderson 
Cc: Baoquan He 
Cc: Randy Wright 
Cc: Vivek Goyal 
Cc: Paul Gortmaker 
Cc: Fabian Frederick 
Cc: Vitaly Kuznetsov 
Cc: Rashika Kheria 
Cc: Greg Pearson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: use %*pb[l] to print bitmaps including cpumasks and nodemasks

2015-02-14T05:21:38+00:00

printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
respectively which can be used to generate the two printf arguments
necessary to format the specified cpu/nodemask.

Signed-off-by: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/proc/array.c: convert to use string_escape_str()

2015-02-13T02:54:12+00:00

Instead of custom approach let's use string_escape_str() to escape a given
string (task_name in this case).

Signed-off-by: Andy Shevchenko 
Cc: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: proc: task_mmu: show page size in /proc//numa_maps

2015-02-13T02:54:12+00:00

The output of /proc/$pid/numa_maps is in terms of number of pages like
anon=22 or dirty=54.  Here's some output:

  7f4680000000 default file=/hugetlb/bigfile anon=50 dirty=50 N0=50
  7f7659600000 default file=/anon_hugepage\040(deleted) anon=50 dirty=50 N0=50
  7fff8d425000 default stack anon=50 dirty=50 N0=50

Looks like we have a stack and a couple of anonymous hugetlbfs
areas page which both use the same amount of memory.  They don't.

The 'bigfile' uses 1GB pages and takes up ~50GB of space.  The
anon_hugepage uses 2MB pages and takes up ~100MB of space while the stack
uses normal 4k pages.  You can go over to smaps to figure out what the
page size _really_ is with KernelPageSize or MMUPageSize.  But, I think
this is a pretty nasty and counterintuitive interface as it stands.

This patch introduces 'kernelpagesize_kB' line element to
/proc//numa_maps report file in order to help identifying the size of
pages that are backing memory areas mapped by a given task.  This is
specially useful to help differentiating between HUGE and GIGANTIC page
backed VMAs.

This patch is based on Dave Hansen's proposal and reviewer's follow-ups
taken from the following dicussion threads:
 * https://lkml.org/lkml/2011/9/21/454
 * https://lkml.org/lkml/2014/12/20/66

Signed-off-by: Rafael Aquini 
Cc: Johannes Weiner 
Cc: Dave Hansen 
Acked-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: proc: use PDE() to get proc_dir_entry

2015-02-13T02:54:12+00:00

Use the PDE() helper to get proc_dir_entry instead of coding it directly.

Signed-off-by: Alexander Kuleshov 
Acked-by: Nicolas Dichtel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/proc/task_mmu.c: add user-space support for resetting mm->hiwater_rss (peak RSS)

2015-02-13T02:54:12+00:00

Peak resident size of a process can be reset back to the process's
current rss value by writing "5" to /proc/pid/clear_refs.  The driving
use-case for this would be getting the peak RSS value, which can be
retrieved from the VmHWM field in /proc/pid/status, per benchmark
iteration or test scenario.

[akpm@linux-foundation.org: clarify behaviour in documentation]
Signed-off-by: Petr Cermak 
Cc: Bjorn Helgaas 
Cc: Primiano Tucci 
Cc: Petr Cermak 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: /proc/pid/clear_refs: avoid split_huge_page()

2015-02-12T01:06:06+00:00

Currently pagewalker splits all THP pages on any clear_refs request.  It's
not necessary.  We can handle this on PMD level.

One side effect is that soft dirty will potentially see more dirty memory,
since we will mark whole THP page dirty at once.

Sanity checked with CRIU test suite. More testing is required.

Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Naoya Horiguchi 
Reviewed-by: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Cc: Andrea Arcangeli 
Cc: Dave Hansen 
Cc: "Kirill A. Shutemov" 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: pagewalk: fix misbehavior of walk_page_range for vma(VM_PFNMAP)

2015-02-12T01:06:06+00:00

walk_page_range() silently skips vma having VM_PFNMAP set, which leads to
undesirable behaviour at client end (who called walk_page_range).  For
example for pagemap_read(), when no callbacks are called against VM_PFNMAP
vma, pagemap_read() may prepare pagemap data for next virtual address
range at wrong index.  That could confuse and/or break userspace
applications.

This patch avoid this misbehavior caused by vma(VM_PFNMAP) like follows:
- for pagemap_read() which has its own ->pte_hole(), call the ->pte_hole()
  over vma(VM_PFNMAP),
- for clear_refs and queue_pages which have their own ->tests_walk,
  just return 1 and skip vma(VM_PFNMAP). This is no problem because
  these are not interested in hole regions,
- for other callers, just skip the vma(VM_PFNMAP) as a default behavior.

Signed-off-by: Naoya Horiguchi 
Signed-off-by: Shiraz Hashim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds