linux-kernel - KVM: BUG during OOM on host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Jun 2017 14:21:15 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     kvm <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krcmar <rkrcmar@...hat.com>
Cc:     Wanpeng Li <wanpeng.li@...mail.com>
Subject: KVM: BUG during OOM on host

Hi all,

When the OOM-Killer kills the guest which is running memory hog
processes, there is tons of splatting as below: the page count reaches
0 before drop_spte. The splatting will disappear when disables THP on
host.

------------[ cut here ]------------
 WARNING: CPU: 4 PID: 28317 at arch/x86/kvm/mmu.c:682
mmu_spte_clear_track_bits+0x84/0x120 [kvm]
 CPU: 4 PID: 28317 Comm: kworker/4:2 Tainted: G    B D W       4.12.0-rc7+ #29
 Workqueue: events mmput_async_fn
 task: ffff9465283c3280 task.stack: ffffacb0083b4000
 RIP: 0010:mmu_spte_clear_track_bits+0x84/0x120 [kvm]
 Call Trace:
  drop_spte+0x1a/0xb0 [kvm]
  mmu_page_zap_pte+0xcc/0xe0 [kvm]
  kvm_mmu_prepare_zap_page+0x81/0x4c0 [kvm]
  ? _raw_spin_lock+0x65/0x70
  kvm_mmu_invalidate_zap_all_pages+0x171/0x240 [kvm]
  kvm_arch_flush_shadow_all+0xe/0x10 [kvm]
  kvm_mmu_notifier_release+0x54/0x90 [kvm]
  ? kvm_mmu_notifier_release+0x5/0x90 [kvm]
  __mmu_notifier_release+0x65/0x100
  exit_mmap+0x168/0x180
  ? __khugepaged_exit+0xdb/0x140
  ? rcu_read_lock_sched_held+0x79/0x80
  ? kmem_cache_free+0x2f2/0x350
  mmput_async_fn+0x4c/0x140
  process_one_work+0x203/0x690
  worker_thread+0x4e/0x3b0
  kthread+0x117/0x150

Regards,
Wanpeng Li