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

[PATCH AUTOSEL 4.18 067/113] powerpc: Fix size calculation using resource_size()

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 ] The problem is the the calculation should be "end - start + 1" but the plus one is missing in this calculation. Fixes: 8626816e905e ("powerpc: add support for MPIC message register API") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- arch/powerpc/sysdev/mpic_msgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c index eb69a5186243..280e964e1aa8 100644 --- a/arch/powerpc/sysdev/mpic_msgr.c +++ b/arch/powerpc/sysdev/mpic_msgr.c @@ -196,7 +196,7 @@ static int mpic_msgr_probe(struct platform_device *dev) /* IO map the message register block. */ of_address_to_resource(np, 0, &rsrc); - msgr_block_addr = ioremap(rsrc.start, rsrc.end - rsrc.start); + msgr_block_addr = ioremap(rsrc.start, resource_size(&rsrc)); if (!msgr_block_addr) { dev_err(&dev->dev, "Failed to iomap MPIC message registers"); return -EFAULT; -- 2.17.1

6 years, 10 months

4
56
0 0

[PATCH 4.4] net: lan78xx: Fix misplaced tasklet_schedule() call

by Ben Hutchings

Commit 136f55f66019 ("net: lan78xx: fix rx handling before first packet is send") was not correctly backported to 4.4. The call to tasklet_schedule() belongs in lan78xx_link_reset(). Fixes: d1fc12d8475c ("net: lan78xx: fix rx handling before first packet is send") Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- This is for 4.4 only; the backports to other stable branches look OK. I didn't test the driver on any branch though. Ben. drivers/net/usb/lan78xx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index acec4b565511..1aede726052c 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -902,6 +902,8 @@ static int lan78xx_link_reset(struct lan78xx_net *dev) ret = lan78xx_update_flowcontrol(dev, ecmd.duplex, ladv, radv); netif_carrier_on(dev->net); + + tasklet_schedule(&dev->bh); } return ret; @@ -1361,8 +1363,6 @@ static void lan78xx_init_mac_address(struct lan78xx_net *dev) netif_dbg(dev, ifup, dev->net, "MAC address set to random addr"); } - - tasklet_schedule(&dev->bh); } ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo); -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

6 years, 10 months

1
0
0 0

[PATCH v4 1/6] drm/nouveau: Check backlight IDs are >= 0, not > 0

by Lyude Paul

Remember, ida IDs start at 0, not 1! Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Karol Herbst <kherbst(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 408b955e5c39..6dd72bc32897 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -116,7 +116,7 @@ nv40_backlight_init(struct drm_connector *connector) &nv40_bl_ops, &props); if (IS_ERR(bd)) { - if (bl_connector.id > 0) + if (bl_connector.id >= 0) ida_simple_remove(&bl_ida, bl_connector.id); return PTR_ERR(bd); } @@ -249,7 +249,7 @@ nv50_backlight_init(struct drm_connector *connector) nv_encoder, ops, &props); if (IS_ERR(bd)) { - if (bl_connector.id > 0) + if (bl_connector.id >= 0) ida_simple_remove(&bl_ida, bl_connector.id); return PTR_ERR(bd); } -- 2.17.1

6 years, 10 months

1
0
0 0

[PATCH] xtensa: ISS: don't allocate memory in platform_setup

by Max Filippov

