September 2018 - Linux-stable-mirror

[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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 months

1
0
0 0

[PATCH] Fixes: fc2a69f3903d ("drm/atomic: Handling the case when, setting old crtc for plane")

by Karsten Hohmeier

Original commit causes "plane A assertion failure" on lid close/lid open with older HP Compaq 6720s laptops (Intel Mobile GME965/GLE960). Full bug report at "https://bugs.freedesktop.org/show_bug.cgi?id=107827". --- drivers/gpu/drm/drm_atomic.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 895741e9cd7d..a59ded403657 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1433,9 +1433,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state, { struct drm_plane *plane = plane_state->plane; struct drm_crtc_state *crtc_state; - /* Nothing to do for same crtc*/ - if (plane_state->crtc == crtc) - return 0; + if (plane_state->crtc) { crtc_state = drm_atomic_get_crtc_state(plane_state->state, plane_state->crtc); -- 2.11.0

6 years, 4 months

6
5
0 0

+ mm-shmem-correctly-annotate-new-inodes-for-lockdep.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: shmem.c: Correctly annotate new inodes for lockdep has been added to the -mm tree. Its filename is mm-shmem-correctly-annotate-new-inodes-for-lockdep.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-shmem-correctly-annotate-new-in… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-shmem-correctly-annotate-new-in… 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: "Joel Fernandes (Google)" <joel(a)joelfernandes.org> Subject: mm: shmem.c: Correctly annotate new inodes for lockdep Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class. This should fix a lockdep splat reported by syzbot: > ====================================================== > WARNING: possible circular locking dependency detected > 4.18.0-rc8-next-20180810+ #36 Not tainted > ------------------------------------------------------ > syz-executor900/4483 is trying to acquire lock: > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock > include/linux/fs.h:765 [inline] > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > > but task is already holding lock: > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 > drivers/staging/android/ashmem.c:448 > > which lock already depends on the new lock. > > -> #2 (ashmem_mutex){+.+.}: > __mutex_lock_common kernel/locking/mutex.c:925 [inline] > __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088 > ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361 > call_mmap include/linux/fs.h:1844 [inline] > mmap_region+0xf27/0x1c50 mm/mmap.c:1762 > do_mmap+0xa10/0x1220 mm/mmap.c:1535 > do_mmap_pgoff include/linux/mm.h:2298 [inline] > vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357 > ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585 > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #1 (&mm->mmap_sem){++++}: > __might_fault+0x155/0x1e0 mm/memory.c:4568 > _copy_to_user+0x30/0x110 lib/usercopy.c:25 > copy_to_user include/linux/uaccess.h:155 [inline] > filldir+0x1ea/0x3a0 fs/readdir.c:196 > dir_emit_dot include/linux/fs.h:3464 [inline] > dir_emit_dots include/linux/fs.h:3475 [inline] > dcache_readdir+0x13a/0x620 fs/libfs.c:193 > iterate_dir+0x48b/0x5d0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #0 (&sb->s_type->i_mutex_key#9){++++}: > lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 > down_write+0x8f/0x130 kernel/locking/rwsem.c:70 > inode_lock include/linux/fs.h:765 [inline] > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455 > ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > other info that might help us debug this: > > Chain exists of: > &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(ashmem_mutex); > lock(&mm->mmap_sem); > lock(ashmem_mutex); > lock(&sb->s_type->i_mutex_key#9); > > *** DEADLOCK *** > > 1 lock held by syz-executor900/4483: > #0: 0000000025208078 (ashmem_mutex){+.+.}, at: > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448 Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: NeilBrown <neilb(a)suse.com> Suggested-by: NeilBrown <neilb(a)suse.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/shmem.c~mm-shmem-correctly-annotate-new-inodes-for-lockdep +++ a/mm/shmem.c @@ -2227,6 +2227,8 @@ static struct inode *shmem_get_inode(str mpol_shared_policy_init(&info->policy, NULL); break; } + + lockdep_annotate_inode_mutex_key(inode); } else shmem_free_inode(sb); return inode; _ Patches currently in -mm which might be from joel(a)joelfernandes.org are mm-shmem-correctly-annotate-new-inodes-for-lockdep.patch

6 years, 4 months

1
0
0 0

more info

by info＠gmail.com

Good day, I have an interesting business offer for you which will be of immense benefit to you. Although this may be hard to believe and thought of as one of the numerous online scam but Please grant me the benefit of doubt and write me to know what this entails, am sure you wont regret it. You stand to gain 50% of $27,500,000.00 million USD from this. All conformable documents to back up the claims will be made available to you prior to your acceptance. Thanks, Diana Cesar.

6 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2018