1. 05 9月, 2019 2 次提交
  2. 04 9月, 2019 6 次提交
  3. 29 8月, 2019 4 次提交
    • N
      vmw_balloon: Fix offline page marking with compaction · 468e0ffa
      Nadav Amit 提交于
      The compaction code already marks pages as offline when it enqueues
      pages in the ballooned page list, and removes the mapping when the pages
      are removed from the list. VMware balloon also updates the flags,
      instead of letting the balloon-compaction logic handle it, which causes
      the assertion VM_BUG_ON_PAGE(!PageOffline(page)) to fire, when
      __ClearPageOffline is called the second time. This causes the following
      crash.
      
      [  487.104520] kernel BUG at include/linux/page-flags.h:749!
      [  487.106364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
      [  487.107681] CPU: 7 PID: 1106 Comm: kworker/7:3 Not tainted 5.3.0-rc5balloon #227
      [  487.109196] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
      [  487.111452] Workqueue: events_freezable vmballoon_work [vmw_balloon]
      [  487.112779] RIP: 0010:vmballoon_release_page_list+0xaa/0x100 [vmw_balloon]
      [  487.114200] Code: fe 48 c1 e7 06 4c 01 c7 8b 47 30 41 89 c1 41 81 e1 00 01 00 f0 41 81 f9 00 00 00 f0 74 d3 48 c7 c6 08 a1 a1 c0 e8 06 0d e7 ea <0f> 0b 44 89 f6 4c 89 c7 e8 49 9c e9 ea 49 8d 75 08 49 8b 45 08 4d
      [  487.118033] RSP: 0018:ffffb82f012bbc98 EFLAGS: 00010246
      [  487.119135] RAX: 0000000000000037 RBX: 0000000000000001 RCX: 0000000000000006
      [  487.120601] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9a85b6bd7620
      [  487.122071] RBP: ffffb82f012bbcc0 R08: 0000000000000001 R09: 0000000000000000
      [  487.123536] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb82f012bbd00
      [  487.125002] R13: ffffe97f4598d9c0 R14: 0000000000000000 R15: ffffb82f012bbd34
      [  487.126463] FS:  0000000000000000(0000) GS:ffff9a85b6bc0000(0000) knlGS:0000000000000000
      [  487.128110] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  487.129316] CR2: 00007ffe6e413ea0 CR3: 0000000230b18001 CR4: 00000000003606e0
      [  487.130812] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  487.132283] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  487.133749] Call Trace:
      [  487.134333]  vmballoon_deflate+0x22c/0x390 [vmw_balloon]
      [  487.135468]  vmballoon_work+0x6e7/0x913 [vmw_balloon]
      [  487.136711]  ? process_one_work+0x21a/0x5e0
      [  487.138581]  process_one_work+0x298/0x5e0
      [  487.139926]  ? vmballoon_migratepage+0x310/0x310 [vmw_balloon]
      [  487.141610]  ? process_one_work+0x298/0x5e0
      [  487.143053]  worker_thread+0x41/0x400
      [  487.144389]  kthread+0x12b/0x150
      [  487.145582]  ? process_one_work+0x5e0/0x5e0
      [  487.146937]  ? kthread_create_on_node+0x60/0x60
      [  487.148637]  ret_from_fork+0x3a/0x50
      
      Fix it by updating the PageOffline indication only when a 2MB page is
      enqueued and dequeued. The 4KB pages will be handled correctly by the
      balloon compaction logic.
      
      Fixes: 83a8afa7 ("vmw_balloon: Compaction support")
      Cc: David Hildenbrand <david@redhat.com>
      Reported-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Link: https://lore.kernel.org/r/20190820160121.452-1-namit@vmware.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      468e0ffa
    • N
      VMCI: Release resource if the work is already queued · ba03a9bb
      Nadav Amit 提交于
      Francois reported that VMware balloon gets stuck after a balloon reset,
      when the VMCI doorbell is removed. A similar error can occur when the
      balloon driver is removed with the following splat:
      
      [ 1088.622000] INFO: task modprobe:3565 blocked for more than 120 seconds.
      [ 1088.622035]       Tainted: G        W         5.2.0 #4
      [ 1088.622087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 1088.622205] modprobe        D    0  3565   1450 0x00000000
      [ 1088.622210] Call Trace:
      [ 1088.622246]  __schedule+0x2a8/0x690
      [ 1088.622248]  schedule+0x2d/0x90
      [ 1088.622250]  schedule_timeout+0x1d3/0x2f0
      [ 1088.622252]  wait_for_completion+0xba/0x140
      [ 1088.622320]  ? wake_up_q+0x80/0x80
      [ 1088.622370]  vmci_resource_remove+0xb9/0xc0 [vmw_vmci]
      [ 1088.622373]  vmci_doorbell_destroy+0x9e/0xd0 [vmw_vmci]
      [ 1088.622379]  vmballoon_vmci_cleanup+0x6e/0xf0 [vmw_balloon]
      [ 1088.622381]  vmballoon_exit+0x18/0xcc8 [vmw_balloon]
      [ 1088.622394]  __x64_sys_delete_module+0x146/0x280
      [ 1088.622408]  do_syscall_64+0x5a/0x130
      [ 1088.622410]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 1088.622415] RIP: 0033:0x7f54f62791b7
      [ 1088.622421] Code: Bad RIP value.
      [ 1088.622421] RSP: 002b:00007fff2a949008 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [ 1088.622426] RAX: ffffffffffffffda RBX: 000055dff8b55d00 RCX: 00007f54f62791b7
      [ 1088.622426] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055dff8b55d68
      [ 1088.622427] RBP: 000055dff8b55d00 R08: 00007fff2a947fb1 R09: 0000000000000000
      [ 1088.622427] R10: 00007f54f62f5cc0 R11: 0000000000000206 R12: 000055dff8b55d68
      [ 1088.622428] R13: 0000000000000001 R14: 000055dff8b55d68 R15: 00007fff2a94a3f0
      
      The cause for the bug is that when the "delayed" doorbell is invoked, it
      takes a reference on the doorbell entry and schedules work that is
      supposed to run the appropriate code and drop the doorbell entry
      reference. The code ignores the fact that if the work is already queued,
      it will not be scheduled to run one more time. As a result one of the
      references would not be dropped. When the code waits for the reference
      to get to zero, during balloon reset or module removal, it gets stuck.
      
      Fix it. Drop the reference if schedule_work() indicates that the work is
      already queued.
      
      Note that this bug got more apparent (or apparent at all) due to
      commit ce664331 ("vmw_balloon: VMCI_DOORBELL_SET does not check status").
      
      Fixes: 83e2ec76 ("VMCI: doorbell implementation.")
      Reported-by: NFrancois Rigault <rigault.francois@gmail.com>
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Cc: Adit Ranadive <aditr@vmware.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Vishnu DASA <vdasa@vmware.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Reviewed-by: NVishnu Dasa <vdasa@vmware.com>
      Link: https://lore.kernel.org/r/20190820202638.49003-1-namit@vmware.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba03a9bb
    • R
      lkdtm/bugs: fix build error in lkdtm_EXHAUST_STACK · b9bc7b8b
      Raul E Rangel 提交于
      lkdtm/bugs.c:94:2: error: format '%d' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Werror=format=]
        pr_info("Calling function with %d frame size to depth %d ...\n",
        ^
      THREAD_SIZE is defined as a unsigned long, cast CONFIG_FRAME_WARN to
      unsigned long as well.
      
      Fixes: 24cccab4 ("lkdtm/bugs: Adjust recursion test to avoid elision")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NRaul E Rangel <rrangel@chromium.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20190827173619.170065-1-rrangel@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9bc7b8b
    • T
      mei: me: add Tiger Lake point LP device ID · 587f1740
      Tomas Winkler 提交于
      Add Tiger Lake Point device ID for TGP LP.
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20190819103210.32748-1-tomas.winkler@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      587f1740
  4. 23 8月, 2019 5 次提交
  5. 20 8月, 2019 1 次提交
    • K
      lkdtm: Split WARNING into separate tests · 1ee170ea
      Kees Cook 提交于
      There are three paths through the kernel code exception logging:
      
      - BUG (no configurable printk message)
      - WARN_ON (no configurable printk message)
      - WARN (configurable printk message)
      
      LKDTM was not testing WARN_ON(). This is needed to evaluate the placement
      of the "cut here" line, which needs special handling in each of the
      three exceptions (and between architectures that implement instruction
      exceptions to implement the code exceptions).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      1ee170ea
  6. 16 8月, 2019 3 次提交
  7. 15 8月, 2019 7 次提交
  8. 13 8月, 2019 1 次提交
  9. 12 8月, 2019 6 次提交
  10. 06 8月, 2019 1 次提交
  11. 31 7月, 2019 1 次提交
  12. 29 7月, 2019 3 次提交