- Linux-stable-mirror - lists.linaro.org

Repeating "unregister_netdevice: waiting for lo to become free" caused by upstream 76da0704507bb ("ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER")

by Rafał Miłecki

Hi, I've just updated my kernel 4.4.x and noticed a regression. Bisecting pointed me to the commit 2417da3f4d6bc ("ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER") [0] which is backport of upstream 76da0704507bb. That backported commit has appeared in a 4.4.103. I use OpenWrt/LEDE [1] distribution and LXC [2] 1.1.5. After stopping a container I start getting these messages: [ 229.419188] unregister_netdevice: waiting for lo to become free. Usage count = 1 [ 239.660408] unregister_netdevice: waiting for lo to become free. Usage count = 1 [ 249.839189] unregister_netdevice: waiting for lo to become free. Usage count = 1 (...) Trying to start LXC nevertheless results in lxc-start command hang around network configuration. Trying to query LXC state afterwards results in a lxc-info command hang too. I tried Googling for this issue and found similar reports: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1729637 https://github.com/fnproject/fn/issues/686 https://lime-technology.com/forums/topic/66863-kernelunregister_netdevice-w… all of them related to the Docker, which is probably a similar use case to the LXC. I couldn't find any reference to commit 76da0704507bb that could suggest fixing the problem I'm seeing. Does anyone have an idea what is the issue I'm seeing about? Or even better, how to fix it? Can I provide any additional info that would help? [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/com… [1] https://openwrt.org/ [2] https://linuxcontainers.org/ -- Rafał

7 years, 2 months

2
4
0 0

[PATCH 1/1] xhci: Fix use-after-free in xhci_free_virt_device

by Mathias Nyman

KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e where xhci_free_virt_device() sets slot id to 0 if udev exists: if (dev->udev && dev->udev->slot_id) dev->udev->slot_id = 0; dev->udev will be true even if udev is freed because dev->udev is not set to NULL. set dev->udev pointer to NULL in xhci_free_dev() The original patch went to stable so this fix needs to be applied there as well. Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot") Cc: <stable(a)vger.kernel.org> Reported-by: Guenter Roeck <linux(a)roeck-us.net> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 9b27798..711da33 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3621,6 +3621,7 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev) del_timer_sync(&virt_dev->eps[i].stop_cmd_timer); } xhci_debugfs_remove_slot(xhci, udev->slot_id); + virt_dev->udev = NULL; ret = xhci_disable_slot(xhci, udev->slot_id); if (ret) xhci_free_virt_device(xhci, udev->slot_id); -- 2.7.4

7 years, 2 months

1
0
0 0

+ ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ipc/shm: fix shmat() nil address after round-down when remapping has been added to the -mm tree. Its filename is ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ipc-shm-fix-shmat-nil-address-afte… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ipc-shm-fix-shmat-nil-address-afte… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Davidlohr Bueso <dave(a)stgolabs.net> Subject: ipc/shm: fix shmat() nil address after round-down when remapping shmat()'s SHM_REMAP option forbids passing a nil address for; this is in fact the very first thing we check for. Andrea reported that for SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check, but we need to check again if the address was rounded down to nil. As of this patch, such cases will return -EINVAL. Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805 Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Reported-by: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/shm.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff -puN ipc/shm.c~ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping ipc/shm.c --- a/ipc/shm.c~ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping +++ a/ipc/shm.c @@ -1363,9 +1363,17 @@ long do_shmat(int shmid, char __user *sh if (addr) { if (addr & (shmlba - 1)) { - if (shmflg & SHM_RND) + if (shmflg & SHM_RND) { addr &= ~(shmlba - 1); /* round down */ - else + + /* + * Ensure that the round-down is non-nil + * when remapping. This can happen for + * cases when addr < shmlba. + */ + if (!addr && (shmflg & SHM_REMAP)) + goto out; + } else #ifndef __ARCH_FORCE_SHMLBA if (addr & ~PAGE_MASK) #endif _ Patches currently in -mm which might be from dave(a)stgolabs.net are ipc-sem-mitigate-semnum-index-against-spectre-v1.patch revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch

7 years, 2 months

1
0
0 0

+ revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: Revert "ipc/shm: Fix shmat mmap nil-page protection" has been added to the -mm tree. Its filename is revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-ipc-shm-fix-shmat-mmap-nil-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-ipc-shm-fix-shmat-mmap-nil-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Davidlohr Bueso <dave(a)stgolabs.net> Subject: Revert "ipc/shm: Fix shmat mmap nil-page protection" Patch series "ipc/shm: shmat() fixes around nil-page". These patches fix two issues reported[1] a while back by Joe and Andrea around how shmat(2) behaves with nil-page. The first reverts a commit that it was incorrectly thought that mapping nil-page (address=0) was a no no with MAP_FIXED. This is not the case, with the exception of SHM_REMAP; which is address in the second patch. I chose two patches because it is easier to backport and it explicitly reverts bogus behaviour. Both patches ought to be in -stable and ltp testcases need updated (the added testcase around the cve can be modified to just test for SHM_RND|SHM_REMAP). [1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805 This patch (of 2): 95e91b831f87 (ipc/shm: Fix shmat mmap nil-page protection) worked on the idea that we should not be mapping as root addr=0 and MAP_FIXED. However, it was reported that this scenario is in fact valid, thus making the patch both bogus and breaks userspace as well. For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem initialization[1]. [1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/… Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de> Reported-by: Joe Lawrence <joe.lawrence(a)redhat.com> Reported-by: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/shm.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff -puN ipc/shm.c~revert-ipc-shm-fix-shmat-mmap-nil-page-protection ipc/shm.c --- a/ipc/shm.c~revert-ipc-shm-fix-shmat-mmap-nil-page-protection +++ a/ipc/shm.c @@ -1363,13 +1363,8 @@ long do_shmat(int shmid, char __user *sh if (addr) { if (addr & (shmlba - 1)) { - /* - * Round down to the nearest multiple of shmlba. - * For sane do_mmap_pgoff() parameters, avoid - * round downs that trigger nil-page and MAP_FIXED. - */ - if ((shmflg & SHM_RND) && addr >= shmlba) - addr &= ~(shmlba - 1); + if (shmflg & SHM_RND) + addr &= ~(shmlba - 1); /* round down */ else #ifndef __ARCH_FORCE_SHMLBA if (addr & ~PAGE_MASK) _ Patches currently in -mm which might be from dave(a)stgolabs.net are ipc-sem-mitigate-semnum-index-against-spectre-v1.patch revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch

7 years, 2 months

1
0
0 0

[PATCH for-rc v2 0/6] IB/hfi1,rdmavt: Fixes for the 4.17 RC

by Dennis Dalessandro

Hi Jason and Doug, Here are 6 patches that might make the bar for RC. The first patch fixes something that came in pretty recently, I beleive 4.13. The second patch is trivial, but does modify user visible text. Patch 3 looks large but it's mostly comments. It just moves code. Patch 4 is also pretty simple. The last two patches fix memory leaks. If you don't think these pass muster for RC please carry over to for-next. Changes since V1: Correct version tag so it shows up as for-rc in patchworks. --- Michael J. Ruhl (1): IB/hfi1 Use correct type for num_user_context Mike Marciniszyn (2): IB/hfi1: Fix handling of FECN marked multicast packet IB/hfi1: Fix loss of BECN with AHG Sebastian Sanchez (3): IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used IB/{hfi1,rdmavt}: Fix memory leak in hfi1_alloc_devdata() upon failure IB/hfi1: Fix memory leak in exception path in get_irq_affinity() drivers/infiniband/hw/hfi1/affinity.c | 11 +++---- drivers/infiniband/hw/hfi1/driver.c | 19 ++++++++++--- drivers/infiniband/hw/hfi1/hfi.h | 8 +++-- drivers/infiniband/hw/hfi1/init.c | 43 ++++++++++++++++++++-------- drivers/infiniband/hw/hfi1/pcie.c | 3 -- drivers/infiniband/hw/hfi1/platform.c | 1 + drivers/infiniband/hw/hfi1/qsfp.c | 2 + drivers/infiniband/hw/hfi1/ruc.c | 50 ++++++++++++++++++++++++++------- drivers/infiniband/hw/hfi1/ud.c | 6 ++-- 9 files changed, 101 insertions(+), 42 deletions(-) -- -Denny

7 years, 2 months

4
10
0 0

[PATCH 0/1] KVM: s390: one more backport for 4.4

by Christian Borntraeger

Greg, this is a backport of a patch that is needed to make "KVM: s390: wire up bpb feature" useful in 4.4. Without that the bpb feature is available but the guest does not know that it can be used. Alexander Yarygin (1): KVM: s390: Enable all facility bits that are known good for passthrough arch/s390/kvm/kvm-s390.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.14.2

7 years, 2 months

3
3
0 0

[PATCH 0/2] fixes for v4.4

by Jarkko Sakkinen

Decided to add Enric's commit because it is also a bug fix instead of modifying Chris commit. Chris Chiu (1): tpm: self test failure should not cause suspend to fail Enric Balletbo i Serra (1): tpm: do not suspend/resume if power stays on drivers/char/tpm/tpm-interface.c | 7 +++++++ drivers/char/tpm/tpm.h | 1 + drivers/char/tpm/tpm_of.c | 3 +++ 3 files changed, 11 insertions(+) -- 2.17.0

7 years, 2 months

2
3
0 0

[PATCH 4.9] arm/arm64: KVM: Add PSCI version selection API

by Marc Zyngier

commit 85bd0ba1ff9875798fad94218b627ea9f768f3c3 upstream. Although we've implemented PSCI 0.1, 0.2 and 1.0, we expose either 0.1 or 1.0 to a guest, defaulting to the latest version of the PSCI implementation that is compatible with the requested version. This is no different from doing a firmware upgrade on KVM. But in order to give a chance to hypothetical badly implemented guests that would have a fit by discovering something other than PSCI 0.2, let's provide a new API that allows userspace to pick one particular version of the API. This is implemented as a new class of "firmware" registers, where we expose the PSCI version. This allows the PSCI version to be save/restored as part of a guest migration, and also set to any supported version if the guest requires it. Cc: stable(a)vger.kernel.org #4.16 Reviewed-by: Christoffer Dall <cdall(a)kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> --- Documentation/virtual/kvm/api.txt | 9 ++++- Documentation/virtual/kvm/arm/psci.txt | 30 +++++++++++++++++ arch/arm/include/asm/kvm_host.h | 3 ++ arch/arm/include/uapi/asm/kvm.h | 6 ++++ arch/arm/kvm/guest.c | 13 ++++++++ arch/arm/kvm/psci.c | 60 ++++++++++++++++++++++++++++++++++ arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/include/uapi/asm/kvm.h | 6 ++++ arch/arm64/kvm/guest.c | 14 +++++++- include/kvm/arm_psci.h | 16 +++++++-- 10 files changed, 156 insertions(+), 4 deletions(-) create mode 100644 Documentation/virtual/kvm/arm/psci.txt diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 1f5eab4ef88f..e46c14fac9da 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2118,6 +2118,9 @@ ARM 32-bit VFP control registers have the following id bit patterns: ARM 64-bit FP registers have the following id bit patterns: 0x4030 0000 0012 0 <regno:12> +ARM firmware pseudo-registers have the following bit pattern: + 0x4030 0000 0014 <regno:16> + arm64 registers are mapped using the lower 32 bits. The upper 16 of that is the register group type, or coprocessor number: @@ -2134,6 +2137,9 @@ arm64 CCSIDR registers are demultiplexed by CSSELR value: arm64 system registers have the following id bit patterns: 0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3> +arm64 firmware pseudo-registers have the following bit pattern: + 0x6030 0000 0014 <regno:16> + MIPS registers are mapped using the lower 32 bits. The upper 16 of that is the register group type: @@ -2656,7 +2662,8 @@ Possible features: and execute guest code when KVM_RUN is called. - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode. Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only). - - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU. + - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 (or a future revision + backward compatible with v0.2) for the CPU. Depends on KVM_CAP_ARM_PSCI_0_2. - KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU. Depends on KVM_CAP_ARM_PMU_V3. diff --git a/Documentation/virtual/kvm/arm/psci.txt b/Documentation/virtual/kvm/arm/psci.txt new file mode 100644 index 000000000000..aafdab887b04 --- /dev/null +++ b/Documentation/virtual/kvm/arm/psci.txt @@ -0,0 +1,30 @@ +KVM implements the PSCI (Power State Coordination Interface) +specification in order to provide services such as CPU on/off, reset +and power-off to the guest. + +The PSCI specification is regularly updated to provide new features, +and KVM implements these updates if they make sense from a virtualization +point of view. + +This means that a guest booted on two different versions of KVM can +observe two different "firmware" revisions. This could cause issues if +a given guest is tied to a particular PSCI revision (unlikely), or if +a migration causes a different PSCI version to be exposed out of the +blue to an unsuspecting guest. + +In order to remedy this situation, KVM exposes a set of "firmware +pseudo-registers" that can be manipulated using the GET/SET_ONE_REG +interface. These registers can be saved/restored by userspace, and set +to a convenient value if required. + +The following register is defined: + +* KVM_REG_ARM_PSCI_VERSION: + + - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set + (and thus has already been initialized) + - Returns the current PSCI version on GET_ONE_REG (defaulting to the + highest PSCI version implemented by KVM and compatible with v0.2) + - Allows any PSCI version implemented by KVM and compatible with + v0.2 to be set with SET_ONE_REG + - Affects the whole VM (even if the register view is per-vcpu) diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index 9fe1043e72d2..f4dab20ac9f3 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -78,6 +78,9 @@ struct kvm_arch { /* Interrupt controller */ struct vgic_dist vgic; int max_vcpus; + + /* Mandated version of PSCI */ + u32 psci_version; }; #define KVM_NR_MEM_OBJS 40 diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h index b38c10c73579..0b8cf31d8416 100644 --- a/arch/arm/include/uapi/asm/kvm.h +++ b/arch/arm/include/uapi/asm/kvm.h @@ -173,6 +173,12 @@ struct kvm_arch_memory_slot { #define KVM_REG_ARM_VFP_FPINST 0x1009 #define KVM_REG_ARM_VFP_FPINST2 0x100A +/* KVM-as-firmware specific pseudo-registers */ +#define KVM_REG_ARM_FW (0x0014 << KVM_REG_ARM_COPROC_SHIFT) +#define KVM_REG_ARM_FW_REG(r) (KVM_REG_ARM | KVM_REG_SIZE_U64 | \ + KVM_REG_ARM_FW | ((r) & 0xffff)) +#define KVM_REG_ARM_PSCI_VERSION KVM_REG_ARM_FW_REG(0) + /* Device Control API: ARM VGIC */ #define KVM_DEV_ARM_VGIC_GRP_ADDR 0 #define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1 diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 9aca92074f85..630117d2e8bd 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -22,6 +22,7 @@ #include <linux/module.h> #include <linux/vmalloc.h> #include <linux/fs.h> +#include <kvm/arm_psci.h> #include <asm/cputype.h> #include <asm/uaccess.h> #include <asm/kvm.h> @@ -176,6 +177,7 @@ static unsigned long num_core_regs(void) unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu) { return num_core_regs() + kvm_arm_num_coproc_regs(vcpu) + + kvm_arm_get_fw_num_regs(vcpu) + NUM_TIMER_REGS; } @@ -196,6 +198,11 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) uindices++; } + ret = kvm_arm_copy_fw_reg_indices(vcpu, uindices); + if (ret) + return ret; + uindices += kvm_arm_get_fw_num_regs(vcpu); + ret = copy_timer_indices(vcpu, uindices); if (ret) return ret; @@ -214,6 +221,9 @@ int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE) return get_core_reg(vcpu, reg); + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW) + return kvm_arm_get_fw_reg(vcpu, reg); + if (is_timer_reg(reg->id)) return get_timer_reg(vcpu, reg); @@ -230,6 +240,9 @@ int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE) return set_core_reg(vcpu, reg); + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW) + return kvm_arm_set_fw_reg(vcpu, reg); + if (is_timer_reg(reg->id)) return set_timer_reg(vcpu, reg); diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c index 3d962257c166..8a9c654f4f87 100644 --- a/arch/arm/kvm/psci.c +++ b/arch/arm/kvm/psci.c @@ -18,6 +18,7 @@ #include <linux/arm-smccc.h> #include <linux/preempt.h> #include <linux/kvm_host.h> +#include <linux/uaccess.h> #include <linux/wait.h> #include <asm/cputype.h> @@ -425,3 +426,62 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu) smccc_set_retval(vcpu, val, 0, 0, 0); return 1; } + +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu) +{ + return 1; /* PSCI version */ +} + +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) +{ + if (put_user(KVM_REG_ARM_PSCI_VERSION, uindices)) + return -EFAULT; + + return 0; +} + +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) +{ + if (reg->id == KVM_REG_ARM_PSCI_VERSION) { + void __user *uaddr = (void __user *)(long)reg->addr; + u64 val; + + val = kvm_psci_version(vcpu, vcpu->kvm); + if (copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id))) + return -EFAULT; + + return 0; + } + + return -EINVAL; +} + +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) +{ + if (reg->id == KVM_REG_ARM_PSCI_VERSION) { + void __user *uaddr = (void __user *)(long)reg->addr; + bool wants_02; + u64 val; + + if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id))) + return -EFAULT; + + wants_02 = test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features); + + switch (val) { + case KVM_ARM_PSCI_0_1: + if (wants_02) + return -EINVAL; + vcpu->kvm->arch.psci_version = val; + return 0; + case KVM_ARM_PSCI_0_2: + case KVM_ARM_PSCI_1_0: + if (!wants_02) + return -EINVAL; + vcpu->kvm->arch.psci_version = val; + return 0; + } + } + + return -EINVAL; +} diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 37d56e85036e..0a33ea304e63 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -73,6 +73,9 @@ struct kvm_arch { /* Timer */ struct arch_timer_kvm timer; + + /* Mandated version of PSCI */ + u32 psci_version; }; #define KVM_NR_MEM_OBJS 40 diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 3051f86a9b5f..702de7a2b024 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -195,6 +195,12 @@ struct kvm_arch_memory_slot { #define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2) #define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2) +/* KVM-as-firmware specific pseudo-registers */ +#define KVM_REG_ARM_FW (0x0014 << KVM_REG_ARM_COPROC_SHIFT) +#define KVM_REG_ARM_FW_REG(r) (KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \ + KVM_REG_ARM_FW | ((r) & 0xffff)) +#define KVM_REG_ARM_PSCI_VERSION KVM_REG_ARM_FW_REG(0) + /* Device Control API: ARM VGIC */ #define KVM_DEV_ARM_VGIC_GRP_ADDR 0 #define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 3f9e15722473..d3e0a2ffb383 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -25,6 +25,7 @@ #include <linux/module.h> #include <linux/vmalloc.h> #include <linux/fs.h> +#include <kvm/arm_psci.h> #include <asm/cputype.h> #include <asm/uaccess.h> #include <asm/kvm.h> @@ -205,7 +206,7 @@ static int get_timer_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu) { return num_core_regs() + kvm_arm_num_sys_reg_descs(vcpu) - + NUM_TIMER_REGS; + + kvm_arm_get_fw_num_regs(vcpu) + NUM_TIMER_REGS; } /** @@ -225,6 +226,11 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices) uindices++; } + ret = kvm_arm_copy_fw_reg_indices(vcpu, uindices); + if (ret) + return ret; + uindices += kvm_arm_get_fw_num_regs(vcpu); + ret = copy_timer_indices(vcpu, uindices); if (ret) return ret; @@ -243,6 +249,9 @@ int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE) return get_core_reg(vcpu, reg); + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW) + return kvm_arm_get_fw_reg(vcpu, reg); + if (is_timer_reg(reg->id)) return get_timer_reg(vcpu, reg); @@ -259,6 +268,9 @@ int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE) return set_core_reg(vcpu, reg); + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_FW) + return kvm_arm_set_fw_reg(vcpu, reg); + if (is_timer_reg(reg->id)) return set_timer_reg(vcpu, reg); diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h index e518e4e3dfb5..4b1548129fa2 100644 --- a/include/kvm/arm_psci.h +++ b/include/kvm/arm_psci.h @@ -37,10 +37,15 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm) * Our PSCI implementation stays the same across versions from * v0.2 onward, only adding the few mandatory functions (such * as FEATURES with 1.0) that are required by newer - * revisions. It is thus safe to return the latest. + * revisions. It is thus safe to return the latest, unless + * userspace has instructed us otherwise. */ - if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features)) + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features)) { + if (vcpu->kvm->arch.psci_version) + return vcpu->kvm->arch.psci_version; + return KVM_ARM_PSCI_LATEST; + } return KVM_ARM_PSCI_0_1; } @@ -48,4 +53,11 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm) int kvm_hvc_call_handler(struct kvm_vcpu *vcpu); +struct kvm_one_reg; + +int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu); +int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices); +int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); + #endif /* __KVM_ARM_PSCI_H__ */ -- 2.14.2

7 years, 2 months

2
1
0 0

patch "USB: Accept bulk endpoints with 1024-byte maxpacket" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: Accept bulk endpoints with 1024-byte maxpacket to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From fb5ee84ea72c5f1b6cabdd1c9d6e8648995ca7c6 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Thu, 3 May 2018 11:04:48 -0400 Subject: USB: Accept bulk endpoints with 1024-byte maxpacket Some non-compliant high-speed USB devices have bulk endpoints with a 1024-byte maxpacket size. Although such endpoints don't work with xHCI host controllers, they do work with EHCI controllers. We used to accept these invalid sizes (with a warning), but we no longer do because of an unintentional change introduced by commit aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors"). This patch restores the old behavior, so that people with these peculiar devices can use them without patching their kernels by hand. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Suggested-by: Elvinas <elvinas(a)veikia.lt> Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors") CC: <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/config.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index c821b4b9647e..7b5cb28ffb35 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -191,7 +191,9 @@ static const unsigned short full_speed_maxpacket_maxes[4] = { static const unsigned short high_speed_maxpacket_maxes[4] = { [USB_ENDPOINT_XFER_CONTROL] = 64, [USB_ENDPOINT_XFER_ISOC] = 1024, - [USB_ENDPOINT_XFER_BULK] = 512, + + /* Bulk should be 512, but some devices use 1024: we will warn below */ + [USB_ENDPOINT_XFER_BULK] = 1024, [USB_ENDPOINT_XFER_INT] = 1024, }; static const unsigned short super_speed_maxpacket_maxes[4] = { -- 2.17.0

7 years, 2 months

1
0
0 0

4.14.y needs commit 71546d100422b

by Guenter Roeck

Hi Greg, please pull commit 71546d100422b ("percpu: include linux/sched.h for cond_resched()") into v4.14.y to avoid build errors for microblaze and other architectures. Also, with that many patches queued, can we possibly get more than the usual number of days for testing the next round of stable releases ? Thanks, Guenter

7 years, 2 months

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror