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

staging: atomisp: remove "fun" strncpy warning

by Greg KH

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [for older kernels only, atomisp has been removed from upstream] gcc-8 rightfully warns that this instance of strncpy is just copying from the source, to the same source, for a few bytes. Meaning this call does nothing. As the author of the code obviously meant it to do something, but this code must be working properly, just replace the call to the kernel internal strscpy() which gcc doesn't know about, so the warning goes away. As this driver was deleted from newer kernel versions, none of this really matters but now at least we do not have to worry about a build warning in the stable trees. Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c @@ -2860,9 +2860,7 @@ ia_css_debug_pipe_graph_dump_stage( if (l <= ENABLE_LINE_MAX_LENGTH) { /* It fits on one line, copy string and init */ /* other helper strings with empty string */ - strcpy_s(enable_info, - sizeof(enable_info), - ei); + strscpy(enable_info, ei, sizeof(enable_info)); } else { /* Too big for one line, find last comma */ p = ENABLE_LINE_MAX_LENGTH;

6 years, 10 months

1
0
0 0

Staging: lustre: remove two build warnings

by Greg KH

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [for older kernels only, lustre has been removed from upstream] When someone writes: strncpy(dest, source, sizeof(source)); they really are just doing the same thing as: strcpy(dest, source); but somehow they feel better because they are now using the "safe" version of the string functions. Cargo-cult programming at its finest... gcc-8 rightfully warns you about doing foolish things like this. Now that the stable kernels are all starting to be built using gcc-8, let's get rid of this warning so that we do not have to gaze at this horror. To dropt the warning, just convert the code to using strcpy() so that if someone really wants to audit this code and find all of the obvious problems, it will be easier to do so. Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lnet/lnet/config.c | 3 +-- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) --- a/drivers/staging/lustre/lnet/lnet/config.c +++ b/drivers/staging/lustre/lnet/lnet/config.c @@ -354,8 +354,7 @@ lnet_parse_networks(struct list_head *ni CERROR("Can't allocate net interface name\n"); goto failed; } - strncpy(ni->ni_interfaces[niface], iface, - strlen(iface)); + strcpy(ni->ni_interfaces[niface], iface); niface++; iface = comma; } while (iface); --- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c +++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c @@ -645,7 +645,7 @@ repeat_fid2path: memmove(ptr + strlen(gf->gf_path) + 1, ptr, strlen(ori_gf->gf_path)); - strncpy(ptr, gf->gf_path, strlen(gf->gf_path)); + strcpy(ptr, gf->gf_path); ptr += strlen(gf->gf_path); *ptr = '/'; }

6 years, 10 months

1
0
0 0

[PATCH] KVM: arm/arm64: Fix VMID alloc race by reverting to lock-less

by Christoffer Dall

