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

stable regression: revert request for netfilter ipv6 defrag bug

by Florian Westphal

Hi, please consider reverting commit 84379c9afe011020e797e3f50a662b08a6355dcf netfilter: ipv6: nf_defrag: drop skb dst before queueing It causes kernel crash for locally generated ipv6 fragments when netfilter ipv6 defragmentation is used. The faulty commit is not essential for -stable, it only delays netns teardown for longer than needed when that netns still has ipv6 frags queued. Much better than crash :-/ commit ids are: 4.4.y: not affected (not backported) 4.9.y: backported as ad8b1ffc3efae2f65080bdb11145c87d299b8f9a 4.14.y: backported as 28c74ff85efd192aeca9005499ca50c24d795f61 4.18.y: (first affected kernel): 84379c9afe011020e797e3f50a662b08a6355dcf For 4.19.y, you could also wait for a bug fix to hit Linus tree, I can ping you again once its in: https://patchwork.ozlabs.org/patch/988233/ Thanks, Florian

7 years

2
1
0 0

[PATCH] kdb: Fix btc (backtrace on each cpu) crash

by Douglas Anderson

Typing 'btc' on kdb doing all sorts of fail. Sometimes it would crash, sometimes display nothing, and sometimes hang. Bisect tracked this down to the commit ad67b74d2469 ("printk: hash addresses printed with %p"), suggesting an obvious fix. The pointer used internally in kdb shouldn't be hashed, so switch it to %px. Fixes: ad67b74d2469 ("printk: hash addresses printed with %p") Cc: stable(a)vger.kernel.org Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- kernel/debug/kdb/kdb_bt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c index 6ad4a9fcbd6f..7921ae4fca8d 100644 --- a/kernel/debug/kdb/kdb_bt.c +++ b/kernel/debug/kdb/kdb_bt.c @@ -179,14 +179,14 @@ kdb_bt(int argc, const char **argv) kdb_printf("no process for cpu %ld\n", cpu); return 0; } - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu)); + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu)); kdb_parse(buf); return 0; } kdb_printf("btc: cpu status: "); kdb_parse("cpu\n"); for_each_online_cpu(cpu) { - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu)); + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu)); kdb_parse(buf); touch_nmi_watchdog(); } -- 2.19.1.568.g152ad8e336-goog

7 years

3
2
0 0

request for 4.14-stable: f9a1c372299f ("ALSA: usx2y: Fix invalid stream URBs")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. -- Regards Sudip

7 years

2
1
0 0

request for 4.14-stable: f9ffcb0a21e1 ("media: uvcvideo: Fix driver reference counting")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. -- Regards Sudip

7 years

2
1
0 0

request for 4.14-stable: 5663d8f9bbe4 ("kvm: x86: fix WARN due to uninitialized guest FPU state")

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

7 years

3
2
0 0

[4.4/4.9/4.14 patch] mtd: spi-nor: Add support for is25wp series chips

by Adrian Bunk

