1. 20 10月, 2007 1 次提交
    • P
      pid namespaces: prepare proc_flust_task() to flush entries from multiple proc trees · 60347f67
      Pavel Emelyanov 提交于
      The first part is trivial - we just make the proc_flush_task() to operate on
      arbitrary vfsmount with arbitrary ids and pass the pid and global proc_mnt to
      it.
      
      The other change is more tricky: I moved the proc_flush_task() call in
      release_task() higher to address the following problem.
      
      When flushing task from many proc trees we need to know the set of ids (not
      just one pid) to find the dentries' names to flush.  Thus we need to pass the
      task's pid to proc_flush_task() as struct pid is the only object that can
      provide all the pid numbers.  But after __exit_signal() task has detached all
      his pids and this information is lost.
      
      This creates a tiny gap for proc_pid_lookup() to bring some dentries back to
      tree and keep them in hash (since pids are still alive before __exit_signal())
      till the next shrink, but since proc_flush_task() does not provide a 100%
      guarantee that the dentries will be flushed, this is OK to do so.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      60347f67
  2. 11 10月, 2007 2 次提交
    • E
      [NET]: Fix race when opening a proc file while a network namespace is exiting. · 077130c0
      Eric W. Biederman 提交于
      The problem:  proc_net files remember which network namespace the are
      against but do not remember hold a reference count (as that would pin
      the network namespace).   So we currently have a small window where
      the reference count on a network namespace may be incremented when opening
      a /proc file when it has already gone to zero.
      
      To fix this introduce maybe_get_net and get_proc_net.
      
      maybe_get_net increments the network namespace reference count only if it is
      greater then zero, ensuring we don't increment a reference count after it
      has gone to zero.
      
      get_proc_net handles all of the magic to go from a proc inode to the network
      namespace instance and call maybe_get_net on it.
      
      PROC_NET the old accessor is removed so that we don't get confused and use
      the wrong helper function.
      
      Then I fix up the callers to use get_proc_net and handle the case case
      where get_proc_net returns NULL.  In that case I return -ENXIO because
      effectively the network namespace has already gone away so the files
      we are trying to access don't exist anymore.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      077130c0
    • E
      [NET]: Make /proc/net per network namespace · 457c4cbc
      Eric W. Biederman 提交于
      This patch makes /proc/net per network namespace.  It modifies the global
      variables proc_net and proc_net_stat to be per network namespace.
      The proc_net file helpers are modified to take a network namespace argument,
      and all of their callers are fixed to pass &init_net for that argument.
      This ensures that all of the /proc/net files are only visible and
      usable in the initial network namespace until the code behind them
      has been updated to be handle multiple network namespaces.
      
      Making /proc/net per namespace is necessary as at least some files
      in /proc/net depend upon the set of network devices which is per
      network namespace, and even more files in /proc/net have contents
      that are relevant to a single network namespace.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      457c4cbc
  3. 12 8月, 2007 1 次提交
  4. 17 7月, 2007 1 次提交
    • A
      Fix rmmod/read/write races in /proc entries · 786d7e16
      Alexey Dobriyan 提交于
      Fix following races:
      ===========================================
      1. Write via ->write_proc sleeps in copy_from_user(). Module disappears
         meanwhile. Or, more generically, system call done on /proc file, method
         supplied by module is called, module dissapeares meanwhile.
      
         pde = create_proc_entry()
         if (!pde)
      	return -ENOMEM;
         pde->write_proc = ...
      				open
      				write
      				copy_from_user
         pde = create_proc_entry();
         if (!pde) {
      	remove_proc_entry();
      	return -ENOMEM;
      	/* module unloaded */
         }
      				*boom*
      ==========================================
      2. bogo-revoke aka proc_kill_inodes()
      
        remove_proc_entry		vfs_read
        proc_kill_inodes		[check ->f_op validness]
      				[check ->f_op->read validness]
      				[verify_area, security permissions checks]
      	->f_op = NULL;
      				if (file->f_op->read)
      					/* ->f_op dereference, boom */
      
      NOTE, NOTE, NOTE: file_operations are proxied for regular files only. Let's
      see how this scheme behaves, then extend if needed for directories.
      Directories creators in /proc only set ->owner for them, so proxying for
      directories may be unneeded.
      
      NOTE, NOTE, NOTE: methods being proxied are ->llseek, ->read, ->write,
      ->poll, ->unlocked_ioctl, ->ioctl, ->compat_ioctl, ->open, ->release.
      If your in-tree module uses something else, yell on me. Full audit pending.
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NAlexey Dobriyan <adobriyan@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      786d7e16
  5. 09 5月, 2007 1 次提交
  6. 08 5月, 2007 1 次提交
    • D
      smaps: add clear_refs file to clear reference · b813e931
      David Rientjes 提交于
      Adds /proc/pid/clear_refs.  When any non-zero number is written to this file,
      pte_mkold() and ClearPageReferenced() is called for each pte and its
      corresponding page, respectively, in that task's VMAs.  This file is only
      writable by the user who owns the task.
      
      It is now possible to measure _approximately_ how much memory a task is using
      by clearing the reference bits with
      
      	echo 1 > /proc/pid/clear_refs
      
      and checking the reference count for each VMA from the /proc/pid/smaps output
      at a measured time interval.  For example, to observe the approximate change
      in memory footprint for a task, write a script that clears the references
      (echo 1 > /proc/pid/clear_refs), sleeps, and then greps for Pgs_Referenced and
      extracts the size in kB.  Add the sizes for each VMA together for the total
      referenced footprint.  Moments later, repeat the process and observe the
      difference.
      
      For example, using an efficient Mozilla:
      
      	accumulated time		referenced memory
      	----------------		-----------------
      		 0 s				 408 kB
      		 1 s				 408 kB
      		 2 s				 556 kB
      		 3 s				1028 kB
      		 4 s				 872 kB
      		 5 s				1956 kB
      		 6 s				 416 kB
      		 7 s				1560 kB
      		 8 s				2336 kB
      		 9 s				1044 kB
      		10 s				 416 kB
      
      This is a valuable tool to get an approximate measurement of the memory
      footprint for a task.
      
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Christoph Lameter <clameter@sgi.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      [akpm@linux-foundation.org: build fixes]
      [mpm@selenic.com: rename for_each_pmd]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b813e931
  7. 15 2月, 2007 1 次提交
    • E
      [PATCH] sysctl: reimplement the sysctl proc support · 77b14db5
      Eric W. Biederman 提交于
      With this change the sysctl inodes can be cached and nothing needs to be done
      when removing a sysctl table.
      
      For a cost of 2K code we will save about 4K of static tables (when we remove
      de from ctl_table) and 70K in proc_dir_entries that we will not allocate, or
      about half that on a 32bit arch.
      
      The speed feels about the same, even though we can now cache the sysctl
      dentries :(
      
      We get the core advantage that we don't need to have a 1 to 1 mapping between
      ctl table entries and proc files.  Making it possible to have /proc/sys vary
      depending on the namespace you are in.  The currently merged namespaces don't
      have an issue here but the network namespace under /proc/sys/net needs to have
      different directories depending on which network adapters are visible.  By
      simply being a cache different directories being visible depending on who you
      are is trivial to implement.
      
      [akpm@osdl.org: fix uninitialised var]
      [akpm@osdl.org: fix ARM build]
      [bunk@stusta.de: make things static]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      77b14db5
  8. 13 2月, 2007 1 次提交
  9. 02 10月, 2006 1 次提交
  10. 27 9月, 2006 1 次提交
  11. 24 9月, 2006 1 次提交
  12. 27 6月, 2006 4 次提交
  13. 26 4月, 2006 1 次提交
  14. 11 4月, 2006 1 次提交
  15. 29 3月, 2006 2 次提交
  16. 27 3月, 2006 2 次提交
    • M
      [PATCH] Use loff_t for size in struct proc_dir_entry · 22e6c1b3
      Maneesh Soni 提交于
      Change proc_dir_entry->size to be loff_t to represent files like
      /proc/vmcore for 32bit systems with more than 4G memory.
      
      Needed for seeing correct size for /proc/vmcore for 32-bit systems with >
      4G RAM.
      Signed-off-by: NManeesh Soni <maneesh@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22e6c1b3
    • S
      [PATCH] protect remove_proc_entry · 64a07bd8
      Steven Rostedt 提交于
      It has been discovered that the remove_proc_entry has a race in the removing
      of entries in the proc file system that are siblings.  There's no protection
      around the traversing and removing of elements that belong in the same
      subdirectory.
      
      This subdirectory list is protected in other areas by the BKL.  So the BKL was
      at first used to protect this area too, but unfortunately, remove_proc_entry
      may be called with spinlocks held.  The BKL may schedule, so this was not a
      solution.
      
      The final solution was to add a new global spin lock to protect this list,
      called proc_subdir_lock.  This lock now protects the list in
      remove_proc_entry, and I also went around looking for other areas that this
      list is modified and added this protection there too.  Care must be taken
      since these locations call several functions that may also schedule.
      
      Since I don't see any location that these functions that modify the
      subdirectory list are called by interrupts, the irqsave/restore versions of
      the spin lock was _not_ used.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64a07bd8
  17. 13 1月, 2006 1 次提交
  18. 09 11月, 2005 1 次提交
    • A
      [PATCH] Fix sysctl unregistration oops (CVE-2005-2709) · 330d57fb
      Al Viro 提交于
      You could open the /proc/sys/net/ipv4/conf/<if>/<whatever> file, then
      wait for interface to go away, try to grab as much memory as possible in
      hope to hit the (kfreed) ctl_table.  Then fill it with pointers to your
      function.  Then do read from file you've opened and if you are lucky,
      you'll get it called as ->proc_handler() in kernel mode.
      
      So this is at least an Oops and possibly more.  It does depend on an
      interface going away though, so less of a security risk than it would
      otherwise be.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      330d57fb
  19. 08 11月, 2005 1 次提交
  20. 26 6月, 2005 1 次提交
    • V
      [PATCH] kdump: Access dump file in elf format (/proc/vmcore) · 666bfddb
      Vivek Goyal 提交于
      From: "Vivek Goyal" <vgoyal@in.ibm.com>
      
      o Support for /proc/vmcore interface. This interface exports elf core image
        either in ELF32 or ELF64 format, depending on the format in which elf headers
        have been stored by crashed kernel.
      o Added support for CONFIG_VMCORE config option.
      o Removed the dependency on /proc/kcore.
      
      From: "Eric W. Biederman" <ebiederm@xmission.com>
      
      This patch has been refactored to more closely match the prevailing style in
      the affected files.  And to clearly indicate the dependency between
      /proc/kcore and proc/vmcore.c
      
      From: Hariprasad Nellitheertha <hari@in.ibm.com>
      
      This patch contains the code that provides an ELF format interface to the
      previous kernel's memory post kexec reboot.
      
      Signed off by Hariprasad Nellitheertha <hari@in.ibm.com>
      Signed-off-by: NEric Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      666bfddb
  21. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4