We recently addressed a VMID generation race by introducing a read/write lock around accesses and updates to the vmid generation values. However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but does so without taking the read lock. As far as I can tell, this can lead to the same kind of race: VM 0, VCPU 0 VM 0, VCPU 1 ------------ ------------ update_vttbr (vmid 254) update_vttbr (vmid 1) // roll over read_lock(kvm_vmid_lock); force_vm_exit() local_irq_disable need_new_vmid_gen == false //because vmid gen matches enter_guest (vmid 254) kvm_arch.vttbr = <PGD>:<VMID 1> read_unlock(kvm_vmid_lock); enter_guest (vmid 1) Which results in running two VCPUs in the same VM with different VMIDs and (even worse) other VCPUs from other VMs could now allocate clashing VMID 254 from the new generation as long as VCPU 0 is not exiting. Attempt to solve this by making sure vttbr is updated before another CPU can observe the updated VMID generation. Cc: stable(a)vger.kernel.org Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race" Reviewed-by: Julien Thierry <julien.thierry(a)arm.com> Signed-off-by: Christoffer Dall <christoffer.dall(a)arm.com> --- virt/kvm/arm/arm.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 23774970c9df..abcd29db2d7a 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -66,7 +66,7 @@ static DEFINE_PER_CPU(struct kvm_vcpu *, kvm_arm_running_vcpu); static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1); static u32 kvm_next_vmid; static unsigned int kvm_vmid_bits __read_mostly; -static DEFINE_RWLOCK(kvm_vmid_lock); +static DEFINE_SPINLOCK(kvm_vmid_lock); static bool vgic_present; @@ -484,7 +484,9 @@ void force_vm_exit(const cpumask_t *mask) */ static bool need_new_vmid_gen(struct kvm *kvm) { - return unlikely(kvm->arch.vmid_gen != atomic64_read(&kvm_vmid_gen)); + u64 current_vmid_gen = atomic64_read(&kvm_vmid_gen); + smp_rmb(); /* Orders read of kvm_vmid_gen and kvm->arch.vmid */ + return unlikely(READ_ONCE(kvm->arch.vmid_gen) != current_vmid_gen); } /** @@ -499,16 +501,11 @@ static void update_vttbr(struct kvm *kvm) { phys_addr_t pgd_phys; u64 vmid, cnp = kvm_cpu_has_cnp() ? VTTBR_CNP_BIT : 0; - bool new_gen; - read_lock(&kvm_vmid_lock); - new_gen = need_new_vmid_gen(kvm); - read_unlock(&kvm_vmid_lock); - - if (!new_gen) + if (!need_new_vmid_gen(kvm)) return; - write_lock(&kvm_vmid_lock); + spin_lock(&kvm_vmid_lock); /* * We need to re-check the vmid_gen here to ensure that if another vcpu @@ -516,7 +513,7 @@ static void update_vttbr(struct kvm *kvm) * use the same vmid. */ if (!need_new_vmid_gen(kvm)) { - write_unlock(&kvm_vmid_lock); + spin_unlock(&kvm_vmid_lock); return; } @@ -539,7 +536,6 @@ static void update_vttbr(struct kvm *kvm) kvm_call_hyp(__kvm_flush_vm_context); } - kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen); kvm->arch.vmid = kvm_next_vmid; kvm_next_vmid++; kvm_next_vmid &= (1 << kvm_vmid_bits) - 1; @@ -550,7 +546,10 @@ static void update_vttbr(struct kvm *kvm) vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK(kvm_vmid_bits); kvm->arch.vttbr = kvm_phys_to_vttbr(pgd_phys) | vmid | cnp; - write_unlock(&kvm_vmid_lock); + smp_wmb(); + WRITE_ONCE(kvm->arch.vmid_gen, atomic64_read(&kvm_vmid_gen)); + + spin_unlock(&kvm_vmid_lock); } static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu) -- 2.18.0

6 years, 10 months

1
0
0 0

[PATCH] KVM: arm/arm64: vgic-v2: Set active_source to 0 when restoring state

by Christoffer Dall

When restoring the active state from userspace, we don't know which CPU was the source for the active state, and this is not architecturally exposed in any of the register state. Set the active_source to 0 in this case. In the future, we can expand on this and exposse the information as additional information to userspace for GICv2 if anyone cares. Cc: stable(a)vger.kernel.org Signed-off-by: Christoffer Dall <christoffer.dall(a)arm.com> --- virt/kvm/arm/vgic/vgic-mmio.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c index f56ff1cf52ec..2b450d49a046 100644 --- a/virt/kvm/arm/vgic/vgic-mmio.c +++ b/virt/kvm/arm/vgic/vgic-mmio.c @@ -338,11 +338,26 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq, vgic_hw_irq_change_active(vcpu, irq, active, !requester_vcpu); } else { u32 model = vcpu->kvm->arch.vgic.vgic_model; + u8 active_source; irq->active = active; + + /* + * The GICv2 architecture indicates that the source CPUID for + * an SGI should be provided during an EOI which implies that + * the active state is stored somewhere, but at the same time + * this state is not architecturally exposed anywhere and we + * have no way of knowing the right source. + * + * This may lead to a VCPU not being able to receive + * additional instances of a particular SGI after migration + * for a GICv2 VM on some GIC implementations. Oh well. + */ + active_source = (requester_vcpu) ? requester_vcpu->vcpu_id : 0; + if (model == KVM_DEV_TYPE_ARM_VGIC_V2 && active && vgic_irq_is_sgi(irq->intid)) - irq->active_source = requester_vcpu->vcpu_id; + irq->active_source = active_source; } if (irq->active) -- 2.18.0

