1. 06 9月, 2008 1 次提交
    • B
      sched: fix process time monotonicity · 49048622
      Balbir Singh 提交于
      Spencer reported a problem where utime and stime were going negative despite
      the fixes in commit b27f03d4. The suspected
      reason for the problem is that signal_struct maintains it's own utime and
      stime (of exited tasks), these are not updated using the new task_utime()
      routine, hence sig->utime can go backwards and cause the same problem
      to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
      fixes the problem
      
      TODO: using max(task->prev_utime, derived utime) works for now, but a more
      generic solution is to implement cputime_max() and use the cputime_gt()
      function for comparison.
      
      Reported-by: spencer@bluehost.com
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      49048622
  2. 03 9月, 2008 1 次提交
    • K
      mm: show quicklist usage in /proc/meminfo · 4b856152
      KOSAKI Motohiro 提交于
      Quicklists can consume several GB of memory.  We should provide a means of
      monitoring this.
      
      After this patch is applied, /proc/meminfo will output the following:
      
      % cat /proc/meminfo
      
      MemTotal:      7715392 kB
      MemFree:       5401600 kB
      Buffers:         80384 kB
      Cached:         300800 kB
      SwapCached:          0 kB
      Active:         235584 kB
      Inactive:       262656 kB
      SwapTotal:     2031488 kB
      SwapFree:      2031488 kB
      Dirty:            3520 kB
      Writeback:           0 kB
      AnonPages:      117696 kB
      Mapped:          38528 kB
      Slab:          1589952 kB
      SReclaimable:    23104 kB
      SUnreclaim:    1566848 kB
      PageTables:      14656 kB
      NFS_Unstable:        0 kB
      Bounce:              0 kB
      WritebackTmp:        0 kB
      CommitLimit:   5889152 kB
      Committed_AS:   393152 kB
      VmallocTotal: 17592177655808 kB
      VmallocUsed:     29056 kB
      VmallocChunk: 17592177626432 kB
      Quicklists:     130944 kB
      HugePages_Total:     0
      HugePages_Free:      0
      HugePages_Rsvd:      0
      HugePages_Surp:      0
      Hugepagesize:    262144 kB
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Keiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4b856152
  3. 25 8月, 2008 1 次提交
  4. 21 8月, 2008 1 次提交
    • C
      /proc/self/maps doesn't display the real file offset · 1804dc6e
      Clement Calmels 提交于
      This addresses
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=11318
      
      In function show_map (file: fs/proc/task_mmu.c), if vma->vm_pgoff > 2^20
      than (vma->vm_pgoff << PAGE_SIZE) is greater than 2^32 (with PAGE_SIZE
      equal to 4096 (i.e.  2^12).  The next seq_printf use an unsigned long for
      the conversion of (vma->vm_pgoff << PAGE_SIZE), as a result the offset
      value displayed in /proc/self/maps is truncated if the page offset is
      greater than 2^20.
      
      A test that shows this issue:
      
      #define _GNU_SOURCE
      #include <sys/types.h>
      #include <sys/stat.h>
      #include <sys/mman.h>
      #include <stdlib.h>
      #include <stdio.h>
      #include <fcntl.h>
      #include <unistd.h>
      #include <string.h>
      
      #define PAGE_SIZE (getpagesize())
      
      #if __i386__
      #   define U64_STR "%llx"
      #elif __x86_64
      #   define U64_STR "%lx"
      #else
      #   error "Architecture Unsupported"
      #endif
      
      int main(int argc, char *argv[])
      {
      	int fd;
      	char *addr;
      	off64_t offset = 0x10000000;
      	char *filename = "/dev/zero";
      
      	fd = open(filename, O_RDONLY);
      	if (fd < 0) {
      		perror("open");
      		return 1;
      	}
      
      	offset *= 0x10;
      	printf("offset = " U64_STR "\n", offset);
      
      	addr = (char*)mmap64(NULL, PAGE_SIZE, PROT_READ, MAP_PRIVATE, fd,
      			     offset);
      	if ((void*)addr == MAP_FAILED) {
      		perror("mmap64");
      		return 1;
      	}
      
      	{
      		FILE *fmaps;
      		char *line = NULL;
      		size_t len = 0;
      		ssize_t read;
      		size_t filename_len = strlen(filename);
      
      		fmaps = fopen("/proc/self/maps", "r");
      		if (!fmaps) {
      			perror("fopen");
      			return 1;
      		}
      		while ((read = getline(&line, &len, fmaps)) != -1) {
      			if ((read > filename_len + 1)
      			    && (strncmp(&line[read - filename_len - 1], filename, filename_len) == 0))
      				printf("%s", line);
      		}
      
      		if (line)
      			free(line);
      
      		fclose(fmaps);
      	}
      
      	close(fd);
      	return 0;
      }
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NClement Calmels <cboulte@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1804dc6e
  5. 06 8月, 2008 1 次提交
    • A
      proc: fix warnings · 7c44319d
      Alexander Beregalov 提交于
      proc: fix warnings
      
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 5 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'u64'
       fs/proc/base.c:2429: warning: format '%llu' expects type 'long long unsigned int', but argument 9 has type 'u64'
      Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Acked-by: NAndrea Righi <righi.andrea@gmail.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c44319d
  6. 01 8月, 2008 2 次提交
  7. 28 7月, 2008 2 次提交
  8. 27 7月, 2008 7 次提交
  9. 26 7月, 2008 6 次提交
  10. 25 7月, 2008 2 次提交
    • E
      vmallocinfo: add NUMA information · a47a126a
      Eric Dumazet 提交于
      Christoph recently added /proc/vmallocinfo file to get information about
      vmalloc allocations.
      
      This patch adds NUMA specific information, giving number of pages
      allocated on each memory node.
      
      This should help to check that vmalloc() is able to respect NUMA policies.
      
      Example of output on a four nodes machine (one cpu per node)
      
      1) network hash tables are evenly spreaded on four nodes (OK) (Same
         point for inodes and dentries hash tables)
      
      2) iptables tables (x_tables) are correctly allocated on each cpu node
         (OK).
      
      3) sys_swapon() allocates its memory from one node only.
      
      4) each loaded module is using memory on one node.
      
      Sysadmins could tune their setup to change points 3) and 4) if necessary.
      
      grep "pages="  /proc/vmallocinfo
      0xffffc20000000000-0xffffc20000201000 2101248 alloc_large_system_hash+0x204/0x2c0 pages=512 vmalloc N0=128 N1=128 N2=128 N3=128
      0xffffc20000201000-0xffffc20000302000 1052672 alloc_large_system_hash+0x204/0x2c0 pages=256 vmalloc N0=64 N1=64 N2=64 N3=64
      0xffffc2000031a000-0xffffc2000031d000   12288 alloc_large_system_hash+0x204/0x2c0 pages=2 vmalloc N1=1 N2=1
      0xffffc2000031f000-0xffffc2000032b000   49152 cramfs_uncompress_init+0x2e/0x80 pages=11 vmalloc N0=3 N1=3 N2=2 N3=3
      0xffffc2000033e000-0xffffc20000341000   12288 sys_swapon+0x640/0xac0 pages=2 vmalloc N0=2
      0xffffc20000341000-0xffffc20000344000   12288 xt_alloc_table_info+0xfe/0x130 [x_tables] pages=2 vmalloc N0=2
      0xffffc20000344000-0xffffc20000347000   12288 xt_alloc_table_info+0xfe/0x130 [x_tables] pages=2 vmalloc N1=2
      0xffffc20000347000-0xffffc2000034a000   12288 xt_alloc_table_info+0xfe/0x130 [x_tables] pages=2 vmalloc N2=2
      0xffffc2000034a000-0xffffc2000034d000   12288 xt_alloc_table_info+0xfe/0x130 [x_tables] pages=2 vmalloc N3=2
      0xffffc20004381000-0xffffc20004402000  528384 alloc_large_system_hash+0x204/0x2c0 pages=128 vmalloc N0=32 N1=32 N2=32 N3=32
      0xffffc20004402000-0xffffc20004803000 4198400 alloc_large_system_hash+0x204/0x2c0 pages=1024 vmalloc vpages N0=256 N1=256 N2=256 N3=256
      0xffffc20004803000-0xffffc20004904000 1052672 alloc_large_system_hash+0x204/0x2c0 pages=256 vmalloc N0=64 N1=64 N2=64 N3=64
      0xffffc20004904000-0xffffc20004bec000 3047424 sys_swapon+0x640/0xac0 pages=743 vmalloc vpages N0=743
      0xffffffffa0000000-0xffffffffa000f000   61440 sys_init_module+0xc27/0x1d00 pages=14 vmalloc N1=14
      0xffffffffa000f000-0xffffffffa0014000   20480 sys_init_module+0xc27/0x1d00 pages=4 vmalloc N0=4
      0xffffffffa0014000-0xffffffffa0017000   12288 sys_init_module+0xc27/0x1d00 pages=2 vmalloc N0=2
      0xffffffffa0017000-0xffffffffa0022000   45056 sys_init_module+0xc27/0x1d00 pages=10 vmalloc N1=10
      0xffffffffa0022000-0xffffffffa0028000   24576 sys_init_module+0xc27/0x1d00 pages=5 vmalloc N3=5
      0xffffffffa0028000-0xffffffffa0050000  163840 sys_init_module+0xc27/0x1d00 pages=39 vmalloc N1=39
      0xffffffffa0050000-0xffffffffa0052000    8192 sys_init_module+0xc27/0x1d00 pages=1 vmalloc N1=1
      0xffffffffa0052000-0xffffffffa0056000   16384 sys_init_module+0xc27/0x1d00 pages=3 vmalloc N1=3
      0xffffffffa0056000-0xffffffffa0081000  176128 sys_init_module+0xc27/0x1d00 pages=42 vmalloc N3=42
      0xffffffffa0081000-0xffffffffa00ae000  184320 sys_init_module+0xc27/0x1d00 pages=44 vmalloc N3=44
      0xffffffffa00ae000-0xffffffffa00b1000   12288 sys_init_module+0xc27/0x1d00 pages=2 vmalloc N3=2
      0xffffffffa00b1000-0xffffffffa00b9000   32768 sys_init_module+0xc27/0x1d00 pages=7 vmalloc N0=7
      0xffffffffa00b9000-0xffffffffa00c4000   45056 sys_init_module+0xc27/0x1d00 pages=10 vmalloc N3=10
      0xffffffffa00c6000-0xffffffffa00e0000  106496 sys_init_module+0xc27/0x1d00 pages=25 vmalloc N2=25
      0xffffffffa00e0000-0xffffffffa00f1000   69632 sys_init_module+0xc27/0x1d00 pages=16 vmalloc N2=16
      0xffffffffa00f1000-0xffffffffa00f4000   12288 sys_init_module+0xc27/0x1d00 pages=2 vmalloc N3=2
      0xffffffffa00f4000-0xffffffffa00f7000   12288 sys_init_module+0xc27/0x1d00 pages=2 vmalloc N3=2
      
      [akpm@linux-foundation.org: fix comment]
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a47a126a
    • A
      mm/vmstat.c: proper externs · c748e134
      Adrian Bunk 提交于
      This patch adds proper extern declarations for five variables in
      include/linux/vmstat.h
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c748e134
  11. 23 7月, 2008 2 次提交
  12. 21 7月, 2008 1 次提交
    • A
      tty: Ldisc revamp · a352def2
      Alan Cox 提交于
      Move the line disciplines towards a conventional ->ops arrangement.  For
      the moment the actual 'tty_ldisc' struct in the tty is kept as part of
      the tty struct but this can then be changed if it turns out that when it
      all settles down we want to refcount ldiscs separately to the tty.
      
      Pull the ldisc code out of /proc and put it with our ldisc code.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a352def2
  13. 18 7月, 2008 2 次提交
  14. 14 7月, 2008 1 次提交
    • S
      Security: split proc ptrace checking into read vs. attach · 006ebb40
      Stephen Smalley 提交于
      Enable security modules to distinguish reading of process state via
      proc from full ptrace access by renaming ptrace_may_attach to
      ptrace_may_access and adding a mode argument indicating whether only
      read access or full attach access is requested.  This allows security
      modules to permit access to reading process state without granting
      full ptrace access.  The base DAC/capability checking remains unchanged.
      
      Read access to /proc/pid/mem continues to apply a full ptrace attach
      check since check_mem_permission() already requires the current task
      to already be ptracing the target.  The other ptrace checks within
      proc for elements like environ, maps, and fds are changed to pass the
      read mode instead of attach.
      
      In the SELinux case, we model such reading of process state as a
      reading of a proc file labeled with the target process' label.  This
      enables SELinux policy to permit such reading of process state without
      permitting control or manipulation of the target process, as there are
      a number of cases where programs probe for such information via proc
      but do not need to be able to control the target (e.g. procps,
      lsof, PolicyKit, ConsoleKit).  At present we have to choose between
      allowing full ptrace in policy (more permissive than required/desired)
      or breaking functionality (or in some cases just silencing the denials
      via dontaudit rules but this can hide genuine attacks).
      
      This version of the patch incorporates comments from Casey Schaufler
      (change/replace existing ptrace_may_attach interface, pass access
      mode), and Chris Wright (provide greater consistency in the checking).
      
      Note that like their predecessors __ptrace_may_attach and
      ptrace_may_attach, the __ptrace_may_access and ptrace_may_access
      interfaces use different return value conventions from each other (0
      or -errno vs. 1 or 0).  I retained this difference to avoid any
      changes to the caller logic but made the difference clearer by
      changing the latter interface to return a bool rather than an int and
      by adding a comment about it to ptrace.h for any future callers.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      006ebb40
  15. 08 7月, 2008 1 次提交
    • A
      x86, generic: CPA add statistics about state of direct mapping v4 · ce0c0e50
      Andi Kleen 提交于
      Add information about the mapping state of the direct mapping to
      /proc/meminfo. I chose /proc/meminfo because that is where all the other
      memory statistics are too and it is a generally useful metric even
      outside debugging situations. A lot of split kernel pages means the
      kernel will run slower.
      
      This way we can see how many large pages are really used for it and how
      many are split.
      
      Useful for general insight into the kernel.
      
      v2: Add hotplug locking to 64bit to plug a very obscure theoretical race.
          32bit doesn't need it because it doesn't support hotadd for lowmem.
          Fix some typos
      v3: Rename dpages_cnt
          Add CONFIG ifdef for count update as requested by tglx
          Expand description
      v4: Fix stupid bugs added in v3
          Move update_page_count to pageattr.c
      Signed-off-by: NAndi Kleen <andi@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce0c0e50
  16. 06 7月, 2008 2 次提交
  17. 13 6月, 2008 2 次提交
  18. 07 6月, 2008 4 次提交
  19. 01 6月, 2008 1 次提交
    • A
      capabilities: remain source compatible with 32-bit raw legacy capability support. · ca05a99a
      Andrew G. Morgan 提交于
      Source code out there hard-codes a notion of what the
      _LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
      raw capability system calls capget() and capset().  Its unfortunate, but
      true.
      
      Since the confusing header file has been in a released kernel, there is
      software that is erroneously using 64-bit capabilities with the semantics
      of 32-bit compatibilities.  These recently compiled programs may suffer
      corruption of their memory when sys_getcap() overwrites more memory than
      they are coded to expect, and the raising of added capabilities when using
      sys_capset().
      
      As such, this patch does a number of things to clean up the situation
      for all. It
      
        1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
           legacy value.
      
        2. adopts a new #define strategy for the kernel's internal
           implementation of the preferred magic.
      
        3. deprecates v2 capability magic in favor of a new (v3) magic
           number. The functionality of v3 is entirely equivalent to v2,
           the only difference being that the v2 magic causes the kernel
           to log a "deprecated" warning so the admin can find applications
           that may be using v2 inappropriately.
      
      [User space code continues to be encouraged to use the libcap API which
      protects the application from details like this.  libcap-2.10 is the first
      to support v3 capabilities.]
      
      Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
      Thanks to Bojan Smojver for the report.
      
      [akpm@linux-foundation.org: s/depreciate/deprecate/g]
      [akpm@linux-foundation.org: be robust about put_user size]
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NAndrew G. Morgan <morgan@kernel.org>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: Bojan Smojver <bojan@rexursive.com>
      Cc: stable@kernel.org
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      ca05a99a