Memory allocator is not initialized at that point yet, use static array instead. Cc: stable(a)vger.kernel.org Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- arch/xtensa/platforms/iss/setup.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/arch/xtensa/platforms/iss/setup.c b/arch/xtensa/platforms/iss/setup.c index f4bbb28026f8..58709e89a8ed 100644 --- a/arch/xtensa/platforms/iss/setup.c +++ b/arch/xtensa/platforms/iss/setup.c @@ -78,23 +78,28 @@ static struct notifier_block iss_panic_block = { void __init platform_setup(char **p_cmdline) { + static void *argv[COMMAND_LINE_SIZE / sizeof(void *)] __initdata; + static char cmdline[COMMAND_LINE_SIZE] __initdata; int argc = simc_argc(); int argv_size = simc_argv_size(); if (argc > 1) { - void **argv = alloc_bootmem(argv_size); - char *cmdline = alloc_bootmem(argv_size); - int i; + if (argv_size > sizeof(argv)) { + pr_err("%s: command line too long: argv_size = %d\n", + __func__, argv_size); + } else { + int i; - cmdline[0] = 0; - simc_argv((void *)argv); + cmdline[0] = 0; + simc_argv((void *)argv); - for (i = 1; i < argc; ++i) { - if (i > 1) - strcat(cmdline, " "); - strcat(cmdline, argv[i]); + for (i = 1; i < argc; ++i) { + if (i > 1) + strcat(cmdline, " "); + strcat(cmdline, argv[i]); + } + *p_cmdline = cmdline; } - *p_cmdline = cmdline; } atomic_notifier_chain_register(&panic_notifier_list, &iss_panic_block); -- 2.11.0

6 years, 10 months

1
0
0 0

[PATCH] memory: ti-aemif: fix a potential NULL-pointer dereference

by Bartosz Golaszewski

From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Platform data pointer may be NULL. We check it everywhere but in one place. Fix it. Fixes: 8af70cd2ca50 ("memory: aemif: add support for board files") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Cc: stable(a)vger.kernel.org --- drivers/memory/ti-aemif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c index 31112f622b88..475e5b3790ed 100644 --- a/drivers/memory/ti-aemif.c +++ b/drivers/memory/ti-aemif.c @@ -411,7 +411,7 @@ static int aemif_probe(struct platform_device *pdev) if (ret < 0) goto error; } - } else { + } else if (pdata) { for (i = 0; i < pdata->num_sub_devices; i++) { pdata->sub_devices[i].dev.parent = dev; ret = platform_device_register(&pdata->sub_devices[i]); -- 2.18.0

6 years, 10 months

3
3
0 0

[PATCH 2/2] printk/tracing: Do not trace printk_nmi_enter()

by Steven Rostedt

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> I hit the following splat in my tests: ------------[ cut here ]------------ IRQs not enabled as expected WARNING: CPU: 3 PID: 0 at kernel/time/tick-sched.c:982 tick_nohz_idle_enter+0x44/0x8c Modules linked in: ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipv6 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.0-rc2-test+ #2 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 EIP: tick_nohz_idle_enter+0x44/0x8c Code: ec 05 00 00 00 75 26 83 b8 c0 05 00 00 00 75 1d 80 3d d0 36 3e c1 00 75 14 68 94 63 12 c1 c6 05 d0 36 3e c1 01 e8 04 ee f8 ff <0f> 0b 58 fa bb a0 e5 66 c1 e8 25 0f 04 00 64 03 1d 28 31 52 c1 8b EAX: 0000001c EBX: f26e7f8c ECX: 00000006 EDX: 00000007 ESI: f26dd1c0 EDI: 00000000 EBP: f26e7f40 ESP: f26e7f38 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010296 CR0: 80050033 CR2: 0813c6b0 CR3: 2f342000 CR4: 001406f0 Call Trace: do_idle+0x33/0x202 cpu_startup_entry+0x61/0x63 start_secondary+0x18e/0x1ed startup_32_smp+0x164/0x168 irq event stamp: 18773830 hardirqs last enabled at (18773829): [<c040150c>] trace_hardirqs_on_thunk+0xc/0x10 hardirqs last disabled at (18773830): [<c040151c>] trace_hardirqs_off_thunk+0xc/0x10 softirqs last enabled at (18773824): [<c0ddaa6f>] __do_softirq+0x25f/0x2bf softirqs last disabled at (18773767): [<c0416bbe>] call_on_stack+0x45/0x4b ---[ end trace b7c64aa79e17954a ]--- After a bit of debugging, I found what was happening. This would trigger when performing "perf" with a high NMI interrupt rate, while enabling and disabling function tracer. Ftrace uses breakpoints to convert the nops at the start of functions to calls to the function trampolines. The breakpoint traps disable interrupts and this makes calls into lockdep via the trace_hardirqs_off_thunk in the entry.S code. What happens is the following: do_idle { [interrupts enabled] <interrupt> [interrupts disabled] TRACE_IRQS_OFF [lockdep says irqs off] [...] TRACE_IRQS_IRET test if pt_regs say return to interrupts enabled [yes] TRACE_IRQS_ON [lockdep says irqs are on] <nmi> nmi_enter() { printk_nmi_enter() [traced by ftrace] [ hit ftrace breakpoint ] <breakpoint exception> TRACE_IRQS_OFF [lockdep says irqs off] [...] TRACE_IRQS_IRET [return from breakpoint] test if pt_regs say interrupts enabled [no] [iret back to interrupt] [iret back to code] tick_nohz_idle_enter() { lockdep_assert_irqs_enabled() [lockdep say no!] Although interrupts are indeed enabled, lockdep thinks it is not, and since we now do asserts via lockdep, it gives a false warning. The issue here is that printk_nmi_enter() is called before lockdep_off(), which disables lockdep (for this reason) in NMIs. By simply not allowing ftrace to see printk_nmi_enter() (via notrace annotation) we keep lockdep from getting confused. Cc: stable(a)vger.kernel.org Fixes: 42a0bb3f71383 ("printk/nmi: generic solution for safe printk in NMI") Acked-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com> Acked-by: Petr Mladek <pmladek(a)suse.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/printk/printk_safe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index a0a74c533e4b..0913b4d385de 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/printk/printk_safe.c @@ -306,12 +306,12 @@ static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args) return printk_safe_log_store(s, fmt, args); } -void printk_nmi_enter(void) +void notrace printk_nmi_enter(void) { this_cpu_or(printk_context, PRINTK_NMI_CONTEXT_MASK); } -void printk_nmi_exit(void) +void notrace printk_nmi_exit(void) { this_cpu_and(printk_context, ~PRINTK_NMI_CONTEXT_MASK); } -- 2.18.0

6 years, 10 months

1
0
0 0

[PATCH v4.9.y] Fixes: Commit 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages")

by Chas Williams

From: Chas Williams <chas3(a)att.com> Commit 3c226c637b69 ("mm: numa: avoid waiting on freed migrated pages") was an incomplete backport of the upstream commit. It is necessary to always reset page_nid before attempting any early exit. --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 9efe88ef9702..e4c6c3edaf6a 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1259,12 +1259,12 @@ int do_huge_pmd_numa_page(struct fault_env *fe, pmd_t pmd) /* Migration could have started since the pmd_trans_migrating check */ if (!page_locked) { + page_nid = -1; if (!get_page_unless_zero(page)) goto out_unlock; spin_unlock(fe->ptl); wait_on_page_locked(page); put_page(page); - page_nid = -1; goto out; } -- 2.14.4

6 years, 10 months

3
8
0 0

patch "usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0" 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: gadget: udc: renesas_usb3: fix maxpacket size of ep0 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 dfe1a51d2a36647f74cbad478801efa7cf394376 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Date: Fri, 3 Aug 2018 12:12:46 +0900 Subject: usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0 This patch fixes an issue that maxpacket size of ep0 is incorrect for SuperSpeed. Otherwise, CDC NCM class with SuperSpeed doesn't work correctly on this driver because its control read data size is more than 64 bytes. Reported-by: Junki Kato <junki.kato.xk(a)renesas.com> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: <stable(a)vger.kernel.org> # v4.5+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Tested-by: Junki Kato <junki.kato.xk(a)renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/gadget/udc/renesas_usb3.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index 1f879b3f2c96..e1656f361e08 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -812,12 +812,15 @@ static void usb3_irq_epc_int_1_speed(struct renesas_usb3 *usb3) switch (speed) { case USB_STA_SPEED_SS: usb3->gadget.speed = USB_SPEED_SUPER; + usb3->gadget.ep0->maxpacket = USB3_EP0_SS_MAX_PACKET_SIZE; break; case USB_STA_SPEED_HS: usb3->gadget.speed = USB_SPEED_HIGH; + usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE; break; case USB_STA_SPEED_FS: usb3->gadget.speed = USB_SPEED_FULL; + usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE; break; default: usb3->gadget.speed = USB_SPEED_UNKNOWN; @@ -2513,7 +2516,7 @@ static int renesas_usb3_init_ep(struct renesas_usb3 *usb3, struct device *dev, /* for control pipe */ usb3->gadget.ep0 = &usb3_ep->ep; usb_ep_set_maxpacket_limit(&usb3_ep->ep, - USB3_EP0_HSFS_MAX_PACKET_SIZE); + USB3_EP0_SS_MAX_PACKET_SIZE); usb3_ep->ep.caps.type_control = true; usb3_ep->ep.caps.dir_in = true; usb3_ep->ep.caps.dir_out = true; -- 2.18.0

6 years, 10 months

1
0
0 0

patch "USB: net2280: Fix erroneous synchronization change" 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: net2280: Fix erroneous synchronization change 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 dec3c23c9aa1815f07d98ae0375b4cbc10971e13 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 8 Aug 2018 11:20:39 -0400 Subject: USB: net2280: Fix erroneous synchronization change Commit f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks") was based on a serious misunderstanding. It introduced regressions into both the dummy-hcd and net2280 drivers. The problem in dummy-hcd was fixed by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), but the problem in net2280 remains. Namely: the ->disconnect(), ->suspend(), ->resume(), and ->reset() callbacks must be invoked without the private lock held; otherwise a deadlock will occur when the callback routine tries to interact with the UDC driver. This patch largely is a reversion of the relevant parts of f16443a034c7. It also drops the private lock around the calls to ->suspend() and ->resume() (something the earlier patch forgot to do). This is safe from races with device interrupts because it occurs within the interrupt handler. Finally, the patch changes where the ->disconnect() callback is invoked when net2280_pullup() turns the pullup off. Rather than making the callback from within stop_activity() at a time when dropping the private lock could be unsafe, the callback is moved to a point after the lock has already been dropped. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks") Reported-by: D. Ziesche <dziesche(a)zes.com> Tested-by: D. Ziesche <dziesche(a)zes.com> CC: <stable(a)vger.kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/gadget/udc/net2280.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c index 318246d8b2e2..b02ab2a8d927 100644 --- a/drivers/usb/gadget/udc/net2280.c +++ b/drivers/usb/gadget/udc/net2280.c @@ -1545,11 +1545,14 @@ static int net2280_pullup(struct usb_gadget *_gadget, int is_on) writel(tmp | BIT(USB_DETECT_ENABLE), &dev->usb->usbctl); } else { writel(tmp & ~BIT(USB_DETECT_ENABLE), &dev->usb->usbctl); - stop_activity(dev, dev->driver); + stop_activity(dev, NULL); } spin_unlock_irqrestore(&dev->lock, flags); + if (!is_on && dev->driver) + dev->driver->disconnect(&dev->gadget); + return 0; } @@ -2466,8 +2469,11 @@ static void stop_activity(struct net2280 *dev, struct usb_gadget_driver *driver) nuke(&dev->ep[i]); /* report disconnect; the driver is already quiesced */ - if (driver) + if (driver) { + spin_unlock(&dev->lock); driver->disconnect(&dev->gadget); + spin_lock(&dev->lock); + } usb_reinit(dev); } @@ -3341,6 +3347,8 @@ static void handle_stat0_irqs(struct net2280 *dev, u32 stat) BIT(PCI_RETRY_ABORT_INTERRUPT)) static void handle_stat1_irqs(struct net2280 *dev, u32 stat) +__releases(dev->lock) +__acquires(dev->lock) { struct net2280_ep *ep; u32 tmp, num, mask, scratch; @@ -3381,12 +3389,14 @@ static void handle_stat1_irqs(struct net2280 *dev, u32 stat) if (disconnect || reset) { stop_activity(dev, dev->driver); ep0_start(dev); + spin_unlock(&dev->lock); if (reset) usb_gadget_udc_reset (&dev->gadget, dev->driver); else (dev->driver->disconnect) (&dev->gadget); + spin_lock(&dev->lock); return; } } @@ -3405,6 +3415,7 @@ static void handle_stat1_irqs(struct net2280 *dev, u32 stat) tmp = BIT(SUSPEND_REQUEST_CHANGE_INTERRUPT); if (stat & tmp) { writel(tmp, &dev->regs->irqstat1); + spin_unlock(&dev->lock); if (stat & BIT(SUSPEND_REQUEST_INTERRUPT)) { if (dev->driver->suspend) dev->driver->suspend(&dev->gadget); @@ -3415,6 +3426,7 @@ static void handle_stat1_irqs(struct net2280 *dev, u32 stat) dev->driver->resume(&dev->gadget); /* at high speed, note erratum 0133 */ } + spin_lock(&dev->lock); stat &= ~tmp; } -- 2.18.0

6 years, 10 months

1
0
0 0

please backport 29869d66870a to v4.9 stable

by Matthieu Baerts

Hello, First, thank you for maintaining so many kernel versions so well! I recently tested the v4.9 version and I had this warning: [ 8.004728] ------------[ cut here ]------------ [ 8.005169] WARNING: CPU: 0 PID: 0 at /home/jenkins/slave/workspace/kernel_v4.9.x/kernelspace/kernel/softirq.c:165 __local_bh_enable_ip+0x66/0x80 [ 8.006397] Modules linked in: [ 8.006738] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.123 #2 [ 8.007297] Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 [ 8.007841] ffff88001fc03a90 ffffffff811c9935 0000000000000000 0000000000000000 [ 8.008519] ffff88001fc03ad0 ffffffff81046d27 000000a50ca87c00 0000000000000200 [ 8.009186] ffff88000ca87c00 ffff88000f200000 ffff88000c5007c0 ffff88000b47f24e [ 8.009813] Call Trace: [ 8.010033] <IRQ> [ 8.010195] [<ffffffff811c9935>] dump_stack+0x63/0x8e [ 8.010636] [<ffffffff81046d27>] __warn+0xc7/0xf0 [ 8.011039] [<ffffffff81046e08>] warn_slowpath_null+0x18/0x20 [ 8.011503] [<ffffffff8104a686>] __local_bh_enable_ip+0x66/0x80 [ 8.012044] [<ffffffff814f8d55>] _raw_spin_unlock_bh+0x15/0x20 [ 8.012515] [<ffffffff8146ee87>] jtcp_rcv_established+0x227/0x2b0 [ 8.013050] [<ffffffff81444963>] tcp_v4_do_rcv+0x163/0x1f0 [ 8.013493] [<ffffffff81447b25>] tcp_v4_rcv+0xe85/0x10a0 [ 8.013957] [<ffffffff8146b23c>] ? nf_nat_ipv4_fn+0x19c/0x1e0 [ 8.014431] [<ffffffff8146e8b0>] ? iptable_nat_ipv4_fn+0x20/0x20 [ 8.015013] [<ffffffff8141fa8f>] ip_local_deliver_finish+0x9f/0x140 [ 8.015517] [<ffffffff81420090>] ip_local_deliver+0xc0/0xd0 [ 8.016027] [<ffffffff8141f9f0>] ? inet_del_offload+0x40/0x40 [ 8.016490] [<ffffffff8141fccb>] ip_rcv_finish+0x19b/0x350 [ 8.017028] [<ffffffff81420353>] ip_rcv+0x2b3/0x460 [ 8.017425] [<ffffffff8141fb30>] ? ip_local_deliver_finish+0x140/0x140 [ 8.017990] [<ffffffff813b5bde>] __netif_receive_skb_core+0x47e/0x840 [ 8.018508] [<ffffffff8144cff1>] ? tcp4_gro_receive+0x131/0x1b0 [ 8.019029] [<ffffffff8145c2b1>] ? inet_gro_receive+0x231/0x2a0 [ 8.019507] [<ffffffff813b8258>] __netif_receive_skb+0x18/0x60 [ 8.020053] [<ffffffff813b82c8>] netif_receive_skb_internal+0x28/0x90 [ 8.020570] [<ffffffff813b8b48>] napi_gro_receive+0x78/0xa0 [ 8.021064] [<ffffffff81332c28>] virtnet_receive+0x1f8/0x890 [ 8.021520] [<ffffffff813333b8>] virtnet_poll+0x18/0x80 [ 8.021986] [<ffffffff813b9cc6>] net_rx_action+0xf6/0x2c0 [ 8.022422] [<ffffffff8104a44c>] __do_softirq+0xcc/0x1e0 [ 8.022874] [<ffffffff8104a767>] irq_exit+0x67/0x70 [ 8.023290] [<ffffffff81019be1>] do_IRQ+0x51/0xe0 [ 8.023695] [<ffffffff814f99d6>] common_interrupt+0x96/0x96 [ 8.024189] <EOI> [ 8.024351] [<ffffffff814f8b30>] ? __sched_text_end+0x3/0x3 [ 8.024830] [<ffffffff814f8bc6>] ? native_safe_halt+0x6/0x10 [ 8.025307] [<ffffffff814f8b39>] default_idle+0x9/0x10 [ 8.025742] [<ffffffff81021210>] arch_cpu_idle+0x10/0x20 [ 8.026190] [<ffffffff814f8c4e>] default_idle_call+0x1e/0x30 [ 8.026813] [<ffffffff81077621>] cpu_startup_entry+0xe1/0x1d0 [ 8.027397] [<ffffffff814f453d>] rest_init+0x6d/0x70 [ 8.027832] [<ffffffff8188f0dc>] start_kernel+0x4d0/0x4dd [ 8.028360] [<ffffffff8188e9fa>] ? set_init_arg+0x55/0x55 [ 8.028821] [<ffffffff8188e120>] ? early_idt_handler_array+0x120/0x120 [ 8.029372] [<ffffffff8188e599>] x86_64_start_reservations+0x2a/0x2c [ 8.029910] [<ffffffff8188e681>] x86_64_start_kernel+0xe6/0xf3 [ 8.030412] ---[ end trace 5826c2ad94ee574a ]--- After a quick search, Christoph found that this kind of call trace had already been reported by Intel's kernel test bot: https://lkml.org/lkml/2017/2/19/251 According to this bot, it seems that the following commit caused the warning: e70ac171658679ecf6bea4bbd9e9325cd6079d2b (tcp: tcp_probe: use spin_lock_bh()) Note that this commit has been backported from v4.10 to v4.9.33. The next day, Eric Dumazet, the author of the first patch, proposed a second one which "simply" reverts this commit: 29869d66870a715177bfb505f66a7e0e8bcc89c3 (tcp: Revert "tcp: tcp_probe: use spin_lock_bh()") You can find the discussions about this patch here, including a question from Eric not being sure why it is not needed: https://patchwork.ozlabs.org/patch/730560/ After having applied this patch (the reverted commit - 29869d66870a) on the v4.9 tree, I confirm I no longer have the warning mentioned at the beginning of this email. I don't think many people are still using tcp probe -- recently removed in v4.16 -- but it could be nice if someone could backport the commit 29869d66870a in v4.9.y tree to avoid extra warnings. Again, thank you for your very nice work! Best regards, Matt -- Matthieu Baerts | R&D Engineer matthieu.baerts(a)tessares.net Tessares SA | Hybrid Access Solutions www.tessares.net 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

6 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror