1. 15 9月, 2005 8 次提交
    • L
      Fix yenta error message when unable to find a bus assignment · 5a23f347
      Linus Torvalds 提交于
      And mention 'pci=assign-busses' as a possible fix.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5a23f347
    • D
      [PATCH] Fix the fdtable freeing in the case of vmalloced fdset/arrays · 0b175a7e
      Dipankar Sarma 提交于
      Noted by David Miller:
      
        "The bug is that free_fd_array() takes a "num" argument, but when
         calling it from __free_fdtable() we're instead passing in the size in
         bytes (ie.  "num * sizeof(struct file *)")."
      
      Yes it is a bug. I think I messed it up while merging newer
      changes with an older version where I was using size in bytes
      to optimize.
      Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0b175a7e
    • A
      [PATCH] Fix slab BUG_ON() triggered by change in array cache size · c7e43c78
      Alok Kataria 提交于
      With the new changes that we made in the initialization of the slab
      allocator, we first setup the cache from which array caches are allocated,
      and then the cache, from which kmem_list3's are allocated.
      
      Now if the array cache comes from a cache in which objsize > 32, (in this
      instance size-64) then, first size-64 cache will be allocated and then the
      size-128 (if this is the cache from which kmem_list3's are going to be
      allocated).
      
      So with these new changes, we are not guaranteed that we will be
      initializing the malloc_sizes array in a serialized order. Thus there is
      a bug in __find_general_cachep, as we are checking whether the first
      cache_sizes ptr is NULL.
      
      This is replaced by checking whether the array-cache cache is initialized.
      Attached is a patch which does that.  Boots fine on a x86-64, with
      DEBUG_SPIN, DEBUG_SLAB, and preempt.
      
      Attached is a patch which does that.  Boots fine on a x86-64, with
      DEBUG_SPIN, DEBUG_SLAB, and preempt.Thanks & Regards, Alok
      Signed-off-by: NAlok N Kataria <alokk@calsoftinc.com>
      Signed-off-by: Shobhit Dayal <shobhitdayal.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Christoph Lameter <christoph@lameter.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c7e43c78
    • I
      [PATCH] yenta oops fix · c7fb0b35
      Ivan Kokshaysky 提交于
      In some cases, especially on modern laptops with a lot of PCI and
      cardbus bridges, we're unable to assign correct secondary/subordinate
      bus numbers to all cardbus bridges due to BIOS limitations unless
      we are using "pci=assign-busses" boot option.
      So some cardbus controllers may not have attached subordinate pci_bus
      structure, and yenta driver must cope with it - just ignore such cardbus
      bridges.
      
      For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c7fb0b35
    • 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 2 次提交