1. 22 7月, 2012 2 次提交
  2. 26 6月, 2012 3 次提交
  3. 21 6月, 2012 1 次提交
    • A
      thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE · e4eed03f
      Andrea Arcangeli 提交于
      In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding the
      mmap_sem for reading, cmpxchg8b cannot be used to read pmd contents under
      Xen.
      
      So instead of dealing only with "consistent" pmdvals in
      pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
      simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
      where the low 32bit and high 32bit could be inconsistent (to avoid having
      to use cmpxchg8b).
      
      The only guarantee we get from pmd_read_atomic is that if the low part of
      the pmd was found null, the high part will be null too (so the pmd will be
      considered unstable).  And if the low part of the pmd is found "stable"
      later, then it means the whole pmd was read atomically (because after a
      pmd is stable, neither MADV_DONTNEED nor page faults can alter it anymore,
      and we read the high part after the low part).
      
      In the 32bit PAE x86 case, it is enough to read the low part of the pmdval
      atomically to declare the pmd as "stable" and that's true for THP and no
      THP, furthermore in the THP case we also have a barrier() that will
      prevent any inconsistent pmdvals to be cached by a later re-read of the
      *pmd.
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Petr Matousek <pmatouse@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Jan Beulich <jbeulich@suse.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
      Tested-by: NAndrew Jones <drjones@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4eed03f
  4. 18 6月, 2012 1 次提交
  5. 16 6月, 2012 1 次提交
  6. 15 6月, 2012 2 次提交
    • S
      x86, compat: Use test_thread_flag(TIF_IA32) in compat signal delivery · 0b91f45b
      Suresh Siddha 提交于
      Signal delivery compat path may not have the 'TS_COMPAT' flag (that
      flag indicates how we entered the kernel).  So use
      test_thread_flag(TIF_IA32) instead of is_ia32_task(): one of the
      functions of TIF_IA32 is just what kind of signal frame we want.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1339722435.3475.57.camel@sbsiddha-desk.sc.intel.com
      Cc: stable@kernel.org	# v3.4
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      0b91f45b
    • S
      xen: mark local pages as FOREIGN in the m2p_override · b9e0d95c
      Stefano Stabellini 提交于
      When the frontend and the backend reside on the same domain, even if we
      add pages to the m2p_override, these pages will never be returned by
      mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
      always fail, so the pfn of the frontend will be returned instead
      (resulting in a deadlock because the frontend pages are already locked).
      
      INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
       ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
       ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
       ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
      Call Trace:
       [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
       [<ffffffff81a0fdd9>] schedule+0x29/0x70
       [<ffffffff81a0fe80>] io_schedule+0x60/0x80
       [<ffffffff81101eee>] sleep_on_page+0xe/0x20
       [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
       [<ffffffff81101ed7>] __lock_page+0x67/0x70
       [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
       [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
       [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
       [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
       [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
       [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
       [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
       [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
       [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
       [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
       [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
       [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
       [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
       [<ffffffff811998b8>] do_io_submit+0x708/0xb90
       [<ffffffff81199d50>] sys_io_submit+0x10/0x20
       [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b
      
      The explanation is in the comment within the code:
      
      We need to do this because the pages shared by the frontend
      (xen-blkfront) can be already locked (lock_page, called by
      do_read_cache_page); when the userspace backend tries to use them
      with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
      do_blockdev_direct_IO is going to try to lock the same pages
      again resulting in a deadlock.
      
      A simplified call graph looks like this:
      
      pygrub                          QEMU
      -----------------------------------------------
      do_read_cache_page              io_submit
        |                              |
      lock_page                       ext3_direct_IO
                                       |
                                      bio_add_page
                                       |
                                      lock_page
      
      Internally the xen-blkback uses m2p_add_override to swizzle (temporarily)
      a 'struct page' to have a different MFN (so that it can point to another
      guest). It also can easily find out whether another pfn corresponding
      to the mfn exists in the m2p, and can set the FOREIGN bit
      in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.
      
      This allows the backend to perform direct_IO on these pages, but as a
      side effect prevents the frontend from using get_user_pages_fast on
      them while they are being shared with the backend.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      b9e0d95c
  7. 14 6月, 2012 1 次提交
  8. 13 6月, 2012 2 次提交
    • S
      perf/x86: Fix broken LBR fixup code · 25f42985
      Stephane Eranian 提交于
      I noticed that the LBR fixups were not working anymore
      on programs where they used to. I tracked this down to
      a recent change to copy_from_user_nmi():
      
       db0dc75d ("perf/x86: Check user address explicitly in copy_from_user_nmi()")
      
      This commit added a call to __range_not_ok() to the
      copy_from_user_nmi() routine. The problem is that the logic
      of the test must be reversed. __range_not_ok() returns 0 if the
      range is VALID. We want to return early from copy_from_user_nmi()
      if the range is NOT valid.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NArun Sharma <asharma@fb.com>
      Link: http://lkml.kernel.org/r/20120611134426.GA7542@quadSigned-off-by: NIngo Molnar <mingo@kernel.org>
      25f42985
    • B
      x86/smp: Fix topology checks on AMD MCM CPUs · 161270fc
      Borislav Petkov 提交于
      The warning below triggers on AMD MCM packages because physical package
      IDs on the cores of a _physical_ socket are the same. I.e., this field
      says which CPUs belong to the same physical package.
      
      However, the same two CPUs belong to two different internal, i.e.
      "logical" nodes in the same physical socket which is reflected in the
      CPU-to-node map on x86 with NUMA.
      
      Which makes this check wrong on the above topologies so circumvent it.
      
      [    0.444413] Booting Node   0, Processors  #1 #2 #3 #4 #5 Ok.
      [    0.461388] ------------[ cut here ]------------
      [    0.465997] WARNING: at arch/x86/kernel/smpboot.c:310 topology_sane.clone.1+0x6e/0x81()
      [    0.473960] Hardware name: Dinar
      [    0.477170] sched: CPU #6's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
      [    0.486860] Booting Node   1, Processors  #6
      [    0.491104] Modules linked in:
      [    0.494141] Pid: 0, comm: swapper/6 Not tainted 3.4.0+ #1
      [    0.499510] Call Trace:
      [    0.501946]  [<ffffffff8144bf92>] ? topology_sane.clone.1+0x6e/0x81
      [    0.508185]  [<ffffffff8102f1fc>] warn_slowpath_common+0x85/0x9d
      [    0.514163]  [<ffffffff8102f2b7>] warn_slowpath_fmt+0x46/0x48
      [    0.519881]  [<ffffffff8144bf92>] topology_sane.clone.1+0x6e/0x81
      [    0.525943]  [<ffffffff8144c234>] set_cpu_sibling_map+0x251/0x371
      [    0.532004]  [<ffffffff8144c4ee>] start_secondary+0x19a/0x218
      [    0.537729] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.628197]  #7 #8 #9 #10 #11 Ok.
      [    0.807108] Booting Node   3, Processors  #12 #13 #14 #15 #16 #17 Ok.
      [    0.897587] Booting Node   2, Processors  #18 #19 #20 #21 #22 #23 Ok.
      [    0.917443] Brought up 24 CPUs
      
      We ran a topology sanity check test we have here on it and
      it all looks ok... hopefully :).
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20120529135442.GE29157@aftab.osrc.amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      161270fc
  9. 12 6月, 2012 4 次提交
  10. 11 6月, 2012 1 次提交
  11. 10 6月, 2012 1 次提交
  12. 08 6月, 2012 4 次提交
  13. 06 6月, 2012 17 次提交