6 years, 10 months

1
0
0 0

Re: [PATCH] USB: serial: option: add HP lt4132

by Johan Hovold

On Sun, Dec 09, 2018 at 03:21:00PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.8, v4.14.87, v4.9.144, v4.4.166, v3.18.128, > > v4.19.8: Build OK! > v4.14.87: Build OK! > v4.9.144: Build OK! > v4.4.166: Build OK! > v3.18.128: Failed to apply! Possible dependencies: > 5d03a2fd2292 ("USB: serial: option: add device ID for HP lt2523 (Novatel E371)") I thought 3.18 was finally EOLed? > How should we proceed with this patch? It applies just fine to mainline, but looks like your scripts found a missing stable patch which would also make it apply to 3.18 without the need to adjust any context. Thanks, Johan

6 years, 10 months

2
2
0 0

Re: [patch] futex: Cure exit race

by Thomas Gleixner

On Mon, 10 Dec 2018, Sasha Levin wrote: > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.8, v4.14.87, v4.9.144, v4.4.166, v3.18.128, > > v4.19.8: Build OK! > v4.14.87: Build OK! > v4.9.144: Build failed! Errors: > kernel/futex.c:1186:28: error: ???uaddr??? undeclared (first use in this function) > > v4.4.166: Build failed! Errors: > kernel/futex.c:1181:28: error: ???uaddr??? undeclared (first use in this function) > > v3.18.128: Build failed! Errors: > kernel/futex.c:1103:28: error: ???uaddr??? undeclared (first use in this function) > > How should we proceed with this patch? I'll look into that once this is sorted... I so love these rotten kernels. Thanks, tglx

6 years, 10 months

2
2
0 0

[PATCH] mfd: cros_ec_dev: Add missing mfd_remove_devices() call in remove

by Enric Balletbo i Serra

The driver adds different MFD child devices via mfd_add_devices() and hence it is required to call mfd_remove_devices() to remove MFD child devices. Fixes: 5e0115581bbc ("cros_ec: Move cros_ec_dev module to drivers/mfd") Cc: stable(a)vger.kernel.org Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- Hi Lee, I saw that you send a mfd-fixes pull request this morning, so sorry in advance for sending this too late. This was broken since the driver moved from platform/chrome to mfd (and probably before that), so it's an old problem. Note that I plan to send a patch series that depends on this to apply cleanly. If the patch is fine with you and there is any possibility to go in this version that will be good, if not, let me know if you prefer queue this in your for-next branch or if you prefer I include the patch on the series I plan to send on top of it to not mess things. Thanks, Enric drivers/mfd/cros_ec_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c index b99a194ce5a4..2d0fee488c5a 100644 --- a/drivers/mfd/cros_ec_dev.c +++ b/drivers/mfd/cros_ec_dev.c @@ -499,6 +499,7 @@ static int ec_device_remove(struct platform_device *pdev) cros_ec_debugfs_remove(ec); + mfd_remove_devices(ec->dev); cdev_del(&ec->cdev); device_unregister(&ec->class_dev); return 0; -- 2.19.2

6 years, 10 months

2
4
0 0

[PATCH] ocxl: Simplify free_spa()

by Greg Kurz

The only users of free_spa() are alloc_link() and free_link(), and in both cases: - link->spa != NULL - free_spa(link) is immediatly followed by kfree(link) The check isn't needed, and it doesn't bring much to clear the link->spa pointer. Drop both. Signed-off-by: Greg Kurz <groug(a)kaod.org> --- drivers/misc/ocxl/link.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c index 31695a078485..eed92055184d 100644 --- a/drivers/misc/ocxl/link.c +++ b/drivers/misc/ocxl/link.c @@ -352,11 +352,8 @@ static void free_spa(struct link *link) pr_debug("Freeing SPA for %x:%x:%x\n", link->domain, link->bus, link->dev); - if (spa && spa->spa_mem) { - free_pages((unsigned long) spa->spa_mem, spa->spa_order); - kfree(spa); - link->spa = NULL; - } + free_pages((unsigned long) spa->spa_mem, spa->spa_order); + kfree(spa); } static int alloc_link(struct pci_dev *dev, int PE_mask, struct link **out_link)

