1. 11 1月, 2014 5 次提交
  2. 10 1月, 2014 1 次提交
  3. 09 1月, 2014 1 次提交
    • J
      Revert "intel_idle: mark states tables with __initdata tag" · ba0dc81e
      Jiang Liu 提交于
      This reverts commit 9d046ccb.
      
      Commit 9d046ccb marks all state tables with __initdata, but
      the state table may be accessed when doing CPU online, which then
      causing system crash as below:
      
      [  204.188841] BUG: unable to handle kernel paging request at ffffffff8227cce8
      [  204.196844] IP: [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.203996] PGD 1e11067 PUD 1e12063 PMD 455859063 PTE 800000000227c062
      [  204.211638] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [  204.216975] Modules linked in: x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd gpio_ich microcode joydev sb_edac edac_core ipmi_si lpc_ich ipmi_msghandler lp tpm_tis parport wmi mac_hid acpi_pad hid_generic ixgbe isci usbhid dca hid libsas ptp ahci libahci scsi_transport_sas megaraid_sas pps_core mdio
      [  204.262815] CPU: 11 PID: 1489 Comm: bash Not tainted 3.13.0-rc7+ #48
      [  204.269993] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.L09.1312061514 12/06/2013
      [  204.281646] task: ffff8804303a24a0 ti: ffff880440fac000 task.ti: ffff880440fac000
      [  204.290311] RIP: 0010:[<ffffffff814aa1c0>]  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.300184] RSP: 0018:ffff880440fadd28  EFLAGS: 00010286
      [  204.306192] RAX: ffffffff8227cca0 RBX: ffffe8fff1a03400 RCX: 0000000000000007
      [  204.314244] RDX: ffff88045f400000 RSI: 0000000000000009 RDI: 0000000000001120
      [  204.322296] RBP: ffff880440fadd38 R08: 0000000000000000 R09: 0000000000000001
      [  204.330411] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000001e
      [  204.338482] R13: 00000000ffffffdb R14: 0000000000000001 R15: 0000000000000000
      [  204.346743] FS:  00007f64f7b0c740(0000) GS:ffff88045ce00000(0000) knlGS:0000000000000000
      [  204.355919] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  204.362449] CR2: ffffffff8227cce8 CR3: 0000000444ab0000 CR4: 00000000001407e0
      [  204.370520] Stack:
      [  204.372853]  000000000000001e ffffffff81f10240 ffff880440fadd50 ffffffff814aa307
      [  204.381519]  ffffffff81ea80e0 ffff880440fadda0 ffffffff8185a230 0000000000000000
      [  204.390196]  000000000000001e 0000000000000002 0000000000000002 0000000000000000
      [  204.398856] Call Trace:
      [  204.401683]  [<ffffffff814aa307>] cpu_hotplug_notify+0x57/0x70
      [  204.408638]  [<ffffffff8185a230>] notifier_call_chain+0x100/0x150
      [  204.415553]  [<ffffffff810a7dae>] __raw_notifier_call_chain+0xe/0x10
      [  204.422772]  [<ffffffff81072163>] cpu_notify+0x23/0x50
      [  204.428616]  [<ffffffff810723b2>] _cpu_up+0x132/0x1a0
      [  204.434361]  [<ffffffff8107249d>] cpu_up+0x7d/0xa0
      [  204.439819]  [<ffffffff81836c9c>] cpu_subsys_online+0x3c/0x90
      [  204.446345]  [<ffffffff81554625>] device_online+0x45/0xa0
      [  204.452471]  [<ffffffff815546ce>] online_store+0x4e/0x80
      [  204.458511]  [<ffffffff815519a8>] dev_attr_store+0x18/0x30
      [  204.464744]  [<ffffffff812a68f1>] sysfs_write_file+0x151/0x1c0
      [  204.471681]  [<ffffffff81217ef1>] vfs_write+0xe1/0x160
      [  204.477524]  [<ffffffff8121889c>] SyS_write+0x4c/0x90
      [  204.483270]  [<ffffffff8185f2ed>] system_call_fastpath+0x1a/0x1f
      [  204.490081] Code: 41 54 41 89 fc 8b 3d 48 25 85 01 53 48 8b 1d 30 25 85 01 48 03 1c c5 40 90 fb 81 48 8b 05 19 25 85 01 c7 43 0c 01 00 00 00 66 90 <48> 83 78 48 00 74 4f 41 83 c0 01 41 39 f0 7e 10 48 c7 c7 38 79
      [  204.515723] RIP  [<ffffffff814aa1c0>] intel_idle_cpu_init+0x40/0x130
      [  204.522996]  RSP <ffff880440fadd28>
      [  204.526976] CR2: ffffffff8227cce8
      [  204.530766] ---[ end trace 336f56cc3d1cfc8c ]---
      
      Fixes: 9d046ccb (intel_idle: mark states tables with __initdata tag)
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ba0dc81e
  4. 05 1月, 2014 1 次提交
  5. 04 1月, 2014 2 次提交
    • L
      Merge tag 'for-v3.13-fixes' of git://git.infradead.org/battery-2.6 · 9a2f1aad
      Linus Torvalds 提交于
      Pull battery fixes from Anton Vorontsov:
       "Two fixes:
      
         - fix build error caused by max17042_battery conversion to the regmap
           API.
      
         - fix kernel oops when booting with wakeup_source_activate enabled"
      
      * tag 'for-v3.13-fixes' of git://git.infradead.org/battery-2.6:
        max17042_battery: Fix build errors caused by missing REGMAP_I2C config
        power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate
      9a2f1aad
    • L
      Merge tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 23e8e590
      Linus Torvalds 提交于
      Pull ACPI and PM fixes and new device IDs from Rafael Wysocki:
       "These commits, except for one, are regression fixes and the remaining
        one fixes a divide error leading to a kernel panic.  The majority of
        the regressions fixed here were introduced during the 3.12 cycle, one
        of them is from this cycle and one is older.
      
        Specifics:
      
         - VGA switcheroo was broken for some users as a result of the
           ACPI-based PCI hotplug (ACPIPHP) changes in 3.12, because some
           previously ignored hotplug events started to be handled.  The fix
           causes them to be ignored again.
      
         - There are two more issues related to cpufreq's suspend/resume
           handling changes from the 3.12 cycle addressed by Viresh Kumar's
           fixes.
      
         - intel_pstate triggers a divide error in a timer function if the
           P-state information it needs is missing during initialization.
           This leads to kernel panics on nested KVM clients and is fixed by
           failing the initialization cleanly in those cases.
      
         - PCI initalization code changes during the 3.9 cycle uncovered BIOS
           issues related to ACPI wakeup notifications (some BIOSes send them
           for devices that aren't supposed to support ACPI wakeup).  Work
           around them by installing an ACPI wakeup notify handler for all PCI
           devices with ACPI support.
      
         - The Calxeda cpuilde driver's probe function is tagged as __init,
           which is incorrect and causes a section mismatch to occur during
           build.  Fix from Andre Przywara removes the __init tag from there.
      
         - During the 3.12 cycle ACPIPHP started to print warnings about
           missing _ADR for devices that legitimately don't have it.  Fix from
           Toshi Kani makes it only print the warnings where they make sense"
      
      * tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
        intel_pstate: Fail initialization if P-state information is missing
        ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function
        PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI
        cpufreq: preserve user_policy across suspend/resume
        cpufreq: Clean up after a failing light-weight initialization
        ACPI / PCI / hotplug: Avoid warning when _ADR not present
      23e8e590
  6. 03 1月, 2014 14 次提交
    • L
      Merge git://git.kernel.org/pub/scm/virt/kvm/kvm · 7a262d2e
      Linus Torvalds 提交于
      Pull kvm bugfixes from Marcelo Tosatti.
      
      * git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
        KVM: x86: Fix APIC map calculation after re-enabling
      7a262d2e
    • L
      Merge branch 'akpm' (incoming from Andrew) · 06f055f3
      Linus Torvalds 提交于
      Merge patches from Andrew Morton:
       "Ten fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        epoll: do not take the nested ep->mtx on EPOLL_CTL_DEL
        sh: add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
        drivers/dma/ioat/dma.c: check DMA mapping error in ioat_dma_self_test()
        mm/memory-failure.c: transfer page count from head page to tail page after split thp
        MAINTAINERS: set up proper record for Xilinx Zynq
        mm: remove bogus warning in copy_huge_pmd()
        memcg: fix memcg_size() calculation
        mm: fix use-after-free in sys_remap_file_pages
        mm: munlock: fix deadlock in __munlock_pagevec()
        mm: munlock: fix a bug where THP tail page is encountered
      06f055f3
    • J
      epoll: do not take the nested ep->mtx on EPOLL_CTL_DEL · 4ff36ee9
      Jason Baron 提交于
      The EPOLL_CTL_DEL path of epoll contains a classic, ab-ba deadlock.
      That is, epoll_ctl(a, EPOLL_CTL_DEL, b, x), will deadlock with
      epoll_ctl(b, EPOLL_CTL_DEL, a, x).  The deadlock was introduced with
      commmit 67347fe4 ("epoll: do not take global 'epmutex' for simple
      topologies").
      
      The acquistion of the ep->mtx for the destination 'ep' was added such
      that a concurrent EPOLL_CTL_ADD operation would see the correct state of
      the ep (Specifically, the check for '!list_empty(&f.file->f_ep_links')
      
      However, by simply not acquiring the lock, we do not serialize behind
      the ep->mtx from the add path, and thus may perform a full path check
      when if we had waited a little longer it may not have been necessary.
      However, this is a transient state, and performing the full loop
      checking in this case is not harmful.
      
      The important point is that we wouldn't miss doing the full loop
      checking when required, since EPOLL_CTL_ADD always locks any 'ep's that
      its operating upon.  The reason we don't need to do lock ordering in the
      add path, is that we are already are holding the global 'epmutex'
      whenever we do the double lock.  Further, the original posting of this
      patch, which was tested for the intended performance gains, did not
      perform this additional locking.
      Signed-off-by: NJason Baron <jbaron@akamai.com>
      Cc: Nathan Zimmer <nzimmer@sgi.com>
      Cc: Eric Wong <normalperson@yhbt.net>
      Cc: Nelson Elhage <nelhage@nelhage.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ff36ee9
    • N
      sh: add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c · ad70b029
      Nobuhiro Iwamatsu 提交于
      Min_low_pfn and max_low_pfn were used in pfn_valid macro if defined
      CONFIG_FLATMEM.  When the functions that use the pfn_valid is used in
      driver module, max_low_pfn and min_low_pfn is to undefined, and fail to
      build.
      
        ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
        ERROR: "max_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
        make[2]: *** [__modpost] Error 1
        make[1]: *** [modules] Error 2
      
      This patch fix this problem.
      Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ad70b029
    • J
      drivers/dma/ioat/dma.c: check DMA mapping error in ioat_dma_self_test() · 3532e566
      Jiang Liu 提交于
      Check DMA mapping return values in function ioat_dma_self_test() to get
      rid of following warning message.
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1203 at lib/dma-debug.c:937 check_unmap+0x4c0/0x9a0()
        ioatdma 0000:00:04.0: DMA-API: device driver failed to check map error[device address=0x000000085191b000] [size=2000 bytes] [mapped as single]
        Modules linked in: ioatdma(+) mac_hid wmi acpi_pad lp parport hidd_generic usbhid hid ixgbe isci dca libsas ahci ptp libahci scsi_transport_sas meegaraid_sas pps_core mdio
        CPU: 0 PID: 1203 Comm: systemd-udevd Not tainted 3.13.0-rc4+ #8
        Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIIN1.86B.0044.L09.1311181644 11/18/2013
        Call Trace:
          dump_stack+0x4d/0x66
          warn_slowpath_common+0x7d/0xa0
          warn_slowpath_fmt+0x4c/0x50
          check_unmap+0x4c0/0x9a0
          debug_dma_unmap_page+0x81/0x90
          ioat_dma_self_test+0x3d2/0x680 [ioatdma]
          ioat3_dma_self_test+0x12/0x30 [ioatdma]
          ioat_probe+0xf4/0x110 [ioatdma]
          ioat3_dma_probe+0x268/0x410 [ioatdma]
          ioat_pci_probe+0x122/0x1b0 [ioatdma]
          local_pci_probe+0x45/0xa0
          pci_device_probe+0xd9/0x130
          driver_probe_device+0x171/0x490
          __driver_attach+0x93/0xa0
          bus_for_each_dev+0x6b/0xb0
          driver_attach+0x1e/0x20
          bus_add_driver+0x1f8/0x2b0
          driver_register+0x81/0x110
          __pci_register_driver+0x60/0x70
          ioat_init_module+0x89/0x1000 [ioatdma]
          do_one_initcall+0xe2/0x250
          load_module+0x2313/0x2a00
          SyS_init_module+0xd9/0x130
          system_call_fastpath+0x1a/0x1f
        ---[ end trace 990c591681d27c31 ]---
        Mapped at:
          debug_dma_map_page+0xbe/0x180
          ioat_dma_self_test+0x1ab/0x680 [ioatdma]
          ioat3_dma_self_test+0x12/0x30 [ioatdma]
          ioat_probe+0xf4/0x110 [ioatdma]
          ioat3_dma_probe+0x268/0x410 [ioatdma]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3532e566
    • N
      mm/memory-failure.c: transfer page count from head page to tail page after split thp · a3e0f9e4
      Naoya Horiguchi 提交于
      Memory failures on thp tail pages cause kernel panic like below:
      
         mce: [Hardware Error]: Machine check events logged
         MCE exception done on CPU 7
         BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
         IP: [<ffffffff811b7cd1>] dequeue_hwpoisoned_huge_page+0x131/0x1e0
         PGD bae42067 PUD ba47d067 PMD 0
         Oops: 0000 [#1] SMP
        ...
         CPU: 7 PID: 128 Comm: kworker/7:2 Tainted: G   M       O 3.13.0-rc4-131217-1558-00003-g83b7df08e462 #25
        ...
         Call Trace:
           me_huge_page+0x3e/0x50
           memory_failure+0x4bb/0xc20
           mce_process_work+0x3e/0x70
           process_one_work+0x171/0x420
           worker_thread+0x11b/0x3a0
           ? manage_workers.isra.25+0x2b0/0x2b0
           kthread+0xe4/0x100
           ? kthread_create_on_node+0x190/0x190
           ret_from_fork+0x7c/0xb0
           ? kthread_create_on_node+0x190/0x190
        ...
         RIP   dequeue_hwpoisoned_huge_page+0x131/0x1e0
         CR2: 0000000000000058
      
      The reasoning of this problem is shown below:
       - when we have a memory error on a thp tail page, the memory error
         handler grabs a refcount of the head page to keep the thp under us.
       - Before unmapping the error page from processes, we split the thp,
         where page refcounts of both of head/tail pages don't change.
       - Then we call try_to_unmap() over the error page (which was a tail
         page before). We didn't pin the error page to handle the memory error,
         this error page is freed and removed from LRU list.
       - We never have the error page on LRU list, so the first page state
         check returns "unknown page," then we move to the second check
         with the saved page flag.
       - The saved page flag have PG_tail set, so the second page state check
         returns "hugepage."
       - We call me_huge_page() for freed error page, then we hit the above panic.
      
      The root cause is that we didn't move refcount from the head page to the
      tail page after split thp.  So this patch suggests to do this.
      
      This panic was introduced by commit 524fca1e ("HWPOISON: fix
      misjudgement of page_action() for errors on mlocked pages").  Note that we
      did have the same refcount problem before this commit, but it was just
      ignored because we had only first page state check which returned "unknown
      page." The commit changed the refcount problem from "doesn't work" to
      "kernel panic."
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reviewed-by: NWanpeng Li <liwanp@linux.vnet.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: <stable@vger.kernel.org>	[3.9+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3e0f9e4
    • M
      MAINTAINERS: set up proper record for Xilinx Zynq · c2fd4e38
      Michal Simek 提交于
      Setup correct zynq entry.
       - Add missing cadence_ttc_timer maintainership
       - Add zynq wildcard
       - Add xilinx wildcard
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c2fd4e38
    • M
      mm: remove bogus warning in copy_huge_pmd() · d0319bd5
      Mel Gorman 提交于
      Sasha Levin reported the following warning being triggered
      
        WARNING: CPU: 28 PID: 35287 at mm/huge_memory.c:887 copy_huge_pmd+0x145/ 0x3a0()
        Call Trace:
          copy_huge_pmd+0x145/0x3a0
          copy_page_range+0x3f2/0x560
          dup_mmap+0x2c9/0x3d0
          dup_mm+0xad/0x150
          copy_process+0xa68/0x12e0
          do_fork+0x96/0x270
          SyS_clone+0x16/0x20
          stub_clone+0x69/0x90
      
      This warning was introduced by "mm: numa: Avoid unnecessary disruption
      of NUMA hinting during migration" for paranoia reasons but the warning
      is bogus.  I was thinking of parallel races between NUMA hinting faults
      and forks but this warning would also be triggered by a parallel reclaim
      splitting a THP during a fork.  Remote the bogus warning.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0319bd5
    • V
      memcg: fix memcg_size() calculation · 695c6083
      Vladimir Davydov 提交于
      The mem_cgroup structure contains nr_node_ids pointers to
      mem_cgroup_per_node objects, not the objects themselves.
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Glauber Costa <glommer@openvz.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Balbir Singh <bsingharora@gmail.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      695c6083
    • R
      mm: fix use-after-free in sys_remap_file_pages · 4eb91982
      Rik van Riel 提交于
      remap_file_pages calls mmap_region, which may merge the VMA with other
      existing VMAs, and free "vma".  This can lead to a use-after-free bug.
      Avoid the bug by remembering vm_flags before calling mmap_region, and
      not trying to dereference vma later.
      Signed-off-by: NRik van Riel <riel@redhat.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4eb91982
    • V
      mm: munlock: fix deadlock in __munlock_pagevec() · 3b25df93
      Vlastimil Babka 提交于
      Commit 7225522b ("mm: munlock: batch non-THP page isolation and
      munlock+putback using pagevec" introduced __munlock_pagevec() to speed
      up munlock by holding lru_lock over multiple isolated pages.  Pages that
      fail to be isolated are put_page()d immediately, also within the lock.
      
      This can lead to deadlock when __munlock_pagevec() becomes the holder of
      the last page pin and put_page() leads to __page_cache_release() which
      also locks lru_lock.  The deadlock has been observed by Sasha Levin
      using trinity.
      
      This patch avoids the deadlock by deferring put_page() operations until
      lru_lock is released.  Another pagevec (which is also used by later
      phases of the function is reused to gather the pages for put_page()
      operation.
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b25df93
    • V
      mm: munlock: fix a bug where THP tail page is encountered · c424be1c
      Vlastimil Babka 提交于
      Since commit ff6a6da6 ("mm: accelerate munlock() treatment of THP
      pages") munlock skips tail pages of a munlocked THP page.  However, when
      the head page already has PageMlocked unset, it will not skip the tail
      pages.
      
      Commit 7225522b ("mm: munlock: batch non-THP page isolation and
      munlock+putback using pagevec") has added a PageTransHuge() check which
      contains VM_BUG_ON(PageTail(page)).  Sasha Levin found this triggered
      using trinity, on the first tail page of a THP page without PageMlocked
      flag.
      
      This patch fixes the issue by skipping tail pages also in the case when
      PageMlocked flag is unset.  There is still a possibility of race with
      THP page split between clearing PageMlocked and determining how many
      pages to skip.  The race might result in former tail pages not being
      skipped, which is however no longer a bug, as during the skip the
      PageTail flags are cleared.
      
      However this race also affects correctness of NR_MLOCK accounting, which
      is to be fixed in a separate patch.
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Bob Liu <bob.liu@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c424be1c
    • L
      Merge tag 'gfs2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes · 152b734a
      Linus Torvalds 提交于
      Pull GFS2 fixes from Steven Whitehouse:
       "Here is a set of small fixes for GFS2.  There is a fix to drop
        s_umount which is copied in from the core vfs, two patches relate to a
        hard to hit "use after free" and memory leak.  Two patches related to
        using DIO and buffered I/O on the same file to ensure correct
        operation in relation to glock state changes.  The final patch adds an
        RCU read lock to ensure correct locking on an error path"
      
      * tag 'gfs2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
        GFS2: Fix unsafe dereference in dump_holder()
        GFS2: Wait for async DIO in glock state changes
        GFS2: Fix incorrect invalidation for DIO/buffered I/O
        GFS2: Fix slab memory leak in gfs2_bufdata
        GFS2: Fix use-after-free race when calling gfs2_remove_from_ail
        GFS2: don't hold s_umount over blkdev_put
      152b734a
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · b4796679
      Linus Torvalds 提交于
      Pull s390 fixes from Martin Schwidefsky:
       "Two small bug fixes and a follow-up to the CONFIG_NR_CPUS change.
      
        A kernel compiled with CONFIG_NR_CPUS=256 will waste quite a bit of
        memory for the per-cpu arrays.  Under z/VM the maximum number of CPUs
        is 64, the code now limits the possible cpu mask to 64 if running
        under z/VM"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/pci: obtain function handle in hotplug notifier
        s390/3270: fix allocation of tty3270_screen structure
        s390/smp: improve setup of possible cpu mask
      b4796679
  7. 02 1月, 2014 4 次提交
  8. 01 1月, 2014 8 次提交
  9. 31 12月, 2013 4 次提交
    • R
      ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug · f244d8b6
      Rafael J. Wysocki 提交于
      The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
      during the 3.12 development cycle uncovered a problem with VGA
      switcheroo that on some systems, when the device-specific method
      (ATPX in the radeon case, _DSM in the nouveau case) is used to turn
      off the discrete graphics, the BIOS generates ACPI hotplug events for
      that device and those events cause ACPIPHP to attempt to remove the
      device from the system (they are events for a device that was present
      previously and is not present any more, so that's what should be done
      according to the spec).  Then, the system stops functioning correctly.
      
      Since the hotplug events in question were simply silently ignored
      previously, the least intrusive way to address that problem is to
      make ACPIPHP ignore them again.  For this purpose, introduce a new
      ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
      events for PCI devices whose ACPI companions have that flag set.
      Next, make the radeon and nouveau switcheroo detection code set the
      no_hotplug flag for the discrete graphics' ACPI companion.
      
      Fixes: bbd34fcd (ACPI / hotplug / PCI: Register all devices under the given bridge)
      References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
      References: https://bugzilla.kernel.org/show_bug.cgi?id=64891Reported-and-tested-by: NMike Lothian <mike@fireburn.co.uk>
      Reported-and-tested-by: <madcatx@atlas.cz>
      Reported-and-tested-by: NJoaquín Aramendía <samsagax@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      f244d8b6
    • R
      intel_pstate: Fail initialization if P-state information is missing · 98a947ab
      Rafael J. Wysocki 提交于
      If pstate.current_pstate is 0 after the initial
      intel_pstate_get_cpu_pstates(), this means that we were unable to
      obtain any useful P-state information and there is no reason to
      continue, so free memory and return an error in that case.
      
      This fixes the following divide error occuring in a nested KVM
      guest:
      
      Intel P-state driver initializing.
      Intel pstate controlling: cpu 0
      cpufreq: __cpufreq_add_dev: ->get() failed
      divide error: 0000 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000
      RIP: 0010:[<ffffffff815c551d>]  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
      RSP: 0000:ffff88001ee03e18  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000
      R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000
      R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348
      FS:  0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0
      Stack:
       fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
       ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
       ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
      Call Trace:
       <IRQ>
       [<ffffffff81083e9a>] call_timer_fn+0x8a/0x310
       [<ffffffff81083e15>] ? call_timer_fn+0x5/0x310
       [<ffffffff815c5400>] ? pid_param_set+0x130/0x130
       [<ffffffff81084354>] run_timer_softirq+0x234/0x380
       [<ffffffff8107aee4>] __do_softirq+0x104/0x430
       [<ffffffff8107b5fd>] irq_exit+0xcd/0xe0
       [<ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60
       [<ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80
       <EOI>
       [<ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0
       [<ffffffff81757719>] printk+0x67/0x69
       [<ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0
       [<ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20
       [<ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0
       [<ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210
       [<ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be
       [<ffffffff81761e3e>] ? mutex_unlock+0xe/0x10
       [<ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12
       [<ffffffff8100214a>] do_one_initcall+0xfa/0x1b0
       [<ffffffff8109dbf5>] ? parse_args+0x225/0x3f0
       [<ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287
       [<ffffffff81f638d0>] ? do_early_param+0x88/0x88
       [<ffffffff8174b530>] ? rest_init+0x150/0x150
       [<ffffffff8174b53e>] kernel_init+0xe/0x130
       [<ffffffff8176e27c>] ret_from_fork+0x7c/0xb0
       [<ffffffff8174b530>] ? rest_init+0x150/0x150
      Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
      RIP  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
       RSP <ffff88001ee03e18>
      ---[ end trace f166110ed22cc37a ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Reported-and-tested-by: NKashyap Chamarthy <kchamart@redhat.com>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: All applicable <stable@vger.kernel.org>
      98a947ab
    • L
      Merge tag 'dt-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux · 71ce176e
      Linus Torvalds 提交于
      Pull devicetree fixes from Rob Herring:
       - Fix 2 regressions found on PPC
       - Allow NULL ptr in unflatten_and_copy_device_tree
       - Update my email address
      
      * tag 'dt-fixes-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
        MAINTAINERS: Update Rob Herring's email address
        of/irq: Fix device_node refcount in of_irq_parse_raw()
        of/Kconfig: Spelling s/one/once/
        Revert "of/address: Handle #address-cells > 2 specially"
        of: Fix NULL dereference in unflatten_and_copy()
      71ce176e
    • J
      KVM: x86: Fix APIC map calculation after re-enabling · e66d2ae7
      Jan Kiszka 提交于
      Update arch.apic_base before triggering recalculate_apic_map. Otherwise
      the recalculation will work against the previous state of the APIC and
      will fail to build the correct map when an APIC is hardware-enabled
      again.
      
      This fixes a regression of 1e08ec4a.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      e66d2ae7