1. 27 6月, 2006 17 次提交
  2. 20 6月, 2006 1 次提交
  3. 20 4月, 2006 1 次提交
  4. 01 4月, 2006 1 次提交
  5. 21 3月, 2006 1 次提交
    • C
      VFS: New /proc file /proc/self/mountstats · b4629fe2
      Chuck Lever 提交于
      Create a new file under /proc/self, called mountstats, where mounted file
      systems can export information (configuration options, performance counters,
      and so on).  Use a mechanism similar to /proc/mounts and s_ops->show_options.
      
      This mechanism does not violate namespace security, and is safe to use while
      other processes are unmounting file systems.
      
      Thanks to Mike Waychison for his review and comments.
      
      Test-plan:
      Test concurrent mount/unmount operations while cat'ing /proc/self/mountstats.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b4629fe2
  6. 12 1月, 2006 1 次提交
  7. 08 11月, 2005 1 次提交
  8. 15 10月, 2005 1 次提交
  9. 23 9月, 2005 1 次提交
  10. 22 9月, 2005 1 次提交
  11. 10 9月, 2005 2 次提交
  12. 08 9月, 2005 3 次提交
  13. 05 9月, 2005 2 次提交
    • M
      [PATCH] add /proc/pid/smaps · e070ad49
      Mauricio Lin 提交于
      Add a "smaps" entry to /proc/pid: show howmuch memory is resident in each
      mapping.
      
      People that want to perform a memory consumption analysing can use it
      mainly if someone needs to figure out which libraries can be reduced for
      embedded systems.  So the new features are the physical size of shared and
      clean [or dirty]; private and clean [or dirty].
      
      Take a look the example below:
      
      # cat /proc/4576/smaps
      
      08048000-080dc000 r-xp /bin/bash
      Size:               592 KB
      Rss:                500 KB
      Shared_Clean:       500 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:        0 KB
      080dc000-080e2000 rw-p /bin/bash
      Size:                24 KB
      Rss:                 24 KB
      Shared_Clean:         0 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:       24 KB
      080e2000-08116000 rw-p
      Size:               208 KB
      Rss:                208 KB
      Shared_Clean:         0 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:      208 KB
      b7e2b000-b7e34000 r-xp /lib/tls/libnss_files-2.3.2.so
      Size:                36 KB
      Rss:                 12 KB
      Shared_Clean:        12 KB
      Shared_Dirty:         0 KB
      Private_Clean:        0 KB
      Private_Dirty:        0 KB
      ...
      
      (Includes a cleanup from "Richard Purdie" <rpurdie@rpsys.net>)
      
      From: Torsten Foertsch <torsten.foertsch@gmx.net>
      
      show_smap calls first show_map and then prints its additional information to
      the seq_file.  show_map checks if all it has to print fits into the buffer and
      if yes marks the current vma as written.  While that is correct for show_map
      it is not for show_smap.  Here the vma should be marked as written only after
      the additional information is also written.
      
      The attached patch cures the problem.  It moves the functionality of the
      show_map function to a new function show_map_internal that is called with an
      additional struct mem_size_stats* argument.  Then show_map calls
      show_map_internal with NULL as struct mem_size_stats* whereas show_smap calls
      it with a real pointer.  Now the final
      
      	if (m->count < m->size)  /* vma is copied successfully */
      		m->version = (vma != get_gate_vma(task))? vma->vm_start: 0;
      
      is done only if the whole entry fits into the buffer.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e070ad49
    • C
      [PATCH] /proc/<pid>/numa_maps to show on which nodes pages reside · 6e21c8f1
      Christoph Lameter 提交于
      This patch was recently discussed on linux-mm:
      http://marc.theaimsgroup.com/?t=112085728500002&r=1&w=2
      
      I inherited a large code base from Ray for page migration.  There was a
      small patch in there that I find to be very useful since it allows the
      display of the locality of the pages in use by a process.  I reworked that
      patch and came up with a /proc/<pid>/numa_maps that gives more information
      about the vma's of a process.  numa_maps is indexes by the start address
      found in /proc/<pid>/maps.  F.e.  with this patch you can see the page use
      of the "getty" process:
      
      margin:/proc/12008 # cat maps
      00000000-00004000 r--p 00000000 00:00 0
      2000000000000000-200000000002c000 r-xp 00000000 08:04 516                /lib/ld-2.3.3.so
      2000000000038000-2000000000040000 rw-p 00028000 08:04 516                /lib/ld-2.3.3.so
      2000000000040000-2000000000044000 rw-p 2000000000040000 00:00 0
      2000000000058000-2000000000260000 r-xp 00000000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000260000-2000000000268000 ---p 00208000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000268000-2000000000274000 rw-p 00200000 08:04 54707842           /lib/tls/libc.so.6.1
      2000000000274000-2000000000280000 rw-p 2000000000274000 00:00 0
      2000000000280000-20000000002b4000 r--p 00000000 08:04 9126923            /usr/lib/locale/en_US.utf8/LC_CTYPE
      2000000000300000-2000000000308000 r--s 00000000 08:04 60071467           /usr/lib/gconv/gconv-modules.cache
      2000000000318000-2000000000328000 rw-p 2000000000318000 00:00 0
      4000000000000000-4000000000008000 r-xp 00000000 08:04 29576399           /sbin/mingetty
      6000000000004000-6000000000008000 rw-p 00004000 08:04 29576399           /sbin/mingetty
      6000000000008000-600000000002c000 rw-p 6000000000008000 00:00 0          [heap]
      60000fff7fffc000-60000fff80000000 rw-p 60000fff7fffc000 00:00 0
      60000ffffff44000-60000ffffff98000 rw-p 60000ffffff44000 00:00 0          [stack]
      a000000000000000-a000000000020000 ---p 00000000 00:00 0                  [vdso]
      
      cat numa_maps
      2000000000000000 default MaxRef=43 Pages=11 Mapped=11 N0=4 N1=3 N2=2 N3=2
      2000000000038000 default MaxRef=1 Pages=2 Mapped=2 Anon=2 N0=2
      2000000000040000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      2000000000058000 default MaxRef=43 Pages=61 Mapped=61 N0=14 N1=15 N2=16 N3=16
      2000000000268000 default MaxRef=1 Pages=2 Mapped=2 Anon=2 N0=2
      2000000000274000 default MaxRef=1 Pages=3 Mapped=3 Anon=3 N0=3
      2000000000280000 default MaxRef=8 Pages=3 Mapped=3 N0=3
      2000000000300000 default MaxRef=8 Pages=2 Mapped=2 N0=2
      2000000000318000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N2=1
      4000000000000000 default MaxRef=6 Pages=2 Mapped=2 N1=2
      6000000000004000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      6000000000008000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      60000fff7fffc000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      60000ffffff44000 default MaxRef=1 Pages=1 Mapped=1 Anon=1 N0=1
      
      getty uses ld.so.  The first vma is the code segment which is used by 43
      other processes and the pages are evenly distributed over the 4 nodes.
      
      The second vma is the process specific data portion for ld.so.  This is
      only one page.
      
      The display format is:
      
      <startaddress>	 Links to information in /proc/<pid>/map
      <memory policy>  This can be "default" "interleave={}", "prefer=<node>" or "bind={<zones>}"
      MaxRef=		<maximum reference to a page in this vma>
      Pages=		<Nr of pages in use>
      Mapped=		<Nr of pages with mapcount >
      Anon=		<nr of anonymous pages>
      Nx=		<Nr of pages on Node x>
      
      The content of the proc-file is self-evident.  If this would be tied into
      the sparsemem system then the contents of this file would not be too
      useful.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e21c8f1
  14. 20 8月, 2005 1 次提交
  15. 24 6月, 2005 1 次提交
    • A
      [PATCH] setuid core dump · d6e71144
      Alan Cox 提交于
      Add a new `suid_dumpable' sysctl:
      
      This value can be used to query and set the core dump mode for setuid
      or otherwise protected/tainted binaries. The modes are
      
      0 - (default) - traditional behaviour.  Any process which has changed
          privilege levels or is execute only will not be dumped
      
      1 - (debug) - all processes dump core when possible.  The core dump is
          owned by the current user and no security is applied.  This is intended
          for system debugging situations only.  Ptrace is unchecked.
      
      2 - (suidsafe) - any binary which normally would not be dumped is dumped
          readable by root only.  This allows the end user to remove such a dump but
          not access it directly.  For security reasons core dumps in this mode will
          not overwrite one another or other files.  This mode is appropriate when
          adminstrators are attempting to debug problems in a normal environment.
      
      (akpm:
      
      > > +EXPORT_SYMBOL(suid_dumpable);
      >
      > EXPORT_SYMBOL_GPL?
      
      No problem to me.
      
      > >  	if (current->euid == current->uid && current->egid == current->gid)
      > >  		current->mm->dumpable = 1;
      >
      > Should this be SUID_DUMP_USER?
      
      Actually the feedback I had from last time was that the SUID_ defines
      should go because its clearer to follow the numbers. They can go
      everywhere (and there are lots of places where dumpable is tested/used
      as a bool in untouched code)
      
      > Maybe this should be renamed to `dump_policy' or something.  Doing that
      > would help us catch any code which isn't using the #defines, too.
      
      Fair comment. The patch was designed to be easy to maintain for Red Hat
      rather than for merging. Changing that field would create a gigantic
      diff because it is used all over the place.
      
      )
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d6e71144
  16. 01 5月, 2005 4 次提交
  17. 30 4月, 2005 1 次提交
    • S
      [AUDIT] LOGIN message credentials · 456be6cd
      Steve Grubb 提交于
      Attached is a new patch that solves the issue of getting valid credentials 
      into the LOGIN message. The current code was assuming that the audit context 
      had already been copied. This is not always the case for LOGIN messages.
      
      To solve the problem, the patch passes the task struct to the function that 
      emits the message where it can get valid credentials.
      Signed-off-by: NSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      456be6cd