6 years, 10 months

3
5
0 0

+ panic-avoid-the-extra-noise-dmesg.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: panic: Avoid the extra noise dmesg has been added to the -mm tree. Its filename is panic-avoid-the-extra-noise-dmesg.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/panic-avoid-the-extra-noise-dmesg.… and later at http://ozlabs.org/~akpm/mmotm/broken-out/panic-avoid-the-extra-noise-dmesg.… 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: Feng Tang <feng.tang(a)intel.com> Subject: panic: Avoid the extra noise dmesg When kernel panic happens, it will first print the panic call stack, then the ending msg like: [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception [ 35.749975] ------------[ cut here ]------------ The above message are very useful for debugging. But if system is configured to not reboot on panic, say the "panic_timeout" parameter equals 0, it will likely print out many noisy message like WARN() call stack for each and every CPU except the panic one, messages like below: WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190 Call Trace: <IRQ> try_to_wake_up default_wake_function autoremove_wake_function __wake_up_common __wake_up_common_lock __wake_up wake_up_klogd_work_func irq_work_run_list irq_work_tick update_process_times tick_sched_timer __hrtimer_run_queues hrtimer_interrupt smp_apic_timer_interrupt apic_timer_interrupt For people working in console mode, the screen will first show the panic call stack, but immediately overridded by these noisy extra messages, which makes debugging much more difficult, as the original context gets lost on screen. Also these noisy messages will confuse some users, as I have seen many bug reporters posted the noisy message into bugzilla, instead of the real panic call stack and context. Removing the "local_irq_enable" will avoid the noisy message. The justification for the removing is: when code runs to this point, it means user has chosed to not reboot, or do any special handling by using the panic notifier method, no much point in re-enabling the interrupt. Link: http://lkml.kernel.org/r/1543902228-23834-1-git-send-email-feng.tang@intel.… Signed-off-by: Feng Tang <feng.tang(a)intel.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Petr Mladek <pmladek(a)suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- --- a/kernel/panic.c~panic-avoid-the-extra-noise-dmesg +++ a/kernel/panic.c @@ -322,7 +322,6 @@ void panic(const char *fmt, ...) } #endif pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf); - local_irq_enable(); for (i = 0; ; i += PANIC_TIMER_STEP) { touch_softlockup_watchdog(); if (i >= i_next) { _ Patches currently in -mm which might be from feng.tang(a)intel.com are panic-add-options-to-print-system-info-when-panic-happens.patch kernel-sysctl-add-panic_print-into-sysctl.patch panic-avoid-the-extra-noise-dmesg.patch

6 years, 10 months

4
24
0 0

[PATCH] ocxl: Fix endiannes bug in read_afu_name()

by Greg Kurz

The double word returned by read_afu_info(OCXL_DVSEC_TEMPL_NAME) contains four characters of the AFU name, read from the PCI config space, hence with a little-endian ordering. When composing the string, a big-endian system must swap the bytes so that the characters appear in the right order. Do this with le32_to_cpu(). Signed-off-by: Greg Kurz <groug(a)kaod.org> --- drivers/misc/ocxl/config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c index 57a6bb1fd3c9..b76198ba8630 100644 --- a/drivers/misc/ocxl/config.c +++ b/drivers/misc/ocxl/config.c @@ -318,7 +318,7 @@ static int read_afu_name(struct pci_dev *dev, struct ocxl_fn_config *fn, if (rc) return rc; ptr = (u32 *) &afu->name[i]; - *ptr = val; + *ptr = le32_to_cpu(val); } afu->name[OCXL_AFU_NAME_SZ - 1] = '\0'; /* play safe */ return 0;

6 years, 10 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror