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

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

7 years

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

7 years

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

7 years

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)

7 years

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

7 years

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;

7 years

3
4
0 0

[PATCH] VSOCK: bind to random port for VMADDR_PORT_ANY

by Lepton Wu

The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more in vhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one. Signed-off-by: Lepton Wu <ytht.net(a)gmail.com> --- net/vmw_vsock/af_vsock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index ab27a2872935..73817e846a1f 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -107,6 +107,7 @@ #include <linux/mutex.h> #include <linux/net.h> #include <linux/poll.h> +#include <linux/random.h> #include <linux/skbuff.h> #include <linux/smp.h> #include <linux/socket.h> @@ -504,9 +505,12 @@ static void vsock_pending_work(struct work_struct *work) static int __vsock_bind_stream(struct vsock_sock *vsk, struct sockaddr_vm *addr) { - static u32 port = LAST_RESERVED_PORT + 1; + static u32 port = 0; struct sockaddr_vm new_addr; + if (!port) + port = prandom_u32(); + vsock_addr_init(&new_addr, addr->svm_cid, addr->svm_port); if (addr->svm_port == VMADDR_PORT_ANY) { -- 2.20.0.rc2.403.gdbc3b29805-goog

7 years

2
1
0 0

[PATCH] mtd: atmel-quadspi: disallow building on ebsa110

by Arnd Bergmann

I ran into a link-time error with the atmel-quadspi driver on the EBSA110 platform: drivers/mtd/built-in.o: In function `atmel_qspi_run_command': :(.text+0x1ee3c): undefined reference to `_memcpy_toio' :(.text+0x1ee48): undefined reference to `_memcpy_fromio' The problem is that _memcpy_toio/_memcpy_fromio are not available on that platform, and we have to prevent building the driver there. In case we want to backport this to older kernels: between linux-4.8 and linux-4.20, the Kconfig entry was in drivers/mtd/spi-nor/Kconfig but had the same problem. Link: https://lore.kernel.org/patchwork/patch/812860/ Fixes: 161aaab8a067 ("mtd: atmel-quadspi: add driver for Atmel QSPI controller") Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/spi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 55d5ffb50750..9f89cb134549 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -93,7 +93,7 @@ config SPI_AT91_USART config SPI_ATMEL_QUADSPI tristate "Atmel Quad SPI Controller" - depends on ARCH_AT91 || (ARM && COMPILE_TEST) + depends on ARCH_AT91 || (ARM && COMPILE_TEST && !ARCH_EBSA110) depends on OF && HAS_IOMEM help This enables support for the Quad SPI controller in master mode. -- 2.18.0

7 years

3
2
0 0

Re: [PATCH v6 1/3] mm: Add support for kmem caches in DMA32 zone

by Nicolas Boichat

Hi Sasha, On Tue, Dec 11, 2018 at 2:42 AM Sasha Levin <sashal(a)kernel.org> 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: Failed to apply! Possible dependencies: > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > a3ba07444782 ("mm/slab.c: only set __GFP_RECLAIMABLE once") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > v4.9.144: Failed to apply! Possible dependencies: > 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization") > 12d14cc43b34 ("drm/i915/gvt: Introduce a framework for tracking HW registers.") > 1b36595ffb35 ("drm/i915: Show RING registers through debugfs") > 28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management") > 3f728236c516 ("drm/i915/gvt: trace stub") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 579cea5f30f2 ("drm/i915/gvt: golden virtual HW state management") > 5f0d5a3ae7cf ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU") > 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct") > 82d375d1b568 ("drm/i915/gvt: Introduce basic vGPU life cycle management") > 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization") > a933568eb61d ("drm/i915: Tidy slab cache allocations") > c8fe6a6811a7 ("drm/i915/gvt: vGPU interrupt virtualization.") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization") > e473405783c0 ("drm/i915/gvt: vGPU workload scheduler") > e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with callers") > > v4.4.166: Failed to apply! Possible dependencies: > 10b2e9e8e808 ("mm/slab: factor out debugging initialization in cache_init_objs()") > 40b44137971c ("mm/slab: clean up DEBUG_PAGEALLOC processing code") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 505f5dcb1c41 ("mm, kasan: add GFP flags to KASAN API") > 55834c59098d ("mm: kasan: initial memory quarantine implementation") > 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") > 7ed2f9e66385 ("mm, kasan: SLAB support") > 832a15d209cd ("mm/slab: align cache size first before determination of OFF_SLAB candidate") > a307ebd468e0 ("mm/slab: activate debug_pagealloc in SLAB when it is actually enabled") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > v3.18.128: Failed to apply! Possible dependencies: > 081fa9dffcde ("staging/lustre/llite: remove llite proc root on init failure") > 12cf89b550d1 ("livepatch: rename config to CONFIG_LIVEPATCH") > 13d1cf7e7025 ("livepatch: samples: add sample live patching module") > 31e7213ab21e ("drivers: staging: lustre: Fix "spaces required around that '='" errors") > 32b7eb877165 ("livepatch: change ARCH_HAVE_LIVE_PATCHING to HAVE_LIVE_PATCHING") > 4fd0b46e8987 ("slab, slub, slob: convert slab_flags_t to 32-bit") > 5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") > 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") > 6471b825c41e ("x86/kconfig: Reorganize arch feature Kconfig select's") > 6e0a0ea12962 ("ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT") > 83ac237a950e ("livepatch: kconfig: use bool instead of boolean") > 957e3facd147 ("gcov: enable GCOV_PROFILE_ALL from ARCH Kconfigs") > b700e7f03df5 ("livepatch: kernel: add support for live patching") > b9dfe0bed999 ("livepatch: handle ancient compilers with more grace") > d50112edde1d ("slab, slub, slob: add slab_flags_t") > > > How should we proceed with this patch? I'm not sure how we need to handle this. 2/3 in this series (https://patchwork.kernel.org/patch/10720495/) is the patch that matters, and has correct Fixes/Cc tag (this only needs to apply >=4.15). I added Cc: stable@ to this patch, as it is a dependency of 2/3. Should I remove Cc: stable from this patch? Or add Fixes: line? Thanks, Nicolas > -- > Thanks, > Sasha

7 years

2
2
0 0

x86: e820 regression

by Erick Cafferata

The following commit introduced a regression on my system. 124049decbb121ec32742c94fb5d9d6bed8f24d8 x86/e820: put !E820_TYPE_RAM regions into memblock.reserved and it was backported to stable, stopping the kernel to boot on my system since around 4.17.4. It was reverted on upstream a couple months ago. commit 2a5bda5a624d6471d25e953b9adba5182ab1b51f upstream There are some other modifications to the file after that. However, at the very least, can the revert be backported? I think the original patch tries to fix a previous bug, so probably the latest commits fixed that one correctly and need to be backported as well.

7 years

4
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror