1. 15 9月, 2005 4 次提交
    • H
      [PATCH] error path in setup_arg_pages() misses vm_unacct_memory() · 2fd4ef85
      Hugh Dickins 提交于
      Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
      security_vm_enough_memory tend to forget to vm_unacct_memory when a
      failure occurs further down (typically in setup_arg_pages variants).
      
      These are all users of insert_vm_struct, and that reservation will only
      be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
      cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.
      
      So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
      Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
      it's inappropriate to reserve against the very unlikely case that gdb
      be used to COW a vDSO page - we ought to do something about that in
      do_wp_page, but there are yet other inconsistencies to be resolved.
      
      The safe and economical way to fix this is to let insert_vm_struct do
      the security_vm_enough_memory check when it finds VM_ACCOUNT is set.
      
      And the MIPS irix_brk has been calling security_vm_enough_memory before
      calling do_brk which repeats it, doubly accounting and so also leaking.
      Remove that, and all the fs and arch calls to security_vm_enough_memory:
      give it a less misleading name later on.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-Off-By: NKirill Korotaev <dev@sw.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2fd4ef85
    • A
      [PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON · fb085cf1
      Alexander Nyberg 提交于
      It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
      and can trigger due to the test itself being racy.
      
      de_thread() does
       	while (atomic_read(&sig->count) > count) {
      	}
      	.....
      	.....
      	BUG_ON(!thread_group_empty(current));
      
      but release_task does
      	write_lock_irq(&tasklist_lock)
      	__exit_signal
      		(this is where atomic_dec(&sig->count) is run)
      	__exit_sighand
      	__unhash_process
      		takes write lock on tasklist_lock
      		remove itself out of PIDTYPE_TGID list
      	write_unlock_irq(&tasklist_lock)
      
      so there's a clear (although small) window between the
      atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
      thread.
      
      And actually there is no need for all threads to have exited at this
      point, so we simply kill the BUG_ON.
      
      Big thanks to Marc Lehmann who provided the test-case.
      
      Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
      Signed-off-by: NAlexander Nyberg <alexn@telia.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fb085cf1
    • J
      [PATCH] pci: only call pci_restore_bars at boot · 32a36585
      John W. Linville 提交于
      Certain (SGI?) ia64 boxes object to having their PCI BARs
      restored unless absolutely necessary. This patch restricts calling
      pci_restore_bars from pci_set_power_state unless the current state
      is PCI_UNKNOWN, the actual (i.e. physical) state of the device is
      PCI_D3hot, and the device indicates that it will lose its configuration
      when transitioning to PCI_D0.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      32a36585
    • L
  2. 14 9月, 2005 30 次提交
  3. 13 9月, 2005 6 次提交