Re: [PATCH 2/2] MIPS: SiByte: Enable swiotlb for SWARM and BigSur
Do we really need a new source file just to call swiotlb_init? And if we do that file should have a SPDX header these days. Otherwise looks fine: Reviewed-by: Christoph Hellwig
Re: [PATCH] leds: trigger: Fix sleeping function called from invalid context
Hi Baolin,
On Wed, Nov 7, 2018 at 6:43 AM Baolin Wang wrote:
> We will meet below issue due to mutex_lock() is called in interrupt context.
> The mutex lock is used to protect the pattern trigger data, but before
> changing
> new pattern trigger data (pattern values or repeat value) by users, we always
> cancel the timer firstly to clear previous patterns' performance. That means
> there is no race in pattern_trig_timer_function(), so we can drop the mutex
> lock in pattern_trig_timer_function() to avoid this issue.
>
> Moreover we can move the timer cancelling into mutex protection, since there
> is no deadlock risk if we remove the mutex lock in
> pattern_trig_timer_function().
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:254
> in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171
> Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (___might_sleep+0xf4/0x158)
> [] (___might_sleep) from [] (mutex_lock+0x18/0x60)
> [] (mutex_lock) from []
> (pattern_trig_timer_function+0x1c/0x11c)
> [] (pattern_trig_timer_function) from []
> (call_timer_fn+0x1c/0x90)
> [] (call_timer_fn) from [] (expire_timers+0x94/0xa4)
> [] (expire_timers) from [] (run_timer_softirq+0x108/0x15c)
> [] (run_timer_softirq) from [] (__do_softirq+0x1d4/0x258)
> [] (__do_softirq) from [] (irq_exit+0x64/0xc4)
> [] (irq_exit) from [] (__handle_domain_irq+0x80/0xb4)
> [] (__handle_domain_irq) from []
> (gic_handle_irq+0x58/0x90)
> [] (gic_handle_irq) from [] (__irq_svc+0x58/0x74)
> Exception stack(0xeb483f60 to 0xeb483fa8)
> 3f60: eb9afaa0 c0217e80 e000 c0e06408
> 3f80: 0002 c0e0647c c0c6a5f0 c0e04900 eb483fb0 c0207ea8 c0207e98
> 3fa0: 60020013
> [] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x38)
> [] (arch_cpu_idle) from [] (do_idle+0x138/0x268)
> [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
> [] (cpu_startup_entry) from [<402022ec>] (0x402022ec)
>
> Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger")
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Baolin Wang
Thanks!
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] MIPS: SiByte: Enable swiotlb for SWARM and BigSur
Do we really need a new source file just to call swiotlb_init? And if we do that file should have a SPDX header these days. Otherwise looks fine: Reviewed-by: Christoph Hellwig
Re: [PATCH] leds: trigger: Fix sleeping function called from invalid context
Hi Baolin,
On Wed, Nov 7, 2018 at 6:43 AM Baolin Wang wrote:
> We will meet below issue due to mutex_lock() is called in interrupt context.
> The mutex lock is used to protect the pattern trigger data, but before
> changing
> new pattern trigger data (pattern values or repeat value) by users, we always
> cancel the timer firstly to clear previous patterns' performance. That means
> there is no race in pattern_trig_timer_function(), so we can drop the mutex
> lock in pattern_trig_timer_function() to avoid this issue.
>
> Moreover we can move the timer cancelling into mutex protection, since there
> is no deadlock risk if we remove the mutex lock in
> pattern_trig_timer_function().
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:254
> in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171
> Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (___might_sleep+0xf4/0x158)
> [] (___might_sleep) from [] (mutex_lock+0x18/0x60)
> [] (mutex_lock) from []
> (pattern_trig_timer_function+0x1c/0x11c)
> [] (pattern_trig_timer_function) from []
> (call_timer_fn+0x1c/0x90)
> [] (call_timer_fn) from [] (expire_timers+0x94/0xa4)
> [] (expire_timers) from [] (run_timer_softirq+0x108/0x15c)
> [] (run_timer_softirq) from [] (__do_softirq+0x1d4/0x258)
> [] (__do_softirq) from [] (irq_exit+0x64/0xc4)
> [] (irq_exit) from [] (__handle_domain_irq+0x80/0xb4)
> [] (__handle_domain_irq) from []
> (gic_handle_irq+0x58/0x90)
> [] (gic_handle_irq) from [] (__irq_svc+0x58/0x74)
> Exception stack(0xeb483f60 to 0xeb483fa8)
> 3f60: eb9afaa0 c0217e80 e000 c0e06408
> 3f80: 0002 c0e0647c c0c6a5f0 c0e04900 eb483fb0 c0207ea8 c0207e98
> 3fa0: 60020013
> [] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x38)
> [] (arch_cpu_idle) from [] (do_idle+0x138/0x268)
> [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
> [] (cpu_startup_entry) from [<402022ec>] (0x402022ec)
>
> Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger")
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Baolin Wang
Thanks!
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] MIPS: SiByte: Set 32-bit bus mask for BCM1250 PCI
On Wed, Nov 07, 2018 at 12:08:23AM +, Maciej W. Rozycki wrote: > The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip > 32-bit PCI host bridge, and the two former SOCs also have an onchip HT > host bridge. The HT host bridge, where present, appears in the PCI > configuration space as if it was a device on the 32-bit PCI bus behind > the PCI host bridge, however at the hardware level its signals are > routed separately, so these two devices are actually peer host bridges. > > As documented[1] and observed in reality the 32-bit PCI host bridge does > not support 64-bit addressing as it does not support the Dual Address > Cycle (DAC) PCI command, and naturally, being 32-bit only, it has no > means to carry the high 32 address bits otherwise. However the DRAM > controller also included in the SOC supports memory amounts of up to > 16GiB, and due to how the address decoder has been wired in the SOC any > memory beyond 1GiB is actually mapped starting from 4GiB physical up, > that is beyond the 32-bit addressable limit. Consequently if the > maximum amount of memory has been installed, then it will span up to > 19GiB. > > Contrariwise, the HT host bridge does support full 40-bit addressing > defined by the HyperTransport (formerly LDT) specification the bridge > adheres to, depending on the peripherals revision of the SOC[2] either > revision 0.17[3] or revision 1.03[4]. This allows addressing any and > all memory installed, and well beyond. > > Set the bus mask then to limit DMA addressing to 32 bits for all the > devices down the 32-bit PCI host bridge, excluding however any devices > that are down the HT host bridge. > > References: > > [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, > Broadcom Corporation, 21 Oct 2002, Section 8: "PCI Bus and > HyperTransport Fabric", "Introduction", p. 190 > > [2] same, Table 140: "HyperTransport Configuration Header (Type 1)", p. > 245 > > [3] "Lightning Data Transport IO Specification", Revision 0.17, Advanced > Micro Devices, 21 Jan 2000, Section 3.2.1.2 "Command Packet", p. 8 > > [4] "HyperTransport I/O Link Specification", Revision 1.03, > HyperTransport Technology Consortium, 10 Oct 2001, Section 3.2.1.2 > "Request Packet", pp. 27-28 > > Signed-off-by: Maciej W. Rozycki > --- > Hi, > > This has been verified with a Broadcom SWARM board and an XHCI USB 32-bit > PCI option board plugged to one of the mainboard's 32-bit slots wired to > the PCI host bridge, and then a flash storage device plugged to adapter's > USB socket. > > With 2/2 applied first so that the bus mask is respected and a diagnostic > patch for `dma_direct_alloc' made to debug an earlier issue also applied > the system shows these messages upon boot: > > xhci_hcd :03:00.0: assign IRQ: got 56 > xhci_hcd :03:00.0: enabling bus mastering > xhci_hcd :03:00.0: xHCI Host Controller > xhci_hcd :03:00.0: new USB bus registered, assigned bus number 1 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b48000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b4c000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b54000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b58000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b5c000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b6 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b64000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b68000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b6c000 > xhci_hcd :03:00.0: hcc params 0x014051c7 hci version 0x100 quirks > 0x00010090 > xhci_hcd :03:00.0: enabling Mem-Wr-Inval > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: xHCI Host Controller > usb usb1: Manufacturer: Linux 4.19.0 xhci-hcd > usb usb1: SerialNumber: :03:00.0 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > xhci_hcd :03:00.0: xHCI Host Controller > xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2 > xhci_hcd :03:00.0: Host supports USB 3.0 SuperSpeed > xhci_hcd :03:00.0: Host took too long to start, waited 16000 microseconds. > xhci_hcd :03:00.0: startup error -19 > xhci_hcd :03:00.0: USB bus 2 deregistered > xhci_hcd
Re: [PATCH 1/2] MIPS: SiByte: Set 32-bit bus mask for BCM1250 PCI
On Wed, Nov 07, 2018 at 12:08:23AM +, Maciej W. Rozycki wrote: > The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip > 32-bit PCI host bridge, and the two former SOCs also have an onchip HT > host bridge. The HT host bridge, where present, appears in the PCI > configuration space as if it was a device on the 32-bit PCI bus behind > the PCI host bridge, however at the hardware level its signals are > routed separately, so these two devices are actually peer host bridges. > > As documented[1] and observed in reality the 32-bit PCI host bridge does > not support 64-bit addressing as it does not support the Dual Address > Cycle (DAC) PCI command, and naturally, being 32-bit only, it has no > means to carry the high 32 address bits otherwise. However the DRAM > controller also included in the SOC supports memory amounts of up to > 16GiB, and due to how the address decoder has been wired in the SOC any > memory beyond 1GiB is actually mapped starting from 4GiB physical up, > that is beyond the 32-bit addressable limit. Consequently if the > maximum amount of memory has been installed, then it will span up to > 19GiB. > > Contrariwise, the HT host bridge does support full 40-bit addressing > defined by the HyperTransport (formerly LDT) specification the bridge > adheres to, depending on the peripherals revision of the SOC[2] either > revision 0.17[3] or revision 1.03[4]. This allows addressing any and > all memory installed, and well beyond. > > Set the bus mask then to limit DMA addressing to 32 bits for all the > devices down the 32-bit PCI host bridge, excluding however any devices > that are down the HT host bridge. > > References: > > [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, > Broadcom Corporation, 21 Oct 2002, Section 8: "PCI Bus and > HyperTransport Fabric", "Introduction", p. 190 > > [2] same, Table 140: "HyperTransport Configuration Header (Type 1)", p. > 245 > > [3] "Lightning Data Transport IO Specification", Revision 0.17, Advanced > Micro Devices, 21 Jan 2000, Section 3.2.1.2 "Command Packet", p. 8 > > [4] "HyperTransport I/O Link Specification", Revision 1.03, > HyperTransport Technology Consortium, 10 Oct 2001, Section 3.2.1.2 > "Request Packet", pp. 27-28 > > Signed-off-by: Maciej W. Rozycki > --- > Hi, > > This has been verified with a Broadcom SWARM board and an XHCI USB 32-bit > PCI option board plugged to one of the mainboard's 32-bit slots wired to > the PCI host bridge, and then a flash storage device plugged to adapter's > USB socket. > > With 2/2 applied first so that the bus mask is respected and a diagnostic > patch for `dma_direct_alloc' made to debug an earlier issue also applied > the system shows these messages upon boot: > > xhci_hcd :03:00.0: assign IRQ: got 56 > xhci_hcd :03:00.0: enabling bus mastering > xhci_hcd :03:00.0: xHCI Host Controller > xhci_hcd :03:00.0: new USB bus registered, assigned bus number 1 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b48000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b4c000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b54000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b58000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b5c000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b6 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b64000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b68000 > xhci_hcd :03:00.0: dma_direct_alloc: coherent: 1 > xhci_hcd :03:00.0: dma_direct_alloc: returned: a80185b6c000 > xhci_hcd :03:00.0: hcc params 0x014051c7 hci version 0x100 quirks > 0x00010090 > xhci_hcd :03:00.0: enabling Mem-Wr-Inval > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: xHCI Host Controller > usb usb1: Manufacturer: Linux 4.19.0 xhci-hcd > usb usb1: SerialNumber: :03:00.0 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > xhci_hcd :03:00.0: xHCI Host Controller > xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2 > xhci_hcd :03:00.0: Host supports USB 3.0 SuperSpeed > xhci_hcd :03:00.0: Host took too long to start, waited 16000 microseconds. > xhci_hcd :03:00.0: startup error -19 > xhci_hcd :03:00.0: USB bus 2 deregistered > xhci_hcd
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed, 2018-11-07 at 08:35 +0100, Michal Hocko wrote: > On Wed 07-11-18 07:35:18, Balbir Singh wrote: > > The check seems to be quite aggressive and in a loop that iterates > > pages, but has nothing to do with the page, did you mean to make > > the check > > > > zone_idx(page_zone(page)) == ZONE_MOVABLE > > Does it make any difference? Can we actually encounter a page from a > different zone here? AFAIK, test_pages_in_a_zone() called from offline_pages() should ensure that the range belongs to a unique zone, so we should not encounter pages from other zones there, right? --- Oscar Suse L3
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed, 2018-11-07 at 08:35 +0100, Michal Hocko wrote: > On Wed 07-11-18 07:35:18, Balbir Singh wrote: > > The check seems to be quite aggressive and in a loop that iterates > > pages, but has nothing to do with the page, did you mean to make > > the check > > > > zone_idx(page_zone(page)) == ZONE_MOVABLE > > Does it make any difference? Can we actually encounter a page from a > different zone here? AFAIK, test_pages_in_a_zone() called from offline_pages() should ensure that the range belongs to a unique zone, so we should not encounter pages from other zones there, right? --- Oscar Suse L3
Re: general protection fault in __x86_indirect_thunk_rbx
syzbot has found a reproducer for the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=169e982540 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=83e12cf81d2c14842146 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bd944740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1121d82b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+83e12cf81d2c14842...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5670 Comm: syz-executor439 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:8801d89af2b0 EFLAGS: 00010293 RAX: 8801d49723c0 RBX: 894cdc00 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 8801d89af338 RBP: 8801d89af4a0 R08: 8801d49723c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d798da00 R13: 8801d89af338 R14: 11003b135e5b R15: dc00 FS: 01292880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20e2aff8 CR3: 0946a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1ad1/0x26d0 kernel/exit.c:867 do_group_exit+0x177/0x440 kernel/exit.c:970 __do_sys_exit_group kernel/exit.c:981 [inline] __se_sys_exit_group kernel/exit.c:979 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x43ec48 Code: Bad RIP value. RSP: 002b:7fff104a8308 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: RCX: 0043ec48 RDX: RSI: 003c RDI: RBP: 004be508 R08: 00e7 R09: ffd0 R10: R11: 0246 R12: 0001 R13: 006d0180 R14: R15: Modules linked in: ---[ end trace db9bef1a2174e463 ]--- RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:8801d89af2b0 EFLAGS: 00010293 RAX: 8801d49723c0 RBX: 894cdc00 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 8801d89af338 RBP: 8801d89af4a0 R08: 8801d49723c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d798da00 R13: 8801d89af338 R14: 11003b135e5b R15: dc00 FS: 01292880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0043ec1e CR3: 0946a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: general protection fault in __x86_indirect_thunk_rbx
syzbot has found a reproducer for the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=169e982540 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=83e12cf81d2c14842146 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bd944740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1121d82b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+83e12cf81d2c14842...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5670 Comm: syz-executor439 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:8801d89af2b0 EFLAGS: 00010293 RAX: 8801d49723c0 RBX: 894cdc00 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 8801d89af338 RBP: 8801d89af4a0 R08: 8801d49723c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d798da00 R13: 8801d89af338 R14: 11003b135e5b R15: dc00 FS: 01292880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20e2aff8 CR3: 0946a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1ad1/0x26d0 kernel/exit.c:867 do_group_exit+0x177/0x440 kernel/exit.c:970 __do_sys_exit_group kernel/exit.c:981 [inline] __se_sys_exit_group kernel/exit.c:979 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x43ec48 Code: Bad RIP value. RSP: 002b:7fff104a8308 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: RCX: 0043ec48 RDX: RSI: 003c RDI: RBP: 004be508 R08: 00e7 R09: ffd0 R10: R11: 0246 R12: 0001 R13: 006d0180 R14: R15: Modules linked in: ---[ end trace db9bef1a2174e463 ]--- RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:8801d89af2b0 EFLAGS: 00010293 RAX: 8801d49723c0 RBX: 894cdc00 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 8801d89af338 RBP: 8801d89af4a0 R08: 8801d49723c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d798da00 R13: 8801d89af338 R14: 11003b135e5b R15: dc00 FS: 01292880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0043ec1e CR3: 0946a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed 07-11-18 08:35:48, Michal Hocko wrote:
> On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> > On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > > allocated but its state is not fully populated yet. A debugging patch to
> > > dump the struct page state shows
> > > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > > : [ 476.592645] flags:
> > > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> > >
> > > Note that the state has been checked for both PageLRU and PageSwapBacked
> > > already. Closing this race completely would require some sort of retry
> > > logic. This can be tricky and error prone (think of potential endless
> > > or long taking loops).
> > >
> > > Workaround this problem for movable zones at least. Such a zone should
> > > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > > has_unmovable_pages more robust") has told us that this is not strictly
> > > true though. Bootmem pages should be marked reserved though so we can
> > > move the original check after the PageReserved check. Pages from other
> > > zones are still prone to races but we even do not pretend that memory
> > > hotremove works for those so pre-mature failure doesn't hurt that much.
> > >
> > > Reported-and-tested-by: Baoquan He
> > > Acked-by: Baoquan He
> > > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
> > > Signed-off-by: Michal Hocko
> > > ---
> > >
> > > Hi,
> > > this has been reported [1] and we have tried multiple things to address
> > > the issue. The only reliable way was to reintroduce the movable zone
> > > check into has_unmovable_pages. This time it should be safe also for
> > > the bug originally fixed by 15c30bc09085.
> > >
> > > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > > mm/page_alloc.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 863d46da6586..c6d900ee4982 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > > page *page, int count,
> > > if (PageReserved(page))
> > > goto unmovable;
> > >
> > > + /*
> > > + * If the zone is movable and we have ruled out all reserved
> > > + * pages then it should be reasonably safe to assume the rest
> > > + * is movable.
> > > + */
> > > + if (zone_idx(zone) == ZONE_MOVABLE)
> > > + continue;
> > > +
> > > /*
> >
> >
> > There is a WARN_ON() in case of failure at the end of the routine,
> > is that triggered when we hit the bug? If we're adding this patch,
> > the WARN_ON needs to go as well.
>
> No the warning should stay in case we encounter reserved pages in zone
> movable.
And to clarify. I am OK with changing the WARN to pr_warn if the warning
is considered harmful but we do want to note that something unexpected
is going on here.
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed 07-11-18 08:35:48, Michal Hocko wrote:
> On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> > On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > > allocated but its state is not fully populated yet. A debugging patch to
> > > dump the struct page state shows
> > > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > > : [ 476.592645] flags:
> > > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> > >
> > > Note that the state has been checked for both PageLRU and PageSwapBacked
> > > already. Closing this race completely would require some sort of retry
> > > logic. This can be tricky and error prone (think of potential endless
> > > or long taking loops).
> > >
> > > Workaround this problem for movable zones at least. Such a zone should
> > > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > > has_unmovable_pages more robust") has told us that this is not strictly
> > > true though. Bootmem pages should be marked reserved though so we can
> > > move the original check after the PageReserved check. Pages from other
> > > zones are still prone to races but we even do not pretend that memory
> > > hotremove works for those so pre-mature failure doesn't hurt that much.
> > >
> > > Reported-and-tested-by: Baoquan He
> > > Acked-by: Baoquan He
> > > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
> > > Signed-off-by: Michal Hocko
> > > ---
> > >
> > > Hi,
> > > this has been reported [1] and we have tried multiple things to address
> > > the issue. The only reliable way was to reintroduce the movable zone
> > > check into has_unmovable_pages. This time it should be safe also for
> > > the bug originally fixed by 15c30bc09085.
> > >
> > > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > > mm/page_alloc.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 863d46da6586..c6d900ee4982 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > > page *page, int count,
> > > if (PageReserved(page))
> > > goto unmovable;
> > >
> > > + /*
> > > + * If the zone is movable and we have ruled out all reserved
> > > + * pages then it should be reasonably safe to assume the rest
> > > + * is movable.
> > > + */
> > > + if (zone_idx(zone) == ZONE_MOVABLE)
> > > + continue;
> > > +
> > > /*
> >
> >
> > There is a WARN_ON() in case of failure at the end of the routine,
> > is that triggered when we hit the bug? If we're adding this patch,
> > the WARN_ON needs to go as well.
>
> No the warning should stay in case we encounter reserved pages in zone
> movable.
And to clarify. I am OK with changing the WARN to pr_warn if the warning
is considered harmful but we do want to note that something unexpected
is going on here.
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > allocated but its state is not fully populated yet. A debugging patch to
> > dump the struct page state shows
> > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > : [ 476.592645] flags:
> > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> >
> > Note that the state has been checked for both PageLRU and PageSwapBacked
> > already. Closing this race completely would require some sort of retry
> > logic. This can be tricky and error prone (think of potential endless
> > or long taking loops).
> >
> > Workaround this problem for movable zones at least. Such a zone should
> > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > has_unmovable_pages more robust") has told us that this is not strictly
> > true though. Bootmem pages should be marked reserved though so we can
> > move the original check after the PageReserved check. Pages from other
> > zones are still prone to races but we even do not pretend that memory
> > hotremove works for those so pre-mature failure doesn't hurt that much.
> >
> > Reported-and-tested-by: Baoquan He
> > Acked-by: Baoquan He
> > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
> > Signed-off-by: Michal Hocko
> > ---
> >
> > Hi,
> > this has been reported [1] and we have tried multiple things to address
> > the issue. The only reliable way was to reintroduce the movable zone
> > check into has_unmovable_pages. This time it should be safe also for
> > the bug originally fixed by 15c30bc09085.
> >
> > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > mm/page_alloc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 863d46da6586..c6d900ee4982 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > page *page, int count,
> > if (PageReserved(page))
> > goto unmovable;
> >
> > + /*
> > +* If the zone is movable and we have ruled out all reserved
> > +* pages then it should be reasonably safe to assume the rest
> > +* is movable.
> > +*/
> > + if (zone_idx(zone) == ZONE_MOVABLE)
> > + continue;
> > +
> > /*
>
>
> There is a WARN_ON() in case of failure at the end of the routine,
> is that triggered when we hit the bug? If we're adding this patch,
> the WARN_ON needs to go as well.
No the warning should stay in case we encounter reserved pages in zone
movable.
> The check seems to be quite aggressive and in a loop that iterates
> pages, but has nothing to do with the page, did you mean to make
> the check
>
> zone_idx(page_zone(page)) == ZONE_MOVABLE
Does it make any difference? Can we actually encounter a page from a
different zone here?
> it also skips all checks for pinned pages and other checks
Yes, this is intentional and the comment tries to explain why. I wish we
could be add a more specific checks for movable pages - e.g. detect long
term pins that would prevent migration - but we do not have any facility
for that. Please note that the worst case of a false positive is a
repeated migration failure and user has a way to break out of migration
by a signal.
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages
On Wed 07-11-18 07:35:18, Balbir Singh wrote:
> On Tue, Nov 06, 2018 at 10:55:24AM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Page state checks are racy. Under a heavy memory workload (e.g. stress
> > -m 200 -t 2h) it is quite easy to hit a race window when the page is
> > allocated but its state is not fully populated yet. A debugging patch to
> > dump the struct page state shows
> > : [ 476.575516] has_unmovable_pages: pfn:0x10dfec00, found:0x1, count:0x0
> > : [ 476.582103] page:ea0437fb count:1 mapcount:1
> > mapping:880e05239841 index:0x7f26e5000 compound_mapcount: 1
> > : [ 476.592645] flags:
> > 0x5fc0090034(uptodate|lru|active|head|swapbacked)
> >
> > Note that the state has been checked for both PageLRU and PageSwapBacked
> > already. Closing this race completely would require some sort of retry
> > logic. This can be tricky and error prone (think of potential endless
> > or long taking loops).
> >
> > Workaround this problem for movable zones at least. Such a zone should
> > only contain movable pages. 15c30bc09085 ("mm, memory_hotplug: make
> > has_unmovable_pages more robust") has told us that this is not strictly
> > true though. Bootmem pages should be marked reserved though so we can
> > move the original check after the PageReserved check. Pages from other
> > zones are still prone to races but we even do not pretend that memory
> > hotremove works for those so pre-mature failure doesn't hurt that much.
> >
> > Reported-and-tested-by: Baoquan He
> > Acked-by: Baoquan He
> > Fixes: "mm, memory_hotplug: make has_unmovable_pages more robust")
> > Signed-off-by: Michal Hocko
> > ---
> >
> > Hi,
> > this has been reported [1] and we have tried multiple things to address
> > the issue. The only reliable way was to reintroduce the movable zone
> > check into has_unmovable_pages. This time it should be safe also for
> > the bug originally fixed by 15c30bc09085.
> >
> > [1] http://lkml.kernel.org/r/20181101091055.GA15166@MiWiFi-R3L-srv
> > mm/page_alloc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 863d46da6586..c6d900ee4982 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7788,6 +7788,14 @@ bool has_unmovable_pages(struct zone *zone, struct
> > page *page, int count,
> > if (PageReserved(page))
> > goto unmovable;
> >
> > + /*
> > +* If the zone is movable and we have ruled out all reserved
> > +* pages then it should be reasonably safe to assume the rest
> > +* is movable.
> > +*/
> > + if (zone_idx(zone) == ZONE_MOVABLE)
> > + continue;
> > +
> > /*
>
>
> There is a WARN_ON() in case of failure at the end of the routine,
> is that triggered when we hit the bug? If we're adding this patch,
> the WARN_ON needs to go as well.
No the warning should stay in case we encounter reserved pages in zone
movable.
> The check seems to be quite aggressive and in a loop that iterates
> pages, but has nothing to do with the page, did you mean to make
> the check
>
> zone_idx(page_zone(page)) == ZONE_MOVABLE
Does it make any difference? Can we actually encounter a page from a
different zone here?
> it also skips all checks for pinned pages and other checks
Yes, this is intentional and the comment tries to explain why. I wish we
could be add a more specific checks for movable pages - e.g. detect long
term pins that would prevent migration - but we do not have any facility
for that. Please note that the worst case of a false positive is a
repeated migration failure and user has a way to break out of migration
by a signal.
--
Michal Hocko
SUSE Labs
Re: [PATCH next] mtd: maps: physmap: Fix infinite loop crash in ROM type probing
Hi Boris and Geert On Tue, Nov 6, 2018 at 11:34 PM Boris Brezillon wrote: > > On Tue, 6 Nov 2018 23:19:14 +0100 > Geert Uytterhoeven wrote: > > > Hi Boris, > > > > On Tue, Nov 6, 2018 at 10:58 PM Boris Brezillon > > wrote: > > > On Tue, 6 Nov 2018 22:44:16 +0100 > > > Geert Uytterhoeven wrote: > > > > On Toshiba RBTX4927, where map_probe is supposed to fail: > > > > > > > > Creating 2 MTD partitions on "physmap-flash.0": > > > > 0x00c0-0x0100 : "boot" > > > > 0x-0x00c0 : "user" > > > > physmap-flash physmap-flash.1: physmap platform flash device: [mem > > > > 0x1e00-0x1eff] > > > > CPU 0 Unable to handle kernel paging request at virtual address > > > > , epc == 80320f40, ra == 80321004 > > > > ... > > > > Call Trace: > > > > [<80320f40>] get_mtd_chip_driver+0x30/0x8c > > > > [<80321004>] do_map_probe+0x20/0x90 > > > > [<80328448>] physmap_flash_probe+0x484/0x4ec > > > > > > > > The access to rom_probe_types[] was changed from a sentinel-based loop > > > > to an infinite loop, causing a crash when reaching the sentinel. > > > > > > Oops. Do you mind if I fix that in-place (squash your changes in > > > Ricardo's original commit)? > > Done. > > > > > No problem. Thanks! > Thanks to both of you for fixing this . > Thanks for reporting/fixing the bug. > > Boris > -- Ricardo Ribalda
Re: [PATCH next] mtd: maps: physmap: Fix infinite loop crash in ROM type probing
Hi Boris and Geert On Tue, Nov 6, 2018 at 11:34 PM Boris Brezillon wrote: > > On Tue, 6 Nov 2018 23:19:14 +0100 > Geert Uytterhoeven wrote: > > > Hi Boris, > > > > On Tue, Nov 6, 2018 at 10:58 PM Boris Brezillon > > wrote: > > > On Tue, 6 Nov 2018 22:44:16 +0100 > > > Geert Uytterhoeven wrote: > > > > On Toshiba RBTX4927, where map_probe is supposed to fail: > > > > > > > > Creating 2 MTD partitions on "physmap-flash.0": > > > > 0x00c0-0x0100 : "boot" > > > > 0x-0x00c0 : "user" > > > > physmap-flash physmap-flash.1: physmap platform flash device: [mem > > > > 0x1e00-0x1eff] > > > > CPU 0 Unable to handle kernel paging request at virtual address > > > > , epc == 80320f40, ra == 80321004 > > > > ... > > > > Call Trace: > > > > [<80320f40>] get_mtd_chip_driver+0x30/0x8c > > > > [<80321004>] do_map_probe+0x20/0x90 > > > > [<80328448>] physmap_flash_probe+0x484/0x4ec > > > > > > > > The access to rom_probe_types[] was changed from a sentinel-based loop > > > > to an infinite loop, causing a crash when reaching the sentinel. > > > > > > Oops. Do you mind if I fix that in-place (squash your changes in > > > Ricardo's original commit)? > > Done. > > > > > No problem. Thanks! > Thanks to both of you for fixing this . > Thanks for reporting/fixing the bug. > > Boris > -- Ricardo Ribalda
[PATCH v2 1/2] PCI: Add HXT vendor ID and ACS quirk
Add the HXT vendor ID to pci_ids.h and use it in quirks. As the
design of HXT SD4800 ACS feature is the same as QCOM QDF2xxx,
pci_quirk_qcom_rp_acs() is reused for SD4800 quirk.
cc: Joey Zheng
Reviewed-by: Sinan Kaya
Signed-off-by: Shunyong Yang
---
v2:
Add Reviewed-by: Sinan Kaya.
v1:
Initial version.
---
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 4700d24e5d55..1e00ef6a88f4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4495,6 +4495,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev,
u16 acs_flags)
/* QCOM QDF2xxx root ports */
{ PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs },
{ PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
+ /* HXT SD4800 root ports. The ACS design is same as QCOM QDF2xxx */
+ { PCI_VENDOR_ID_HXT, 0x0401, pci_quirk_qcom_rp_acs },
/* Intel PCH root ports */
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_spt_pch_acs },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 69f0abe1ba1a..e60a6bc38298 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2565,6 +2565,8 @@
#define PCI_VENDOR_ID_HYGON0x1d94
+#define PCI_VENDOR_ID_HXT 0x1dbf
+
#define PCI_VENDOR_ID_TEKRAM 0x1de1
#define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
--
1.8.3.1
[PATCH v2 1/2] PCI: Add HXT vendor ID and ACS quirk
Add the HXT vendor ID to pci_ids.h and use it in quirks. As the
design of HXT SD4800 ACS feature is the same as QCOM QDF2xxx,
pci_quirk_qcom_rp_acs() is reused for SD4800 quirk.
cc: Joey Zheng
Reviewed-by: Sinan Kaya
Signed-off-by: Shunyong Yang
---
v2:
Add Reviewed-by: Sinan Kaya.
v1:
Initial version.
---
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 4700d24e5d55..1e00ef6a88f4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4495,6 +4495,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev,
u16 acs_flags)
/* QCOM QDF2xxx root ports */
{ PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs },
{ PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
+ /* HXT SD4800 root ports. The ACS design is same as QCOM QDF2xxx */
+ { PCI_VENDOR_ID_HXT, 0x0401, pci_quirk_qcom_rp_acs },
/* Intel PCH root ports */
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_spt_pch_acs },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 69f0abe1ba1a..e60a6bc38298 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2565,6 +2565,8 @@
#define PCI_VENDOR_ID_HYGON0x1d94
+#define PCI_VENDOR_ID_HXT 0x1dbf
+
#define PCI_VENDOR_ID_TEKRAM 0x1de1
#define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
--
1.8.3.1
[PATCH v2 2/2] PCI: pciehp: Add HXT quirk for Command Completed errata
The HXT SD4800 PCI controller does not set the Command Completed bit unless writes to the Slot Command register change "Control" bits. This patch adds SD4800 to the quirk. Cc: Joey Zheng Signed-off-by: Shunyong Yang diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 7dd443aea5a5..91db67963aea 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -920,3 +920,5 @@ static void quirk_cmd_compl(struct pci_dev *pdev) PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_QCOM, 0x0401, PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_HXT, 0x0401, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); -- 1.8.3.1
[PATCH v2 2/2] PCI: pciehp: Add HXT quirk for Command Completed errata
The HXT SD4800 PCI controller does not set the Command Completed bit unless writes to the Slot Command register change "Control" bits. This patch adds SD4800 to the quirk. Cc: Joey Zheng Signed-off-by: Shunyong Yang diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 7dd443aea5a5..91db67963aea 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -920,3 +920,5 @@ static void quirk_cmd_compl(struct pci_dev *pdev) PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_QCOM, 0x0401, PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_HXT, 0x0401, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); -- 1.8.3.1
Re: [PATCH 06/24] leds: sc27xx-blt: Use led_compose_name()
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Switch to using generic LED support for composing LED class
> device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Xiaotong Lu
> Cc: Baolin Wang
Thanks for simplifying the code, it can work well for SC27XX LED.
Tested-by: Baolin Wang
> ---
> drivers/leds/leds-sc27xx-bltc.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
> index 9d9b7aa..9fe7cb1 100644
> --- a/drivers/leds/leds-sc27xx-bltc.c
> +++ b/drivers/leds/leds-sc27xx-bltc.c
> @@ -6,7 +6,6 @@
> #include
> #include
> #include
> -#include
>
> /* PMIC global control register definition */
> #define SC27XX_MODULE_EN0 0xc08
> @@ -36,7 +35,7 @@
> #define SC27XX_LEDS_MAX3
>
> struct sc27xx_led {
> - char name[LED_MAX_NAME_SIZE];
> + struct fwnode_handle *fwnode;
> struct led_classdev ldev;
> struct sc27xx_led_priv *priv;
> u8 line;
> @@ -132,16 +131,22 @@ static int sc27xx_led_register(struct device *dev,
> struct sc27xx_led_priv *priv)
>
> for (i = 0; i < SC27XX_LEDS_MAX; i++) {
> struct sc27xx_led *led = >leds[i];
> + struct led_init_data init_data = { led->fwnode };
>
> if (!led->active)
> continue;
>
> + err = led_compose_name(led->fwnode, "sc27xx", ":",
> + init_data.name);
> + if (err)
> + return err;
> +
> led->line = i;
> led->priv = priv;
> - led->ldev.name = led->name;
> led->ldev.brightness_set_blocking = sc27xx_led_set;
>
> - err = devm_led_classdev_register(dev, >ldev);
> + err = devm_led_classdev_register_ext(dev, >ldev,
> +_data);
> if (err)
> return err;
> }
> @@ -154,7 +159,6 @@ static int sc27xx_led_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct device_node *np = dev->of_node, *child;
> struct sc27xx_led_priv *priv;
> - const char *str;
> u32 base, count, reg;
> int err;
>
> @@ -196,15 +200,8 @@ static int sc27xx_led_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + priv->leds[reg].fwnode = of_fwnode_handle(child);
> priv->leds[reg].active = true;
> -
> - err = of_property_read_string(child, "label", );
> - if (err)
> - snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> -"sc27xx::");
> - else
> - snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> -"sc27xx:%s", str);
> }
>
> err = sc27xx_led_register(dev, priv);
> --
> 2.1.4
>
--
Baolin Wang
Best Regards
Re: [PATCH 06/24] leds: sc27xx-blt: Use led_compose_name()
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Switch to using generic LED support for composing LED class
> device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Xiaotong Lu
> Cc: Baolin Wang
Thanks for simplifying the code, it can work well for SC27XX LED.
Tested-by: Baolin Wang
> ---
> drivers/leds/leds-sc27xx-bltc.c | 23 ++-
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
> index 9d9b7aa..9fe7cb1 100644
> --- a/drivers/leds/leds-sc27xx-bltc.c
> +++ b/drivers/leds/leds-sc27xx-bltc.c
> @@ -6,7 +6,6 @@
> #include
> #include
> #include
> -#include
>
> /* PMIC global control register definition */
> #define SC27XX_MODULE_EN0 0xc08
> @@ -36,7 +35,7 @@
> #define SC27XX_LEDS_MAX3
>
> struct sc27xx_led {
> - char name[LED_MAX_NAME_SIZE];
> + struct fwnode_handle *fwnode;
> struct led_classdev ldev;
> struct sc27xx_led_priv *priv;
> u8 line;
> @@ -132,16 +131,22 @@ static int sc27xx_led_register(struct device *dev,
> struct sc27xx_led_priv *priv)
>
> for (i = 0; i < SC27XX_LEDS_MAX; i++) {
> struct sc27xx_led *led = >leds[i];
> + struct led_init_data init_data = { led->fwnode };
>
> if (!led->active)
> continue;
>
> + err = led_compose_name(led->fwnode, "sc27xx", ":",
> + init_data.name);
> + if (err)
> + return err;
> +
> led->line = i;
> led->priv = priv;
> - led->ldev.name = led->name;
> led->ldev.brightness_set_blocking = sc27xx_led_set;
>
> - err = devm_led_classdev_register(dev, >ldev);
> + err = devm_led_classdev_register_ext(dev, >ldev,
> +_data);
> if (err)
> return err;
> }
> @@ -154,7 +159,6 @@ static int sc27xx_led_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct device_node *np = dev->of_node, *child;
> struct sc27xx_led_priv *priv;
> - const char *str;
> u32 base, count, reg;
> int err;
>
> @@ -196,15 +200,8 @@ static int sc27xx_led_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + priv->leds[reg].fwnode = of_fwnode_handle(child);
> priv->leds[reg].active = true;
> -
> - err = of_property_read_string(child, "label", );
> - if (err)
> - snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> -"sc27xx::");
> - else
> - snprintf(priv->leds[reg].name, LED_MAX_NAME_SIZE,
> -"sc27xx:%s", str);
> }
>
> err = sc27xx_led_register(dev, priv);
> --
> 2.1.4
>
--
Baolin Wang
Best Regards
Re: [PATCH 02/24] leds: core: Add support for composing LED class device names
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Add public led_compose_name() API for composing LED class device
> name basing on fwnode_handle data. The function composes device name
> according to either a new pattern or the legacy
> pattern. The decision on using the
> particular pattern is made basing on whether fwnode contains new
> "function" and "color" properties, or the legacy "label" proeprty.
>
> Backwards compatibility with in-driver hard-coded LED class device
> names is assured thanks to the default_desc argument.
>
> In case none of the aformentioned properties was found, then, for OF
> nodes, the node name is adopted for LED class device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc: Linus Walleij
> Cc: Oleh Kravchenko
> Cc: Sakari Ailus
> Cc: Simon Shields
> Cc: Xiaotong Lu
> ---
> Documentation/leds/leds-class.txt | 2 +-
> drivers/leds/led-core.c | 71
> +++
> include/linux/leds.h | 32 ++
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/leds/leds-class.txt
> b/Documentation/leds/leds-class.txt
> index 836cb16..e9009c4 100644
> --- a/Documentation/leds/leds-class.txt
> +++ b/Documentation/leds/leds-class.txt
> @@ -43,7 +43,7 @@ LED Device Naming
>
> Is currently of the form:
>
> -"devicename:colour:function"
> +"colour:function"
>
> There have been calls for LED properties such as colour to be exported as
> individual led class attributes. As a solution which doesn't incur as much
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index ede4fa0..f7371fc 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include "leds.h"
>
> @@ -327,3 +329,72 @@ void led_sysfs_enable(struct led_classdev *led_cdev)
> led_cdev->flags &= ~LED_SYSFS_DISABLE;
> }
> EXPORT_SYMBOL_GPL(led_sysfs_enable);
> +
> +static void led_parse_properties(struct fwnode_handle *fwnode,
> +struct led_properties *props)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return;
> +
> + ret = fwnode_property_read_string(fwnode, "label", >label);
> + if (!ret)
> + return;
> +
> + ret = fwnode_property_read_string(fwnode, "function",
> >function);
> + if (ret)
> + pr_info("Failed to parse function property\n");
> +
> + ret = fwnode_property_read_string(fwnode, "color", >color);
> + if (ret)
> + pr_info("Failed to parse color property\n");
Now the color and function properties can be optional, so we should
deal with different return errors.
-EINVAL means we have not set color or function property, which means
we should not give failure message for users (maybe "not supply color
property\n") and return 0 as success.
For other errors, we should not ignore them, instead we should give
failure messages and return errors.
Tested-by: Baolin Wang
> +}
> +
> +int led_compose_name(struct fwnode_handle *fwnode, const char *led_hw_name,
> +const char *default_desc, char *led_classdev_name)
> +{
> + struct led_properties props = {};
> +
> + if (!led_classdev_name)
> + return -EINVAL;
> +
> + led_parse_properties(fwnode, );
> +
> + if (props.label) {
> + /*
> +* Presence of 'label' DT property implies legacy LED name,
> +* formatted as , with possible
> +* section omission if doesn't apply to given device.
> +*
> +* If no led_hw_name has been passed, then it indicates that
> +* DT label should be used as-is for LED class device name.
> +* Otherwise the label is prepended with led_hw_name to
> compose
> +* the final LED class device name.
> +*/
> + if (!led_hw_name) {
> + strncpy(led_classdev_name, props.label,
> + LED_MAX_NAME_SIZE);
> + } else {
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE,
> "%s:%s",
> +led_hw_name, props.label);
> + }
> + } else if (props.function || props.color) {
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s:%s",
> +props.color ?: "", props.function ?: "");
> + } else if (default_desc) {
> + if (!led_hw_name) {
> + pr_err("Legacy LED naming requires devicename
> segment");
> + return -EINVAL;
> + }
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s:%s",
> +led_hw_name, default_desc);
> + } else if
Re: [PATCH 02/24] leds: core: Add support for composing LED class device names
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Add public led_compose_name() API for composing LED class device
> name basing on fwnode_handle data. The function composes device name
> according to either a new pattern or the legacy
> pattern. The decision on using the
> particular pattern is made basing on whether fwnode contains new
> "function" and "color" properties, or the legacy "label" proeprty.
>
> Backwards compatibility with in-driver hard-coded LED class device
> names is assured thanks to the default_desc argument.
>
> In case none of the aformentioned properties was found, then, for OF
> nodes, the node name is adopted for LED class device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc: Linus Walleij
> Cc: Oleh Kravchenko
> Cc: Sakari Ailus
> Cc: Simon Shields
> Cc: Xiaotong Lu
> ---
> Documentation/leds/leds-class.txt | 2 +-
> drivers/leds/led-core.c | 71
> +++
> include/linux/leds.h | 32 ++
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/leds/leds-class.txt
> b/Documentation/leds/leds-class.txt
> index 836cb16..e9009c4 100644
> --- a/Documentation/leds/leds-class.txt
> +++ b/Documentation/leds/leds-class.txt
> @@ -43,7 +43,7 @@ LED Device Naming
>
> Is currently of the form:
>
> -"devicename:colour:function"
> +"colour:function"
>
> There have been calls for LED properties such as colour to be exported as
> individual led class attributes. As a solution which doesn't incur as much
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index ede4fa0..f7371fc 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include "leds.h"
>
> @@ -327,3 +329,72 @@ void led_sysfs_enable(struct led_classdev *led_cdev)
> led_cdev->flags &= ~LED_SYSFS_DISABLE;
> }
> EXPORT_SYMBOL_GPL(led_sysfs_enable);
> +
> +static void led_parse_properties(struct fwnode_handle *fwnode,
> +struct led_properties *props)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return;
> +
> + ret = fwnode_property_read_string(fwnode, "label", >label);
> + if (!ret)
> + return;
> +
> + ret = fwnode_property_read_string(fwnode, "function",
> >function);
> + if (ret)
> + pr_info("Failed to parse function property\n");
> +
> + ret = fwnode_property_read_string(fwnode, "color", >color);
> + if (ret)
> + pr_info("Failed to parse color property\n");
Now the color and function properties can be optional, so we should
deal with different return errors.
-EINVAL means we have not set color or function property, which means
we should not give failure message for users (maybe "not supply color
property\n") and return 0 as success.
For other errors, we should not ignore them, instead we should give
failure messages and return errors.
Tested-by: Baolin Wang
> +}
> +
> +int led_compose_name(struct fwnode_handle *fwnode, const char *led_hw_name,
> +const char *default_desc, char *led_classdev_name)
> +{
> + struct led_properties props = {};
> +
> + if (!led_classdev_name)
> + return -EINVAL;
> +
> + led_parse_properties(fwnode, );
> +
> + if (props.label) {
> + /*
> +* Presence of 'label' DT property implies legacy LED name,
> +* formatted as , with possible
> +* section omission if doesn't apply to given device.
> +*
> +* If no led_hw_name has been passed, then it indicates that
> +* DT label should be used as-is for LED class device name.
> +* Otherwise the label is prepended with led_hw_name to
> compose
> +* the final LED class device name.
> +*/
> + if (!led_hw_name) {
> + strncpy(led_classdev_name, props.label,
> + LED_MAX_NAME_SIZE);
> + } else {
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE,
> "%s:%s",
> +led_hw_name, props.label);
> + }
> + } else if (props.function || props.color) {
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s:%s",
> +props.color ?: "", props.function ?: "");
> + } else if (default_desc) {
> + if (!led_hw_name) {
> + pr_err("Legacy LED naming requires devicename
> segment");
> + return -EINVAL;
> + }
> + snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s:%s",
> +led_hw_name, default_desc);
> + } else if
[PATCH] cpuset: remove set but not used variable 'cs'
This fixes the following warning:
kernel/cgroup/cpuset.c: In function ‘cpuset_cancel_attach’:
kernel/cgroup/cpuset.c:1501:17: warning: variable ‘cs’ set but not used
[-Wunused-but-set-variable]
struct cpuset *cs;
^
Signed-off-by: Yi Wang
---
kernel/cgroup/cpuset.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 266f10c..784f948 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1498,10 +1498,8 @@ static int cpuset_can_attach(struct cgroup_taskset *tset)
static void cpuset_cancel_attach(struct cgroup_taskset *tset)
{
struct cgroup_subsys_state *css;
- struct cpuset *cs;
cgroup_taskset_first(tset, );
- cs = css_cs(css);
mutex_lock(_mutex);
css_cs(css)->attach_in_progress--;
--
1.8.3.1
[PATCH] cpuset: remove set but not used variable 'cs'
This fixes the following warning:
kernel/cgroup/cpuset.c: In function ‘cpuset_cancel_attach’:
kernel/cgroup/cpuset.c:1501:17: warning: variable ‘cs’ set but not used
[-Wunused-but-set-variable]
struct cpuset *cs;
^
Signed-off-by: Yi Wang
---
kernel/cgroup/cpuset.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 266f10c..784f948 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -1498,10 +1498,8 @@ static int cpuset_can_attach(struct cgroup_taskset *tset)
static void cpuset_cancel_attach(struct cgroup_taskset *tset)
{
struct cgroup_subsys_state *css;
- struct cpuset *cs;
cgroup_taskset_first(tset, );
- cs = css_cs(css);
mutex_lock(_mutex);
css_cs(css)->attach_in_progress--;
--
1.8.3.1
[PATCH] arm64: fix commit style in the comments
Use git commit description style 'commit <12+ chars of sha1>
("")' in the comments.
Signed-off-by: Peng Hao
---
arch/arm64/kernel/sys32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index 0f8bcb7..8317a5a 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -40,8 +40,8 @@
* arbitrary binaries may rely upon it, so we must do the same.
* For more details, see commit:
*
-* 713c481519f19df9 ("[ARM] 3108/2: old ABI compat: statfs64 and
-* fstatfs64")
+* commit 713c481519f19df9 ("[ARM] 3108/2: old ABI compat: statfs64
+* and fstatfs64")
*/
if (sz == 88)
sz = 84;
--
1.8.3.1
[PATCH] arm64: fix commit style in the comments
Use git commit description style 'commit <12+ chars of sha1>
("")' in the comments.
Signed-off-by: Peng Hao
---
arch/arm64/kernel/sys32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index 0f8bcb7..8317a5a 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -40,8 +40,8 @@
* arbitrary binaries may rely upon it, so we must do the same.
* For more details, see commit:
*
-* 713c481519f19df9 ("[ARM] 3108/2: old ABI compat: statfs64 and
-* fstatfs64")
+* commit 713c481519f19df9 ("[ARM] 3108/2: old ABI compat: statfs64
+* and fstatfs64")
*/
if (sz == 88)
sz = 84;
--
1.8.3.1
[PATCH] dt-bindings: watchdog: update bindings for MT7629 SoC
This updates dt-binding documentation for MT7629 SoC Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 859dee1..8682d6a 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -8,6 +8,7 @@ Required properties: "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 - reg : Specifies base physical address and size of the registers. -- 1.9.1
[PATCH] dt-bindings: rng: update bindings for MT7629 SoC
This updates bindings for MT7629 RNG driver. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt index 366b99b..ffa6a66 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt @@ -1,9 +1,10 @@ Device-Tree bindings for Mediatek random number generator -found in Mediatek SoC family +found in MediaTek SoC family Required properties: - compatible : Should be "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 + "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 "mediatek,mt7623-rng" : for MT7623 - clocks : list of clock specifiers, corresponding to entries in clock-names property; -- 1.9.1
[PATCH] dt-bindings: watchdog: update bindings for MT7629 SoC
This updates dt-binding documentation for MT7629 SoC Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 859dee1..8682d6a 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -8,6 +8,7 @@ Required properties: "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 - reg : Specifies base physical address and size of the registers. -- 1.9.1
[PATCH] dt-bindings: rng: update bindings for MT7629 SoC
This updates bindings for MT7629 RNG driver. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt index 366b99b..ffa6a66 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt @@ -1,9 +1,10 @@ Device-Tree bindings for Mediatek random number generator -found in Mediatek SoC family +found in MediaTek SoC family Required properties: - compatible : Should be "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 + "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 "mediatek,mt7623-rng" : for MT7623 - clocks : list of clock specifiers, corresponding to entries in clock-names property; -- 1.9.1
Re: [PATCH 1/2] nds32: Fix the missing "fpu_dp" message.
Hi Nylon,
Nylon Chen 於 2018年11月7日 週三 下午1:32寫道：
>
> The "fpu_dp" should be added to hwcap_str table to make sure the cpu features
> displayed correctly.
>
> Signed-off-by: Nylon Chen
> ---
> arch/nds32/kernel/setup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
> index eacc79024879..e39274a21481 100644
> --- a/arch/nds32/kernel/setup.c
> +++ b/arch/nds32/kernel/setup.c
> @@ -71,6 +71,7 @@ static const char *hwcap_str[] = {
> "mac",
> "l2c",
> "dx_regs",
> + "fpu_dp",
> "v2",
> NULL,
> };
Thank you for providing this patch however I just found the order of
dx_regs and v2 is not match to HWCAP_V2
and HWCAP_DX_REGS.
Would you please based on next branch in
https://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git to
re-gen the patch and send again? Thank you. :)
Re: [PATCH 1/2] nds32: Fix the missing "fpu_dp" message.
Hi Nylon,
Nylon Chen 於 2018年11月7日 週三 下午1:32寫道：
>
> The "fpu_dp" should be added to hwcap_str table to make sure the cpu features
> displayed correctly.
>
> Signed-off-by: Nylon Chen
> ---
> arch/nds32/kernel/setup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
> index eacc79024879..e39274a21481 100644
> --- a/arch/nds32/kernel/setup.c
> +++ b/arch/nds32/kernel/setup.c
> @@ -71,6 +71,7 @@ static const char *hwcap_str[] = {
> "mac",
> "l2c",
> "dx_regs",
> + "fpu_dp",
> "v2",
> NULL,
> };
Thank you for providing this patch however I just found the order of
dx_regs and v2 is not match to HWCAP_V2
and HWCAP_DX_REGS.
Would you please based on next branch in
https://git.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git to
re-gen the patch and send again? Thank you. :)
Re: [PATCH v1 0/4]mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
On 06.11.2018 11:43, Arun KS wrote: On 2018-11-06 14:07, Konstantin Khlebnikov wrote: On 06.11.2018 11:30, Arun KS wrote: On 2018-11-06 13:47, Konstantin Khlebnikov wrote: On 06.11.2018 8:38, Arun KS wrote: Any comments? Looks good. Except unclear motivation behind this change. This should be in comment of one of patch. totalram_pages, zone->managed_pages and totalhigh_pages are sometimes modified outside managed_page_count_lock. Hence convert these variable to atomic to avoid readers potentially seeing a store tear. So, this is just theoretical issue or splat from sanitizer. After boot memory online\offline are strictly serialized by rw-semaphore. Few instances which can race with hot add. Please see below, https://patchwork.kernel.org/patch/10627521/ Could you point what exactly are you fixing with this set? from v2: > totalram_pages, zone->managed_pages and totalhigh_pages updates > are protected by managed_page_count_lock, but readers never care > about it. Convert these variables to atomic to avoid readers > potentially seeing a store tear. This? Aligned unsigned long almost always stored at once. To make it completely correct you could replace a += b; with WRITE_ONCE(a, a + b); Regards, Arun Will update the comment. Regards, Arun Reviewed-by: Konstantin Khlebnikov Regards, Arun On 2018-10-26 16:30, Arun KS wrote: This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The patch was comiple tested on x86(x86_64_defconfig & i386_defconfig) on tip of linux-mmotm. And memory hotplug tested on arm64, but on an older version of kernel. Arun KS (4): mm: Fix multiple evaluvations of totalram_pages and managed_pages mm: Convert zone->managed_pages to atomic variable mm: convert totalram_pages and totalhigh_pages variables to atomic mm: Remove managed_page_count spinlock arch/csky/mm/init.c | 4 +- arch/powerpc/platforms/pseries/cmm.c | 10 ++-- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 3 +- arch/x86/kernel/cpu/microcode/core.c | 5 +- drivers/char/agp/backend.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/hv/hv_balloon.c | 19 +++ drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c | 2 +- drivers/parisc/ccio-dma.c | 4 +- drivers/parisc/sba_iommu.c | 4 +- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +-- fs/ceph/super.h | 2 +- fs/file_table.c | 7 +-- fs/fuse/inode.c | 2 +- fs/nfs/write.c | 2 +- fs/nfsd/nfscache.c | 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c | 2 +- include/linux/highmem.h | 28 ++- include/linux/mm.h | 27 +- include/linux/mmzone.h | 15 +++--- include/linux/swap.h | 1 - kernel/fork.c | 5 +- kernel/kexec_core.c | 5 +- kernel/power/snapshot.c | 2 +- lib/show_mem.c | 2 +- mm/highmem.c | 4 +- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 6 +-- mm/memory_hotplug.c | 4 +- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 71 +-- mm/shmem.c | 7 +-- mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 +- mm/vmstat.c | 4 +- mm/workingset.c | 2 +- mm/zswap.c | 4 +- net/dccp/proto.c | 7 +-- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c | 2 +- net/netfilter/nf_conntrack_core.c | 7 +--
Re: [PATCH v1 0/4]mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
On 06.11.2018 11:43, Arun KS wrote: On 2018-11-06 14:07, Konstantin Khlebnikov wrote: On 06.11.2018 11:30, Arun KS wrote: On 2018-11-06 13:47, Konstantin Khlebnikov wrote: On 06.11.2018 8:38, Arun KS wrote: Any comments? Looks good. Except unclear motivation behind this change. This should be in comment of one of patch. totalram_pages, zone->managed_pages and totalhigh_pages are sometimes modified outside managed_page_count_lock. Hence convert these variable to atomic to avoid readers potentially seeing a store tear. So, this is just theoretical issue or splat from sanitizer. After boot memory online\offline are strictly serialized by rw-semaphore. Few instances which can race with hot add. Please see below, https://patchwork.kernel.org/patch/10627521/ Could you point what exactly are you fixing with this set? from v2: > totalram_pages, zone->managed_pages and totalhigh_pages updates > are protected by managed_page_count_lock, but readers never care > about it. Convert these variables to atomic to avoid readers > potentially seeing a store tear. This? Aligned unsigned long almost always stored at once. To make it completely correct you could replace a += b; with WRITE_ONCE(a, a + b); Regards, Arun Will update the comment. Regards, Arun Reviewed-by: Konstantin Khlebnikov Regards, Arun On 2018-10-26 16:30, Arun KS wrote: This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The patch was comiple tested on x86(x86_64_defconfig & i386_defconfig) on tip of linux-mmotm. And memory hotplug tested on arm64, but on an older version of kernel. Arun KS (4): mm: Fix multiple evaluvations of totalram_pages and managed_pages mm: Convert zone->managed_pages to atomic variable mm: convert totalram_pages and totalhigh_pages variables to atomic mm: Remove managed_page_count spinlock arch/csky/mm/init.c | 4 +- arch/powerpc/platforms/pseries/cmm.c | 10 ++-- arch/s390/mm/init.c | 2 +- arch/um/kernel/mem.c | 3 +- arch/x86/kernel/cpu/microcode/core.c | 5 +- drivers/char/agp/backend.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/hv/hv_balloon.c | 19 +++ drivers/md/dm-bufio.c | 2 +- drivers/md/dm-crypt.c | 2 +- drivers/md/dm-integrity.c | 2 +- drivers/md/dm-stats.c | 2 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +- drivers/misc/vmw_balloon.c | 2 +- drivers/parisc/ccio-dma.c | 4 +- drivers/parisc/sba_iommu.c | 4 +- drivers/staging/android/ion/ion_system_heap.c | 2 +- drivers/xen/xen-selfballoon.c | 6 +-- fs/ceph/super.h | 2 +- fs/file_table.c | 7 +-- fs/fuse/inode.c | 2 +- fs/nfs/write.c | 2 +- fs/nfsd/nfscache.c | 2 +- fs/ntfs/malloc.h | 2 +- fs/proc/base.c | 2 +- include/linux/highmem.h | 28 ++- include/linux/mm.h | 27 +- include/linux/mmzone.h | 15 +++--- include/linux/swap.h | 1 - kernel/fork.c | 5 +- kernel/kexec_core.c | 5 +- kernel/power/snapshot.c | 2 +- lib/show_mem.c | 2 +- mm/highmem.c | 4 +- mm/huge_memory.c | 2 +- mm/kasan/quarantine.c | 2 +- mm/memblock.c | 6 +-- mm/memory_hotplug.c | 4 +- mm/mm_init.c | 2 +- mm/oom_kill.c | 2 +- mm/page_alloc.c | 71 +-- mm/shmem.c | 7 +-- mm/slab.c | 2 +- mm/swap.c | 2 +- mm/util.c | 2 +- mm/vmalloc.c | 4 +- mm/vmstat.c | 4 +- mm/workingset.c | 2 +- mm/zswap.c | 4 +- net/dccp/proto.c | 7 +-- net/decnet/dn_route.c | 2 +- net/ipv4/tcp_metrics.c | 2 +- net/netfilter/nf_conntrack_core.c | 7 +--
Re: [PATCH 01/24] leds: class: Improve LED and LED flash class registration API
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Replace of_led_classdev_register() with led_classdev_register_ext(), which
> accepts easily extendable struct led_init_data, instead of the fixed
> struct device_node argument. The latter can be now passed in a fwnode
> property of the struct led_init_data.
>
> The modification is driven by the need for passing another argument
> to the LED class initialization function - a LED class device name.
> Currently it is conveyed in the "name" char pointer property of
> struct led_classdev, which is semantically and functionally incorrect
> since it is needed only on LED class device registration, but persists
> in system memory throughout the whole LED class device lifetime.
>
> Whereas in case of the name strings coming from DT "label" property or
> statically initialized ones the cost is only the pointer size, it grows
> to LED_MAX_NAME_SIZE (64) with the advent of a new LED class device naming
> scheme, where color and function properties come from separate board
> firmware properties and the name needs to be constructed in a new buffer.
>
> The change will not break any existing clients since the patch alters
> also existing led_classdev{_flash}_register() macro wrappers, that pass
> NULL in place of init_data, which leads to using legacy name
> initialization path basing on the struct led_classdev's "name" property.
>
> Two existing users of devm_of_led_classdev_registers() are modified
> to use devm_led_classdev_register(), which will not impact their
> operation since they in fact didn't need to pass struct device_node on
> registration from the beginning.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc: Linus Walleij
> Cc: Oleh Kravchenko
> Cc: Sakari Ailus
> Cc: Simon Shields
> Cc: Xiaotong Lu
> ---
> drivers/leds/led-class-flash.c | 9 +
> drivers/leds/led-class.c| 34 ++
> drivers/leds/leds-cr0014114.c | 3 +--
> drivers/leds/leds-gpio.c| 2 +-
> include/linux/led-class-flash.h | 13 +
> include/linux/leds.h| 29 +++--
> 6 files changed, 57 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
> index cf39827..8d1c117 100644
> --- a/drivers/leds/led-class-flash.c
> +++ b/drivers/leds/led-class-flash.c
> @@ -285,8 +285,9 @@ static void led_flash_init_sysfs_groups(struct
> led_classdev_flash *fled_cdev)
> led_cdev->groups = flash_groups;
> }
>
> -int led_classdev_flash_register(struct device *parent,
> - struct led_classdev_flash *fled_cdev)
> +int led_classdev_flash_register_ext(struct device *parent,
> + struct led_classdev_flash *fled_cdev,
> + struct led_init_data *init_data)
> {
> struct led_classdev *led_cdev;
> const struct led_flash_ops *ops;
> @@ -312,13 +313,13 @@ int led_classdev_flash_register(struct device *parent,
> }
>
> /* Register led class device */
> - ret = led_classdev_register(parent, led_cdev);
> + ret = led_classdev_register_ext(parent, led_cdev, init_data);
> if (ret < 0)
> return ret;
>
> return 0;
> }
> -EXPORT_SYMBOL_GPL(led_classdev_flash_register);
> +EXPORT_SYMBOL_GPL(led_classdev_flash_register_ext);
>
> void led_classdev_flash_unregister(struct led_classdev_flash *fled_cdev)
> {
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 3c7e348..8c80763 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -244,18 +245,25 @@ static int led_classdev_next_name(const char
> *init_name, char *name,
> }
>
> /**
> - * of_led_classdev_register - register a new object of led_classdev class.
> + * led_classdev_register_ext - register a new object of led_classdev class.
> *
> * @parent: parent of LED device
> * @led_cdev: the led_classdev structure for this device.
> - * @np: DT node describing this LED
> + * @init_data: LED class device initialization data
> */
> -int of_led_classdev_register(struct device *parent, struct device_node *np,
> - struct led_classdev *led_cdev)
> +int led_classdev_register_ext(struct device *parent,
> + struct led_classdev *led_cdev,
> + struct led_init_data *init_data)
> {
> char name[LED_MAX_NAME_SIZE];
> int ret;
>
> + if (init_data && init_data->name) {
> + led_cdev->name = init_data->name;
> + } else {
> + dev_info(parent, "init_data not available");
> + }
> +
> ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
> if (ret < 0)
>
Re: [PATCH 01/24] leds: class: Improve LED and LED flash class registration API
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Replace of_led_classdev_register() with led_classdev_register_ext(), which
> accepts easily extendable struct led_init_data, instead of the fixed
> struct device_node argument. The latter can be now passed in a fwnode
> property of the struct led_init_data.
>
> The modification is driven by the need for passing another argument
> to the LED class initialization function - a LED class device name.
> Currently it is conveyed in the "name" char pointer property of
> struct led_classdev, which is semantically and functionally incorrect
> since it is needed only on LED class device registration, but persists
> in system memory throughout the whole LED class device lifetime.
>
> Whereas in case of the name strings coming from DT "label" property or
> statically initialized ones the cost is only the pointer size, it grows
> to LED_MAX_NAME_SIZE (64) with the advent of a new LED class device naming
> scheme, where color and function properties come from separate board
> firmware properties and the name needs to be constructed in a new buffer.
>
> The change will not break any existing clients since the patch alters
> also existing led_classdev{_flash}_register() macro wrappers, that pass
> NULL in place of init_data, which leads to using legacy name
> initialization path basing on the struct led_classdev's "name" property.
>
> Two existing users of devm_of_led_classdev_registers() are modified
> to use devm_led_classdev_register(), which will not impact their
> operation since they in fact didn't need to pass struct device_node on
> registration from the beginning.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc: Linus Walleij
> Cc: Oleh Kravchenko
> Cc: Sakari Ailus
> Cc: Simon Shields
> Cc: Xiaotong Lu
> ---
> drivers/leds/led-class-flash.c | 9 +
> drivers/leds/led-class.c| 34 ++
> drivers/leds/leds-cr0014114.c | 3 +--
> drivers/leds/leds-gpio.c| 2 +-
> include/linux/led-class-flash.h | 13 +
> include/linux/leds.h| 29 +++--
> 6 files changed, 57 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
> index cf39827..8d1c117 100644
> --- a/drivers/leds/led-class-flash.c
> +++ b/drivers/leds/led-class-flash.c
> @@ -285,8 +285,9 @@ static void led_flash_init_sysfs_groups(struct
> led_classdev_flash *fled_cdev)
> led_cdev->groups = flash_groups;
> }
>
> -int led_classdev_flash_register(struct device *parent,
> - struct led_classdev_flash *fled_cdev)
> +int led_classdev_flash_register_ext(struct device *parent,
> + struct led_classdev_flash *fled_cdev,
> + struct led_init_data *init_data)
> {
> struct led_classdev *led_cdev;
> const struct led_flash_ops *ops;
> @@ -312,13 +313,13 @@ int led_classdev_flash_register(struct device *parent,
> }
>
> /* Register led class device */
> - ret = led_classdev_register(parent, led_cdev);
> + ret = led_classdev_register_ext(parent, led_cdev, init_data);
> if (ret < 0)
> return ret;
>
> return 0;
> }
> -EXPORT_SYMBOL_GPL(led_classdev_flash_register);
> +EXPORT_SYMBOL_GPL(led_classdev_flash_register_ext);
>
> void led_classdev_flash_unregister(struct led_classdev_flash *fled_cdev)
> {
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 3c7e348..8c80763 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -244,18 +245,25 @@ static int led_classdev_next_name(const char
> *init_name, char *name,
> }
>
> /**
> - * of_led_classdev_register - register a new object of led_classdev class.
> + * led_classdev_register_ext - register a new object of led_classdev class.
> *
> * @parent: parent of LED device
> * @led_cdev: the led_classdev structure for this device.
> - * @np: DT node describing this LED
> + * @init_data: LED class device initialization data
> */
> -int of_led_classdev_register(struct device *parent, struct device_node *np,
> - struct led_classdev *led_cdev)
> +int led_classdev_register_ext(struct device *parent,
> + struct led_classdev *led_cdev,
> + struct led_init_data *init_data)
> {
> char name[LED_MAX_NAME_SIZE];
> int ret;
>
> + if (init_data && init_data->name) {
> + led_cdev->name = init_data->name;
> + } else {
> + dev_info(parent, "init_data not available");
> + }
> +
> ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
> if (ret < 0)
>
Re: [alsa-devel] [PATCH 2/2] ASoC: qdsp6: q6afe-dai: Fix the dai widgets
Thanks Srinivas for the fix.
On 11/6/2018 5:08 PM, Srinivas Kandagatla wrote:
For some reason the dapm widgets are incorrectly defined from the start,
Not sure how we ended up with such thing. Fix them now!
Without this fix the backend dais are always powered up even if there
is no active stream.
Reported-by: Jimmy Cheng-Yi Chiang
Reported-by: Rohit kumar
Tested-by: Rohit kumar
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/qdsp6/q6afe-dai.c | 208 +++
1 file changed, 104 insertions(+), 104 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe-dai.c b/sound/soc/qcom/qdsp6/q6afe-dai.c
index 60ff4a2d3577..8f6c8fc073a9 100644
--- a/sound/soc/qcom/qdsp6/q6afe-dai.c
+++ b/sound/soc/qcom/qdsp6/q6afe-dai.c
@@ -1112,204 +1112,204 @@ static int q6afe_of_xlate_dai_name(struct
snd_soc_component *component,
}
static const struct snd_soc_dapm_widget q6afe_dai_widgets[] = {
- SND_SOC_DAPM_AIF_OUT("HDMI_RX", "HDMI Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_RX", "Slimbus Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_RX", "Slimbus1 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_RX", "Slimbus2 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_RX", "Slimbus3 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_RX", "Slimbus4 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_RX", "Slimbus5 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_RX", "Slimbus6 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_0_TX", "Slimbus Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_1_TX", "Slimbus1 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_2_TX", "Slimbus2 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_3_TX", "Slimbus3 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_4_TX", "Slimbus4 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_5_TX", "Slimbus5 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_6_TX", "Slimbus6 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("QUAT_MI2S_RX", "Quaternary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_0_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_1_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_2_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_3_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_4_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_5_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_6_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("QUAT_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("QUAT_MI2S_TX", "Quaternary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("QUAT_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("TERT_MI2S_RX", "Tertiary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("TERT_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("TERT_MI2S_TX", "Tertiary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("TERT_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SEC_MI2S_RX", "Secondary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SEC_MI2S_TX", "Secondary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("SEC_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SEC_MI2S_RX_SD1",
+ SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX_SD1",
"Secondary MI2S Playback SD1",
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRI_MI2S_RX", "Primary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("PRI_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("PRI_MI2S_TX", "Primary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("PRI_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRIMARY_TDM_RX_0", "Primary TDM0 Playback",
+ SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_0", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRIMARY_TDM_RX_1", "Primary TDM1 Playback",
+ SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_1", NULL,
0, 0, 0, 0),
-
Re: [alsa-devel] [PATCH 2/2] ASoC: qdsp6: q6afe-dai: Fix the dai widgets
Thanks Srinivas for the fix.
On 11/6/2018 5:08 PM, Srinivas Kandagatla wrote:
For some reason the dapm widgets are incorrectly defined from the start,
Not sure how we ended up with such thing. Fix them now!
Without this fix the backend dais are always powered up even if there
is no active stream.
Reported-by: Jimmy Cheng-Yi Chiang
Reported-by: Rohit kumar
Tested-by: Rohit kumar
Signed-off-by: Srinivas Kandagatla
---
sound/soc/qcom/qdsp6/q6afe-dai.c | 208 +++
1 file changed, 104 insertions(+), 104 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe-dai.c b/sound/soc/qcom/qdsp6/q6afe-dai.c
index 60ff4a2d3577..8f6c8fc073a9 100644
--- a/sound/soc/qcom/qdsp6/q6afe-dai.c
+++ b/sound/soc/qcom/qdsp6/q6afe-dai.c
@@ -1112,204 +1112,204 @@ static int q6afe_of_xlate_dai_name(struct
snd_soc_component *component,
}
static const struct snd_soc_dapm_widget q6afe_dai_widgets[] = {
- SND_SOC_DAPM_AIF_OUT("HDMI_RX", "HDMI Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_RX", "Slimbus Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_RX", "Slimbus1 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_RX", "Slimbus2 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_RX", "Slimbus3 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_RX", "Slimbus4 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_RX", "Slimbus5 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_RX", "Slimbus6 Playback", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_0_TX", "Slimbus Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_1_TX", "Slimbus1 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_2_TX", "Slimbus2 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_3_TX", "Slimbus3 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_4_TX", "Slimbus4 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_5_TX", "Slimbus5 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SLIMBUS_6_TX", "Slimbus6 Capture", 0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("QUAT_MI2S_RX", "Quaternary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("HDMI_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_0_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_1_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_2_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_3_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_4_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_5_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("SLIMBUS_6_RX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_0_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_1_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_2_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_3_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_4_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_5_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_OUT("SLIMBUS_6_TX", NULL, 0, 0, 0, 0),
+ SND_SOC_DAPM_AIF_IN("QUAT_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("QUAT_MI2S_TX", "Quaternary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("QUAT_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("TERT_MI2S_RX", "Tertiary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("TERT_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("TERT_MI2S_TX", "Tertiary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("TERT_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SEC_MI2S_RX", "Secondary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("SEC_MI2S_TX", "Secondary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("SEC_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("SEC_MI2S_RX_SD1",
+ SND_SOC_DAPM_AIF_IN("SEC_MI2S_RX_SD1",
"Secondary MI2S Playback SD1",
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRI_MI2S_RX", "Primary MI2S Playback",
+ SND_SOC_DAPM_AIF_IN("PRI_MI2S_RX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_IN("PRI_MI2S_TX", "Primary MI2S Capture",
+ SND_SOC_DAPM_AIF_OUT("PRI_MI2S_TX", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRIMARY_TDM_RX_0", "Primary TDM0 Playback",
+ SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_0", NULL,
0, 0, 0, 0),
- SND_SOC_DAPM_AIF_OUT("PRIMARY_TDM_RX_1", "Primary TDM1 Playback",
+ SND_SOC_DAPM_AIF_IN("PRIMARY_TDM_RX_1", NULL,
0, 0, 0, 0),
-
Re: RFC: userspace exception fixups
On 2018-11-07 02:17, Andy Lutomirski wrote: On Tue, Nov 6, 2018 at 4:02 PM Sean Christopherson wrote: /* * EEXIT or EENTER faulted. In the latter case, %RAX already holds some * fault indicator, e.g. -EFAULT. */ eexit_or_eenter_fault: ret But userspace wants to know whether it was a fault or not. So I think we either need two landing pads or we need to hijack a flag bit (are there any known-zeroed flag bits after EEXIT?) to say whether it was a fault. And, if it was a fault, we should give the vector, the sanitized error code, and possibly CR2. On AEX, %rax will contain ENCLU_LEAF_ERESUME (0x3). On EEXIT, %rax will contain ENCLU_LEAF_EEXIT (0x4). -- Jethro Beekman | Fortanix smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: userspace exception fixups
On 2018-11-07 02:17, Andy Lutomirski wrote: On Tue, Nov 6, 2018 at 4:02 PM Sean Christopherson wrote: /* * EEXIT or EENTER faulted. In the latter case, %RAX already holds some * fault indicator, e.g. -EFAULT. */ eexit_or_eenter_fault: ret But userspace wants to know whether it was a fault or not. So I think we either need two landing pads or we need to hijack a flag bit (are there any known-zeroed flag bits after EEXIT?) to say whether it was a fault. And, if it was a fault, we should give the vector, the sanitized error code, and possibly CR2. On AEX, %rax will contain ENCLU_LEAF_ERESUME (0x3). On EEXIT, %rax will contain ENCLU_LEAF_EEXIT (0x4). -- Jethro Beekman | Fortanix smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On 11/6/18 12:41 PM, Dave Chinner wrote: > On Tue, Nov 06, 2018 at 12:00:06PM +0100, Jan Kara wrote: >> On Tue 06-11-18 13:47:15, Dave Chinner wrote: >>> On Mon, Nov 05, 2018 at 04:26:04PM -0800, John Hubbard wrote: On 11/5/18 1:54 AM, Jan Kara wrote: > Hmm, have you tried larger buffer sizes? Because synchronous 8k IO isn't > going to max-out NVME iops by far. Can I suggest you install fio [1] (it > has the advantage that it is pretty much standard for a test like this so > everyone knows what the test does from a glimpse) and run with it > something > like the following workfile: > > [reader] > direct=1 > ioengine=libaio > blocksize=4096 > size=1g > numjobs=1 > rw=read > iodepth=64 > > And see how the numbers with and without your patches compare? > > Honza > > [1] https://github.com/axboe/fio That program is *very* good to have. Whew. Anyway, it looks like read bandwidth is approximately 74 MiB/s with my patch (it varies a bit, run to run), as compared to around 85 without the patch, so still showing about a 20% performance degradation, assuming I'm reading this correctly. Raw data follows, using the fio options you listed above: Baseline (without my patch): >>> lat (usec): min=179, max=14003, avg=2913.65, stdev=1241.75 clat percentiles (usec): | 1.00th=[ 2311], 5.00th=[ 2343], 10.00th=[ 2343], 20.00th=[ 2343], | 30.00th=[ 2343], 40.00th=[ 2376], 50.00th=[ 2376], 60.00th=[ 2376], | 70.00th=[ 2409], 80.00th=[ 2933], 90.00th=[ 4359], 95.00th=[ 5276], | 99.00th=[ 8291], 99.50th=[ 9110], 99.90th=[10945], 99.95th=[11469], | 99.99th=[12256] >>> . Modified (with my patch): >>> . lat (usec): min=81, max=15766, avg=3496.57, stdev=1450.21 clat percentiles (usec): | 1.00th=[ 2835], 5.00th=[ 2835], 10.00th=[ 2835], 20.00th=[ 2868], | 30.00th=[ 2868], 40.00th=[ 2868], 50.00th=[ 2868], 60.00th=[ 2900], | 70.00th=[ 2933], 80.00th=[ 3425], 90.00th=[ 5080], 95.00th=[ 6259], | 99.00th=[10159], 99.50th=[11076], 99.90th=[12649], 99.95th=[13435], | 99.99th=[14484] >>> >>> So it's adding at least 500us of completion latency to every IO? >>> I'd argue that the IO latency impact is far worse than the a 20% >>> throughput drop. >> >> Hum, right. So for each IO we have to remove the page from LRU on submit > > Which cost us less then 10us on average: > > slat (usec): min=13, max=3855, avg=44.17, stdev=61.18 > vs > slat (usec): min=18, max=4378, avg=52.59, stdev=63.66 > >> and then put it back on IO completion (which is going to race with new >> submits so LRU lock contention might be an issue). > > Removal has to take the same LRU lock, so I don't think contention > is the problem here. More likely the overhead is in selecting the > LRU to put it on. e.g. list_lru_from_kmem() which may well be doing > a memcg lookup. > >> Spending 500 us on that >> is not unthinkable when the lock is contended but it is more expensive than >> I'd have thought. John, could you perhaps profile where the time is spent? > OK, some updates on that: 1. First of all, I fixed a direct-io-related call site (it was still calling put_page instead of put_user_page), and that not only got rid of a problem, it also changed performance: it makes the impact of the patch a bit less. (Sorry about that! I was hoping that I could get away with temporarily ignoring that failure, but no.) The bandwidth numbers in particular look much closer to each other. 2. Second, note that these fio results are noisy. The std deviation is large enough that some of this could be noise. In order to highlight that, I did 5 runs each of with, and without the patch, and while there is definitely a performance drop on average, it's also true that there is overlap in the results. In other words, the best "with patch" run is about the same as the worst "without patch" run. 3. Finally, initial profiling shows that we're adding about 1% total to the this particular test run...I think. I may have to narrow this down some more, but I don't seem to see any real lock contention. Hints or ideas on measurement methods are welcome, btw. -- 0.59% in put_user_page -- 0.2% (or 0.54%, depending on how you read the perf out below) in get_user_pages_fast: 1.36%--iov_iter_get_pages | --1.27%--get_user_pages_fast | --0.54%--pin_page_for_dma 0.59%--put_user_page 1.34% 0.03% fio [kernel.vmlinux] [k] _raw_spin_lock 0.95% 0.55% fio [kernel.vmlinux] [k] do_raw_spin_lock
Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On 11/6/18 12:41 PM, Dave Chinner wrote: > On Tue, Nov 06, 2018 at 12:00:06PM +0100, Jan Kara wrote: >> On Tue 06-11-18 13:47:15, Dave Chinner wrote: >>> On Mon, Nov 05, 2018 at 04:26:04PM -0800, John Hubbard wrote: On 11/5/18 1:54 AM, Jan Kara wrote: > Hmm, have you tried larger buffer sizes? Because synchronous 8k IO isn't > going to max-out NVME iops by far. Can I suggest you install fio [1] (it > has the advantage that it is pretty much standard for a test like this so > everyone knows what the test does from a glimpse) and run with it > something > like the following workfile: > > [reader] > direct=1 > ioengine=libaio > blocksize=4096 > size=1g > numjobs=1 > rw=read > iodepth=64 > > And see how the numbers with and without your patches compare? > > Honza > > [1] https://github.com/axboe/fio That program is *very* good to have. Whew. Anyway, it looks like read bandwidth is approximately 74 MiB/s with my patch (it varies a bit, run to run), as compared to around 85 without the patch, so still showing about a 20% performance degradation, assuming I'm reading this correctly. Raw data follows, using the fio options you listed above: Baseline (without my patch): >>> lat (usec): min=179, max=14003, avg=2913.65, stdev=1241.75 clat percentiles (usec): | 1.00th=[ 2311], 5.00th=[ 2343], 10.00th=[ 2343], 20.00th=[ 2343], | 30.00th=[ 2343], 40.00th=[ 2376], 50.00th=[ 2376], 60.00th=[ 2376], | 70.00th=[ 2409], 80.00th=[ 2933], 90.00th=[ 4359], 95.00th=[ 5276], | 99.00th=[ 8291], 99.50th=[ 9110], 99.90th=[10945], 99.95th=[11469], | 99.99th=[12256] >>> . Modified (with my patch): >>> . lat (usec): min=81, max=15766, avg=3496.57, stdev=1450.21 clat percentiles (usec): | 1.00th=[ 2835], 5.00th=[ 2835], 10.00th=[ 2835], 20.00th=[ 2868], | 30.00th=[ 2868], 40.00th=[ 2868], 50.00th=[ 2868], 60.00th=[ 2900], | 70.00th=[ 2933], 80.00th=[ 3425], 90.00th=[ 5080], 95.00th=[ 6259], | 99.00th=[10159], 99.50th=[11076], 99.90th=[12649], 99.95th=[13435], | 99.99th=[14484] >>> >>> So it's adding at least 500us of completion latency to every IO? >>> I'd argue that the IO latency impact is far worse than the a 20% >>> throughput drop. >> >> Hum, right. So for each IO we have to remove the page from LRU on submit > > Which cost us less then 10us on average: > > slat (usec): min=13, max=3855, avg=44.17, stdev=61.18 > vs > slat (usec): min=18, max=4378, avg=52.59, stdev=63.66 > >> and then put it back on IO completion (which is going to race with new >> submits so LRU lock contention might be an issue). > > Removal has to take the same LRU lock, so I don't think contention > is the problem here. More likely the overhead is in selecting the > LRU to put it on. e.g. list_lru_from_kmem() which may well be doing > a memcg lookup. > >> Spending 500 us on that >> is not unthinkable when the lock is contended but it is more expensive than >> I'd have thought. John, could you perhaps profile where the time is spent? > OK, some updates on that: 1. First of all, I fixed a direct-io-related call site (it was still calling put_page instead of put_user_page), and that not only got rid of a problem, it also changed performance: it makes the impact of the patch a bit less. (Sorry about that! I was hoping that I could get away with temporarily ignoring that failure, but no.) The bandwidth numbers in particular look much closer to each other. 2. Second, note that these fio results are noisy. The std deviation is large enough that some of this could be noise. In order to highlight that, I did 5 runs each of with, and without the patch, and while there is definitely a performance drop on average, it's also true that there is overlap in the results. In other words, the best "with patch" run is about the same as the worst "without patch" run. 3. Finally, initial profiling shows that we're adding about 1% total to the this particular test run...I think. I may have to narrow this down some more, but I don't seem to see any real lock contention. Hints or ideas on measurement methods are welcome, btw. -- 0.59% in put_user_page -- 0.2% (or 0.54%, depending on how you read the perf out below) in get_user_pages_fast: 1.36%--iov_iter_get_pages | --1.27%--get_user_pages_fast | --0.54%--pin_page_for_dma 0.59%--put_user_page 1.34% 0.03% fio [kernel.vmlinux] [k] _raw_spin_lock 0.95% 0.55% fio [kernel.vmlinux] [k] do_raw_spin_lock
Re: [PATCH] lib/genaloc: Fix allocation of aligned buffer from non-aligned chunk
On 11/7/18 12:15 AM, Andrew Morton wrote: > On Tue, 6 Nov 2018 14:20:53 +0200 Alexey Skidanov > wrote: > >> On success, gen_pool_first_fit_align() returns the bit number such that >> chunk_start_addr + (bit << order) is properly aligned. On failure, >> the bitmap size parameter is returned. >> >> When the chunk_start_addr isn't aligned properly, the >> chunk_start_addr + (bit << order) isn't aligned too. >> >> To fix this, gen_pool_first_fit_align() takes into account >> the chunk_start_addr alignment and returns the bit value such that >> chunk_start_addr + (bit << order) is properly aligned >> (exactly as it done in CMA). >> >> ... >> >> --- a/include/linux/genalloc.h >> +++ b/include/linux/genalloc.h >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> > > We have three typos here. Which makes me wonder why we're passing the > new argument and then not using it? > genpool uses allocation callbacks function that implement some allocation strategy - bes fit, first fit, ... All of them has the same type. The added chunk start_addr is used only in one of them - gen_pool_first_fit_align() Thanks, Alexey
Re: [PATCH] lib/genaloc: Fix allocation of aligned buffer from non-aligned chunk
On 11/7/18 12:15 AM, Andrew Morton wrote: > On Tue, 6 Nov 2018 14:20:53 +0200 Alexey Skidanov > wrote: > >> On success, gen_pool_first_fit_align() returns the bit number such that >> chunk_start_addr + (bit << order) is properly aligned. On failure, >> the bitmap size parameter is returned. >> >> When the chunk_start_addr isn't aligned properly, the >> chunk_start_addr + (bit << order) isn't aligned too. >> >> To fix this, gen_pool_first_fit_align() takes into account >> the chunk_start_addr alignment and returns the bit value such that >> chunk_start_addr + (bit << order) is properly aligned >> (exactly as it done in CMA). >> >> ... >> >> --- a/include/linux/genalloc.h >> +++ b/include/linux/genalloc.h >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> >> +struct gen_pool *pool, unsigned long start_add) >> >> ... >> > > We have three typos here. Which makes me wonder why we're passing the > new argument and then not using it? > genpool uses allocation callbacks function that implement some allocation strategy - bes fit, first fit, ... All of them has the same type. The added chunk start_addr is used only in one of them - gen_pool_first_fit_align() Thanks, Alexey
Re: [PATCH v6 1/2] memory_hotplug: Free pages as higher order
On 2018-11-07 01:38, Michal Hocko wrote: On Tue 06-11-18 21:01:29, Arun KS wrote: On 2018-11-06 19:36, Michal Hocko wrote: > On Tue 06-11-18 11:33:13, Arun KS wrote: > > When free pages are done with higher order, time spend on > > coalescing pages by buddy allocator can be reduced. With > > section size of 256MB, hot add latency of a single section > > shows improvement from 50-60 ms to less than 1 ms, hence > > improving the hot add latency by 60%. Modify external > > providers of online callback to align with the change. > > > > This patch modifies totalram_pages, zone->managed_pages and > > totalhigh_pages outside managed_page_count_lock. A follow up > > series will be send to convert these variable to atomic to > > avoid readers potentially seeing a store tear. > > Is there any reason to rush this through rather than wait for counters > conversion first? Sure Michal. Conversion patch, https://patchwork.kernel.org/cover/10657217/ is currently incremental to this patch. The ordering should be other way around. Because as things stand with this patch first it is possible to introduce a subtle race prone updates. As I've said I am skeptical the race would matter, really, but there is no real reason to risk for that. Especially when you have the other (first) half ready. Makes sense. I have rebased the preparatory patch on top of -rc1. https://patchwork.kernel.org/patch/10670787/ Regards, Arun
Re: [PATCH v6 1/2] memory_hotplug: Free pages as higher order
On 2018-11-07 01:38, Michal Hocko wrote: On Tue 06-11-18 21:01:29, Arun KS wrote: On 2018-11-06 19:36, Michal Hocko wrote: > On Tue 06-11-18 11:33:13, Arun KS wrote: > > When free pages are done with higher order, time spend on > > coalescing pages by buddy allocator can be reduced. With > > section size of 256MB, hot add latency of a single section > > shows improvement from 50-60 ms to less than 1 ms, hence > > improving the hot add latency by 60%. Modify external > > providers of online callback to align with the change. > > > > This patch modifies totalram_pages, zone->managed_pages and > > totalhigh_pages outside managed_page_count_lock. A follow up > > series will be send to convert these variable to atomic to > > avoid readers potentially seeing a store tear. > > Is there any reason to rush this through rather than wait for counters > conversion first? Sure Michal. Conversion patch, https://patchwork.kernel.org/cover/10657217/ is currently incremental to this patch. The ordering should be other way around. Because as things stand with this patch first it is possible to introduce a subtle race prone updates. As I've said I am skeptical the race would matter, really, but there is no real reason to risk for that. Especially when you have the other (first) half ready. Makes sense. I have rebased the preparatory patch on top of -rc1. https://patchwork.kernel.org/patch/10670787/ Regards, Arun
Re: [PATCH v1 0/4]mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
On 2018-11-07 05:52, Andrew Morton wrote: On Fri, 26 Oct 2018 16:30:58 +0530 Arun KS wrote: This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The whole point appears to be removal of managed_page_count_lock, yes? Why? What is the value of this patchset? If "performance" then are any measurements available? Hello Andrew, https://patchwork.kernel.org/patch/10670787/ In version 2, I have added motivation behind this conversion. Pasting same here, totalram_pages, zone->managed_pages and totalhigh_pages updates are protected by managed_page_count_lock, but readers never care about it. Convert these variables to atomic to avoid readers potentially seeing a store tear. I don't think we have a performance improvement here. Regards, Arun
Re: [PATCH v1 0/4]mm: convert totalram_pages, totalhigh_pages and managed pages to atomic
On 2018-11-07 05:52, Andrew Morton wrote: On Fri, 26 Oct 2018 16:30:58 +0530 Arun KS wrote: This series convert totalram_pages, totalhigh_pages and zone->managed_pages to atomic variables. The whole point appears to be removal of managed_page_count_lock, yes? Why? What is the value of this patchset? If "performance" then are any measurements available? Hello Andrew, https://patchwork.kernel.org/patch/10670787/ In version 2, I have added motivation behind this conversion. Pasting same here, totalram_pages, zone->managed_pages and totalhigh_pages updates are protected by managed_page_count_lock, but readers never care about it. Convert these variables to atomic to avoid readers potentially seeing a store tear. I don't think we have a performance improvement here. Regards, Arun
Re: [PATCH] lib/genaloc: Fix allocation of aligned buffer from non-aligned chunk
On 11/7/18 12:11 AM, Andrew Morton wrote: > On Tue, 6 Nov 2018 14:20:53 +0200 Alexey Skidanov > wrote: > >> On success, gen_pool_first_fit_align() returns the bit number such that >> chunk_start_addr + (bit << order) is properly aligned. On failure, >> the bitmap size parameter is returned. >> >> When the chunk_start_addr isn't aligned properly, the >> chunk_start_addr + (bit << order) isn't aligned too. >> >> To fix this, gen_pool_first_fit_align() takes into account >> the chunk_start_addr alignment and returns the bit value such that >> chunk_start_addr + (bit << order) is properly aligned >> (exactly as it done in CMA). > > Why does this need "fixing"? Are there current callers which can > misalign chunk_start_addr? Or is there a requirement that future > callers can misalign chunk_start_addr? > I work on adding aligned allocation support for ION heaps (https://www.spinics.net/lists/linux-driver-devel/msg118754.html). Two of these heaps use genpool internally. If you want to have an ability to allocate buffers aligned on different boundaries (for example, 4K, 1MB, ...), this fix actually removes the requirement for chunk_start_addr to be aligned on the max possible alignment. Thanks, Alexey
Re: [PATCH] lib/genaloc: Fix allocation of aligned buffer from non-aligned chunk
On 11/7/18 12:11 AM, Andrew Morton wrote: > On Tue, 6 Nov 2018 14:20:53 +0200 Alexey Skidanov > wrote: > >> On success, gen_pool_first_fit_align() returns the bit number such that >> chunk_start_addr + (bit << order) is properly aligned. On failure, >> the bitmap size parameter is returned. >> >> When the chunk_start_addr isn't aligned properly, the >> chunk_start_addr + (bit << order) isn't aligned too. >> >> To fix this, gen_pool_first_fit_align() takes into account >> the chunk_start_addr alignment and returns the bit value such that >> chunk_start_addr + (bit << order) is properly aligned >> (exactly as it done in CMA). > > Why does this need "fixing"? Are there current callers which can > misalign chunk_start_addr? Or is there a requirement that future > callers can misalign chunk_start_addr? > I work on adding aligned allocation support for ION heaps (https://www.spinics.net/lists/linux-driver-devel/msg118754.html). Two of these heaps use genpool internally. If you want to have an ability to allocate buffers aligned on different boundaries (for example, 4K, 1MB, ...), this fix actually removes the requirement for chunk_start_addr to be aligned on the max possible alignment. Thanks, Alexey
Re: [PATCH v4 1/6] tpm: dynamically allocate active_banks array
On 11/06/2018 08:31 PM, Roberto Sassu wrote:
This patch removes the hard-coded limit of the active_banks array size.
The hard-coded limit in static array active_banks[] represents the
maximum possible banks.
A TPM might have three banks, but only one bank may be active.
To confirm my understanding, is the idea for this patch is to
dynamically identify the number of possible banks or the number of
active banks ?
It stores in the tpm_chip structure the number of active PCR banks,
determined in tpm2_get_pcr_allocation(), and replaces the static array
with a pointer to a dynamically allocated array.
As a consequence of the introduction of nr_active_banks, tpm_pcr_extend()
does not check anymore if the algorithm stored in tpm_chip is equal to
zero. The active_banks array always contains valid algorithms.
Fixes: 1db15344f874 ("tpm: implement TPM 2.0 capability to get active
PCR banks")
Signed-off-by: Roberto Sassu
---
drivers/char/tpm/tpm-chip.c | 1 +
drivers/char/tpm/tpm-interface.c | 19 ---
drivers/char/tpm/tpm.h | 3 ++-
drivers/char/tpm/tpm2-cmd.c | 17 -
4 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 46caadca916a..2a9e8b744436 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -160,6 +160,7 @@ static void tpm_dev_release(struct device *dev)
kfree(chip->log.bios_event_log);
kfree(chip->work_space.context_buf);
kfree(chip->work_space.session_buf);
+ kfree(chip->active_banks);
kfree(chip);
}
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1a803b0cf980..ba7ca6b3e664 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1039,8 +1039,7 @@ static int tpm1_pcr_extend(struct tpm_chip *chip, int
pcr_idx, const u8 *hash,
int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
{
int rc;
- struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
- u32 count = 0;
+ struct tpm2_digest *digest_list;
int i;
chip = tpm_find_get_ops(chip);
@@ -1048,16 +1047,22 @@ int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx,
const u8 *hash)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- memset(digest_list, 0, sizeof(digest_list));
+ digest_list = kmalloc_array(chip->nr_active_banks,
+ sizeof(*digest_list), GFP_KERNEL);
+ if (!digest_list)
+ return -ENOMEM;
- for (i = 0; i < ARRAY_SIZE(chip->active_banks) &&
- chip->active_banks[i] != TPM2_ALG_ERROR; i++) {
+ memset(digest_list, 0,
+ chip->nr_active_banks * sizeof(*digest_list));
+
+ for (i = 0; i < chip->nr_active_banks; i++) {
digest_list[i].alg_id = chip->active_banks[i];
memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
- count++;
}
- rc = tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
+ rc = tpm2_pcr_extend(chip, pcr_idx, chip->nr_active_banks,
+digest_list);
+ kfree(digest_list);
tpm_put_ops(chip);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f3501d05264f..98368c3a6ff7 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -248,7 +248,8 @@ struct tpm_chip {
const struct attribute_group *groups[3];
unsigned int groups_cnt;
- u16 active_banks[7];
+ u32 nr_active_banks;
+ u16 *active_banks;
#ifdef CONFIG_ACPI
acpi_handle acpi_dev_handle;
char ppi_version[TPM_PPI_VERSION_LEN + 1];
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index c31b490bd41d..533089cede07 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -242,7 +242,7 @@ int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32
count,
int i;
int j;
- if (count > ARRAY_SIZE(chip->active_banks))
+ if (count > chip->nr_active_banks)
return -EINVAL;
rc = tpm_buf_init(, TPM2_ST_SESSIONS, TPM2_CC_PCR_EXTEND);
@@ -859,7 +859,6 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip
*chip)
void *marker;
void *end;
void *pcr_select_offset;
- unsigned int count;
u32 sizeof_pcr_selection;
u32 rsp_len;
int rc;
@@ -878,11 +877,14 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip
*chip)
if (rc)
goto out;
- count = be32_to_cpup(
+ chip->nr_active_banks = be32_to_cpup(
(__be32 *)[TPM_HEADER_SIZE + 5]);
As per
Re: [PATCH v4 1/6] tpm: dynamically allocate active_banks array
On 11/06/2018 08:31 PM, Roberto Sassu wrote:
This patch removes the hard-coded limit of the active_banks array size.
The hard-coded limit in static array active_banks[] represents the
maximum possible banks.
A TPM might have three banks, but only one bank may be active.
To confirm my understanding, is the idea for this patch is to
dynamically identify the number of possible banks or the number of
active banks ?
It stores in the tpm_chip structure the number of active PCR banks,
determined in tpm2_get_pcr_allocation(), and replaces the static array
with a pointer to a dynamically allocated array.
As a consequence of the introduction of nr_active_banks, tpm_pcr_extend()
does not check anymore if the algorithm stored in tpm_chip is equal to
zero. The active_banks array always contains valid algorithms.
Fixes: 1db15344f874 ("tpm: implement TPM 2.0 capability to get active
PCR banks")
Signed-off-by: Roberto Sassu
---
drivers/char/tpm/tpm-chip.c | 1 +
drivers/char/tpm/tpm-interface.c | 19 ---
drivers/char/tpm/tpm.h | 3 ++-
drivers/char/tpm/tpm2-cmd.c | 17 -
4 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 46caadca916a..2a9e8b744436 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -160,6 +160,7 @@ static void tpm_dev_release(struct device *dev)
kfree(chip->log.bios_event_log);
kfree(chip->work_space.context_buf);
kfree(chip->work_space.session_buf);
+ kfree(chip->active_banks);
kfree(chip);
}
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1a803b0cf980..ba7ca6b3e664 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1039,8 +1039,7 @@ static int tpm1_pcr_extend(struct tpm_chip *chip, int
pcr_idx, const u8 *hash,
int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
{
int rc;
- struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
- u32 count = 0;
+ struct tpm2_digest *digest_list;
int i;
chip = tpm_find_get_ops(chip);
@@ -1048,16 +1047,22 @@ int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx,
const u8 *hash)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- memset(digest_list, 0, sizeof(digest_list));
+ digest_list = kmalloc_array(chip->nr_active_banks,
+ sizeof(*digest_list), GFP_KERNEL);
+ if (!digest_list)
+ return -ENOMEM;
- for (i = 0; i < ARRAY_SIZE(chip->active_banks) &&
- chip->active_banks[i] != TPM2_ALG_ERROR; i++) {
+ memset(digest_list, 0,
+ chip->nr_active_banks * sizeof(*digest_list));
+
+ for (i = 0; i < chip->nr_active_banks; i++) {
digest_list[i].alg_id = chip->active_banks[i];
memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
- count++;
}
- rc = tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
+ rc = tpm2_pcr_extend(chip, pcr_idx, chip->nr_active_banks,
+digest_list);
+ kfree(digest_list);
tpm_put_ops(chip);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f3501d05264f..98368c3a6ff7 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -248,7 +248,8 @@ struct tpm_chip {
const struct attribute_group *groups[3];
unsigned int groups_cnt;
- u16 active_banks[7];
+ u32 nr_active_banks;
+ u16 *active_banks;
#ifdef CONFIG_ACPI
acpi_handle acpi_dev_handle;
char ppi_version[TPM_PPI_VERSION_LEN + 1];
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index c31b490bd41d..533089cede07 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -242,7 +242,7 @@ int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32
count,
int i;
int j;
- if (count > ARRAY_SIZE(chip->active_banks))
+ if (count > chip->nr_active_banks)
return -EINVAL;
rc = tpm_buf_init(, TPM2_ST_SESSIONS, TPM2_CC_PCR_EXTEND);
@@ -859,7 +859,6 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip
*chip)
void *marker;
void *end;
void *pcr_select_offset;
- unsigned int count;
u32 sizeof_pcr_selection;
u32 rsp_len;
int rc;
@@ -878,11 +877,14 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip
*chip)
if (rc)
goto out;
- count = be32_to_cpup(
+ chip->nr_active_banks = be32_to_cpup(
(__be32 *)[TPM_HEADER_SIZE + 5]);
As per
Re: [PATCH] KVM/VMX: Check ept_pointer before flushing ept tlb
Hi Vitaly:
Thanks for your review.
On 11/6/2018 11:50 PM, Vitaly Kuznetsov wrote:
ltyker...@gmail.com writes:
From: Lan Tianyu
This patch is to initialize ept_pointer to INVALID_PAGE and check it
before flushing ept tlb. If ept_pointer is invalidated, bypass the flush
request.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/vmx.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4555077d69ce..edbc96cb990a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1580,14 +1580,22 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
/*
* FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
* base of EPT PML4 table, strip off EPT configuration information.
+* If ept_pointer is invalid pointer, bypass the flush request.
*/
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
- kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (!VALID_PAGE(to_vmx(vcpu)->ept_pointer))
+ return 0;
+
To be honest I fail to understand the reason behind the patch: instead
of doing one unneeded flush request with ept_pointer==0 (after vCPU is
initialized) we now do the check every time. Could you please elaborate
on why this is needed?
The reason to introduce the check here is to avoid flushing ept tlb
without valid ept table. When nested guest boots up and only BP is
active, we should not do flush for APs and L1 hypervisor hasn't set
valid EPT table for APs.
ret |= hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer &
PAGE_MASK);
+ to_vmx(vcpu)->ept_pointer & PAGE_MASK);
I would use a local variable for 'to_vmx(vcpu)->ept_pointer' or even
'to_vmx(vcpu)->ept_pointer & PAGE_MASK' and use it in VALID_PAGE() - as
lower bits are unrelated;
Yes, that makes sense. INVALID_PAGE also contains lower bits and so a
local variable for 'to_vmx(vcpu)->ept_pointer' maybe better.
+ }
} else {
+ if (!VALID_PAGE(to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer))
+ return 0;
Ditto.
+
ret = hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer &
PAGE_MASK);
+ to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
This doesn't belong to this patch.
I found the line exceeds 80 chars and so adjust indent. Maybe I should
change it in a separate patch despite it's a small change.
}
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
@@ -11568,6 +11576,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
*kvm, unsigned int id)
vmx->pi_desc.nv = POSTED_INTR_VECTOR;
vmx->pi_desc.sn = 1;
+ vmx->ept_pointer = INVALID_PAGE;
+
return >vcpu;
free_vmcs:
Re: [PATCH] KVM/VMX: Check ept_pointer before flushing ept tlb
Hi Vitaly:
Thanks for your review.
On 11/6/2018 11:50 PM, Vitaly Kuznetsov wrote:
ltyker...@gmail.com writes:
From: Lan Tianyu
This patch is to initialize ept_pointer to INVALID_PAGE and check it
before flushing ept tlb. If ept_pointer is invalidated, bypass the flush
request.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/vmx.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4555077d69ce..edbc96cb990a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1580,14 +1580,22 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
/*
* FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
* base of EPT PML4 table, strip off EPT configuration information.
+* If ept_pointer is invalid pointer, bypass the flush request.
*/
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
- kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (!VALID_PAGE(to_vmx(vcpu)->ept_pointer))
+ return 0;
+
To be honest I fail to understand the reason behind the patch: instead
of doing one unneeded flush request with ept_pointer==0 (after vCPU is
initialized) we now do the check every time. Could you please elaborate
on why this is needed?
The reason to introduce the check here is to avoid flushing ept tlb
without valid ept table. When nested guest boots up and only BP is
active, we should not do flush for APs and L1 hypervisor hasn't set
valid EPT table for APs.
ret |= hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer &
PAGE_MASK);
+ to_vmx(vcpu)->ept_pointer & PAGE_MASK);
I would use a local variable for 'to_vmx(vcpu)->ept_pointer' or even
'to_vmx(vcpu)->ept_pointer & PAGE_MASK' and use it in VALID_PAGE() - as
lower bits are unrelated;
Yes, that makes sense. INVALID_PAGE also contains lower bits and so a
local variable for 'to_vmx(vcpu)->ept_pointer' maybe better.
+ }
} else {
+ if (!VALID_PAGE(to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer))
+ return 0;
Ditto.
+
ret = hyperv_flush_guest_mapping(
- to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer &
PAGE_MASK);
+ to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
This doesn't belong to this patch.
I found the line exceeds 80 chars and so adjust indent. Maybe I should
change it in a separate patch despite it's a small change.
}
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
@@ -11568,6 +11576,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
*kvm, unsigned int id)
vmx->pi_desc.nv = POSTED_INTR_VECTOR;
vmx->pi_desc.sn = 1;
+ vmx->ept_pointer = INVALID_PAGE;
+
return >vcpu;
free_vmcs:
Re: [GIT PULL] Qualcomm ARM64 DT updates for 4.20
On Sun, Oct 28, 2018 at 11:24 PM Amit Kucheria wrote: > > On Thu, Oct 25, 2018 at 9:38 PM Andy Gross wrote: > > > > On Thu, Oct 25, 2018 at 10:55:32AM +0530, Amit Kucheria wrote: > > > > > > > > > Andy, > > > > > > While you acked the tsens thermal DT patches[1] so they could go > > > through the thermal tree[2] to avoid a dependency, Eduardo would > > > prefer the DT changes for tsens to go through the arch tree. > > > > > > To avoid a scenario where these DT changes don't get merged until the > > > next merge window, would you or arm-soc maintainers consider merging > > > them in -rc2 (after the thermal-soc tree gets merged)? > > > > > > For convenience, I've provided just the DT changes with all tags in a > > > separate branch on top of v4.19 here: > > > https://git.linaro.org/people/amit.kucheria/kernel.git/log/?h=up/thermal/tsens-preirq-cleanup-v4 > > > > > > Regards, > > > Amit > > > [1] Here is a reference to the patch series with Andy's acks: > > > https://lore.kernel.org/lkml/cover.1536744310.git.amit.kuche...@linaro.org/T/ > > > [2] Here is a link to Eduardo's tree containing a subset of the above > > > series (I don't yet see a pull request): > > > https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=linus > > > > I can just send a pull request for -rc1. No biggie. > > > > Thanks Andy. > > FWIW, the dependency patches landed in Linus' tree. Andy, a gentle reminder that the DT patches can now go in safely. Thanks, Amit
Re: [GIT PULL] Qualcomm ARM64 DT updates for 4.20
On Sun, Oct 28, 2018 at 11:24 PM Amit Kucheria wrote: > > On Thu, Oct 25, 2018 at 9:38 PM Andy Gross wrote: > > > > On Thu, Oct 25, 2018 at 10:55:32AM +0530, Amit Kucheria wrote: > > > > > > > > > Andy, > > > > > > While you acked the tsens thermal DT patches[1] so they could go > > > through the thermal tree[2] to avoid a dependency, Eduardo would > > > prefer the DT changes for tsens to go through the arch tree. > > > > > > To avoid a scenario where these DT changes don't get merged until the > > > next merge window, would you or arm-soc maintainers consider merging > > > them in -rc2 (after the thermal-soc tree gets merged)? > > > > > > For convenience, I've provided just the DT changes with all tags in a > > > separate branch on top of v4.19 here: > > > https://git.linaro.org/people/amit.kucheria/kernel.git/log/?h=up/thermal/tsens-preirq-cleanup-v4 > > > > > > Regards, > > > Amit > > > [1] Here is a reference to the patch series with Andy's acks: > > > https://lore.kernel.org/lkml/cover.1536744310.git.amit.kuche...@linaro.org/T/ > > > [2] Here is a link to Eduardo's tree containing a subset of the above > > > series (I don't yet see a pull request): > > > https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=linus > > > > I can just send a pull request for -rc1. No biggie. > > > > Thanks Andy. > > FWIW, the dependency patches landed in Linus' tree. Andy, a gentle reminder that the DT patches can now go in safely. Thanks, Amit
Re: [PATCH RFC] hist lookups
From: Jiri Olsa Date: Tue, 6 Nov 2018 21:42:55 +0100 > I pushed that fix in perf/fixes branch, but I'm still occasionaly > hitting the namespace crash.. working on it ;-) Jiri, how can this new scheme work without setting copy_on_queue for the queued_events we use here? I don't see copy_on_queue being set and that means the queued event structures reference the event memory directly in the mmaps, after the mmap thread has released them back to the queue. That means new events can come in to the mmap ring and overwrite what was there previously, maybe even while deliver_event() is in the middle of parsing the event. Setting copy_on_queue for data[0] and data[1] makes all of the crashes go away for me. I get a lot of "[unknown]" shared objects shortly after perf top starts up during a full workload. I've been wondering about one side effect of how the mmap queues are processed, consider the following: cpu 0 cpu 1 exec create new mmap2 events scheduled to cpu 0 for whatever reason sample 1 sample 2 And let's say that perf top is backlogged processing the mmap ring of events generated for cpu 0, and sees sample 1 and sample 2 before getting to any of cpu 1's events. This means the thread and map and symbol objects won't exist and we'll get those '[Unknown]' histogram entries, and they won't go away. When it finally stops looping over the mmap ring for cpu 0's events it gets to cpu 1's mmap ring and sees the exec and mmap2 events but at that point it's far too late. I surmise from what I see with perf top right now that this happens a lot.
Re: [PATCH RFC] hist lookups
From: Jiri Olsa Date: Tue, 6 Nov 2018 21:42:55 +0100 > I pushed that fix in perf/fixes branch, but I'm still occasionaly > hitting the namespace crash.. working on it ;-) Jiri, how can this new scheme work without setting copy_on_queue for the queued_events we use here? I don't see copy_on_queue being set and that means the queued event structures reference the event memory directly in the mmaps, after the mmap thread has released them back to the queue. That means new events can come in to the mmap ring and overwrite what was there previously, maybe even while deliver_event() is in the middle of parsing the event. Setting copy_on_queue for data[0] and data[1] makes all of the crashes go away for me. I get a lot of "[unknown]" shared objects shortly after perf top starts up during a full workload. I've been wondering about one side effect of how the mmap queues are processed, consider the following: cpu 0 cpu 1 exec create new mmap2 events scheduled to cpu 0 for whatever reason sample 1 sample 2 And let's say that perf top is backlogged processing the mmap ring of events generated for cpu 0, and sees sample 1 and sample 2 before getting to any of cpu 1's events. This means the thread and map and symbol objects won't exist and we'll get those '[Unknown]' histogram entries, and they won't go away. When it finally stops looping over the mmap ring for cpu 0's events it gets to cpu 1's mmap ring and sees the exec and mmap2 events but at that point it's far too late. I surmise from what I see with perf top right now that this happens a lot.
Target bindeb-pkg no longer install DTBs
Hi, Since 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 [kbuild: consolidate Devicetree dtb build rules], the target bindeb-pkg no longer installs DTBs in the .deb package. Thanks, Nuno
Target bindeb-pkg no longer install DTBs
Hi, Since 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 [kbuild: consolidate Devicetree dtb build rules], the target bindeb-pkg no longer installs DTBs in the .deb package. Thanks, Nuno
[PATCH RFC v2 2/4] mm: userfault: return VM_FAULT_RETRY on signals
There was a special path in handle_userfault() in the past that we'll
return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting
for userfault handling. We did that by reacquiring the mmap_sem before
returning. However that brings a risk in that the vmas might have
changed when we retake the mmap_sem and even we could be holding an
invalid vma structure. The problem was reported by syzbot.
This patch removes the special path and we'll return a VM_FAULT_RETRY
with the common path even if we have got such signals. Then for all the
architectures that is passing in VM_FAULT_ALLOW_RETRY into
handle_mm_fault(), we check not only for SIGKILL but for all the rest of
userspace pending signals right after we returned from
handle_mm_fault().
The idea comes from the upstream discussion between Linus and Andrea:
https://lkml.org/lkml/2017/10/30/560
(This patch contains a potential fix for a double-free of mmap_sem on
ARC architecture; please see https://lkml.org/lkml/2018/11/1/723 for
more information)
Suggested-by: Linus Torvalds
Suggested-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c | 2 +-
arch/arc/mm/fault.c| 11 +++
arch/arm/mm/fault.c| 14 ++
arch/arm64/mm/fault.c | 6 +++---
arch/hexagon/mm/vm_fault.c | 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 2 +-
arch/microblaze/mm/fault.c | 2 +-
arch/mips/mm/fault.c | 2 +-
arch/nds32/mm/fault.c | 6 +++---
arch/nios2/mm/fault.c | 2 +-
arch/openrisc/mm/fault.c | 2 +-
arch/parisc/mm/fault.c | 2 +-
arch/powerpc/mm/fault.c| 4 +++-
arch/riscv/mm/fault.c | 4 ++--
arch/s390/mm/fault.c | 9 ++---
arch/sh/mm/fault.c | 4
arch/sparc/mm/fault_32.c | 3 +++
arch/sparc/mm/fault_64.c | 3 +++
arch/um/kernel/trap.c | 5 -
arch/unicore32/mm/fault.c | 4 ++--
arch/x86/mm/fault.c| 12 +++-
arch/xtensa/mm/fault.c | 3 +++
fs/userfaultfd.c | 24
24 files changed, 73 insertions(+), 57 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index d73dc473fbb9..46e5e420ad2a 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -150,7 +150,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
the fault. */
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && signal_pending(current))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index c9da6102eb4f..52b6b71b74e2 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -142,11 +142,14 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
fault = handle_mm_fault(vma, address, flags);
/* If Pagefault was interrupted by SIGKILL, exit page fault "early" */
- if (unlikely(fatal_signal_pending(current))) {
- if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY))
+ if (unlikely(fatal_signal_pending(current) && user_mode(regs))) {
+ /*
+* VM_FAULT_RETRY means we have released the mmap_sem,
+* otherwise we need to drop it before leaving
+*/
+ if (!(fault & VM_FAULT_RETRY))
up_read(>mmap_sem);
- if (user_mode(regs))
- return;
+ return;
}
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index f4ea4c62c613..743077d19669 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -308,14 +308,20 @@ do_page_fault(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
fault = __do_page_fault(mm, addr, fsr, flags, tsk);
- /* If we need to retry but a fatal signal is pending, handle the
+ /* If we need to retry but a signal is pending, handle the
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
- if (!user_mode(regs))
+ if (fault & VM_FAULT_RETRY) {
+ if (fatal_signal_pending(current) && !user_mode(regs))
goto no_context;
- return 0;
+ else if (signal_pending(current))
+ /*
+* It's either a common signal, or a fatal
+* signal but for the userspace, we return
+* immediately.
+*/
+ return 0;
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7d9571f4ae3d..744d6451ea83 100644
---
[PATCH RFC v2 2/4] mm: userfault: return VM_FAULT_RETRY on signals
There was a special path in handle_userfault() in the past that we'll
return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting
for userfault handling. We did that by reacquiring the mmap_sem before
returning. However that brings a risk in that the vmas might have
changed when we retake the mmap_sem and even we could be holding an
invalid vma structure. The problem was reported by syzbot.
This patch removes the special path and we'll return a VM_FAULT_RETRY
with the common path even if we have got such signals. Then for all the
architectures that is passing in VM_FAULT_ALLOW_RETRY into
handle_mm_fault(), we check not only for SIGKILL but for all the rest of
userspace pending signals right after we returned from
handle_mm_fault().
The idea comes from the upstream discussion between Linus and Andrea:
https://lkml.org/lkml/2017/10/30/560
(This patch contains a potential fix for a double-free of mmap_sem on
ARC architecture; please see https://lkml.org/lkml/2018/11/1/723 for
more information)
Suggested-by: Linus Torvalds
Suggested-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c | 2 +-
arch/arc/mm/fault.c| 11 +++
arch/arm/mm/fault.c| 14 ++
arch/arm64/mm/fault.c | 6 +++---
arch/hexagon/mm/vm_fault.c | 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 2 +-
arch/microblaze/mm/fault.c | 2 +-
arch/mips/mm/fault.c | 2 +-
arch/nds32/mm/fault.c | 6 +++---
arch/nios2/mm/fault.c | 2 +-
arch/openrisc/mm/fault.c | 2 +-
arch/parisc/mm/fault.c | 2 +-
arch/powerpc/mm/fault.c| 4 +++-
arch/riscv/mm/fault.c | 4 ++--
arch/s390/mm/fault.c | 9 ++---
arch/sh/mm/fault.c | 4
arch/sparc/mm/fault_32.c | 3 +++
arch/sparc/mm/fault_64.c | 3 +++
arch/um/kernel/trap.c | 5 -
arch/unicore32/mm/fault.c | 4 ++--
arch/x86/mm/fault.c| 12 +++-
arch/xtensa/mm/fault.c | 3 +++
fs/userfaultfd.c | 24
24 files changed, 73 insertions(+), 57 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index d73dc473fbb9..46e5e420ad2a 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -150,7 +150,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
the fault. */
fault = handle_mm_fault(vma, address, flags);
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && signal_pending(current))
return;
if (unlikely(fault & VM_FAULT_ERROR)) {
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index c9da6102eb4f..52b6b71b74e2 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -142,11 +142,14 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
fault = handle_mm_fault(vma, address, flags);
/* If Pagefault was interrupted by SIGKILL, exit page fault "early" */
- if (unlikely(fatal_signal_pending(current))) {
- if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY))
+ if (unlikely(fatal_signal_pending(current) && user_mode(regs))) {
+ /*
+* VM_FAULT_RETRY means we have released the mmap_sem,
+* otherwise we need to drop it before leaving
+*/
+ if (!(fault & VM_FAULT_RETRY))
up_read(>mmap_sem);
- if (user_mode(regs))
- return;
+ return;
}
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index f4ea4c62c613..743077d19669 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -308,14 +308,20 @@ do_page_fault(unsigned long addr, unsigned int fsr,
struct pt_regs *regs)
fault = __do_page_fault(mm, addr, fsr, flags, tsk);
- /* If we need to retry but a fatal signal is pending, handle the
+ /* If we need to retry but a signal is pending, handle the
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
- if (!user_mode(regs))
+ if (fault & VM_FAULT_RETRY) {
+ if (fatal_signal_pending(current) && !user_mode(regs))
goto no_context;
- return 0;
+ else if (signal_pending(current))
+ /*
+* It's either a common signal, or a fatal
+* signal but for the userspace, we return
+* immediately.
+*/
+ return 0;
}
/*
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 7d9571f4ae3d..744d6451ea83 100644
---
[PATCH RFC v2 4/4] mm: gup: allow VM_FAULT_RETRY for multiple times
This is the gup counterpart of the change that allows the VM_FAULT_RETRY
to happen for more than once.
Signed-off-by: Peter Xu
---
mm/gup.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 6faff46cd409..8a0e7f9bd29a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -522,7 +522,10 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
if (*flags & FOLL_TRIED) {
- VM_WARN_ON_ONCE(fault_flags & FAULT_FLAG_ALLOW_RETRY);
+ /*
+* Note: FAULT_FLAG_ALLOW_RETRY and FAULT_FLAG_TRIED
+* can co-exist
+*/
fault_flags |= FAULT_FLAG_TRIED;
}
@@ -938,17 +941,23 @@ static __always_inline long
__get_user_pages_locked(struct task_struct *tsk,
/* VM_FAULT_RETRY triggered, so seek to the faulting offset */
pages += ret;
start += ret << PAGE_SHIFT;
+ lock_dropped = true;
+retry:
/*
* Repeat on the address that fired VM_FAULT_RETRY
-* without FAULT_FLAG_ALLOW_RETRY but with
+* with both FAULT_FLAG_ALLOW_RETRY and
* FAULT_FLAG_TRIED.
*/
*locked = 1;
- lock_dropped = true;
down_read(>mmap_sem);
ret = __get_user_pages(tsk, mm, start, 1, flags | FOLL_TRIED,
- pages, NULL, NULL);
+ pages, NULL, locked);
+ if (!*locked) {
+ /* Continue to retry until we succeeded */
+ BUG_ON(ret != 0);
+ goto retry;
+ }
if (ret != 1) {
BUG_ON(ret > 1);
if (!pages_done)
--
2.17.1
[PATCH RFC v2 4/4] mm: gup: allow VM_FAULT_RETRY for multiple times
This is the gup counterpart of the change that allows the VM_FAULT_RETRY
to happen for more than once.
Signed-off-by: Peter Xu
---
mm/gup.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 6faff46cd409..8a0e7f9bd29a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -522,7 +522,10 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
if (*flags & FOLL_TRIED) {
- VM_WARN_ON_ONCE(fault_flags & FAULT_FLAG_ALLOW_RETRY);
+ /*
+* Note: FAULT_FLAG_ALLOW_RETRY and FAULT_FLAG_TRIED
+* can co-exist
+*/
fault_flags |= FAULT_FLAG_TRIED;
}
@@ -938,17 +941,23 @@ static __always_inline long
__get_user_pages_locked(struct task_struct *tsk,
/* VM_FAULT_RETRY triggered, so seek to the faulting offset */
pages += ret;
start += ret << PAGE_SHIFT;
+ lock_dropped = true;
+retry:
/*
* Repeat on the address that fired VM_FAULT_RETRY
-* without FAULT_FLAG_ALLOW_RETRY but with
+* with both FAULT_FLAG_ALLOW_RETRY and
* FAULT_FLAG_TRIED.
*/
*locked = 1;
- lock_dropped = true;
down_read(>mmap_sem);
ret = __get_user_pages(tsk, mm, start, 1, flags | FOLL_TRIED,
- pages, NULL, NULL);
+ pages, NULL, locked);
+ if (!*locked) {
+ /* Continue to retry until we succeeded */
+ BUG_ON(ret != 0);
+ goto retry;
+ }
if (ret != 1) {
BUG_ON(ret > 1);
if (!pages_done)
--
2.17.1
[PATCH RFC v2 0/4] mm: some enhancements to the page fault mechanism
(sorry I got the cc list messed up; am sending another one with no change but only to fix the cc list) This is an RFC series as cleanup and enhancements to current page fault logic. The whole idea comes from the discussion between Andrea and Linus on the bug reported by syzbot here: https://lkml.org/lkml/2017/11/2/833 Basically it does two things: (a) Allows the page fault logic to be more interactive on not only SIGKILL, but also the rest of userspace signals, and, (b) Allows the page fault retry (VM_FAULT_RETRY) to happen for more than once. For (a): with the changes we should be able to react faster when page faults are working in parallel with userspace signals like SIGSTOP and SIGCONT (and more), and with that we can remove the buggy part in userfaultfd and benefit the whole page fault mechanism on faster signal processing to reach the userspace. For (b), we should be able to allow the page fault handler to loop for even more than twice. Some context: for now since we have FAULT_FLAG_ALLOW_RETRY we can allow to retry the page fault once with the same interrupt context, however never more than twice. This can be not only a potential cleanup to remove this assumption since AFAIU the code itself doesn't really have this twice-only limitation (though that should be a protective approach in the past), at the same time it'll greatly simplify future works like userfaultfd write-protect where it's possible to retry for more than twice (please have a look at [1] below for a possible user that might require the page fault to be handled for a third time; if we can remove the retry limitation we can simply drop that patch and those complexity). Some more details on each of the patch (even more in commit messages): Patch 1: A cleanup of existing GUP code to rename the confusing "nonblocking" parameter to "locked" which seems suite more. Patch 2: Complete the page fault faster for non-sigkill signals Patch 3: Remove the limitation to only allow to retry page fault for twice (page fault part) Patch 4: Similar work of patch 3, but for GUP. The series is only lightly tested. Before more tests, I'd be really glad to see whether there's any feedbacks on these changes, on whether the changes make any sense, or anything important that I may have missed, or any suggestions on how to better test the work, etc... Looking forward to your comments. Thanks, [1] https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/commit/?h=userfault=b245ecf6cf59156966f3da6e6b674f6695a5ffa5 Peter Xu (4): mm: gup: rename "nonblocking" to "locked" where proper mm: userfault: return VM_FAULT_RETRY on signals mm: allow VM_FAULT_RETRY for multiple times mm: gup: allow VM_FAULT_RETRY for multiple times arch/alpha/mm/fault.c | 4 +-- arch/arc/mm/fault.c| 12 arch/arm/mm/fault.c| 17 ++- arch/arm64/mm/fault.c | 11 ++- arch/hexagon/mm/vm_fault.c | 3 +- arch/ia64/mm/fault.c | 3 +- arch/m68k/mm/fault.c | 5 +--- arch/microblaze/mm/fault.c | 3 +- arch/mips/mm/fault.c | 3 +- arch/nds32/mm/fault.c | 7 ++--- arch/nios2/mm/fault.c | 5 +--- arch/openrisc/mm/fault.c | 3 +- arch/parisc/mm/fault.c | 4 +-- arch/powerpc/mm/fault.c| 9 ++ arch/riscv/mm/fault.c | 9 ++ arch/s390/mm/fault.c | 14 - arch/sh/mm/fault.c | 5 +++- arch/sparc/mm/fault_32.c | 4 ++- arch/sparc/mm/fault_64.c | 4 ++- arch/um/kernel/trap.c | 6 ++-- arch/unicore32/mm/fault.c | 10 ++- arch/x86/mm/fault.c| 13 ++-- arch/xtensa/mm/fault.c | 4 ++- fs/userfaultfd.c | 24 --- mm/gup.c | 61 +- mm/hugetlb.c | 8 ++--- 26 files changed, 114 insertions(+), 137 deletions(-) -- 2.17.1
[PATCH RFC v2 3/4] mm: allow VM_FAULT_RETRY for multiple times
The idea comes from a discussion between Linus and Andrea [1].
Before this patch we only allow a page fault to retry once. We achieved
this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
handle_mm_fault() the second time. This was majorly used to avoid
unexpected starvation of the system by looping over forever to handle
the page fault on a single page. However that should hardly happen, and
after all for each code path to return a VM_FAULT_RETRY we'll first wait
for a condition (during which time we should possibly yield the cpu) to
happen before VM_FAULT_RETRY is really returned.
This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY
flag when we receive VM_FAULT_RETRY. It means that the page fault
handler now can retry the page fault for multiple times if necessary
without the need to generate another page fault event. Meanwhile we
still keep the FAULT_FLAG_TRIED flag so page fault handler can still
identify whether a page fault is the first attempt or not.
GUP code is not touched yet and will be covered in follow up patch.
This will be a nice enhancement for current code at the same time a
supporting material for the future userfaultfd-writeprotect work since
in that work there will always be an explicit userfault writeprotect
retry for protected pages, and if that cannot resolve the page
fault (e.g., when userfaultfd-writeprotect is used in conjunction with
shared memory) then we'll possibly need a 3rd retry of the page fault.
It might also benefit other potential users who will have similar
requirement like userfault write-protection.
Please read the thread below for more information.
[1] https://lkml.org/lkml/2017/11/2/833
Suggested-by: Linus Torvalds
Suggested-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c | 2 +-
arch/arc/mm/fault.c| 1 -
arch/arm/mm/fault.c| 3 ---
arch/arm64/mm/fault.c | 5 -
arch/hexagon/mm/vm_fault.c | 1 -
arch/ia64/mm/fault.c | 1 -
arch/m68k/mm/fault.c | 3 ---
arch/microblaze/mm/fault.c | 1 -
arch/mips/mm/fault.c | 1 -
arch/nds32/mm/fault.c | 1 -
arch/nios2/mm/fault.c | 3 ---
arch/openrisc/mm/fault.c | 1 -
arch/parisc/mm/fault.c | 2 --
arch/powerpc/mm/fault.c| 5 -
arch/riscv/mm/fault.c | 5 -
arch/s390/mm/fault.c | 5 +
arch/sh/mm/fault.c | 1 -
arch/sparc/mm/fault_32.c | 1 -
arch/sparc/mm/fault_64.c | 1 -
arch/um/kernel/trap.c | 1 -
arch/unicore32/mm/fault.c | 6 +-
arch/x86/mm/fault.c| 1 -
arch/xtensa/mm/fault.c | 1 -
23 files changed, 3 insertions(+), 49 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 46e5e420ad2a..deae82bb83c1 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -169,7 +169,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
else
current->min_flt++;
if (fault & VM_FAULT_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ flags |= FAULT_FLAG_TRIED;
/* No need to up_read(>mmap_sem) as we would
* have already released it in __lock_page_or_retry
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 52b6b71b74e2..a8b02db45324 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -168,7 +168,6 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
}
if (fault & VM_FAULT_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
flags |= FAULT_FLAG_TRIED;
goto retry;
}
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 743077d19669..377781d8491a 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -342,9 +342,6 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
regs, addr);
}
if (fault & VM_FAULT_RETRY) {
- /* Clear FAULT_FLAG_ALLOW_RETRY to avoid any risk
- * of starvation. */
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
flags |= FAULT_FLAG_TRIED;
goto retry;
}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 744d6451ea83..8a26e03fc2bf 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -510,12 +510,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
return 0;
}
- /*
-* Clear FAULT_FLAG_ALLOW_RETRY to avoid any risk of
-* starvation.
-*/
if (mm_flags & FAULT_FLAG_ALLOW_RETRY) {
- mm_flags &= ~FAULT_FLAG_ALLOW_RETRY;
mm_flags |=
[PATCH RFC v2 1/4] mm: gup: rename "nonblocking" to "locked" where proper
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is returned.
We have the correct naming in e.g. get_user_pages_locked() or
get_user_pages_remote() as "locked", however there're still many places
that are using the "nonblocking" as name.
Renaming the places to "locked" where proper to better suite the
functionality of the variable. While at it, fixing up some of the
comments accordingly.
Signed-off-by: Peter Xu
---
mm/gup.c | 44 +---
mm/hugetlb.c | 8
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 841d7ef53591..6faff46cd409 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -500,12 +500,12 @@ static int get_gate_page(struct mm_struct *mm, unsigned
long address,
}
/*
- * mmap_sem must be held on entry. If @nonblocking != NULL and
- * *@flags does not include FOLL_NOWAIT, the mmap_sem may be released.
- * If it is, *@nonblocking will be set to 0 and -EBUSY returned.
+ * mmap_sem must be held on entry. If @locked != NULL and *@flags
+ * does not include FOLL_NOWAIT, the mmap_sem may be released. If it
+ * is, *@locked will be set to 0 and -EBUSY returned.
*/
static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
- unsigned long address, unsigned int *flags, int *nonblocking)
+ unsigned long address, unsigned int *flags, int *locked)
{
unsigned int fault_flags = 0;
vm_fault_t ret;
@@ -517,7 +517,7 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
fault_flags |= FAULT_FLAG_WRITE;
if (*flags & FOLL_REMOTE)
fault_flags |= FAULT_FLAG_REMOTE;
- if (nonblocking)
+ if (locked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
@@ -543,8 +543,8 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
}
if (ret & VM_FAULT_RETRY) {
- if (nonblocking && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
- *nonblocking = 0;
+ if (locked && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
+ *locked = 0;
return -EBUSY;
}
@@ -621,7 +621,7 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
* only intends to ensure the pages are faulted in.
* @vmas: array of pointers to vmas corresponding to each page.
* Or NULL if the caller does not require them.
- * @nonblocking: whether waiting for disk IO or mmap_sem contention
+ * @locked: whether we're still with the mmap_sem held
*
* Returns number of pages pinned. This may be fewer than the number
* requested. If nr_pages is 0 or negative, returns 0. If no pages
@@ -650,13 +650,11 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
* appropriate) must be called after the page is finished with, and
* before put_page is called.
*
- * If @nonblocking != NULL, __get_user_pages will not wait for disk IO
- * or mmap_sem contention, and if waiting is needed to pin all pages,
- * *@nonblocking will be set to 0. Further, if @gup_flags does not
- * include FOLL_NOWAIT, the mmap_sem will be released via up_read() in
- * this case.
+ * If @locked != NULL, *@locked will be set to 0 when mmap_sem is
+ * released by an up_read(). That can happen if @gup_flags does not
+ * has FOLL_NOWAIT.
*
- * A caller using such a combination of @nonblocking and @gup_flags
+ * A caller using such a combination of @locked and @gup_flags
* must therefore hold the mmap_sem for reading only, and recognize
* when it's been released. Otherwise, it must be held for either
* reading or writing and will not be released.
@@ -668,7 +666,7 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
- struct vm_area_struct **vmas, int *nonblocking)
+ struct vm_area_struct **vmas, int *locked)
{
long ret = 0, i = 0;
struct vm_area_struct *vma = NULL;
@@ -713,7 +711,7 @@ static long __get_user_pages(struct task_struct *tsk,
struct mm_struct *mm,
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
, _pages, i,
- gup_flags, nonblocking);
+
[PATCH RFC v2 0/4] mm: some enhancements to the page fault mechanism
(sorry I got the cc list messed up; am sending another one with no change but only to fix the cc list) This is an RFC series as cleanup and enhancements to current page fault logic. The whole idea comes from the discussion between Andrea and Linus on the bug reported by syzbot here: https://lkml.org/lkml/2017/11/2/833 Basically it does two things: (a) Allows the page fault logic to be more interactive on not only SIGKILL, but also the rest of userspace signals, and, (b) Allows the page fault retry (VM_FAULT_RETRY) to happen for more than once. For (a): with the changes we should be able to react faster when page faults are working in parallel with userspace signals like SIGSTOP and SIGCONT (and more), and with that we can remove the buggy part in userfaultfd and benefit the whole page fault mechanism on faster signal processing to reach the userspace. For (b), we should be able to allow the page fault handler to loop for even more than twice. Some context: for now since we have FAULT_FLAG_ALLOW_RETRY we can allow to retry the page fault once with the same interrupt context, however never more than twice. This can be not only a potential cleanup to remove this assumption since AFAIU the code itself doesn't really have this twice-only limitation (though that should be a protective approach in the past), at the same time it'll greatly simplify future works like userfaultfd write-protect where it's possible to retry for more than twice (please have a look at [1] below for a possible user that might require the page fault to be handled for a third time; if we can remove the retry limitation we can simply drop that patch and those complexity). Some more details on each of the patch (even more in commit messages): Patch 1: A cleanup of existing GUP code to rename the confusing "nonblocking" parameter to "locked" which seems suite more. Patch 2: Complete the page fault faster for non-sigkill signals Patch 3: Remove the limitation to only allow to retry page fault for twice (page fault part) Patch 4: Similar work of patch 3, but for GUP. The series is only lightly tested. Before more tests, I'd be really glad to see whether there's any feedbacks on these changes, on whether the changes make any sense, or anything important that I may have missed, or any suggestions on how to better test the work, etc... Looking forward to your comments. Thanks, [1] https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/commit/?h=userfault=b245ecf6cf59156966f3da6e6b674f6695a5ffa5 Peter Xu (4): mm: gup: rename "nonblocking" to "locked" where proper mm: userfault: return VM_FAULT_RETRY on signals mm: allow VM_FAULT_RETRY for multiple times mm: gup: allow VM_FAULT_RETRY for multiple times arch/alpha/mm/fault.c | 4 +-- arch/arc/mm/fault.c| 12 arch/arm/mm/fault.c| 17 ++- arch/arm64/mm/fault.c | 11 ++- arch/hexagon/mm/vm_fault.c | 3 +- arch/ia64/mm/fault.c | 3 +- arch/m68k/mm/fault.c | 5 +--- arch/microblaze/mm/fault.c | 3 +- arch/mips/mm/fault.c | 3 +- arch/nds32/mm/fault.c | 7 ++--- arch/nios2/mm/fault.c | 5 +--- arch/openrisc/mm/fault.c | 3 +- arch/parisc/mm/fault.c | 4 +-- arch/powerpc/mm/fault.c| 9 ++ arch/riscv/mm/fault.c | 9 ++ arch/s390/mm/fault.c | 14 - arch/sh/mm/fault.c | 5 +++- arch/sparc/mm/fault_32.c | 4 ++- arch/sparc/mm/fault_64.c | 4 ++- arch/um/kernel/trap.c | 6 ++-- arch/unicore32/mm/fault.c | 10 ++- arch/x86/mm/fault.c| 13 ++-- arch/xtensa/mm/fault.c | 4 ++- fs/userfaultfd.c | 24 --- mm/gup.c | 61 +- mm/hugetlb.c | 8 ++--- 26 files changed, 114 insertions(+), 137 deletions(-) -- 2.17.1
[PATCH RFC v2 3/4] mm: allow VM_FAULT_RETRY for multiple times
The idea comes from a discussion between Linus and Andrea [1].
Before this patch we only allow a page fault to retry once. We achieved
this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
handle_mm_fault() the second time. This was majorly used to avoid
unexpected starvation of the system by looping over forever to handle
the page fault on a single page. However that should hardly happen, and
after all for each code path to return a VM_FAULT_RETRY we'll first wait
for a condition (during which time we should possibly yield the cpu) to
happen before VM_FAULT_RETRY is really returned.
This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY
flag when we receive VM_FAULT_RETRY. It means that the page fault
handler now can retry the page fault for multiple times if necessary
without the need to generate another page fault event. Meanwhile we
still keep the FAULT_FLAG_TRIED flag so page fault handler can still
identify whether a page fault is the first attempt or not.
GUP code is not touched yet and will be covered in follow up patch.
This will be a nice enhancement for current code at the same time a
supporting material for the future userfaultfd-writeprotect work since
in that work there will always be an explicit userfault writeprotect
retry for protected pages, and if that cannot resolve the page
fault (e.g., when userfaultfd-writeprotect is used in conjunction with
shared memory) then we'll possibly need a 3rd retry of the page fault.
It might also benefit other potential users who will have similar
requirement like userfault write-protection.
Please read the thread below for more information.
[1] https://lkml.org/lkml/2017/11/2/833
Suggested-by: Linus Torvalds
Suggested-by: Andrea Arcangeli
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c | 2 +-
arch/arc/mm/fault.c| 1 -
arch/arm/mm/fault.c| 3 ---
arch/arm64/mm/fault.c | 5 -
arch/hexagon/mm/vm_fault.c | 1 -
arch/ia64/mm/fault.c | 1 -
arch/m68k/mm/fault.c | 3 ---
arch/microblaze/mm/fault.c | 1 -
arch/mips/mm/fault.c | 1 -
arch/nds32/mm/fault.c | 1 -
arch/nios2/mm/fault.c | 3 ---
arch/openrisc/mm/fault.c | 1 -
arch/parisc/mm/fault.c | 2 --
arch/powerpc/mm/fault.c| 5 -
arch/riscv/mm/fault.c | 5 -
arch/s390/mm/fault.c | 5 +
arch/sh/mm/fault.c | 1 -
arch/sparc/mm/fault_32.c | 1 -
arch/sparc/mm/fault_64.c | 1 -
arch/um/kernel/trap.c | 1 -
arch/unicore32/mm/fault.c | 6 +-
arch/x86/mm/fault.c| 1 -
arch/xtensa/mm/fault.c | 1 -
23 files changed, 3 insertions(+), 49 deletions(-)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 46e5e420ad2a..deae82bb83c1 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -169,7 +169,7 @@ do_page_fault(unsigned long address, unsigned long mmcsr,
else
current->min_flt++;
if (fault & VM_FAULT_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ flags |= FAULT_FLAG_TRIED;
/* No need to up_read(>mmap_sem) as we would
* have already released it in __lock_page_or_retry
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index 52b6b71b74e2..a8b02db45324 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -168,7 +168,6 @@ void do_page_fault(unsigned long address, struct pt_regs
*regs)
}
if (fault & VM_FAULT_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
flags |= FAULT_FLAG_TRIED;
goto retry;
}
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 743077d19669..377781d8491a 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -342,9 +342,6 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
regs, addr);
}
if (fault & VM_FAULT_RETRY) {
- /* Clear FAULT_FLAG_ALLOW_RETRY to avoid any risk
- * of starvation. */
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
flags |= FAULT_FLAG_TRIED;
goto retry;
}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 744d6451ea83..8a26e03fc2bf 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -510,12 +510,7 @@ static int __kprobes do_page_fault(unsigned long addr,
unsigned int esr,
return 0;
}
- /*
-* Clear FAULT_FLAG_ALLOW_RETRY to avoid any risk of
-* starvation.
-*/
if (mm_flags & FAULT_FLAG_ALLOW_RETRY) {
- mm_flags &= ~FAULT_FLAG_ALLOW_RETRY;
mm_flags |=
[PATCH RFC v2 1/4] mm: gup: rename "nonblocking" to "locked" where proper
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is returned.
We have the correct naming in e.g. get_user_pages_locked() or
get_user_pages_remote() as "locked", however there're still many places
that are using the "nonblocking" as name.
Renaming the places to "locked" where proper to better suite the
functionality of the variable. While at it, fixing up some of the
comments accordingly.
Signed-off-by: Peter Xu
---
mm/gup.c | 44 +---
mm/hugetlb.c | 8
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 841d7ef53591..6faff46cd409 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -500,12 +500,12 @@ static int get_gate_page(struct mm_struct *mm, unsigned
long address,
}
/*
- * mmap_sem must be held on entry. If @nonblocking != NULL and
- * *@flags does not include FOLL_NOWAIT, the mmap_sem may be released.
- * If it is, *@nonblocking will be set to 0 and -EBUSY returned.
+ * mmap_sem must be held on entry. If @locked != NULL and *@flags
+ * does not include FOLL_NOWAIT, the mmap_sem may be released. If it
+ * is, *@locked will be set to 0 and -EBUSY returned.
*/
static int faultin_page(struct task_struct *tsk, struct vm_area_struct *vma,
- unsigned long address, unsigned int *flags, int *nonblocking)
+ unsigned long address, unsigned int *flags, int *locked)
{
unsigned int fault_flags = 0;
vm_fault_t ret;
@@ -517,7 +517,7 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
fault_flags |= FAULT_FLAG_WRITE;
if (*flags & FOLL_REMOTE)
fault_flags |= FAULT_FLAG_REMOTE;
- if (nonblocking)
+ if (locked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
if (*flags & FOLL_NOWAIT)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
@@ -543,8 +543,8 @@ static int faultin_page(struct task_struct *tsk, struct
vm_area_struct *vma,
}
if (ret & VM_FAULT_RETRY) {
- if (nonblocking && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
- *nonblocking = 0;
+ if (locked && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
+ *locked = 0;
return -EBUSY;
}
@@ -621,7 +621,7 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
* only intends to ensure the pages are faulted in.
* @vmas: array of pointers to vmas corresponding to each page.
* Or NULL if the caller does not require them.
- * @nonblocking: whether waiting for disk IO or mmap_sem contention
+ * @locked: whether we're still with the mmap_sem held
*
* Returns number of pages pinned. This may be fewer than the number
* requested. If nr_pages is 0 or negative, returns 0. If no pages
@@ -650,13 +650,11 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
* appropriate) must be called after the page is finished with, and
* before put_page is called.
*
- * If @nonblocking != NULL, __get_user_pages will not wait for disk IO
- * or mmap_sem contention, and if waiting is needed to pin all pages,
- * *@nonblocking will be set to 0. Further, if @gup_flags does not
- * include FOLL_NOWAIT, the mmap_sem will be released via up_read() in
- * this case.
+ * If @locked != NULL, *@locked will be set to 0 when mmap_sem is
+ * released by an up_read(). That can happen if @gup_flags does not
+ * has FOLL_NOWAIT.
*
- * A caller using such a combination of @nonblocking and @gup_flags
+ * A caller using such a combination of @locked and @gup_flags
* must therefore hold the mmap_sem for reading only, and recognize
* when it's been released. Otherwise, it must be held for either
* reading or writing and will not be released.
@@ -668,7 +666,7 @@ static int check_vma_flags(struct vm_area_struct *vma,
unsigned long gup_flags)
static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
- struct vm_area_struct **vmas, int *nonblocking)
+ struct vm_area_struct **vmas, int *locked)
{
long ret = 0, i = 0;
struct vm_area_struct *vma = NULL;
@@ -713,7 +711,7 @@ static long __get_user_pages(struct task_struct *tsk,
struct mm_struct *mm,
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
, _pages, i,
- gup_flags, nonblocking);
+
[PATCH] leds: trigger: Fix sleeping function called from invalid context
We will meet below issue due to mutex_lock() is called in interrupt context.
The mutex lock is used to protect the pattern trigger data, but before changing
new pattern trigger data (pattern values or repeat value) by users, we always
cancel the timer firstly to clear previous patterns' performance. That means
there is no race in pattern_trig_timer_function(), so we can drop the mutex
lock in pattern_trig_timer_function() to avoid this issue.
Moreover we can move the timer cancelling into mutex protection, since there
is no deadlock risk if we remove the mutex lock in
pattern_trig_timer_function().
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted
4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x7c/0x9c)
[] (dump_stack) from [] (___might_sleep+0xf4/0x158)
[] (___might_sleep) from [] (mutex_lock+0x18/0x60)
[] (mutex_lock) from []
(pattern_trig_timer_function+0x1c/0x11c)
[] (pattern_trig_timer_function) from []
(call_timer_fn+0x1c/0x90)
[] (call_timer_fn) from [] (expire_timers+0x94/0xa4)
[] (expire_timers) from [] (run_timer_softirq+0x108/0x15c)
[] (run_timer_softirq) from [] (__do_softirq+0x1d4/0x258)
[] (__do_softirq) from [] (irq_exit+0x64/0xc4)
[] (irq_exit) from [] (__handle_domain_irq+0x80/0xb4)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x90)
[] (gic_handle_irq) from [] (__irq_svc+0x58/0x74)
Exception stack(0xeb483f60 to 0xeb483fa8)
3f60: eb9afaa0 c0217e80 e000 c0e06408
3f80: 0002 c0e0647c c0c6a5f0 c0e04900 eb483fb0 c0207ea8 c0207e98
3fa0: 60020013
[] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x38)
[] (arch_cpu_idle) from [] (do_idle+0x138/0x268)
[] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
[] (cpu_startup_entry) from [<402022ec>] (0x402022ec)
Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger")
Reported-by: Geert Uytterhoeven
Signed-off-by: Baolin Wang
---
drivers/leds/trigger/ledtrig-pattern.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-pattern.c
b/drivers/leds/trigger/ledtrig-pattern.c
index 174a298..1870cf8 100644
--- a/drivers/leds/trigger/ledtrig-pattern.c
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -75,8 +75,6 @@ static void pattern_trig_timer_function(struct timer_list *t)
{
struct pattern_trig_data *data = from_timer(data, t, timer);
- mutex_lock(>lock);
-
for (;;) {
if (!data->is_indefinite && !data->repeat)
break;
@@ -117,8 +115,6 @@ static void pattern_trig_timer_function(struct timer_list
*t)
break;
}
-
- mutex_unlock(>lock);
}
static int pattern_trig_start_pattern(struct led_classdev *led_cdev)
@@ -177,14 +173,10 @@ static ssize_t repeat_store(struct device *dev, struct
device_attribute *attr,
if (res < -1 || res == 0)
return -EINVAL;
- /*
-* Clear previous patterns' performence firstly, and remove the timer
-* without mutex lock to avoid dead lock.
-*/
- del_timer_sync(>timer);
-
mutex_lock(>lock);
+ del_timer_sync(>timer);
+
if (data->is_hw_pattern)
led_cdev->pattern_clear(led_cdev);
@@ -235,14 +227,10 @@ static ssize_t pattern_trig_store_patterns(struct
led_classdev *led_cdev,
struct pattern_trig_data *data = led_cdev->trigger_data;
int ccount, cr, offset = 0, err = 0;
- /*
-* Clear previous patterns' performence firstly, and remove the timer
-* without mutex lock to avoid dead lock.
-*/
- del_timer_sync(>timer);
-
mutex_lock(>lock);
+ del_timer_sync(>timer);
+
if (data->is_hw_pattern)
led_cdev->pattern_clear(led_cdev);
--
1.7.9.5
[PATCH] leds: trigger: Fix sleeping function called from invalid context
We will meet below issue due to mutex_lock() is called in interrupt context.
The mutex lock is used to protect the pattern trigger data, but before changing
new pattern trigger data (pattern values or repeat value) by users, we always
cancel the timer firstly to clear previous patterns' performance. That means
there is no race in pattern_trig_timer_function(), so we can drop the mutex
lock in pattern_trig_timer_function() to avoid this issue.
Moreover we can move the timer cancelling into mutex protection, since there
is no deadlock risk if we remove the mutex lock in
pattern_trig_timer_function().
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted
4.20.0-rc1-koelsch-00841-ga338c8181013c1a9 #171
Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x7c/0x9c)
[] (dump_stack) from [] (___might_sleep+0xf4/0x158)
[] (___might_sleep) from [] (mutex_lock+0x18/0x60)
[] (mutex_lock) from []
(pattern_trig_timer_function+0x1c/0x11c)
[] (pattern_trig_timer_function) from []
(call_timer_fn+0x1c/0x90)
[] (call_timer_fn) from [] (expire_timers+0x94/0xa4)
[] (expire_timers) from [] (run_timer_softirq+0x108/0x15c)
[] (run_timer_softirq) from [] (__do_softirq+0x1d4/0x258)
[] (__do_softirq) from [] (irq_exit+0x64/0xc4)
[] (irq_exit) from [] (__handle_domain_irq+0x80/0xb4)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x90)
[] (gic_handle_irq) from [] (__irq_svc+0x58/0x74)
Exception stack(0xeb483f60 to 0xeb483fa8)
3f60: eb9afaa0 c0217e80 e000 c0e06408
3f80: 0002 c0e0647c c0c6a5f0 c0e04900 eb483fb0 c0207ea8 c0207e98
3fa0: 60020013
[] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x38)
[] (arch_cpu_idle) from [] (do_idle+0x138/0x268)
[] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
[] (cpu_startup_entry) from [<402022ec>] (0x402022ec)
Fixes: 5fd752b6b3a2 ("leds: core: Introduce LED pattern trigger")
Reported-by: Geert Uytterhoeven
Signed-off-by: Baolin Wang
---
drivers/leds/trigger/ledtrig-pattern.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-pattern.c
b/drivers/leds/trigger/ledtrig-pattern.c
index 174a298..1870cf8 100644
--- a/drivers/leds/trigger/ledtrig-pattern.c
+++ b/drivers/leds/trigger/ledtrig-pattern.c
@@ -75,8 +75,6 @@ static void pattern_trig_timer_function(struct timer_list *t)
{
struct pattern_trig_data *data = from_timer(data, t, timer);
- mutex_lock(>lock);
-
for (;;) {
if (!data->is_indefinite && !data->repeat)
break;
@@ -117,8 +115,6 @@ static void pattern_trig_timer_function(struct timer_list
*t)
break;
}
-
- mutex_unlock(>lock);
}
static int pattern_trig_start_pattern(struct led_classdev *led_cdev)
@@ -177,14 +173,10 @@ static ssize_t repeat_store(struct device *dev, struct
device_attribute *attr,
if (res < -1 || res == 0)
return -EINVAL;
- /*
-* Clear previous patterns' performence firstly, and remove the timer
-* without mutex lock to avoid dead lock.
-*/
- del_timer_sync(>timer);
-
mutex_lock(>lock);
+ del_timer_sync(>timer);
+
if (data->is_hw_pattern)
led_cdev->pattern_clear(led_cdev);
@@ -235,14 +227,10 @@ static ssize_t pattern_trig_store_patterns(struct
led_classdev *led_cdev,
struct pattern_trig_data *data = led_cdev->trigger_data;
int ccount, cr, offset = 0, err = 0;
- /*
-* Clear previous patterns' performence firstly, and remove the timer
-* without mutex lock to avoid dead lock.
-*/
- del_timer_sync(>timer);
-
mutex_lock(>lock);
+ del_timer_sync(>timer);
+
if (data->is_hw_pattern)
led_cdev->pattern_clear(led_cdev);
--
1.7.9.5
[PATCHv3 4/4] arm64: dts: layerscape: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.
Signed-off-by: Hou Zhiqiang
---
V3:
- Reworded the subject.
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 8
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 5da732f82fa0..028a6daa5597 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -475,7 +475,7 @@
};
pcie@340 {
- compatible = "fsl,ls1012a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 3fed504b5381..5480d6c4c548 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -661,7 +661,7 @@
};
pcie@340 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -686,7 +686,7 @@
};
pcie@350 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -711,7 +711,7 @@
};
pcie@360 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
0x50 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 51cbd50012d6..519315c5d507 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -630,7 +630,7 @@
};
pcie@340 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -655,7 +655,7 @@
};
pcie@350 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -680,7 +680,7 @@
};
pcie@360 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
0x50 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index a07f612ab56b..10b253c88a16 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -512,7 +512,7 @@
};
pcie@340 {
- compatible = "fsl,ls1088a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
[PATCHv3 4/4] arm64: dts: layerscape: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.
Signed-off-by: Hou Zhiqiang
---
V3:
- Reworded the subject.
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 +++---
arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 8
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 5da732f82fa0..028a6daa5597 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -475,7 +475,7 @@
};
pcie@340 {
- compatible = "fsl,ls1012a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1012a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 3fed504b5381..5480d6c4c548 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -661,7 +661,7 @@
};
pcie@340 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -686,7 +686,7 @@
};
pcie@350 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -711,7 +711,7 @@
};
pcie@360 {
- compatible = "fsl,ls1043a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1043a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
0x50 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 51cbd50012d6..519315c5d507 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -630,7 +630,7 @@
};
pcie@340 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -655,7 +655,7 @@
};
pcie@350 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -680,7 +680,7 @@
};
pcie@360 {
- compatible = "fsl,ls1046a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1046a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
0x50 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index a07f612ab56b..10b253c88a16 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -512,7 +512,7 @@
};
pcie@340 {
- compatible = "fsl,ls1088a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
[PATCHv3 2/4] dt-bindings: pci: layerscape-pci: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the compatible string "snps,dw-pcie", it is for the reference
platform driver for PCI RC IP Protoyping Kits based on the ARC SDP,
so it is not suitable for all platform with designware PCIe controller,
and platform vendors have themselves' drivers.
The compatible string "snsp,dw-pcie" was added by mistake and it's not
matched that time, but it is matched because PCIe drivers has been
collected recently.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Rob Herring
---
V3:
- no change
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 5eb1c202932f..9b2b8d66d1f4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -13,8 +13,8 @@ information.
Required properties:
- compatible: should contain the platform identifier such as:
-"fsl,ls1021a-pcie", "snps,dw-pcie"
-"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+"fsl,ls1021a-pcie"
+"fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
"fsl,ls2088a-pcie"
"fsl,ls1088a-pcie"
"fsl,ls1046a-pcie"
@@ -36,7 +36,7 @@ Required properties:
Example:
pcie@340 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001 /* controller registers
*/
0x40 0x 0x0 0x2000>; /* configuration space
*/
reg-names = "regs", "config";
--
2.17.1
[PATCHv3 3/4] ARM: dts: ls1021a: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.
Signed-off-by: Hou Zhiqiang
---
V3:
- Reworded the subject.
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index bdd6e66a79ad..1aaa3288a450 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -716,7 +716,7 @@
};
pcie@340 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -739,7 +739,7 @@
};
pcie@350 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0350 0x0 0x0001 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
--
2.17.1
[PATCHv3 0/4] dts/layerscape-pci: removed unsuitable compatible string
From: Hou Zhiqiang Removed the compatible string "snps,dw-pcie" from FSL layerscape-pci compatible string list. Hou Zhiqiang (4): dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1043a-pcie" dt-bindings: pci: layerscape-pci: removed compatible string "snps,dw-pcie" ARM: dts: ls1021a: removed compatible string "snps,dw-pcie" arm64: dts: layerscape: removed compatible string "snps,dw-pcie" .../devicetree/bindings/pci/layerscape-pci.txt | 7 --- arch/arm/boot/dts/ls1021a.dtsi | 4 ++-- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 8 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12 8 files changed, 24 insertions(+), 27 deletions(-) -- 2.17.1
[PATCHv3 2/4] dt-bindings: pci: layerscape-pci: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the compatible string "snps,dw-pcie", it is for the reference
platform driver for PCI RC IP Protoyping Kits based on the ARC SDP,
so it is not suitable for all platform with designware PCIe controller,
and platform vendors have themselves' drivers.
The compatible string "snsp,dw-pcie" was added by mistake and it's not
matched that time, but it is matched because PCIe drivers has been
collected recently.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Rob Herring
---
V3:
- no change
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 5eb1c202932f..9b2b8d66d1f4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -13,8 +13,8 @@ information.
Required properties:
- compatible: should contain the platform identifier such as:
-"fsl,ls1021a-pcie", "snps,dw-pcie"
-"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
+"fsl,ls1021a-pcie"
+"fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
"fsl,ls2088a-pcie"
"fsl,ls1088a-pcie"
"fsl,ls1046a-pcie"
@@ -36,7 +36,7 @@ Required properties:
Example:
pcie@340 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001 /* controller registers
*/
0x40 0x 0x0 0x2000>; /* configuration space
*/
reg-names = "regs", "config";
--
2.17.1
[PATCHv3 3/4] ARM: dts: ls1021a: removed compatible string "snps,dw-pcie"
From: Hou Zhiqiang
Removed the wrong compatible string "snps,dw-pcie", in case
match incorrect driver.
Signed-off-by: Hou Zhiqiang
---
V3:
- Reworded the subject.
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index bdd6e66a79ad..1aaa3288a450 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -716,7 +716,7 @@
};
pcie@340 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0340 0x0 0x0001 /* controller
registers */
0x40 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
@@ -739,7 +739,7 @@
};
pcie@350 {
- compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+ compatible = "fsl,ls1021a-pcie";
reg = <0x00 0x0350 0x0 0x0001 /* controller
registers */
0x48 0x 0x0 0x2000>; /*
configuration space */
reg-names = "regs", "config";
--
2.17.1
[PATCHv3 0/4] dts/layerscape-pci: removed unsuitable compatible string
From: Hou Zhiqiang Removed the compatible string "snps,dw-pcie" from FSL layerscape-pci compatible string list. Hou Zhiqiang (4): dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1043a-pcie" dt-bindings: pci: layerscape-pci: removed compatible string "snps,dw-pcie" ARM: dts: ls1021a: removed compatible string "snps,dw-pcie" arm64: dts: layerscape: removed compatible string "snps,dw-pcie" .../devicetree/bindings/pci/layerscape-pci.txt | 7 --- arch/arm/boot/dts/ls1021a.dtsi | 4 ++-- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 2 +- arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 6 +++--- arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 8 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 12 8 files changed, 24 insertions(+), 27 deletions(-) -- 2.17.1
[PATCHv3 1/4] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1043a-pcie"
From: Hou Zhiqiang The PCIe compatible string for LS1043A was lost, so add it. Signed-off-by: Hou Zhiqiang Reviewed-by: Rob Herring --- V3: - no change Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 66df1e81e0b8..5eb1c202932f 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -18,6 +18,7 @@ Required properties: "fsl,ls2088a-pcie" "fsl,ls1088a-pcie" "fsl,ls1046a-pcie" +"fsl,ls1043a-pcie" "fsl,ls1012a-pcie" - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an -- 2.17.1
[PATCHv3 1/4] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1043a-pcie"
From: Hou Zhiqiang The PCIe compatible string for LS1043A was lost, so add it. Signed-off-by: Hou Zhiqiang Reviewed-by: Rob Herring --- V3: - no change Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 66df1e81e0b8..5eb1c202932f 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -18,6 +18,7 @@ Required properties: "fsl,ls2088a-pcie" "fsl,ls1088a-pcie" "fsl,ls1046a-pcie" +"fsl,ls1043a-pcie" "fsl,ls1012a-pcie" - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an -- 2.17.1
[PATCH 1/2] nds32: Fix the missing "fpu_dp" message.
The "fpu_dp" should be added to hwcap_str table to make sure the cpu features
displayed correctly.
Signed-off-by: Nylon Chen
---
arch/nds32/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
index eacc79024879..e39274a21481 100644
--- a/arch/nds32/kernel/setup.c
+++ b/arch/nds32/kernel/setup.c
@@ -71,6 +71,7 @@ static const char *hwcap_str[] = {
"mac",
"l2c",
"dx_regs",
+ "fpu_dp",
"v2",
NULL,
};
--
2.18.0
[PATCH 2/2] nds32: support hardware prefetcher
We add a config for user to enable or disable this feature.
It can be used to control the hardware prefetch function.
Signed-off-by: Nylon Chen
---
arch/nds32/Kconfig.cpu| 7 +++
arch/nds32/include/asm/bitfield.h | 6 ++
arch/nds32/kernel/head.S | 2 +-
arch/nds32/kernel/setup.c | 7 +++
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
index b8c8984d1456..8fd1236db3fa 100644
--- a/arch/nds32/Kconfig.cpu
+++ b/arch/nds32/Kconfig.cpu
@@ -143,6 +143,13 @@ config CACHE_L2
Say Y here to enable L2 cache if your SoC are integrated with L2CC.
If unsure, say N.
+config HW_PRE
+ bool "Enable hardware prefetcher"
+default y
+ help
+ Say Y here to enable hardware prefetcher feature.
+ Only when CPU_VER.REV >= 0x09 can support.
+
menu "Memory configuration"
choice
diff --git a/arch/nds32/include/asm/bitfield.h
b/arch/nds32/include/asm/bitfield.h
index 8e84fc385b94..2a33700e7ffa 100644
--- a/arch/nds32/include/asm/bitfield.h
+++ b/arch/nds32/include/asm/bitfield.h
@@ -735,14 +735,20 @@
#define N13MISC_CTL_offRTP 1 /* Disable Return Target Predictor */
#define N13MISC_CTL_offPTEPF 2 /* Disable HPTWK L2 PTE pefetch */
#define N13MISC_CTL_offSP_SHADOW_EN4 /* Enable shadow stack pointers
*/
+#define MISC_CTL_offHWPRE 11 /* Enable HardWare PREFETCH */
/* bit 6, 9:31 reserved */
#define N13MISC_CTL_makBTB ( 0x1 << N13MISC_CTL_offBTB )
#define N13MISC_CTL_makRTP ( 0x1 << N13MISC_CTL_offRTP )
#define N13MISC_CTL_makPTEPF ( 0x1 << N13MISC_CTL_offPTEPF )
#define N13MISC_CTL_makSP_SHADOW_EN( 0x1 << N13MISC_CTL_offSP_SHADOW_EN )
+#define MISC_CTL_makHWPRE_EN ( 0x1 << MISC_CTL_offHWPRE )
+#ifdef CONFIG_HW_PRE
+#define MISC_init
(N13MISC_CTL_makBTB|N13MISC_CTL_makRTP|N13MISC_CTL_makSP_SHADOW_EN|MISC_CTL_makHWPRE_EN)
+#else
#define MISC_init
(N13MISC_CTL_makBTB|N13MISC_CTL_makRTP|N13MISC_CTL_makSP_SHADOW_EN)
+#endif
/**
* PRUSR_ACC_CTL (Privileged Resource User Access Control Registers)
diff --git a/arch/nds32/kernel/head.S b/arch/nds32/kernel/head.S
index c5fdae174ced..029e27fb0d71 100644
--- a/arch/nds32/kernel/head.S
+++ b/arch/nds32/kernel/head.S
@@ -160,7 +160,7 @@ _tlb:
#endif
mtsr$r3, $TLB_MISC
- mfsr$r0, $MISC_CTL ! Enable BTB and RTP and shadow sp
+ mfsr$r0, $MISC_CTL ! Enable BTB, RTP, shadow sp and HW_PRE
ori $r0, $r0, #MISC_init
mtsr$r0, $MISC_CTL
diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
index e39274a21481..39384952d2ef 100644
--- a/arch/nds32/kernel/setup.c
+++ b/arch/nds32/kernel/setup.c
@@ -38,6 +38,7 @@
#define HWCAP_FPU_DP 0x04
#define HWCAP_V2 0x08
#define HWCAP_DX_REGS 0x10
+#define HWCAP_HWPRE0x20
unsigned long cpu_id, cpu_rev, cpu_cfgid;
char cpu_series;
@@ -73,6 +74,7 @@ static const char *hwcap_str[] = {
"dx_regs",
"fpu_dp",
"v2",
+ "hw_pre",
NULL,
};
@@ -213,6 +215,11 @@ static void __init setup_cpuinfo(void)
if (__nds32__mfsr(NDS32_SR_MSC_CFG) & MSC_CFG_mskL2C)
elf_hwcap |= HWCAP_L2C;
+#ifdef CONFIG_HW_PRE
+ if (__nds32__mfsr(NDS32_SR_MISC_CTL) & MISC_CTL_makHWPRE_EN)
+ elf_hwcap |= HWCAP_HWPRE;
+#endif
+
tmp = __nds32__mfsr(NDS32_SR_CACHE_CTL);
if (!IS_ENABLED(CONFIG_CPU_DCACHE_DISABLE))
tmp |= CACHE_CTL_mskDC_EN;
--
2.18.0
[PATCH 1/2] nds32: Fix the missing "fpu_dp" message.
The "fpu_dp" should be added to hwcap_str table to make sure the cpu features
displayed correctly.
Signed-off-by: Nylon Chen
---
arch/nds32/kernel/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
index eacc79024879..e39274a21481 100644
--- a/arch/nds32/kernel/setup.c
+++ b/arch/nds32/kernel/setup.c
@@ -71,6 +71,7 @@ static const char *hwcap_str[] = {
"mac",
"l2c",
"dx_regs",
+ "fpu_dp",
"v2",
NULL,
};
--
2.18.0
[PATCH 2/2] nds32: support hardware prefetcher
We add a config for user to enable or disable this feature.
It can be used to control the hardware prefetch function.
Signed-off-by: Nylon Chen
---
arch/nds32/Kconfig.cpu| 7 +++
arch/nds32/include/asm/bitfield.h | 6 ++
arch/nds32/kernel/head.S | 2 +-
arch/nds32/kernel/setup.c | 7 +++
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
index b8c8984d1456..8fd1236db3fa 100644
--- a/arch/nds32/Kconfig.cpu
+++ b/arch/nds32/Kconfig.cpu
@@ -143,6 +143,13 @@ config CACHE_L2
Say Y here to enable L2 cache if your SoC are integrated with L2CC.
If unsure, say N.
+config HW_PRE
+ bool "Enable hardware prefetcher"
+default y
+ help
+ Say Y here to enable hardware prefetcher feature.
+ Only when CPU_VER.REV >= 0x09 can support.
+
menu "Memory configuration"
choice
diff --git a/arch/nds32/include/asm/bitfield.h
b/arch/nds32/include/asm/bitfield.h
index 8e84fc385b94..2a33700e7ffa 100644
--- a/arch/nds32/include/asm/bitfield.h
+++ b/arch/nds32/include/asm/bitfield.h
@@ -735,14 +735,20 @@
#define N13MISC_CTL_offRTP 1 /* Disable Return Target Predictor */
#define N13MISC_CTL_offPTEPF 2 /* Disable HPTWK L2 PTE pefetch */
#define N13MISC_CTL_offSP_SHADOW_EN4 /* Enable shadow stack pointers
*/
+#define MISC_CTL_offHWPRE 11 /* Enable HardWare PREFETCH */
/* bit 6, 9:31 reserved */
#define N13MISC_CTL_makBTB ( 0x1 << N13MISC_CTL_offBTB )
#define N13MISC_CTL_makRTP ( 0x1 << N13MISC_CTL_offRTP )
#define N13MISC_CTL_makPTEPF ( 0x1 << N13MISC_CTL_offPTEPF )
#define N13MISC_CTL_makSP_SHADOW_EN( 0x1 << N13MISC_CTL_offSP_SHADOW_EN )
+#define MISC_CTL_makHWPRE_EN ( 0x1 << MISC_CTL_offHWPRE )
+#ifdef CONFIG_HW_PRE
+#define MISC_init
(N13MISC_CTL_makBTB|N13MISC_CTL_makRTP|N13MISC_CTL_makSP_SHADOW_EN|MISC_CTL_makHWPRE_EN)
+#else
#define MISC_init
(N13MISC_CTL_makBTB|N13MISC_CTL_makRTP|N13MISC_CTL_makSP_SHADOW_EN)
+#endif
/**
* PRUSR_ACC_CTL (Privileged Resource User Access Control Registers)
diff --git a/arch/nds32/kernel/head.S b/arch/nds32/kernel/head.S
index c5fdae174ced..029e27fb0d71 100644
--- a/arch/nds32/kernel/head.S
+++ b/arch/nds32/kernel/head.S
@@ -160,7 +160,7 @@ _tlb:
#endif
mtsr$r3, $TLB_MISC
- mfsr$r0, $MISC_CTL ! Enable BTB and RTP and shadow sp
+ mfsr$r0, $MISC_CTL ! Enable BTB, RTP, shadow sp and HW_PRE
ori $r0, $r0, #MISC_init
mtsr$r0, $MISC_CTL
diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
index e39274a21481..39384952d2ef 100644
--- a/arch/nds32/kernel/setup.c
+++ b/arch/nds32/kernel/setup.c
@@ -38,6 +38,7 @@
#define HWCAP_FPU_DP 0x04
#define HWCAP_V2 0x08
#define HWCAP_DX_REGS 0x10
+#define HWCAP_HWPRE0x20
unsigned long cpu_id, cpu_rev, cpu_cfgid;
char cpu_series;
@@ -73,6 +74,7 @@ static const char *hwcap_str[] = {
"dx_regs",
"fpu_dp",
"v2",
+ "hw_pre",
NULL,
};
@@ -213,6 +215,11 @@ static void __init setup_cpuinfo(void)
if (__nds32__mfsr(NDS32_SR_MSC_CFG) & MSC_CFG_mskL2C)
elf_hwcap |= HWCAP_L2C;
+#ifdef CONFIG_HW_PRE
+ if (__nds32__mfsr(NDS32_SR_MISC_CTL) & MISC_CTL_makHWPRE_EN)
+ elf_hwcap |= HWCAP_HWPRE;
+#endif
+
tmp = __nds32__mfsr(NDS32_SR_CACHE_CTL);
if (!IS_ENABLED(CONFIG_CPU_DCACHE_DISABLE))
tmp |= CACHE_CTL_mskDC_EN;
--
2.18.0
BUG: unable to handle kernel paging request in locks_remove_file
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1103882b40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=1d200d0b1db9c9f449d0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1d200d0b1db9c9f44...@syzkaller.appspotmail.com kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at 880194657bb8 PGD be01067 P4D be01067 PUD 1bf029063 PMD 8001946001e3 Oops: 0011 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8074 Comm: syz-executor4 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x880194657bb8 Code: c1 eb 86 af 8c 32 00 f1 ff 1f d0 7c 65 94 01 88 ff ff f8 7d 65 94 01 88 ff ff 00 00 00 00 00 fc ff df 04 00 00 00 00 00 00 00 <78> 7d 65 94 01 88 ff ff bc 9e 2b 81 ff ff ff ff 38 89 d3 8c 01 88 kobject: 'loop5' (fd72d949): kobject_uevent_env RSP: 0018:880194657508 EFLAGS: 00010212 RAX: 0004 RBX: 880194657bb8 RCX: c9000a5f1000 RDX: 039f RSI: 81ed5c9e RDI: 880194657588 RBP: 8801946576f0 R08: 88018cd380c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d9678080 R13: 880194657588 R14: 1100328caea5 R15: dc00 kobject: 'loop5' (fd72d949): fill_kobj_path: path = '/devices/virtual/block/loop5' FS: 7f5f1e438700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 880194657bb8 CR3: 0001cd753000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 kobject: 'loop3' (367508b9): kobject_uevent_env Call Trace: kobject: 'loop3' (367508b9): fill_kobj_path: path = '/devices/virtual/block/loop3' locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 get_signal+0x1550/0x1970 kernel/signal.c:2347 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5f1e437c78 EFLAGS: 0246 ORIG_RAX: 0049 RAX: fe00 RBX: 0002 RCX: 00457569 RDX: RSI: 0001 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7f5f1e4386d4 R13: 004bdd9e R14: 004ccdb8 R15: Modules linked in: CR2: 880194657bb8 ---[ end trace f5c1663e01f0c934 ]--- RIP: 0010:0x880194657bb8 Code: c1 eb 86 af 8c 32 00 f1 ff 1f d0 7c 65 94 01 88 ff ff f8 7d 65 94 01 88 ff ff 00 00 00 00 00 fc ff df 04 00 00 00 00 00 00 00 <78> 7d 65 94 01 88 ff ff bc 9e 2b 81 ff ff ff ff 38 89 d3 8c 01 88 RSP: 0018:880194657508 EFLAGS: 00010212 RAX: 0004 RBX: 880194657bb8 RCX: c9000a5f1000 RDX: 039f RSI: 81ed5c9e RDI: 880194657588 RBP: 8801946576f0 R08: 88018cd380c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d9678080 R13: 880194657588 R14: 1100328caea5 R15: dc00 FS: 7f5f1e438700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 880194657bb8 CR3: 0001cd753000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
BUG: unable to handle kernel paging request in locks_remove_file
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1103882b40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=1d200d0b1db9c9f449d0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1d200d0b1db9c9f44...@syzkaller.appspotmail.com kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at 880194657bb8 PGD be01067 P4D be01067 PUD 1bf029063 PMD 8001946001e3 Oops: 0011 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8074 Comm: syz-executor4 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x880194657bb8 Code: c1 eb 86 af 8c 32 00 f1 ff 1f d0 7c 65 94 01 88 ff ff f8 7d 65 94 01 88 ff ff 00 00 00 00 00 fc ff df 04 00 00 00 00 00 00 00 <78> 7d 65 94 01 88 ff ff bc 9e 2b 81 ff ff ff ff 38 89 d3 8c 01 88 kobject: 'loop5' (fd72d949): kobject_uevent_env RSP: 0018:880194657508 EFLAGS: 00010212 RAX: 0004 RBX: 880194657bb8 RCX: c9000a5f1000 RDX: 039f RSI: 81ed5c9e RDI: 880194657588 RBP: 8801946576f0 R08: 88018cd380c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d9678080 R13: 880194657588 R14: 1100328caea5 R15: dc00 kobject: 'loop5' (fd72d949): fill_kobj_path: path = '/devices/virtual/block/loop5' FS: 7f5f1e438700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 880194657bb8 CR3: 0001cd753000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 kobject: 'loop3' (367508b9): kobject_uevent_env Call Trace: kobject: 'loop3' (367508b9): fill_kobj_path: path = '/devices/virtual/block/loop3' locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 get_signal+0x1550/0x1970 kernel/signal.c:2347 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5f1e437c78 EFLAGS: 0246 ORIG_RAX: 0049 RAX: fe00 RBX: 0002 RCX: 00457569 RDX: RSI: 0001 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7f5f1e4386d4 R13: 004bdd9e R14: 004ccdb8 R15: Modules linked in: CR2: 880194657bb8 ---[ end trace f5c1663e01f0c934 ]--- RIP: 0010:0x880194657bb8 Code: c1 eb 86 af 8c 32 00 f1 ff 1f d0 7c 65 94 01 88 ff ff f8 7d 65 94 01 88 ff ff 00 00 00 00 00 fc ff df 04 00 00 00 00 00 00 00 <78> 7d 65 94 01 88 ff ff bc 9e 2b 81 ff ff ff ff 38 89 d3 8c 01 88 RSP: 0018:880194657508 EFLAGS: 00010212 RAX: 0004 RBX: 880194657bb8 RCX: c9000a5f1000 RDX: 039f RSI: 81ed5c9e RDI: 880194657588 RBP: 8801946576f0 R08: 88018cd380c0 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801d9678080 R13: 880194657588 R14: 1100328caea5 R15: dc00 FS: 7f5f1e438700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 880194657bb8 CR3: 0001cd753000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[PATCH] ARM: dts: imx7d-sdb: add rev-a board support
Current imx7d-sdb.dts has some incorrect settings about
Rev-A and Rev-B boards, some of the settings are based on
Rev-A board but some are based on Rev-B board, clean up it
by adding i.MX7D SDB Rev-A board support, make default
imx7d-sdb.dts for Rev-B board as usual, and introduce
imx7d-sdb-reva.dts for Rev-A board. Below are the affected
differences of Rev-A and Rev-B board:
Rev-A Rev-B
USB_OTG2_PWR: UART3_CTS_B GPIO1_IO07
ENET_EN_B: NoneGPIO1_IO04
TP_INT_B: EPDC_DATA13 EPDC_BDR1
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-sdb-reva.dts | 40
arch/arm/boot/dts/imx7d-sdb.dts | 21 ---
3 files changed, 59 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/imx7d-sdb-reva.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ef9ffa4..6d133b9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -572,6 +572,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-pico-pi.dtb \
imx7d-sbc-imx7.dtb \
imx7d-sdb.dtb \
+ imx7d-sdb-reva.dtb \
imx7d-sdb-sht11.dtb \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
diff --git a/arch/arm/boot/dts/imx7d-sdb-reva.dts
b/arch/arm/boot/dts/imx7d-sdb-reva.dts
new file mode 100644
index 000..c57c13d
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sdb-reva.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright (C) 2015 Freescale Semiconductor, Inc.
+
+/dts-v1/;
+
+#include "imx7d-sdb.dts"
+
+/ {
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ pinctrl-0 = <_enet2>;
+ /delete-property/pinctrl-assert-gpios;
+};
+
+ {
+ imx7d-sdb {
+ pinctrl_tsc2046_pendown: tsc2046_pendown {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA13__GPIO2_IO130x59
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14
+ MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x34
/* bt reg on */
+ >;
+ };
+ };
+};
+
+_lpsr {
+ /delete-property/pinctrl-names;
+ /delete-property/pinctrl-0;
+};
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index f1bafda..b89d9f6 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -73,7 +73,7 @@
regulator-name = "usb_otg2_vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = < 7 GPIO_ACTIVE_HIGH>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
@@ -203,7 +203,8 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_enet2>;
+ pinctrl-0 = <_enet2 _enet2_epdc0_en>;
+ pinctrl-assert-gpios = < 4 GPIO_ACTIVE_LOW>;
assigned-clocks = < IMX7D_ENET2_TIME_ROOT_SRC>,
< IMX7D_ENET2_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
@@ -491,6 +492,12 @@
>;
};
+ pinctrl_enet2_epdc0_en: enet2_epdc0_grp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x14
+ >;
+ };
+
pinctrl_flexcan2: flexcan2grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO14__FLEXCAN2_RX0x59
@@ -513,7 +520,6 @@
pinctrl_hog: hoggrp {
fsl,pins = <
- MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x34
/* bt reg on */
>;
};
@@ -724,6 +730,9 @@
};
_lpsr {
+ pinctrl-names = "default";
+ pinctrl-0 = <_hog_2>;
+
pinctrl_wdog: wdoggrp {
fsl,pins = <
MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B 0x74
@@ -735,4 +744,10 @@
MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x30
>;
};
+
+ pinctrl_hog_2: hoggrp-2 {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x14
+ >;
+ };
};
--
2.7.4
[PATCH] ARM: dts: imx7d-sdb: add rev-a board support
Current imx7d-sdb.dts has some incorrect settings about
Rev-A and Rev-B boards, some of the settings are based on
Rev-A board but some are based on Rev-B board, clean up it
by adding i.MX7D SDB Rev-A board support, make default
imx7d-sdb.dts for Rev-B board as usual, and introduce
imx7d-sdb-reva.dts for Rev-A board. Below are the affected
differences of Rev-A and Rev-B board:
Rev-A Rev-B
USB_OTG2_PWR: UART3_CTS_B GPIO1_IO07
ENET_EN_B: NoneGPIO1_IO04
TP_INT_B: EPDC_DATA13 EPDC_BDR1
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7d-sdb-reva.dts | 40
arch/arm/boot/dts/imx7d-sdb.dts | 21 ---
3 files changed, 59 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/imx7d-sdb-reva.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ef9ffa4..6d133b9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -572,6 +572,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-pico-pi.dtb \
imx7d-sbc-imx7.dtb \
imx7d-sdb.dtb \
+ imx7d-sdb-reva.dtb \
imx7d-sdb-sht11.dtb \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
diff --git a/arch/arm/boot/dts/imx7d-sdb-reva.dts
b/arch/arm/boot/dts/imx7d-sdb-reva.dts
new file mode 100644
index 000..c57c13d
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sdb-reva.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright (C) 2015 Freescale Semiconductor, Inc.
+
+/dts-v1/;
+
+#include "imx7d-sdb.dts"
+
+/ {
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ pinctrl-0 = <_enet2>;
+ /delete-property/pinctrl-assert-gpios;
+};
+
+ {
+ imx7d-sdb {
+ pinctrl_tsc2046_pendown: tsc2046_pendown {
+ fsl,pins = <
+ MX7D_PAD_EPDC_DATA13__GPIO2_IO130x59
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14
+ MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x34
/* bt reg on */
+ >;
+ };
+ };
+};
+
+_lpsr {
+ /delete-property/pinctrl-names;
+ /delete-property/pinctrl-0;
+};
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index f1bafda..b89d9f6 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -73,7 +73,7 @@
regulator-name = "usb_otg2_vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- gpio = < 7 GPIO_ACTIVE_HIGH>;
+ gpio = < 7 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
@@ -203,7 +203,8 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_enet2>;
+ pinctrl-0 = <_enet2 _enet2_epdc0_en>;
+ pinctrl-assert-gpios = < 4 GPIO_ACTIVE_LOW>;
assigned-clocks = < IMX7D_ENET2_TIME_ROOT_SRC>,
< IMX7D_ENET2_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
@@ -491,6 +492,12 @@
>;
};
+ pinctrl_enet2_epdc0_en: enet2_epdc0_grp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x14
+ >;
+ };
+
pinctrl_flexcan2: flexcan2grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO14__FLEXCAN2_RX0x59
@@ -513,7 +520,6 @@
pinctrl_hog: hoggrp {
fsl,pins = <
- MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x34
/* bt reg on */
>;
};
@@ -724,6 +730,9 @@
};
_lpsr {
+ pinctrl-names = "default";
+ pinctrl-0 = <_hog_2>;
+
pinctrl_wdog: wdoggrp {
fsl,pins = <
MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B 0x74
@@ -735,4 +744,10 @@
MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x30
>;
};
+
+ pinctrl_hog_2: hoggrp-2 {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x14
+ >;
+ };
};
--
2.7.4
[PATCHv2] PCI/Layerscape: fix wrongly invoking of outbound window disable accessor
From: Hou Zhiqiang
The order of parameters is not correct when invoking the outbound
window disable routine.
Fixes: commit 4a2745d760fac ("PCI: layerscape: Disable outbound
windows configured by bootloader").
Cc: sta...@vger.kernel.org
Signed-off-by: Hou Zhiqiang
---
V2:
- Tagged this patch for stable.
- Reworded the commit description.
drivers/pci/controller/dwc/pci-layerscape.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
b/drivers/pci/controller/dwc/pci-layerscape.c
index 3724d3ef7008..7aa9a82b7ebd 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -88,7 +88,7 @@ static void ls_pcie_disable_outbound_atus(struct ls_pcie
*pcie)
int i;
for (i = 0; i < PCIE_IATU_NUM; i++)
- dw_pcie_disable_atu(pcie->pci, DW_PCIE_REGION_OUTBOUND, i);
+ dw_pcie_disable_atu(pcie->pci, i, DW_PCIE_REGION_OUTBOUND);
}
static int ls1021_pcie_link_up(struct dw_pcie *pci)
--
2.17.1
[PATCHv2] PCI/Layerscape: fix wrongly invoking of outbound window disable accessor
From: Hou Zhiqiang
The order of parameters is not correct when invoking the outbound
window disable routine.
Fixes: commit 4a2745d760fac ("PCI: layerscape: Disable outbound
windows configured by bootloader").
Cc: sta...@vger.kernel.org
Signed-off-by: Hou Zhiqiang
---
V2:
- Tagged this patch for stable.
- Reworded the commit description.
drivers/pci/controller/dwc/pci-layerscape.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
b/drivers/pci/controller/dwc/pci-layerscape.c
index 3724d3ef7008..7aa9a82b7ebd 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -88,7 +88,7 @@ static void ls_pcie_disable_outbound_atus(struct ls_pcie
*pcie)
int i;
for (i = 0; i < PCIE_IATU_NUM; i++)
- dw_pcie_disable_atu(pcie->pci, DW_PCIE_REGION_OUTBOUND, i);
+ dw_pcie_disable_atu(pcie->pci, i, DW_PCIE_REGION_OUTBOUND);
}
static int ls1021_pcie_link_up(struct dw_pcie *pci)
--
2.17.1
KASAN: stack-out-of-bounds Read in locks_remove_flock
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=14aa485d40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=1818cd833edc063452c6 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1818cd833edc06345...@syzkaller.appspotmail.com == BUG: KASAN: stack-out-of-bounds in locks_remove_flock+0x33c/0x350 fs/locks.c:2567 Read of size 8 at addr 8801c71c7a08 by task syz-executor5/20562 CPU: 0 PID: 20562 Comm: syz-executor5 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 locks_remove_flock+0x33c/0x350 fs/locks.c:2567 locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x411021 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffdb42509a0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0005 RCX: 00411021 RDX: RSI: 00732ea0 RDI: 0004 RBP: R08: R09: R10: 7ffdb42508c0 R11: 0293 R12: R13: 0001 R14: 0201 R15: 0005 The buggy address belongs to the page: page:ea00071c71c0 count:0 mapcount:0 mapping: index:0x0 flags: 0x2fffc00() raw: 02fffc00 071c0101 raw: page dumped because: kasan: bad access detected Memory state around the buggy address: 8801c71c7900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8801c71c7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8801c71c7a00: f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ 8801c71c7a80: 00 f1 f1 f1 f1 00 00 f2 f2 f2 f2 f2 f2 f8 f2 f2 8801c71c7b00: f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 00 00 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
KASAN: stack-out-of-bounds Read in locks_remove_flock
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=14aa485d40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=1818cd833edc063452c6 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1818cd833edc06345...@syzkaller.appspotmail.com == BUG: KASAN: stack-out-of-bounds in locks_remove_flock+0x33c/0x350 fs/locks.c:2567 Read of size 8 at addr 8801c71c7a08 by task syz-executor5/20562 CPU: 0 PID: 20562 Comm: syz-executor5 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 locks_remove_flock+0x33c/0x350 fs/locks.c:2567 locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x411021 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffdb42509a0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0005 RCX: 00411021 RDX: RSI: 00732ea0 RDI: 0004 RBP: R08: R09: R10: 7ffdb42508c0 R11: 0293 R12: R13: 0001 R14: 0201 R15: 0005 The buggy address belongs to the page: page:ea00071c71c0 count:0 mapcount:0 mapping: index:0x0 flags: 0x2fffc00() raw: 02fffc00 071c0101 raw: page dumped because: kasan: bad access detected Memory state around the buggy address: 8801c71c7900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8801c71c7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8801c71c7a00: f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ 8801c71c7a80: 00 f1 f1 f1 f1 00 00 f2 f2 f2 f2 f2 f2 f8 f2 f2 8801c71c7b00: f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 00 00 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
KASAN: use-after-free Read in locks_remove_flock
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=16e42f5b40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=34a98afb89842107f03f compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+34a98afb89842107f...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in locks_remove_flock+0x33c/0x350 fs/locks.c:2567 Read of size 8 at addr 8801c92fc040 by task syz-executor1/15515 CPU: 1 PID: 15515 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 locks_remove_flock+0x33c/0x350 fs/locks.c:2567 locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc1e8ed4c78 EFLAGS: 0246 ORIG_RAX: 0049 RAX: RBX: 0002 RCX: 00457569 RDX: RSI: 0002 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7fc1e8ed56d4 R13: 004bdd9e R14: 004ccdb8 R15: Allocated by task 15515: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 kmem_cache_zalloc include/linux/slab.h:731 [inline] locks_alloc_lock+0x9e/0x300 fs/locks.c:304 flock_make_lock+0x22c/0x2a0 fs/locks.c:438 __do_sys_flock fs/locks.c:2057 [inline] __se_sys_flock fs/locks.c:2038 [inline] __x64_sys_flock+0x12b/0x350 fs/locks.c:2038 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 15515: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3760 locks_free_lock+0x295/0x420 fs/locks.c:341 __do_sys_flock fs/locks.c:2078 [inline] __se_sys_flock fs/locks.c:2038 [inline] __x64_sys_flock+0x289/0x350 fs/locks.c:2038 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8801c92fc000 which belongs to the cache file_lock_cache of size 264 The buggy address is located 64 bytes inside of 264-byte region [8801c92fc000, 8801c92fc108) The buggy address belongs to the page: page:ea000724bf00 count:1 mapcount:0 mapping:8801d9a1c3c0 index:0x0 flags: 0x2fffc000200(slab) raw: 02fffc000200 8801d9a82e48 ea00075e1608 8801d9a1c3c0 raw: 8801c92fc000 0001000c page dumped because: kasan: bad access detected Memory state around the buggy address: 8801c92fbf00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 8801c92fbf80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 8801c92fc000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 8801c92fc080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8801c92fc100: fb fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb == [ cut here ] downgrading a read lock WARNING: CPU: 0 PID: 15521 at kernel/locking/lockdep.c:3556 __lock_downgrade kernel/locking/lockdep.c:3556 [inline] WARNING: CPU: 0 PID: 15521 at
general protection fault in __x86_indirect_thunk_rbx
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=10ae982540 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=83e12cf81d2c14842146 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+83e12cf81d2c14842...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 9939 Comm: syz-executor5 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:88019f166eb0 EFLAGS: 00010293 RAX: 8801c298a680 RBX: 5f415e415d415c41 RCX: 81ed555d kobject: 'loop2' (5961f4a7): kobject_uevent_env RDX: RSI: 81ed5c9e RDI: 88019f166f38 RBP: 88019f1670a0 R08: 8801c298a680 R09: ed003b5e5b67 kobject: 'loop2' (5961f4a7): fill_kobj_path: path = '/devices/virtual/block/loop2' R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801ce6465c0 R13: 88019f166f38 R14: 110033e2cddb R15: dc00 FS: 7fdc2a4eb700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0072c000 CR3: 00019fde7000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1ad1/0x26d0 kernel/exit.c:867 do_group_exit+0x177/0x440 kernel/exit.c:970 get_signal+0x8a8/0x1970 kernel/signal.c:2517 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fdc2a4eac78 EFLAGS: 0246 ORIG_RAX: 002c RAX: ffe0 RBX: 0006 RCX: 00457569 RDX: 029f RSI: 20a88f88 RDI: 0005 RBP: 0072bf00 R08: 20e68000 R09: 0010 R10: R11: 0246 R12: 7fdc2a4eb6d4 R13: 004c3b86 R14: 004d5cc8 R15: Modules linked in: ---[ end trace f409c0e248b1eb30 ]--- RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:88019f166eb0 EFLAGS: 00010293 RAX: 8801c298a680 RBX: 5f415e415d415c41 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 88019f166f38 RBP: 88019f1670a0 R08: 8801c298a680 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801ce6465c0 audit: type=1326 audit(1541560871.105:63): auid=4294967295 uid=0 gid=0 ses=4294967295 subj==unconfined pid=9895 comm="syz-executor3" exe="/root/syz-executor3" sig=9 arch=c03e syscall=228 compat=0 ip=0x45a3ca code=0x0 R13: 88019f166f38 R14: 110033e2cddb R15: dc00 FS: 7fdc2a4eb700() GS:8801daf0() knlGS: kobject: 'loop4' (e724a344): kobject_uevent_env CS: 0010 DS: ES: CR0: 80050033 kobject: 'loop4' (e724a344): fill_kobj_path: path = '/devices/virtual/block/loop4' kobject: 'kvm' (c2eca0f7): kobject_uevent_env kobject: 'loop3' (e5653105): kobject_uevent_env kobject: 'kvm' (c2eca0f7): fill_kobj_path: path = '/devices/virtual/misc/kvm' kobject: 'loop3' (e5653105): fill_kobj_path: path = '/devices/virtual/block/loop3' CR2: 7fe26d074db8 CR3: 0001a2d54000 CR4: 001406e0 DR0:
KASAN: use-after-free Read in locks_remove_flock
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=16e42f5b40 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=34a98afb89842107f03f compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+34a98afb89842107f...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in locks_remove_flock+0x33c/0x350 fs/locks.c:2567 Read of size 8 at addr 8801c92fc040 by task syz-executor1/15515 CPU: 1 PID: 15515 Comm: syz-executor1 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 locks_remove_flock+0x33c/0x350 fs/locks.c:2567 locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc1e8ed4c78 EFLAGS: 0246 ORIG_RAX: 0049 RAX: RBX: 0002 RCX: 00457569 RDX: RSI: 0002 RDI: 0003 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7fc1e8ed56d4 R13: 004bdd9e R14: 004ccdb8 R15: Allocated by task 15515: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 kmem_cache_zalloc include/linux/slab.h:731 [inline] locks_alloc_lock+0x9e/0x300 fs/locks.c:304 flock_make_lock+0x22c/0x2a0 fs/locks.c:438 __do_sys_flock fs/locks.c:2057 [inline] __se_sys_flock fs/locks.c:2038 [inline] __x64_sys_flock+0x12b/0x350 fs/locks.c:2038 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 15515: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3760 locks_free_lock+0x295/0x420 fs/locks.c:341 __do_sys_flock fs/locks.c:2078 [inline] __se_sys_flock fs/locks.c:2038 [inline] __x64_sys_flock+0x289/0x350 fs/locks.c:2038 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8801c92fc000 which belongs to the cache file_lock_cache of size 264 The buggy address is located 64 bytes inside of 264-byte region [8801c92fc000, 8801c92fc108) The buggy address belongs to the page: page:ea000724bf00 count:1 mapcount:0 mapping:8801d9a1c3c0 index:0x0 flags: 0x2fffc000200(slab) raw: 02fffc000200 8801d9a82e48 ea00075e1608 8801d9a1c3c0 raw: 8801c92fc000 0001000c page dumped because: kasan: bad access detected Memory state around the buggy address: 8801c92fbf00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 8801c92fbf80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 8801c92fc000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 8801c92fc080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8801c92fc100: fb fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb == [ cut here ] downgrading a read lock WARNING: CPU: 0 PID: 15521 at kernel/locking/lockdep.c:3556 __lock_downgrade kernel/locking/lockdep.c:3556 [inline] WARNING: CPU: 0 PID: 15521 at
general protection fault in __x86_indirect_thunk_rbx
Hello, syzbot found the following crash on: HEAD commit:d881de30d29e Add linux-next specific files for 20181107 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=10ae982540 kernel config: https://syzkaller.appspot.com/x/.config?x=caa433e1c8778437 dashboard link: https://syzkaller.appspot.com/bug?extid=83e12cf81d2c14842146 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+83e12cf81d2c14842...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 9939 Comm: syz-executor5 Not tainted 4.20.0-rc1-next-20181107+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:88019f166eb0 EFLAGS: 00010293 RAX: 8801c298a680 RBX: 5f415e415d415c41 RCX: 81ed555d kobject: 'loop2' (5961f4a7): kobject_uevent_env RDX: RSI: 81ed5c9e RDI: 88019f166f38 RBP: 88019f1670a0 R08: 8801c298a680 R09: ed003b5e5b67 kobject: 'loop2' (5961f4a7): fill_kobj_path: path = '/devices/virtual/block/loop2' R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801ce6465c0 R13: 88019f166f38 R14: 110033e2cddb R15: dc00 FS: 7fdc2a4eb700() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0072c000 CR3: 00019fde7000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: locks_remove_file+0x148/0x5c0 fs/locks.c:2607 __fput+0x2f0/0xa70 fs/file_table.c:271 fput+0x15/0x20 fs/file_table.c:312 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1ad1/0x26d0 kernel/exit.c:867 do_group_exit+0x177/0x440 kernel/exit.c:970 get_signal+0x8a8/0x1970 kernel/signal.c:2517 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fdc2a4eac78 EFLAGS: 0246 ORIG_RAX: 002c RAX: ffe0 RBX: 0006 RCX: 00457569 RDX: 029f RSI: 20a88f88 RDI: 0005 RBP: 0072bf00 R08: 20e68000 R09: 0010 R10: R11: 0246 R12: 7fdc2a4eb6d4 R13: 004c3b86 R14: 004d5cc8 R15: Modules linked in: ---[ end trace f409c0e248b1eb30 ]--- RIP: 0010:__x86_indirect_thunk_rbx+0x10/0x20 arch/x86/lib/retpoline.S:33 Code: 90 0f ae e8 eb f9 48 89 04 24 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 90 0f ae e8 eb f9 48 89 1c 24 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3 RSP: 0018:88019f166eb0 EFLAGS: 00010293 RAX: 8801c298a680 RBX: 5f415e415d415c41 RCX: 81ed555d RDX: RSI: 81ed5c9e RDI: 88019f166f38 RBP: 88019f1670a0 R08: 8801c298a680 R09: ed003b5e5b67 R10: ed003b5e5b67 R11: 8801daf2db3b R12: 8801ce6465c0 audit: type=1326 audit(1541560871.105:63): auid=4294967295 uid=0 gid=0 ses=4294967295 subj==unconfined pid=9895 comm="syz-executor3" exe="/root/syz-executor3" sig=9 arch=c03e syscall=228 compat=0 ip=0x45a3ca code=0x0 R13: 88019f166f38 R14: 110033e2cddb R15: dc00 FS: 7fdc2a4eb700() GS:8801daf0() knlGS: kobject: 'loop4' (e724a344): kobject_uevent_env CS: 0010 DS: ES: CR0: 80050033 kobject: 'loop4' (e724a344): fill_kobj_path: path = '/devices/virtual/block/loop4' kobject: 'kvm' (c2eca0f7): kobject_uevent_env kobject: 'loop3' (e5653105): kobject_uevent_env kobject: 'kvm' (c2eca0f7): fill_kobj_path: path = '/devices/virtual/misc/kvm' kobject: 'loop3' (e5653105): fill_kobj_path: path = '/devices/virtual/block/loop3' CR2: 7fe26d074db8 CR3: 0001a2d54000 CR4: 001406e0 DR0:
