* FAILED: patch "[PATCH] KVM: s390: Fix guest migration for huge guests resulting in" failed to apply to 4.4-stable tree
@ 2017-03-15 7:56 gregkh
2017-03-16 12:53 ` [PATCH] Backport KVM: s390: Fix guest migration for huge guests resulting in panic Janosch Frank
0 siblings, 1 reply; 3+ messages in thread
From: gregkh @ 2017-03-15 7:56 UTC (permalink / raw)
To: frankja, borntraeger, schwidefsky, stable; +Cc: stable
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 2e4d88009f57057df7672fa69a32b5224af54d37 Mon Sep 17 00:00:00 2001
From: Janosch Frank <frankja@linux.vnet.ibm.com>
Date: Thu, 2 Mar 2017 15:23:42 +0100
Subject: [PATCH] KVM: s390: Fix guest migration for huge guests resulting in
panic
While we can technically not run huge page guests right now, we can
setup a guest with huge pages. Trying to migrate it will trigger a
VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
will happily try to work on non-existing page table entries.
With this patch, we always return "dirty" if we encounter a large page
when migrating. This at least fixes the immediate problem until we
have proper handling for both kind of pages.
Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
Cc: <stable@vger.kernel.org> # 3.16+
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index b48dc5f1900b..463e5ef02304 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -608,12 +608,29 @@ void ptep_zap_key(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
bool test_and_clear_guest_dirty(struct mm_struct *mm, unsigned long addr)
{
spinlock_t *ptl;
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
pgste_t pgste;
pte_t *ptep;
pte_t pte;
bool dirty;
- ptep = get_locked_pte(mm, addr, &ptl);
+ pgd = pgd_offset(mm, addr);
+ pud = pud_alloc(mm, pgd, addr);
+ if (!pud)
+ return false;
+ pmd = pmd_alloc(mm, pud, addr);
+ if (!pmd)
+ return false;
+ /* We can't run guests backed by huge pages, but userspace can
+ * still set them up and then try to migrate them without any
+ * migration support.
+ */
+ if (pmd_large(*pmd))
+ return true;
+
+ ptep = pte_alloc_map_lock(mm, pmd, addr, &ptl);
if (unlikely(!ptep))
return false;
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH] Backport KVM: s390: Fix guest migration for huge guests resulting in panic
2017-03-15 7:56 FAILED: patch "[PATCH] KVM: s390: Fix guest migration for huge guests resulting in" failed to apply to 4.4-stable tree gregkh
@ 2017-03-16 12:53 ` Janosch Frank
2017-03-16 12:53 ` [PATCH] " Janosch Frank
0 siblings, 1 reply; 3+ messages in thread
From: Janosch Frank @ 2017-03-16 12:53 UTC (permalink / raw)
To: gregkh; +Cc: stable, borntraeger, schwidefsky, frankja
Dear Greg,
Here's the backport for the KVM migration fix that failed to apply on
4.4. It is applicable to 3.16 - 4.4.
Cheers,
Janosch
Janosch Frank (1):
KVM: s390: Fix guest migration for huge guests resulting in panic
arch/s390/mm/pgtable.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] KVM: s390: Fix guest migration for huge guests resulting in panic
2017-03-16 12:53 ` [PATCH] Backport KVM: s390: Fix guest migration for huge guests resulting in panic Janosch Frank
@ 2017-03-16 12:53 ` Janosch Frank
0 siblings, 0 replies; 3+ messages in thread
From: Janosch Frank @ 2017-03-16 12:53 UTC (permalink / raw)
To: gregkh; +Cc: stable, borntraeger, schwidefsky, frankja
While we can technically not run huge page guests right now, we can
setup a guest with huge pages. Trying to migrate it will trigger a
VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
will happily try to work on non-existing page table entries.
With this patch, we always return "dirty" if we encounter a large page
when migrating. This at least fixes the immediate problem until we
have proper handling for both kind of pages.
Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
Upstream-ID: 2e4d88009f57057df7672fa69a32b5224af54d37
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
---
arch/s390/mm/pgtable.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 80fcdfb..6802530 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -1411,11 +1411,28 @@ EXPORT_SYMBOL_GPL(s390_enable_skey);
*/
bool gmap_test_and_clear_dirty(unsigned long address, struct gmap *gmap)
{
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
pte_t *pte;
spinlock_t *ptl;
bool dirty = false;
- pte = get_locked_pte(gmap->mm, address, &ptl);
+ pgd = pgd_offset(gmap->mm, address);
+ pud = pud_alloc(gmap->mm, pgd, address);
+ if (!pud)
+ return false;
+ pmd = pmd_alloc(gmap->mm, pud, address);
+ if (!pmd)
+ return false;
+ /* We can't run guests backed by huge pages, but userspace can
+ * still set them up and then try to migrate them without any
+ * migration support.
+ */
+ if (pmd_large(*pmd))
+ return true;
+
+ pte = pte_alloc_map_lock(gmap->mm, pmd, address, &ptl);
if (unlikely(!pte))
return false;
--
2.7.4
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-16 12:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-15 7:56 FAILED: patch "[PATCH] KVM: s390: Fix guest migration for huge guests resulting in" failed to apply to 4.4-stable tree gregkh
2017-03-16 12:53 ` [PATCH] Backport KVM: s390: Fix guest migration for huge guests resulting in panic Janosch Frank
2017-03-16 12:53 ` [PATCH] " Janosch Frank
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.