Hello there,
The CKI team is planning to shutdown the kernel testing pipelines
including stable kernels during the holidays.
Shutdown timeline:
2019-12-23 16:00 CET: CKI kernel testing pipelines are disabled.
2019-12-30 12:00 CET: CKI kernel testing pipelines back online and testing.
FAQ:
Q: What if a test is running for one of my commits when the pipelines
are disabled?
A: All of the tests that are running when the pipelines are disabled will
be allowed to finish.
Q: What if I commit patches to one of the tested kernel trees after the
pipelines are disabled?
A: The tip of those kernel trees will be tested as soon as the pipelines
are back online.
Q: I have more questions about how this shutdown will affect me.
A: Email us at cki-project(a)redhat.com.
Thank you! Michael Hofmann and the CKI Project Team 🤖
From: Vipul Kumar <vipul_kumar(a)mentor.com>
'commit f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE
flags on Intel Atom SoCs")', causing time drift for Bay trail SoC.
These flags are set for SoCs having cpuid_level 0x15 or more.
Bay trail is having cpuid_level 0xb.
So, unset both flags to make sure the clocksource calibration can
be done.
Signed-off-by: Vipul Kumar <vipul_kumar(a)mentor.com>
---
arch/x86/kernel/tsc_msr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index e0cbe4f2af49..1ca27c28db98 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -112,6 +112,9 @@ unsigned long cpu_khz_from_msr(void)
lapic_timer_period = (freq * 1000) / HZ;
#endif
+ if (boot_cpu_data.cpuid_level < 0x15)
+ return res;
+
/*
* TSC frequency determined by MSR is always considered "known"
* because it is reported by HW.
--
2.20.1
A device mapping is normally always mapped at Stage-2, since there
is very little gain in having it faulted in.
Nonetheless, it is possible to end-up in a situation where the device
mapping has been removed from Stage-2 (userspace munmaped the VFIO
region, and the MMU notifier did its job), but present in a userspace
mapping (userpace has mapped it back at the same address). In such
a situation, the device mapping will be demand-paged as the guest
performs memory accesses.
This requires to be careful when dealing with mapping size, cache
management, and to handle potential execution of a device mapping.
Cc: stable(a)vger.kernel.org
Reported-by: Alexandru Elisei <alexandru.elisei(a)arm.com>
Signed-off-by: Marc Zyngier <maz(a)kernel.org>
---
virt/kvm/arm/mmu.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index a48994af70b8..0b32a904a1bb 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -38,6 +38,11 @@ static unsigned long io_map_base;
#define KVM_S2PTE_FLAG_IS_IOMAP (1UL << 0)
#define KVM_S2_FLAG_LOGGING_ACTIVE (1UL << 1)
+static bool is_iomap(unsigned long flags)
+{
+ return flags & KVM_S2PTE_FLAG_IS_IOMAP;
+}
+
static bool memslot_is_logging(struct kvm_memory_slot *memslot)
{
return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
@@ -1698,6 +1703,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
vma_pagesize = vma_kernel_pagesize(vma);
if (logging_active ||
+ (vma->vm_flags & VM_PFNMAP) ||
!fault_supports_stage2_huge_mapping(memslot, hva, vma_pagesize)) {
force_pte = true;
vma_pagesize = PAGE_SIZE;
@@ -1760,6 +1766,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
writable = false;
}
+ if (exec_fault && is_iomap(flags))
+ return -ENOEXEC;
+
spin_lock(&kvm->mmu_lock);
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
@@ -1781,7 +1790,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (writable)
kvm_set_pfn_dirty(pfn);
- if (fault_status != FSC_PERM)
+ if (fault_status != FSC_PERM && !is_iomap(flags))
clean_dcache_guest_page(pfn, vma_pagesize);
if (exec_fault)
@@ -1948,9 +1957,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
if (kvm_is_error_hva(hva) || (write_fault && !writable)) {
if (is_iabt) {
/* Prefetch Abort on I/O address */
- kvm_inject_pabt(vcpu, kvm_vcpu_get_hfar(vcpu));
- ret = 1;
- goto out_unlock;
+ ret = -ENOEXEC;
+ goto out;
}
/*
@@ -1992,6 +2000,11 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
ret = user_mem_abort(vcpu, fault_ipa, memslot, hva, fault_status);
if (ret == 0)
ret = 1;
+out:
+ if (ret == -ENOEXEC) {
+ kvm_inject_pabt(vcpu, kvm_vcpu_get_hfar(vcpu));
+ ret = 1;
+ }
out_unlock:
srcu_read_unlock(&vcpu->kvm->srcu, idx);
return ret;
--
2.20.1
At least on the HP Envy x360 15-cp0xxx model the WMI interface
for HPWMI_FEATURE2_QUERY requires an outsize of at least 128 bytes,
otherwise it fails with an error code 5 (HPWMI_RET_INVALID_PARAMETERS):
Dec 06 00:59:38 kernel: hp_wmi: query 0xd returned error 0x5
We do not care about the contents of the buffer, we just want to know
if the HPWMI_FEATURE2_QUERY command is supported.
This commits bumps the buffer size, fixing the error.
Cc: stable(a)vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/platform/x86/hp-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 9579a706fc08..a881b709af25 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -300,7 +300,7 @@ static int __init hp_wmi_bios_2008_later(void)
static int __init hp_wmi_bios_2009_later(void)
{
- int state = 0;
+ u8 state[128];
int ret = hp_wmi_perform_query(HPWMI_FEATURE2_QUERY, HPWMI_READ, &state,
sizeof(state), sizeof(state));
if (!ret)
--
2.23.0
On 16.12.19 16:06, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: f7f99100d8d9 ("mm: stop zeroing memory during allocation in vmemmap").
>
> The bot has tested the following trees: v5.4.2, v5.3.15, v4.19.88.
>
> v5.4.2: Build OK!
> v5.3.15: Build OK!
> v4.19.88: Failed to apply! Possible dependencies:
> 907ec5fca3dc ("mm: zero remaining unavailable struct pages")
> ec393a0f014e ("mm: return zero_resv_unavail optimization")
Yes, these two look like the right dependencies and should be picked as
well.
--
Thanks,
David / dhildenb