From: Kimmo Rautkoski <ext-kimmo.rautkoski(a)vaisala.com> Added support for is25wp032, is25wp064 and is25wp128. Signed-off-by: Kimmo Rautkoski <ext-kimmo.rautkoski(a)vaisala.com> Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> [ Adrian Bunk: Trivial adaption to changed context. ] Signed-off-by: Adrian Bunk <bunk(a)kernel.org> --- drivers/mtd/spi-nor/spi-nor.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 19c000722cbc..34ecc12ee3d9 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -1005,6 +1005,12 @@ static const struct flash_info spi_nor_ids[] = { /* ISSI */ { "is25cd512", INFO(0x7f9d20, 0, 32 * 1024, 2, SECT_4K) }, + { "is25wp032", INFO(0x9d7016, 0, 64 * 1024, 64, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { "is25wp064", INFO(0x9d7017, 0, 64 * 1024, 128, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { "is25wp128", INFO(0x9d7018, 0, 64 * 1024, 256, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, /* Macronix */ { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) }, -- 2.11.0

7 years

3
3
0 0

[PATCH 4.18] Revert "mm: slowly shrink slabs with a relatively small number of objects"

by Sasha Levin

This reverts commit 62aad93f09c1952ede86405894df1b22012fd5ab. Which was upstream commit 172b06c32b94 ("mm: slowly shrink slabs with a relatively small number of objects"). The upstream commit was found to cause regressions. While there is a proposed fix upstream, revent this patch from stable trees for now as testing the fix will take some time. Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- mm/vmscan.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index fc0436407471..03822f86f288 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -386,17 +386,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, delta = freeable >> priority; delta *= 4; do_div(delta, shrinker->seeks); - - /* - * Make sure we apply some minimal pressure on default priority - * even on small cgroups. Stale objects are not only consuming memory - * by themselves, but can also hold a reference to a dying cgroup, - * preventing it from being reclaimed. A dying cgroup with all - * corresponding structures like per-cpu stats and kmem caches - * can be really big, so it may lead to a significant waste of memory. - */ - delta = max_t(unsigned long long, delta, min(freeable, batch_size)); - total_scan += delta; if (total_scan < 0) { pr_err("shrink_slab: %pF negative objects to delete nr=%ld\n", -- 2.17.1

7 years

1
1
0 0

[PATCH v4.14-stable] sch_netem: restore skb->dev after dequeuing from the rbtree

by Christoph Paasch

Upstream commit bffa72cf7f9d ("net: sk_buff rbnode reorg") got backported as commit 6b921536f170 ("net: sk_buff rbnode reorg") into the v4.14.x-tree. However, the backport does not include the changes in sch_netem.c We need these, as otherwise the skb->dev pointer is not set when dequeueing from the netem rbtree, resulting in a panic: [ 15.427748] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 [ 15.428863] IP: netif_skb_features+0x24/0x230 [ 15.429402] PGD 0 P4D 0 [ 15.429733] Oops: 0000 [#1] SMP PTI [ 15.430169] Modules linked in: [ 15.430614] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.77.mptcp #77 [ 15.431497] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 15.432568] task: ffff88042db19680 task.stack: ffffc90000070000 [ 15.433356] RIP: 0010:netif_skb_features+0x24/0x230 [ 15.433977] RSP: 0018:ffff88043fd83e70 EFLAGS: 00010286 [ 15.434665] RAX: ffff880429ad80c0 RBX: ffff88042bd0e400 RCX: ffff880429ad8000 [ 15.435585] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88042bd0e400 [ 15.436551] RBP: ffff88042bd0e400 R08: ffff88042a4b6c9c R09: 0000000000000001 [ 15.437485] R10: 0000000000000004 R11: 0000000000000000 R12: ffff88042c700000 [ 15.438393] R13: ffff88042c700000 R14: ffff88042a4b6c00 R15: ffff88042c6bb000 [ 15.439315] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [ 15.440314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 15.441084] CR2: 00000000000000d0 CR3: 000000042c374000 CR4: 00000000000006e0 [ 15.442016] Call Trace: [ 15.442333] <IRQ> [ 15.442596] validate_xmit_skb+0x17/0x270 [ 15.443134] validate_xmit_skb_list+0x38/0x60 [ 15.443698] sch_direct_xmit+0x102/0x190 [ 15.444198] __qdisc_run+0xe3/0x240 [ 15.444671] net_tx_action+0x121/0x140 [ 15.445177] __do_softirq+0xe2/0x224 [ 15.445654] irq_exit+0xbf/0xd0 [ 15.446072] smp_apic_timer_interrupt+0x5d/0x90 [ 15.446654] apic_timer_interrupt+0x7d/0x90 [ 15.447185] </IRQ> [ 15.447460] RIP: 0010:native_safe_halt+0x2/0x10 [ 15.447992] RSP: 0018:ffffc90000073f10 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10 [ 15.449008] RAX: ffffffff816667d0 RBX: ffffffff820946b0 RCX: 0000000000000000 [ 15.449895] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 15.450768] RBP: ffffffff82026940 R08: 00000004e858e5e1 R09: ffff88042a4b6d58 [ 15.451643] R10: 0000000000000000 R11: 000000d0d56879bb R12: 0000000000000000 [ 15.452478] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 15.453340] ? __sched_text_end+0x2/0x2 [ 15.453835] default_idle+0xf/0x20 [ 15.454259] do_idle+0x170/0x200 [ 15.454653] cpu_startup_entry+0x14/0x20 [ 15.455142] secondary_startup_64+0xa5/0xb0 [ 15.455715] Code: 1f 84 00 00 00 00 00 55 53 48 89 fd 48 83 ec 08 8b 87 bc 00 00 00 48 8b 8f c0 00 00 00 0f b6 97 81 00 00 00 48 8b 77 10 48 01 c8 <48> 8b 9 [ 15.458138] RIP: netif_skb_features+0x24/0x230 RSP: ffff88043fd83e70 [ 15.458933] CR2: 00000000000000d0 [ 15.459352] ---[ end trace 083925903ae60570 ]--- Fixes: 6b921536f170 ("net: sk_buff rbnode reorg") Cc: Stephen Hemminger <stephen(a)networkplumber.org> Cc: Eric Dumazet <edumazet(a)google.com> Cc: Soheil Hassas Yeganeh <soheil(a)google.com> Cc: Wei Wang <weiwan(a)google.com> Cc: Willem de Bruijn <willemb(a)google.com> Signed-off-by: Christoph Paasch <cpaasch(a)apple.com> --- Notes: This patch should only make it into v4.14-stable as that's the only branch where the offending commit has been backported to. net/sched/sch_netem.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c index 2a2ab6bfe5d8..3d325b840802 100644 --- a/net/sched/sch_netem.c +++ b/net/sched/sch_netem.c @@ -624,6 +624,10 @@ static struct sk_buff *netem_dequeue(struct Qdisc *sch) skb->next = NULL; skb->prev = NULL; skb->tstamp = netem_skb_cb(skb)->tstamp_save; + /* skb->dev shares skb->rbnode area, + * we need to restore its value. + */ + skb->dev = qdisc_dev(sch); #ifdef CONFIG_NET_CLS_ACT /* -- 2.16.2

7 years

4
3
0 0

Automated testing for stable kernel branches?

by Major Hayden

Hello there, I am working on a project at Red Hat where we do quick testing on patches for internal kernels before they merge. The goal is to catch bugs or issues before they merge into kernel trees and avoid situations where kernels need time-consuming bisects when lots of patches are merged at once. We aim to put valuable feedback into a kernel developer's inbox within four hours. Our team has built a pipeline where we merge patches, compile kernels (for various architectures), and run tests on real hardware (various architectures). The current test set is fairly basic and it includes LTP plus some additional open source tests. We are looking to gradually expand those over time as we evaluate which tests provide the most value and find the most problems. We would love to bring this to upstream kernel repositories and we thought that linux-stable might be a good place to start. The developer/maintainer experience would look something like this: 1) Developer submits a patchset 2) Those patches end up in Patchwork 3) We pull patches from patchwork, compile kernels, and test them 4) We reply to the thread on the mailing list with a brief set of results (one time per patchset) Developers do not need to change any existing workflows. We gather the patches, test them, and reply in the appropriate place. Is this something that the linux-stable community and maintainers would find valuable? If so, feel free to ask any questions about our process and we can go over any of those parts in more detail. If not, please let me know anyway! Our team is always looking for ways to improve. :) Thanks a bunch for reading this far and I look forward to hearing from you. -- Major Hayden

7 years

3
7
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Hans de Goede

Hi, On 31-10-18 07:02, Mogens Jensen wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, October 30, 2018 7:10 PM, Hans de Goede <hdegoede(a)redhat.com> wrote: > >> Hi, >> >> On 30-10-18 19:56, Mogens Jensen wrote: >> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Tuesday, October 30, 2018 4:04 PM, Hans de Goede hdegoede(a)redhat.com wrote: >>> >>>> Hi, >>>> On 30-10-18 16:46, Hans de Goede wrote: >>>> >>>>> Hi, >>>>> On 30-10-18 16:04, Pierre-Louis Bossart wrote: >>>>> >>>>>> In addition I am not aware of any baytrail device using plt_clk_0, so moving a common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might work though, >>>>> >>>>> Ok, so we need to have a DMI based quirk for the Swanky and maybe also >>>>> the clapper to use plt_clk_0 there. Asking for 2 clks if we only need >>>>> one does not seem like a good plan. >>>> >>>> Dean, Mogens, >>>> To write a proper patch for this I'm going to need DMI strings >>>> from your devices. >>>> Can you please run (as normal user): >>>> grep . /sys/class/dmi/id/* 2> /dev/null >>>> And reply with the output of this command? >>>> I have attached the output from a coreboot seabios based clapper. >> >> Thank you. >> >>> Should I still test 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to have been some development in the case since that request was made. >> >> Yes please test that, I expect that to also fix things for the >> Clapper, but I need to have that confirmed before submitting a >> patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0 >> instead of pmc_plt_clk_3. >> >> Regards, >> >> Hans >> > Unfortunately I only have access to longterm kernel 4.14 for building/running on this system, and 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does not patch against 4.14.78. Can a test patch for 4.14 be created? Can you run (as root): for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat $i/clk_flags; echo; done When running a kernel with working audio? Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that I can fix this for the clapper for 4.18+ I've just checked the 4.14 sources and in 4.14 the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver does not support mclk control yet, so for the 4.14 kernel the only way to fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") commit. Regards, Hans

7 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror