1. 16 12月, 2009 19 次提交
  2. 13 12月, 2009 1 次提交
    • L
      [BKL] add 'might_sleep()' to the outermost lock taker · f01eb364
      Linus Torvalds 提交于
      As shown by the previous patch (6698e347: "tty: Fix BKL taken under a
      spinlock bug introduced in the BKL split") the BKL removal is prone to
      some subtle issues, where removing the BKL in one place may in fact make
      a previously nested BKL call the new outer call, and then prone to nasty
      deadlocks with other spinlocks.
      
      In general, we should never take the BKL while we're holding a spinlock,
      so let's just add a "might_sleep()" to it (even though the BKL doesn't
      technically sleep - at least not yet), and we'll get nice warnings the
      next time this kind of problem happens during BKL removal.
      Acked-and-Tested-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f01eb364
  3. 04 12月, 2009 2 次提交
  4. 03 12月, 2009 1 次提交
    • P
      rcu: Make RCU's CPU-stall detector be default · 8bfb2f8e
      Paul E. McKenney 提交于
      The RCU_CPU_STALL_DETECTOR costs almost nothing and has located
      some bugs that might otherwise have been difficult to track
      down.  Make it be default for the TREE RCU implementations.
      
      The vmlinux size impact is limited (on 64-bit x86 defconfig):
      
         text	   data	    bss	    dec	    hex	filename
         8440248	1260076	 995588	10695912	 a334e8	vmlinux.before
         8440774	1260060	 995588	10696422	 a336e6	vmlinux.after
      
      +526 bytes - acceptable default cost.
      
      For RAM starved systems, TINY_RCU does not support CPU-stall detection
      and is much smaller, but then again it is a uniprocessor...
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <12597846162906-git-send-email->
      [ v2: added image size calculations to the changelog ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8bfb2f8e
  5. 20 11月, 2009 2 次提交
    • D
      FS-Cache: Don't delete pending pages from the page-store tracking tree · 285e728b
      David Howells 提交于
      Don't delete pending pages from the page-store tracking tree, but rather send
      them for another write as they've presumably been updated.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      285e728b
    • D
      FS-Cache: Use radix tree preload correctly in tracking of pages to be stored · b34df792
      David Howells 提交于
      __fscache_write_page() attempts to load the radix tree preallocation pool for
      the CPU it is on before calling radix_tree_insert(), as the insertion must be
      done inside a pair of spinlocks.
      
      Use of the preallocation pool, however, is contingent on the radix tree being
      initialised without __GFP_WAIT specified.  __fscache_acquire_cookie() was
      passing GFP_NOFS to INIT_RADIX_TREE() - but that includes __GFP_WAIT.
      
      The solution is to AND out __GFP_WAIT.
      
      Additionally, the banner comment to radix_tree_preload() is altered to make
      note of this prerequisite.  Possibly there should be a WARN_ON() too.
      
      Without this fix, I have seen the following recursive deadlock caused by
      radix_tree_insert() attempting to allocate memory inside the spinlocked
      region, which resulted in FS-Cache being called back into to release memory -
      which required the spinlock already held.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.32-rc6-cachefs #24
      ---------------------------------------------
      nfsiod/7916 is trying to acquire lock:
       (&cookie->lock){+.+.-.}, at: [<ffffffffa0076872>] __fscache_uncache_page+0xdb/0x160 [fscache]
      
      but task is already holding lock:
       (&cookie->lock){+.+.-.}, at: [<ffffffffa0076acc>] __fscache_write_page+0x15c/0x3f3 [fscache]
      
      other info that might help us debug this:
      5 locks held by nfsiod/7916:
       #0:  (nfsiod){+.+.+.}, at: [<ffffffff81048290>] worker_thread+0x19a/0x2e2
       #1:  (&task->u.tk_work#2){+.+.+.}, at: [<ffffffff81048290>] worker_thread+0x19a/0x2e2
       #2:  (&cookie->lock){+.+.-.}, at: [<ffffffffa0076acc>] __fscache_write_page+0x15c/0x3f3 [fscache]
       #3:  (&object->lock#2){+.+.-.}, at: [<ffffffffa0076b07>] __fscache_write_page+0x197/0x3f3 [fscache]
       #4:  (&cookie->stores_lock){+.+...}, at: [<ffffffffa0076b0f>] __fscache_write_page+0x19f/0x3f3 [fscache]
      
      stack backtrace:
      Pid: 7916, comm: nfsiod Not tainted 2.6.32-rc6-cachefs #24
      Call Trace:
       [<ffffffff8105ac7f>] __lock_acquire+0x1649/0x16e3
       [<ffffffff81059ded>] ? __lock_acquire+0x7b7/0x16e3
       [<ffffffff8100e27d>] ? dump_trace+0x248/0x257
       [<ffffffff8105ad70>] lock_acquire+0x57/0x6d
       [<ffffffffa0076872>] ? __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffff8135467c>] _spin_lock+0x2c/0x3b
       [<ffffffffa0076872>] ? __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffffa0076872>] __fscache_uncache_page+0xdb/0x160 [fscache]
       [<ffffffffa0077eb7>] ? __fscache_check_page_write+0x0/0x71 [fscache]
       [<ffffffffa00b4755>] nfs_fscache_release_page+0x86/0xc4 [nfs]
       [<ffffffffa00907f0>] nfs_release_page+0x3c/0x41 [nfs]
       [<ffffffff81087ffb>] try_to_release_page+0x32/0x3b
       [<ffffffff81092c2b>] shrink_page_list+0x316/0x4ac
       [<ffffffff81058a9b>] ? mark_held_locks+0x52/0x70
       [<ffffffff8135451b>] ? _spin_unlock_irq+0x2b/0x31
       [<ffffffff81093153>] shrink_inactive_list+0x392/0x67c
       [<ffffffff81058a9b>] ? mark_held_locks+0x52/0x70
       [<ffffffff810934ca>] shrink_list+0x8d/0x8f
       [<ffffffff81093744>] shrink_zone+0x278/0x33c
       [<ffffffff81052c70>] ? ktime_get_ts+0xad/0xba
       [<ffffffff8109453b>] try_to_free_pages+0x22e/0x392
       [<ffffffff8109184c>] ? isolate_pages_global+0x0/0x212
       [<ffffffff8108e16b>] __alloc_pages_nodemask+0x3dc/0x5cf
       [<ffffffff810ae24a>] cache_alloc_refill+0x34d/0x6c1
       [<ffffffff811bcf74>] ? radix_tree_node_alloc+0x52/0x5c
       [<ffffffff810ae929>] kmem_cache_alloc+0xb2/0x118
       [<ffffffff811bcf74>] radix_tree_node_alloc+0x52/0x5c
       [<ffffffff811bcfd5>] radix_tree_insert+0x57/0x19c
       [<ffffffffa0076b53>] __fscache_write_page+0x1e3/0x3f3 [fscache]
       [<ffffffffa00b4248>] __nfs_readpage_to_fscache+0x58/0x11e [nfs]
       [<ffffffffa009bb77>] nfs_readpage_release+0x34/0x9b [nfs]
       [<ffffffffa009c0d9>] nfs_readpage_release_full+0x32/0x4b [nfs]
       [<ffffffffa0006cff>] rpc_release_calldata+0x12/0x14 [sunrpc]
       [<ffffffffa0006e2d>] rpc_free_task+0x59/0x61 [sunrpc]
       [<ffffffffa0006f03>] rpc_async_release+0x10/0x12 [sunrpc]
       [<ffffffff810482e5>] worker_thread+0x1ef/0x2e2
       [<ffffffff81048290>] ? worker_thread+0x19a/0x2e2
       [<ffffffff81352433>] ? thread_return+0x3e/0x101
       [<ffffffffa0006ef3>] ? rpc_async_release+0x0/0x12 [sunrpc]
       [<ffffffff8104bff5>] ? autoremove_wake_function+0x0/0x34
       [<ffffffff81058d25>] ? trace_hardirqs_on+0xd/0xf
       [<ffffffff810480f6>] ? worker_thread+0x0/0x2e2
       [<ffffffff8104bd21>] kthread+0x7a/0x82
       [<ffffffff8100beda>] child_rip+0xa/0x20
       [<ffffffff8100b87c>] ? restore_args+0x0/0x30
       [<ffffffff8104c2b9>] ? add_wait_queue+0x15/0x44
       [<ffffffff8104bca7>] ? kthread+0x0/0x82
       [<ffffffff8100bed0>] ? child_rip+0x0/0x20
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      b34df792
  6. 19 11月, 2009 1 次提交
  7. 16 11月, 2009 1 次提交
  8. 11 11月, 2009 2 次提交
  9. 10 11月, 2009 3 次提交
    • F
      x86: Handle HW IOMMU initialization failure gracefully · 75f1cdf1
      FUJITA Tomonori 提交于
      If HW IOMMU initialization fails (Intel VT-d often does this,
      typically due to BIOS bugs), we fall back to nommu. It doesn't
      work for the majority since nowadays we have more than 4GB
      memory so we must use swiotlb instead of nommu.
      
      The problem is that it's too late to initialize swiotlb when HW
      IOMMU initialization fails. We need to allocate swiotlb memory
      earlier from bootmem allocator. Chris explained the issue in
      detail:
      
        http://marc.info/?l=linux-kernel&m=125657444317079&w=2
      
      The current x86 IOMMU initialization sequence is too complicated
      and handling the above issue makes it more hacky.
      
      This patch changes x86 IOMMU initialization sequence to handle
      the above issue cleanly.
      
      The new x86 IOMMU initialization sequence are:
      
      1. we initialize the swiotlb (and setting swiotlb to 1) in the case
         of (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to
         swiotlb_dma_ops or nommu_dma_ops. if swiotlb usage is forced by
         the boot option, we finish here.
      
      2. we call the detection functions of all the IOMMUs
      
      3. the detection function sets x86_init.iommu.iommu_init to the
         IOMMU initialization function (so we can avoid calling the
         initialization functions of all the IOMMUs needlessly).
      
      4. if the IOMMU initialization function doesn't need to swiotlb
         then sets swiotlb to zero (e.g. the initialization is
         sucessful).
      
      5. if we find that swiotlb is set to zero, we free swiotlb
         resource.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      Cc: muli@il.ibm.com
      LKML-Reference: <1257849980-22640-10-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      75f1cdf1
    • F
      swiotlb: Defer swiotlb init printing, export swiotlb_print_info() · ad32e8cb
      FUJITA Tomonori 提交于
      This enables us to avoid printing swiotlb memory info when we
      initialize swiotlb. After swiotlb initialization, we could find
      that we don't need swiotlb.
      
      This patch removes the code to print swiotlb memory info in
      swiotlb_init() and exports the function to do that.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      Cc: muli@il.ibm.com
      Cc: tony.luck@intel.com
      Cc: benh@kernel.crashing.org
      LKML-Reference: <1257849980-22640-9-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      [ -v2: merge up conflict ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ad32e8cb
    • F
      swiotlb: Add swiotlb_free() function · 5740afdb
      FUJITA Tomonori 提交于
      swiotlb_free() function frees all allocated memory for swiotlb.
      
      We need to initialize swiotlb before IOMMU initialization (x86
      and powerpc needs to allocate memory from bootmem allocator). If
      IOMMU initialization is successful, we need to free swiotlb
      resource (don't want to waste 64MB).
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      Cc: muli@il.ibm.com
      LKML-Reference: <1257849980-22640-8-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      [ -v2: build fix for the !CONFIG_SWIOTLB case ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5740afdb
  10. 05 11月, 2009 4 次提交
  11. 03 11月, 2009 3 次提交
  12. 29 10月, 2009 1 次提交