From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@bugzilla.kernel.org
Subject: [Bug 196717] CPU: 0 PID: 5405 at arch/x86/kvm/mmu.c:717
mmu_spte_clear_track_bits+0xe7/0x100
Date: Wed, 23 Aug 2017 01:39:21 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
To: kvm@kernel.org
Return-path:
Received: from mail.wl.linuxfoundation.org ([198.145.29.98]:48380 "EHLO
mail.wl.linuxfoundation.org" rhost-flags-OK-OK-OK-OK)
by vger.kernel.org with ESMTP id S1753148AbdHWBkV (ORCPT
); Tue, 22 Aug 2017 21:40:21 -0400
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B0B38288E8
for ; Wed, 23 Aug 2017 01:40:20 +0000 (UTC)
In-Reply-To:
Sender: kvm-owner@vger.kernel.org
List-ID:
https://bugzilla.kernel.org/show_bug.cgi?id=196717
--- Comment #6 from Jeff Cook (jeff@jeffcook.io) ---
After a little bit of digging, it seems that the patchset "KVM: nVMX: nested
EPT improvements and A/D bits, RDRAND and RDSEED exits" (described at
https://lkml.org/lkml/2017/3/8/586) is the likely origin point of this error.
This was first merged in 4.12, which is when I first started encountering this
error.
Something about the "accessed_dirty" flag causes the warning on line 717 of
arch/x86/kvm/mmu.c to trigger:
WARN_ON(!kvm_is_reserved_pfn(pfn) && !page_count(pfn_to_page(pfn)));
and then later, the system refuses to allocate the memory requested because
when checking if the page is safe to use, it encounters a dirty flag:
[94449.442437] BUG: Bad page state in process makepkg pfn:2a401a
[94449.442447] flags: 0x17fff0000000014(referenced|dirty)
[...]
[94449.442462] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[94449.442465] bad because of flags: 0x14(referenced|dirty)
[...]
[94449.442615] Call Trace:
[...]
[94449.442907] bad_page+0xce/0x130
[94449.442912] check_new_page_bad+0x67/0x80
[94449.442916] get_page_from_freelist+0x979/0xad0
[...]
As the diff for kvm/mmu.c between 4.11 and 4.12 is quite small, it seems likely
that this change is the origin point of the bug.
Perhaps something in along the way has not been updated to account for this
flag? I would revert to test, but it appears that this patchset has grown
several dependents. If someone wants to suggest a series of commits to revert
or a patch to test, I am happy to try that.
--
You are receiving this mail because:
You are watching the assignee of the bug.