1. 20 11月, 2006 1 次提交
  2. 17 11月, 2006 1 次提交
  3. 16 11月, 2006 2 次提交
  4. 15 11月, 2006 1 次提交
    • H
      [PATCH] hugetlb: prepare_hugepage_range check offset too · 68589bc3
      Hugh Dickins 提交于
      (David:)
      
      If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example,
      because the given file offset is not hugepage aligned - then do_mmap_pgoff
      will go to the unmap_and_free_vma backout path.
      
      But at this stage the vma hasn't been marked as hugepage, and the backout path
      will call unmap_region() on it.  That will eventually call down to the
      non-hugepage version of unmap_page_range().  On ppc64, at least, that will
      cause serious problems if there are any existing hugepage pagetable entries in
      the vicinity - for example if there are any other hugepage mappings under the
      same PUD.  unmap_page_range() will trigger a bad_pud() on the hugepage pud
      entries.  I suspect this will also cause bad problems on ia64, though I don't
      have a machine to test it on.
      
      (Hugh:)
      
      prepare_hugepage_range() should check file offset alignment when it checks
      virtual address and length, to stop MAP_FIXED with a bad huge offset from
      unmapping before it fails further down.  PowerPC should apply the same
      prepare_hugepage_range alignment checks as ia64 and all the others do.
      
      Then none of the alignment checks in hugetlbfs_file_mmap are required (nor
      is the check for too small a mapping); but even so, move up setting of
      VM_HUGETLB and add a comment to warn of what David Gibson discovered - if
      hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region
      when unwinding from error will go the non-huge way, which may cause bad
      behaviour on architectures (powerpc and ia64) which segregate their huge
      mappings into a separate region of the address space.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Acked-by: NAdam Litke <agl@us.ibm.com>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      68589bc3
  5. 13 11月, 2006 2 次提交
  6. 09 11月, 2006 4 次提交
  7. 06 11月, 2006 3 次提交
  8. 04 11月, 2006 4 次提交
  9. 03 11月, 2006 1 次提交
  10. 01 11月, 2006 1 次提交
  11. 31 10月, 2006 2 次提交
    • R
      [PATCH] MTD: fix last kernel-doc warning · 351edd24
      Randy Dunlap 提交于
      Fix the last current kernel-doc warning:
      Warning(/var/linsrc/linux-2619-rc3g5//include/linux/mtd/nand.h:416): No description found for parameter 'write_page'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      351edd24
    • P
      [PATCH] lockdep: annotate DECLARE_WAIT_QUEUE_HEAD · 7259f0d0
      Peter Zijlstra 提交于
      kernel: INFO: trying to register non-static key.
      kernel: the code is fine but needs lockdep annotation.
      kernel: turning off the locking correctness validator.
      kernel:  [<c04051ed>] show_trace_log_lvl+0x58/0x16a
      kernel:  [<c04057fa>] show_trace+0xd/0x10
      kernel:  [<c0405913>] dump_stack+0x19/0x1b
      kernel:  [<c043b1e2>] __lock_acquire+0xf0/0x90d
      kernel:  [<c043bf70>] lock_acquire+0x4b/0x6b
      kernel:  [<c061472f>] _spin_lock_irqsave+0x22/0x32
      kernel:  [<c04363d3>] prepare_to_wait+0x17/0x4b
      kernel:  [<f89a24b6>] lpfc_do_work+0xdd/0xcc2 [lpfc]
      kernel:  [<c04361b9>] kthread+0xc3/0xf2
      kernel:  [<c0402005>] kernel_thread_helper+0x5/0xb
      
      Another case of non-static lockdep keys; duplicate the paradigm set by
      DECLARE_COMPLETION_ONSTACK and introduce DECLARE_WAIT_QUEUE_HEAD_ONSTACK.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Greg KH <gregkh@suse.de>
      Cc: Markus Lidel <markus.lidel@shadowconnect.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7259f0d0
  12. 29 10月, 2006 7 次提交
    • O
      [PATCH] taskstats: kill ->taskstats_lock in favor of ->siglock · b8534d7b
      Oleg Nesterov 提交于
      signal_struct is (mostly) protected by ->sighand->siglock, I think we don't
      need ->taskstats_lock to protect ->stats.  This also allows us to simplify the
      locking in fill_tgid().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Jay Lan <jlan@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b8534d7b
    • O
      [PATCH] taskstats_tgid_alloc: optimization · 17b02695
      Oleg Nesterov 提交于
      Every subthread (except first) does unneeded kmem_cache_alloc/kmem_cache_free.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Jay Lan <jlan@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      17b02695
    • O
      [PATCH] taskstats_tgid_free: fix usage · 093a8e8a
      Oleg Nesterov 提交于
      taskstats_tgid_free() is called on copy_process's error path. This is wrong.
      
      	IF (clone_flags & CLONE_THREAD)
      		We should not clear ->signal->taskstats, current uses it,
      		it probably has a valid accumulated info.
      	ELSE
      		taskstats_tgid_init() set ->signal->taskstats = NULL,
      		there is nothing to free.
      
      Move the callsite to __exit_signal(). We don't need any locking, entire
      thread group is exiting, nobody should have a reference to soon to be
      released ->signal.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Jay Lan <jlan@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      093a8e8a
    • S
      [PATCH] Constify compat_get_bitmap argument · 5fa3839a
      Stephen Rothwell 提交于
      This means we can call it when the bitmap we want to fetch is declared
      const.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5fa3839a
    • G
      [PATCH] __vmalloc with GFP_ATOMIC causes 'sleeping from invalid context' · 52fd24ca
      Giridhar Pemmasani 提交于
      If __vmalloc is called to allocate memory with GFP_ATOMIC in atomic
      context, the chain of calls results in __get_vm_area_node allocating memory
      for vm_struct with GFP_KERNEL, causing the 'sleeping from invalid context'
      warning.  This patch fixes it by passing the gfp flags along so
      __get_vm_area_node allocates memory for vm_struct with the same flags.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      52fd24ca
    • M
      [PATCH] vmscan: Fix temp_priority race · 3bb1a852
      Martin Bligh 提交于
      The temp_priority field in zone is racy, as we can walk through a reclaim
      path, and just before we copy it into prev_priority, it can be overwritten
      (say with DEF_PRIORITY) by another reclaimer.
      
      The same bug is contained in both try_to_free_pages and balance_pgdat, but
      it is fixed slightly differently.  In balance_pgdat, we keep a separate
      priority record per zone in a local array.  In try_to_free_pages there is
      no need to do this, as the priority level is the same for all zones that we
      reclaim from.
      
      Impact of this bug is that temp_priority is copied into prev_priority, and
      setting this artificially high causes reclaimers to set distress
      artificially low.  They then fail to reclaim mapped pages, when they are,
      in fact, under severe memory pressure (their priority may be as low as 0).
      This causes the OOM killer to fire incorrectly.
      
      From: Andrew Morton <akpm@osdl.org>
      
      __zone_reclaim() isn't modifying zone->prev_priority.  But zone->prev_priority
      is used in the decision whether or not to bring mapped pages onto the inactive
      list.  Hence there's a risk here that __zone_reclaim() will fail because
      zone->prev_priority ir large (ie: low urgency) and lots of mapped pages end up
      stuck on the active list.
      
      Fix that up by decreasing (ie making more urgent) zone->prev_priority as
      __zone_reclaim() scans the zone's pages.
      
      This bug perhaps explains why ZONE_RECLAIM_PRIORITY was created.  It should be
      possible to remove that now, and to just start out at DEF_PRIORITY?
      
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3bb1a852
    • N
      [PATCH] mm: clean up pagecache allocation · 2ae88149
      Nick Piggin 提交于
      - Consolidate page_cache_alloc
      
      - Fix splice: only the pagecache pages and filesystem data need to use
        mapping_gfp_mask.
      
      - Fix grab_cache_page_nowait: same as splice, also honour NUMA placement.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2ae88149
  13. 28 10月, 2006 1 次提交
    • A
      [PATCH] drivers: wait for threaded probes between initcall levels · 735a7ffb
      Andrew Morton 提交于
      The multithreaded-probing code has a problem: after one initcall level (eg,
      core_initcall) has been processed, we will then start processing the next
      level (postcore_initcall) while the kernel threads which are handling
      core_initcall are still executing.  This breaks the guarantees which the
      layered initcalls previously gave us.
      
      IOW, we want to be multithreaded _within_ an initcall level, but not between
      different levels.
      
      Fix that up by causing the probing code to wait for all outstanding probes at
      one level to complete before we start processing the next level.
      
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      735a7ffb
  14. 24 10月, 2006 1 次提交
  15. 22 10月, 2006 9 次提交