* selftests: bpf: test_progs: deadlock at trace_call_bpf
From: Naresh Kamboju @ 2018-07-24 9:21 UTC (permalink / raw)
To: netdev, ast, Daniel Borkmann, rostedt
Cc: open list, open list:KERNEL SELFTEST FRAMEWORK
Deadlock warning on x86 machine while testing selftests: bpf:
test_progs and running linux next 4.18.0-rc3-next-20180705 and still
happening on 4.18.0-rc5-next-20180720.
Any one noticed this kernel warning about deadlock ?
selftests: bpf: test_progs
libbpf: incorrect bpf_call opcode
libbpf: incorrect bpf_call opcode
test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
[ 69.903862] ========================================================
[ 69.910213] WARNING: possible irq lock inversion dependency detected
[ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
[ 69.921428] --------------------------------------------------------
[ 69.927774] dd/2928 just changed the state of lock:
[ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
pcpu_freelist_push+0x28/0x50
[ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
in the past:
[ 69.947420] (&rq->lock){-.-.}
[ 69.947421]
[ 69.947421]
[ 69.947421] and interrupts could create inverse lock ordering between them.
[ 69.947421]
[ 69.961842]
[ 69.961842] other info that might help us debug this:
[ 69.968357] Possible interrupt unsafe locking scenario:
[ 69.968357]
[ 69.975136] CPU0 CPU1
[ 69.979659] ---- ----
[ 69.984184] lock(&head->lock);
[ 69.987406] local_irq_disable();
[ 69.993319] lock(&rq->lock);
[ 69.998882] lock(&head->lock);
[ 70.004618] <Interrupt>
[ 70.007235] lock(&rq->lock);
[ 70.010461]
[ 70.010461] *** DEADLOCK ***
[ 70.010461]
[ 70.016372] 1 lock held by dd/2928:
[ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
trace_call_bpf+0x37/0x1d0
[ 70.027768]
[ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
[ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
[ 70.040204] IN-HARDIRQ-W at:
[ 70.043428] lock_acquire+0xd5/0x1c0
[ 70.048820] _raw_spin_lock+0x2f/0x40
[ 70.054299] scheduler_tick+0x51/0xf0
[ 70.059781] update_process_times+0x47/0x60
[ 70.065779] tick_periodic+0x2b/0xc0
[ 70.071171] tick_handle_periodic+0x25/0x70
[ 70.077168] timer_interrupt+0x15/0x20
[ 70.082731] __handle_irq_event_percpu+0x48/0x320
[ 70.089250] handle_irq_event_percpu+0x32/0x80
[ 70.095505] handle_irq_event+0x39/0x60
[ 70.101157] handle_level_irq+0x7f/0x100
[ 70.106893] handle_irq+0x6f/0x110
[ 70.112112] do_IRQ+0x5c/0x110
[ 70.116982] ret_from_intr+0x0/0x1d
[ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
[ 70.128891] __setup_irq+0x45d/0x700
[ 70.134281] setup_irq+0x4c/0x90
[ 70.139324] hpet_time_init+0x25/0x37
[ 70.144803] x86_late_time_init+0xf/0x1c
[ 70.150538] start_kernel+0x40c/0x4ca
[ 70.156017] x86_64_start_reservations+0x24/0x26
[ 70.162445] x86_64_start_kernel+0x6f/0x72
[ 70.168357] secondary_startup_64+0xa4/0xb0
[ 70.174356] IN-SOFTIRQ-W at:
[ 70.177578] lock_acquire+0xd5/0x1c0
[ 70.182970] _raw_spin_lock+0x2f/0x40
[ 70.188448] try_to_wake_up+0x31b/0x540
[ 70.194097] wake_up_process+0x15/0x20
[ 70.199661] swake_up_locked+0x24/0x40
[ 70.205226] swake_up_one+0x1f/0x30
[ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
[ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
[ 70.223048] rcu_process_callbacks+0x111/0x10c0
[ 70.229396] __do_softirq+0xbf/0x493
[ 70.234788] irq_exit+0xc3/0xd0
[ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
[ 70.246176] apic_timer_interrupt+0xf/0x20
[ 70.252084] console_unlock+0x4e8/0x620
[ 70.257737] vprintk_emit+0x254/0x430
[ 70.263214] vprintk_default+0x1f/0x30
[ 70.268776] vprintk_func+0x27/0x60
[ 70.274082] printk+0x52/0x6e
[ 70.278864] native_cpu_up+0x71b/0x7a0
[ 70.284431] bringup_cpu+0x2a/0xb0
[ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
[ 70.295818] _cpu_up+0xae/0x160
[ 70.300776] do_cpu_up+0x8d/0xb0
[ 70.305818] cpu_up+0x13/0x20
[ 70.310602] smp_init+0x67/0xc4
[ 70.315559] kernel_init_freeable+0x134/0x259
[ 70.321731] kernel_init+0xe/0x110
[ 70.326947] ret_from_fork+0x3a/0x50
[ 70.332339] INITIAL USE at:
[ 70.335477] lock_acquire+0xd5/0x1c0
[ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
[ 70.346864] rq_attach_root+0x1b/0xc0
[ 70.352255] sched_init+0x310/0x432
[ 70.357472] start_kernel+0x26e/0x4ca
[ 70.362861] x86_64_start_reservations+0x24/0x26
[ 70.369207] x86_64_start_kernel+0x6f/0x72
[ 70.375048] secondary_startup_64+0xa4/0xb0
[ 70.380958] }
[ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
[ 70.389310] ... acquired at:
[ 70.392364] _raw_spin_lock+0x2f/0x40
[ 70.396192] pcpu_freelist_pop+0x7a/0xd0
[ 70.400286] bpf_get_stackid+0x1ca/0x470
[ 70.404383] bpf_get_stackid_tp+0x11/0x20
[ 70.408559] ___bpf_prog_run+0x7f2/0x1090
[ 70.412739] __bpf_prog_run32+0x39/0x50
[ 70.416742] trace_call_bpf+0xc8/0x1d0
[ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.425444] perf_trace_sched_switch+0x116/0x190
[ 70.430227] __schedule+0x6d8/0xa20
[ 70.433883] schedule+0x3d/0x90
[ 70.437194] worker_thread+0xd0/0x410
[ 70.441025] kthread+0x10d/0x140
[ 70.444424] ret_from_fork+0x3a/0x50
[ 70.448165]
[ 70.449658] -> (&head->lock){+...} ops: 61660 {
[ 70.454181] HARDIRQ-ON-W at:
[ 70.457319] lock_acquire+0xd5/0x1c0
[ 70.462536] _raw_spin_lock+0x2f/0x40
[ 70.467841] pcpu_freelist_push+0x28/0x50
[ 70.473492] bpf_get_stackid+0x43a/0x470
[ 70.479054] bpf_get_stackid_tp+0x11/0x20
[ 70.484724] ___bpf_prog_run+0x7f2/0x1090
[ 70.490372] __bpf_prog_run32+0x39/0x50
[ 70.495852] trace_call_bpf+0xc8/0x1d0
[ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.507500] perf_trace_urandom_read+0xbf/0x100
[ 70.513670] urandom_read+0x1ce/0x340
[ 70.518975] __vfs_read+0x37/0x160
[ 70.524027] vfs_read+0xa8/0x150
[ 70.528898] ksys_read+0x58/0xc0
[ 70.533766] __x64_sys_read+0x1a/0x20
[ 70.539092] do_syscall_64+0x4f/0x190
[ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.551092] INITIAL USE at:
[ 70.554143] lock_acquire+0xd5/0x1c0
[ 70.559272] _raw_spin_lock+0x2f/0x40
[ 70.564491] pcpu_freelist_populate+0xb6/0x110
[ 70.570489] htab_map_alloc+0x3b6/0x4c0
[ 70.575878] map_create+0xf0/0x370
[ 70.580836] __x64_sys_bpf+0x10b/0x260
[ 70.586138] do_syscall_64+0x4f/0x190
[ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.597960] }
[ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
[ 70.606142] ... acquired at:
[ 70.609104] mark_lock+0x392/0x570
[ 70.612676] __lock_acquire+0x5cd/0x13c0
[ 70.616767] lock_acquire+0xd5/0x1c0
[ 70.620511] _raw_spin_lock+0x2f/0x40
[ 70.624342] pcpu_freelist_push+0x28/0x50
[ 70.628519] bpf_get_stackid+0x43a/0x470
[ 70.632610] bpf_get_stackid_tp+0x11/0x20
[ 70.636785] ___bpf_prog_run+0x7f2/0x1090
[ 70.640965] __bpf_prog_run32+0x39/0x50
[ 70.644969] trace_call_bpf+0xc8/0x1d0
[ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.653668] perf_trace_urandom_read+0xbf/0x100
[ 70.658366] urandom_read+0x1ce/0x340
[ 70.662199] __vfs_read+0x37/0x160
[ 70.665768] vfs_read+0xa8/0x150
[ 70.669166] ksys_read+0x58/0xc0
[ 70.672562] __x64_sys_read+0x1a/0x20
[ 70.676393] do_syscall_64+0x4f/0x190
[ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.685440]
[ 70.686933]
[ 70.686933] stack backtrace:
[ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
[ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 70.705875] Call Trace:
[ 70.708321] dump_stack+0x68/0x95
[ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
[ 70.716935] check_usage_backwards+0x14b/0x160
[ 70.721374] mark_lock+0x392/0x570
[ 70.724771] ? mark_lock+0x392/0x570
[ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 70.733904] __lock_acquire+0x5cd/0x13c0
[ 70.737823] ? find_get_entry+0x1a2/0x2f0
[ 70.741825] lock_acquire+0xd5/0x1c0
[ 70.745397] ? lock_acquire+0xd5/0x1c0
[ 70.749141] ? pcpu_freelist_push+0x28/0x50
[ 70.753317] _raw_spin_lock+0x2f/0x40
[ 70.756974] ? pcpu_freelist_push+0x28/0x50
[ 70.761153] pcpu_freelist_push+0x28/0x50
[ 70.765156] bpf_get_stackid+0x43a/0x470
[ 70.769073] bpf_get_stackid_tp+0x11/0x20
[ 70.773077] ___bpf_prog_run+0x7f2/0x1090
[ 70.777083] __bpf_prog_run32+0x39/0x50
[ 70.780912] ? lock_acquire+0xd5/0x1c0
[ 70.784656] trace_call_bpf+0xc8/0x1d0
[ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.793013] perf_trace_urandom_read+0xbf/0x100
[ 70.797544] urandom_read+0x1ce/0x340
[ 70.801202] __vfs_read+0x37/0x160
[ 70.804598] ? security_file_permission+0x8d/0xb0
[ 70.809297] ? security_file_permission+0x8d/0xb0
[ 70.813993] vfs_read+0xa8/0x150
[ 70.817218] ksys_read+0x58/0xc0
[ 70.820442] __x64_sys_read+0x1a/0x20
[ 70.824106] do_syscall_64+0x4f/0x190
[ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.832807] RIP: 0033:0x7f302526f160
[ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
04 24
[ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
[ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
[ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
[ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
[ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
e 54
test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
Full kernel selftest test log,
https://lkft.validation.linaro.org/scheduler/job/314724#L2142
Best regards
Naresh Kamboju
^ permalink raw reply
* selftests: bpf: test_progs: deadlock at trace_call_bpf
From: Naresh Kamboju @ 2018-07-24 9:21 UTC (permalink / raw)
Deadlock warning on x86 machine while testing selftests: bpf:
test_progs and running linux next 4.18.0-rc3-next-20180705 and still
happening on 4.18.0-rc5-next-20180720.
Any one noticed this kernel warning about deadlock ?
selftests: bpf: test_progs
libbpf: incorrect bpf_call opcode
libbpf: incorrect bpf_call opcode
test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
[ 69.903862] ========================================================
[ 69.910213] WARNING: possible irq lock inversion dependency detected
[ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
[ 69.921428] --------------------------------------------------------
[ 69.927774] dd/2928 just changed the state of lock:
[ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
pcpu_freelist_push+0x28/0x50
[ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
in the past:
[ 69.947420] (&rq->lock){-.-.}
[ 69.947421]
[ 69.947421]
[ 69.947421] and interrupts could create inverse lock ordering between them.
[ 69.947421]
[ 69.961842]
[ 69.961842] other info that might help us debug this:
[ 69.968357] Possible interrupt unsafe locking scenario:
[ 69.968357]
[ 69.975136] CPU0 CPU1
[ 69.979659] ---- ----
[ 69.984184] lock(&head->lock);
[ 69.987406] local_irq_disable();
[ 69.993319] lock(&rq->lock);
[ 69.998882] lock(&head->lock);
[ 70.004618] <Interrupt>
[ 70.007235] lock(&rq->lock);
[ 70.010461]
[ 70.010461] *** DEADLOCK ***
[ 70.010461]
[ 70.016372] 1 lock held by dd/2928:
[ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
trace_call_bpf+0x37/0x1d0
[ 70.027768]
[ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
[ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
[ 70.040204] IN-HARDIRQ-W at:
[ 70.043428] lock_acquire+0xd5/0x1c0
[ 70.048820] _raw_spin_lock+0x2f/0x40
[ 70.054299] scheduler_tick+0x51/0xf0
[ 70.059781] update_process_times+0x47/0x60
[ 70.065779] tick_periodic+0x2b/0xc0
[ 70.071171] tick_handle_periodic+0x25/0x70
[ 70.077168] timer_interrupt+0x15/0x20
[ 70.082731] __handle_irq_event_percpu+0x48/0x320
[ 70.089250] handle_irq_event_percpu+0x32/0x80
[ 70.095505] handle_irq_event+0x39/0x60
[ 70.101157] handle_level_irq+0x7f/0x100
[ 70.106893] handle_irq+0x6f/0x110
[ 70.112112] do_IRQ+0x5c/0x110
[ 70.116982] ret_from_intr+0x0/0x1d
[ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
[ 70.128891] __setup_irq+0x45d/0x700
[ 70.134281] setup_irq+0x4c/0x90
[ 70.139324] hpet_time_init+0x25/0x37
[ 70.144803] x86_late_time_init+0xf/0x1c
[ 70.150538] start_kernel+0x40c/0x4ca
[ 70.156017] x86_64_start_reservations+0x24/0x26
[ 70.162445] x86_64_start_kernel+0x6f/0x72
[ 70.168357] secondary_startup_64+0xa4/0xb0
[ 70.174356] IN-SOFTIRQ-W at:
[ 70.177578] lock_acquire+0xd5/0x1c0
[ 70.182970] _raw_spin_lock+0x2f/0x40
[ 70.188448] try_to_wake_up+0x31b/0x540
[ 70.194097] wake_up_process+0x15/0x20
[ 70.199661] swake_up_locked+0x24/0x40
[ 70.205226] swake_up_one+0x1f/0x30
[ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
[ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
[ 70.223048] rcu_process_callbacks+0x111/0x10c0
[ 70.229396] __do_softirq+0xbf/0x493
[ 70.234788] irq_exit+0xc3/0xd0
[ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
[ 70.246176] apic_timer_interrupt+0xf/0x20
[ 70.252084] console_unlock+0x4e8/0x620
[ 70.257737] vprintk_emit+0x254/0x430
[ 70.263214] vprintk_default+0x1f/0x30
[ 70.268776] vprintk_func+0x27/0x60
[ 70.274082] printk+0x52/0x6e
[ 70.278864] native_cpu_up+0x71b/0x7a0
[ 70.284431] bringup_cpu+0x2a/0xb0
[ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
[ 70.295818] _cpu_up+0xae/0x160
[ 70.300776] do_cpu_up+0x8d/0xb0
[ 70.305818] cpu_up+0x13/0x20
[ 70.310602] smp_init+0x67/0xc4
[ 70.315559] kernel_init_freeable+0x134/0x259
[ 70.321731] kernel_init+0xe/0x110
[ 70.326947] ret_from_fork+0x3a/0x50
[ 70.332339] INITIAL USE at:
[ 70.335477] lock_acquire+0xd5/0x1c0
[ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
[ 70.346864] rq_attach_root+0x1b/0xc0
[ 70.352255] sched_init+0x310/0x432
[ 70.357472] start_kernel+0x26e/0x4ca
[ 70.362861] x86_64_start_reservations+0x24/0x26
[ 70.369207] x86_64_start_kernel+0x6f/0x72
[ 70.375048] secondary_startup_64+0xa4/0xb0
[ 70.380958] }
[ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
[ 70.389310] ... acquired at:
[ 70.392364] _raw_spin_lock+0x2f/0x40
[ 70.396192] pcpu_freelist_pop+0x7a/0xd0
[ 70.400286] bpf_get_stackid+0x1ca/0x470
[ 70.404383] bpf_get_stackid_tp+0x11/0x20
[ 70.408559] ___bpf_prog_run+0x7f2/0x1090
[ 70.412739] __bpf_prog_run32+0x39/0x50
[ 70.416742] trace_call_bpf+0xc8/0x1d0
[ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.425444] perf_trace_sched_switch+0x116/0x190
[ 70.430227] __schedule+0x6d8/0xa20
[ 70.433883] schedule+0x3d/0x90
[ 70.437194] worker_thread+0xd0/0x410
[ 70.441025] kthread+0x10d/0x140
[ 70.444424] ret_from_fork+0x3a/0x50
[ 70.448165]
[ 70.449658] -> (&head->lock){+...} ops: 61660 {
[ 70.454181] HARDIRQ-ON-W at:
[ 70.457319] lock_acquire+0xd5/0x1c0
[ 70.462536] _raw_spin_lock+0x2f/0x40
[ 70.467841] pcpu_freelist_push+0x28/0x50
[ 70.473492] bpf_get_stackid+0x43a/0x470
[ 70.479054] bpf_get_stackid_tp+0x11/0x20
[ 70.484724] ___bpf_prog_run+0x7f2/0x1090
[ 70.490372] __bpf_prog_run32+0x39/0x50
[ 70.495852] trace_call_bpf+0xc8/0x1d0
[ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.507500] perf_trace_urandom_read+0xbf/0x100
[ 70.513670] urandom_read+0x1ce/0x340
[ 70.518975] __vfs_read+0x37/0x160
[ 70.524027] vfs_read+0xa8/0x150
[ 70.528898] ksys_read+0x58/0xc0
[ 70.533766] __x64_sys_read+0x1a/0x20
[ 70.539092] do_syscall_64+0x4f/0x190
[ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.551092] INITIAL USE at:
[ 70.554143] lock_acquire+0xd5/0x1c0
[ 70.559272] _raw_spin_lock+0x2f/0x40
[ 70.564491] pcpu_freelist_populate+0xb6/0x110
[ 70.570489] htab_map_alloc+0x3b6/0x4c0
[ 70.575878] map_create+0xf0/0x370
[ 70.580836] __x64_sys_bpf+0x10b/0x260
[ 70.586138] do_syscall_64+0x4f/0x190
[ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.597960] }
[ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
[ 70.606142] ... acquired at:
[ 70.609104] mark_lock+0x392/0x570
[ 70.612676] __lock_acquire+0x5cd/0x13c0
[ 70.616767] lock_acquire+0xd5/0x1c0
[ 70.620511] _raw_spin_lock+0x2f/0x40
[ 70.624342] pcpu_freelist_push+0x28/0x50
[ 70.628519] bpf_get_stackid+0x43a/0x470
[ 70.632610] bpf_get_stackid_tp+0x11/0x20
[ 70.636785] ___bpf_prog_run+0x7f2/0x1090
[ 70.640965] __bpf_prog_run32+0x39/0x50
[ 70.644969] trace_call_bpf+0xc8/0x1d0
[ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.653668] perf_trace_urandom_read+0xbf/0x100
[ 70.658366] urandom_read+0x1ce/0x340
[ 70.662199] __vfs_read+0x37/0x160
[ 70.665768] vfs_read+0xa8/0x150
[ 70.669166] ksys_read+0x58/0xc0
[ 70.672562] __x64_sys_read+0x1a/0x20
[ 70.676393] do_syscall_64+0x4f/0x190
[ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.685440]
[ 70.686933]
[ 70.686933] stack backtrace:
[ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
[ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 70.705875] Call Trace:
[ 70.708321] dump_stack+0x68/0x95
[ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
[ 70.716935] check_usage_backwards+0x14b/0x160
[ 70.721374] mark_lock+0x392/0x570
[ 70.724771] ? mark_lock+0x392/0x570
[ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 70.733904] __lock_acquire+0x5cd/0x13c0
[ 70.737823] ? find_get_entry+0x1a2/0x2f0
[ 70.741825] lock_acquire+0xd5/0x1c0
[ 70.745397] ? lock_acquire+0xd5/0x1c0
[ 70.749141] ? pcpu_freelist_push+0x28/0x50
[ 70.753317] _raw_spin_lock+0x2f/0x40
[ 70.756974] ? pcpu_freelist_push+0x28/0x50
[ 70.761153] pcpu_freelist_push+0x28/0x50
[ 70.765156] bpf_get_stackid+0x43a/0x470
[ 70.769073] bpf_get_stackid_tp+0x11/0x20
[ 70.773077] ___bpf_prog_run+0x7f2/0x1090
[ 70.777083] __bpf_prog_run32+0x39/0x50
[ 70.780912] ? lock_acquire+0xd5/0x1c0
[ 70.784656] trace_call_bpf+0xc8/0x1d0
[ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.793013] perf_trace_urandom_read+0xbf/0x100
[ 70.797544] urandom_read+0x1ce/0x340
[ 70.801202] __vfs_read+0x37/0x160
[ 70.804598] ? security_file_permission+0x8d/0xb0
[ 70.809297] ? security_file_permission+0x8d/0xb0
[ 70.813993] vfs_read+0xa8/0x150
[ 70.817218] ksys_read+0x58/0xc0
[ 70.820442] __x64_sys_read+0x1a/0x20
[ 70.824106] do_syscall_64+0x4f/0x190
[ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.832807] RIP: 0033:0x7f302526f160
[ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
04 24
[ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
[ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
[ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
[ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
[ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
e 54
test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
Full kernel selftest test log,
https://lkft.validation.linaro.org/scheduler/job/314724#L2142
Best regards
Naresh Kamboju
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* selftests: bpf: test_progs: deadlock at trace_call_bpf
From: naresh.kamboju @ 2018-07-24 9:21 UTC (permalink / raw)
Deadlock warning on x86 machine while testing selftests: bpf:
test_progs and running linux next 4.18.0-rc3-next-20180705 and still
happening on 4.18.0-rc5-next-20180720.
Any one noticed this kernel warning about deadlock ?
selftests: bpf: test_progs
libbpf: incorrect bpf_call opcode
libbpf: incorrect bpf_call opcode
test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
[ 69.903862] ========================================================
[ 69.910213] WARNING: possible irq lock inversion dependency detected
[ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
[ 69.921428] --------------------------------------------------------
[ 69.927774] dd/2928 just changed the state of lock:
[ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
pcpu_freelist_push+0x28/0x50
[ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
in the past:
[ 69.947420] (&rq->lock){-.-.}
[ 69.947421]
[ 69.947421]
[ 69.947421] and interrupts could create inverse lock ordering between them.
[ 69.947421]
[ 69.961842]
[ 69.961842] other info that might help us debug this:
[ 69.968357] Possible interrupt unsafe locking scenario:
[ 69.968357]
[ 69.975136] CPU0 CPU1
[ 69.979659] ---- ----
[ 69.984184] lock(&head->lock);
[ 69.987406] local_irq_disable();
[ 69.993319] lock(&rq->lock);
[ 69.998882] lock(&head->lock);
[ 70.004618] <Interrupt>
[ 70.007235] lock(&rq->lock);
[ 70.010461]
[ 70.010461] *** DEADLOCK ***
[ 70.010461]
[ 70.016372] 1 lock held by dd/2928:
[ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
trace_call_bpf+0x37/0x1d0
[ 70.027768]
[ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
[ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
[ 70.040204] IN-HARDIRQ-W at:
[ 70.043428] lock_acquire+0xd5/0x1c0
[ 70.048820] _raw_spin_lock+0x2f/0x40
[ 70.054299] scheduler_tick+0x51/0xf0
[ 70.059781] update_process_times+0x47/0x60
[ 70.065779] tick_periodic+0x2b/0xc0
[ 70.071171] tick_handle_periodic+0x25/0x70
[ 70.077168] timer_interrupt+0x15/0x20
[ 70.082731] __handle_irq_event_percpu+0x48/0x320
[ 70.089250] handle_irq_event_percpu+0x32/0x80
[ 70.095505] handle_irq_event+0x39/0x60
[ 70.101157] handle_level_irq+0x7f/0x100
[ 70.106893] handle_irq+0x6f/0x110
[ 70.112112] do_IRQ+0x5c/0x110
[ 70.116982] ret_from_intr+0x0/0x1d
[ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
[ 70.128891] __setup_irq+0x45d/0x700
[ 70.134281] setup_irq+0x4c/0x90
[ 70.139324] hpet_time_init+0x25/0x37
[ 70.144803] x86_late_time_init+0xf/0x1c
[ 70.150538] start_kernel+0x40c/0x4ca
[ 70.156017] x86_64_start_reservations+0x24/0x26
[ 70.162445] x86_64_start_kernel+0x6f/0x72
[ 70.168357] secondary_startup_64+0xa4/0xb0
[ 70.174356] IN-SOFTIRQ-W at:
[ 70.177578] lock_acquire+0xd5/0x1c0
[ 70.182970] _raw_spin_lock+0x2f/0x40
[ 70.188448] try_to_wake_up+0x31b/0x540
[ 70.194097] wake_up_process+0x15/0x20
[ 70.199661] swake_up_locked+0x24/0x40
[ 70.205226] swake_up_one+0x1f/0x30
[ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
[ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
[ 70.223048] rcu_process_callbacks+0x111/0x10c0
[ 70.229396] __do_softirq+0xbf/0x493
[ 70.234788] irq_exit+0xc3/0xd0
[ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
[ 70.246176] apic_timer_interrupt+0xf/0x20
[ 70.252084] console_unlock+0x4e8/0x620
[ 70.257737] vprintk_emit+0x254/0x430
[ 70.263214] vprintk_default+0x1f/0x30
[ 70.268776] vprintk_func+0x27/0x60
[ 70.274082] printk+0x52/0x6e
[ 70.278864] native_cpu_up+0x71b/0x7a0
[ 70.284431] bringup_cpu+0x2a/0xb0
[ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
[ 70.295818] _cpu_up+0xae/0x160
[ 70.300776] do_cpu_up+0x8d/0xb0
[ 70.305818] cpu_up+0x13/0x20
[ 70.310602] smp_init+0x67/0xc4
[ 70.315559] kernel_init_freeable+0x134/0x259
[ 70.321731] kernel_init+0xe/0x110
[ 70.326947] ret_from_fork+0x3a/0x50
[ 70.332339] INITIAL USE at:
[ 70.335477] lock_acquire+0xd5/0x1c0
[ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
[ 70.346864] rq_attach_root+0x1b/0xc0
[ 70.352255] sched_init+0x310/0x432
[ 70.357472] start_kernel+0x26e/0x4ca
[ 70.362861] x86_64_start_reservations+0x24/0x26
[ 70.369207] x86_64_start_kernel+0x6f/0x72
[ 70.375048] secondary_startup_64+0xa4/0xb0
[ 70.380958] }
[ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
[ 70.389310] ... acquired at:
[ 70.392364] _raw_spin_lock+0x2f/0x40
[ 70.396192] pcpu_freelist_pop+0x7a/0xd0
[ 70.400286] bpf_get_stackid+0x1ca/0x470
[ 70.404383] bpf_get_stackid_tp+0x11/0x20
[ 70.408559] ___bpf_prog_run+0x7f2/0x1090
[ 70.412739] __bpf_prog_run32+0x39/0x50
[ 70.416742] trace_call_bpf+0xc8/0x1d0
[ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.425444] perf_trace_sched_switch+0x116/0x190
[ 70.430227] __schedule+0x6d8/0xa20
[ 70.433883] schedule+0x3d/0x90
[ 70.437194] worker_thread+0xd0/0x410
[ 70.441025] kthread+0x10d/0x140
[ 70.444424] ret_from_fork+0x3a/0x50
[ 70.448165]
[ 70.449658] -> (&head->lock){+...} ops: 61660 {
[ 70.454181] HARDIRQ-ON-W at:
[ 70.457319] lock_acquire+0xd5/0x1c0
[ 70.462536] _raw_spin_lock+0x2f/0x40
[ 70.467841] pcpu_freelist_push+0x28/0x50
[ 70.473492] bpf_get_stackid+0x43a/0x470
[ 70.479054] bpf_get_stackid_tp+0x11/0x20
[ 70.484724] ___bpf_prog_run+0x7f2/0x1090
[ 70.490372] __bpf_prog_run32+0x39/0x50
[ 70.495852] trace_call_bpf+0xc8/0x1d0
[ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.507500] perf_trace_urandom_read+0xbf/0x100
[ 70.513670] urandom_read+0x1ce/0x340
[ 70.518975] __vfs_read+0x37/0x160
[ 70.524027] vfs_read+0xa8/0x150
[ 70.528898] ksys_read+0x58/0xc0
[ 70.533766] __x64_sys_read+0x1a/0x20
[ 70.539092] do_syscall_64+0x4f/0x190
[ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.551092] INITIAL USE at:
[ 70.554143] lock_acquire+0xd5/0x1c0
[ 70.559272] _raw_spin_lock+0x2f/0x40
[ 70.564491] pcpu_freelist_populate+0xb6/0x110
[ 70.570489] htab_map_alloc+0x3b6/0x4c0
[ 70.575878] map_create+0xf0/0x370
[ 70.580836] __x64_sys_bpf+0x10b/0x260
[ 70.586138] do_syscall_64+0x4f/0x190
[ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.597960] }
[ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
[ 70.606142] ... acquired at:
[ 70.609104] mark_lock+0x392/0x570
[ 70.612676] __lock_acquire+0x5cd/0x13c0
[ 70.616767] lock_acquire+0xd5/0x1c0
[ 70.620511] _raw_spin_lock+0x2f/0x40
[ 70.624342] pcpu_freelist_push+0x28/0x50
[ 70.628519] bpf_get_stackid+0x43a/0x470
[ 70.632610] bpf_get_stackid_tp+0x11/0x20
[ 70.636785] ___bpf_prog_run+0x7f2/0x1090
[ 70.640965] __bpf_prog_run32+0x39/0x50
[ 70.644969] trace_call_bpf+0xc8/0x1d0
[ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.653668] perf_trace_urandom_read+0xbf/0x100
[ 70.658366] urandom_read+0x1ce/0x340
[ 70.662199] __vfs_read+0x37/0x160
[ 70.665768] vfs_read+0xa8/0x150
[ 70.669166] ksys_read+0x58/0xc0
[ 70.672562] __x64_sys_read+0x1a/0x20
[ 70.676393] do_syscall_64+0x4f/0x190
[ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.685440]
[ 70.686933]
[ 70.686933] stack backtrace:
[ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
[ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 70.705875] Call Trace:
[ 70.708321] dump_stack+0x68/0x95
[ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
[ 70.716935] check_usage_backwards+0x14b/0x160
[ 70.721374] mark_lock+0x392/0x570
[ 70.724771] ? mark_lock+0x392/0x570
[ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 70.733904] __lock_acquire+0x5cd/0x13c0
[ 70.737823] ? find_get_entry+0x1a2/0x2f0
[ 70.741825] lock_acquire+0xd5/0x1c0
[ 70.745397] ? lock_acquire+0xd5/0x1c0
[ 70.749141] ? pcpu_freelist_push+0x28/0x50
[ 70.753317] _raw_spin_lock+0x2f/0x40
[ 70.756974] ? pcpu_freelist_push+0x28/0x50
[ 70.761153] pcpu_freelist_push+0x28/0x50
[ 70.765156] bpf_get_stackid+0x43a/0x470
[ 70.769073] bpf_get_stackid_tp+0x11/0x20
[ 70.773077] ___bpf_prog_run+0x7f2/0x1090
[ 70.777083] __bpf_prog_run32+0x39/0x50
[ 70.780912] ? lock_acquire+0xd5/0x1c0
[ 70.784656] trace_call_bpf+0xc8/0x1d0
[ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.793013] perf_trace_urandom_read+0xbf/0x100
[ 70.797544] urandom_read+0x1ce/0x340
[ 70.801202] __vfs_read+0x37/0x160
[ 70.804598] ? security_file_permission+0x8d/0xb0
[ 70.809297] ? security_file_permission+0x8d/0xb0
[ 70.813993] vfs_read+0xa8/0x150
[ 70.817218] ksys_read+0x58/0xc0
[ 70.820442] __x64_sys_read+0x1a/0x20
[ 70.824106] do_syscall_64+0x4f/0x190
[ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.832807] RIP: 0033:0x7f302526f160
[ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
04 24
[ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
[ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
[ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
[ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
[ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
e 54
test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
Full kernel selftest test log,
https://lkft.validation.linaro.org/scheduler/job/314724#L2142
Best regards
Naresh Kamboju
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next-20180723: battery status funny after bootup
From: Rafael J. Wysocki @ 2018-07-24 9:21 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, lucas.magasweran, Rafael J. Wysocki,
kernel list, Linux-pm mailing list, Len Brown,
ACPI Devel Maling List
In-Reply-To: <20180724091226.GB22465@amd>
On Tue, Jul 24, 2018 at 11:12 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Tue 2018-07-24 10:27:08, Rafael J. Wysocki wrote:
>> On Mon, Jul 23, 2018 at 11:49 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> >
>> > pavel@amd:~$ cat /proc/acpi/battery/BAT0/state
>> > present: yes
>> > capacity state: ok
>> > charging state: charged
>> > present rate: 0 mW
>> > remaining capacity: 0 mWh
>> > present voltage: 0 mV
>> > pavel@amd:~$ uname -a
>> > Linux amd 4.18.0-rc6-next-20180723+ #141 SMP Mon Jul 23 22:11:47 CEST
>> > 2018 i686 GNU/Linux
>> >
>> > It will correct itself if I unplug/replug the AC adapter, I
>> > believe. Gnome2 battery monitor also looks confused.
>>
>> There are two battery changes in linux-next now that are not present
>> in the mainline
>>
>> 2a2aad34362b ACPI: battery: remove redundant old_present check on insertion
>> 706ac4aa536f ACPI: battery: use cache_time as cache "enabled"
>>
>> Does reverting any of them help? Or is the problem present in the
>> mainline too?
>
> Thanks for pointers! Not it mainline, I'd notice that.
>
> I reverted 706ac4aa536f , and on the next boot:
>
> pavel@amd:~$ cat /proc/acpi/battery/BAT0/state
> present: yes
> capacity state: ok
> charging state: charged
> present rate: 0 mW
> remaining capacity: 37150 mWh
> present voltage: 16400 mV
>
> ..plus icon was ok from the start.
OK, I'll drop 706ac4aa536f then, thanks!
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0 1/4] migration: update recv bitmap only on dest vm
From: Juan Quintela @ 2018-07-24 9:20 UTC (permalink / raw)
To: Peter Xu; +Cc: qemu-devel, Dr . David Alan Gilbert
In-Reply-To: <20180723123305.24792-2-peterx@redhat.com>
Peter Xu <peterx@redhat.com> wrote:
> We shouldn't update the received bitmap if we're the source VM. This
> fixes a breakage when release-ram is enabled on postcopy.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> migration/ram.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Reviewed-by: Juan Quintela <quintela@redhat.com>
^ permalink raw reply
* Re: [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem
From: Peter Zijlstra @ 2018-07-24 9:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Mark Rutland, mingo, andy.shevchenko, arnd, aryabinin, boqun.feng,
catalin.marinas, dvyukov, glider, hpa, linux-kernel, parri.andrea,
peter, tglx, will.deacon, linux-arm-kernel
In-Reply-To: <20180724071518.GA7300@gmail.com>
On Tue, Jul 24, 2018 at 09:15:18AM +0200, Ingo Molnar wrote:
>
> * Mark Rutland <mark.rutland@arm.com> wrote:
>
> > From: Peter Zijlstra <peterz@infradead.org>
> >
> > Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
> > working after making the atomic_long interface type safe.
> >
> > Needing casts is bad form, which made me look at the code. There are no
> > ld_semaphore::count users outside of these functions so there is no
> > reason why it can not be an atomic_long_t in the first place, obviating
> > the need for this cast.
> >
> > That also ensures the loads use atomic_long_read(), which implies (at
> > least) READ_ONCE() in order to guarantee single-copy-atomic loads.
> >
> > When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
> > very thin (the only difference is not changing *old on success, which
> > most callers don't seem to care about).
> >
> > So rework the whole thing to use atomic_long_t and its accessors
> > directly.
> >
> > While there, fixup all the horrible comment styles.
> >
> > Cc: Peter Hurley <peter@hurleysoftware.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > ---
> > drivers/tty/tty_ldsem.c | 82 ++++++++++++++++++++---------------------------
> > include/linux/tty_ldisc.h | 4 +--
> > 2 files changed, 37 insertions(+), 49 deletions(-)
> >
> > Note: Greg has queued this via the in the tty tree for v4.19, which can be seen at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=5fd691afdf929061c391d897fa627822c3b2fd5a
>
> Can this patch be skipped, or do the others depend on it?
IIRC it depends on it, without this patch you get build issues due to
atomic_long_cmpxchg() getting picky about it's arguments (type safety
improved).
^ permalink raw reply
* [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem
From: Peter Zijlstra @ 2018-07-24 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724071518.GA7300@gmail.com>
On Tue, Jul 24, 2018 at 09:15:18AM +0200, Ingo Molnar wrote:
>
> * Mark Rutland <mark.rutland@arm.com> wrote:
>
> > From: Peter Zijlstra <peterz@infradead.org>
> >
> > Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
> > working after making the atomic_long interface type safe.
> >
> > Needing casts is bad form, which made me look at the code. There are no
> > ld_semaphore::count users outside of these functions so there is no
> > reason why it can not be an atomic_long_t in the first place, obviating
> > the need for this cast.
> >
> > That also ensures the loads use atomic_long_read(), which implies (at
> > least) READ_ONCE() in order to guarantee single-copy-atomic loads.
> >
> > When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
> > very thin (the only difference is not changing *old on success, which
> > most callers don't seem to care about).
> >
> > So rework the whole thing to use atomic_long_t and its accessors
> > directly.
> >
> > While there, fixup all the horrible comment styles.
> >
> > Cc: Peter Hurley <peter@hurleysoftware.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > ---
> > drivers/tty/tty_ldsem.c | 82 ++++++++++++++++++++---------------------------
> > include/linux/tty_ldisc.h | 4 +--
> > 2 files changed, 37 insertions(+), 49 deletions(-)
> >
> > Note: Greg has queued this via the in the tty tree for v4.19, which can be seen at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=5fd691afdf929061c391d897fa627822c3b2fd5a
>
> Can this patch be skipped, or do the others depend on it?
IIRC it depends on it, without this patch you get build issues due to
atomic_long_cmpxchg() getting picky about it's arguments (type safety
improved).
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
From: liujunjie (A) @ 2018-07-24 9:18 UTC (permalink / raw)
To: Markus Armbruster
Cc: wangxin (U), Gonglei (Arei), Huangweidong (C),
qemu-devel@nongnu.org
In-Reply-To: <87zhyh2f7v.fsf@dusky.pond.sub.org>
Even using gdb command: set print elements 0, is still too large to print the whole string.
So I try to obtain the string in another way.
After several attempts(not easy in fact), I finally obtain the real length. The way is as follows:
(gdb) p (int *)str
$1 = (int *) 0x7f13a2e67010
(gdb) p *(char*) (0x7f13a2e67010 + 0x8B0FD63FF)@192
$2 = "--W\r\nffffffffffd17000: 00000000fec00000 XG-DACT-W\r\nffffffffffd18000: ", '0' <repeats 11 times>, "77000 XG-DA---W\r\nffffffffffd19000: ", '0 "78000 XG-DA---W\r\nffffffffffd1a000: ", '0' <repeats 11 times>, "79000 XG-DA---W\r\n\000\000"
With \000 at the end, we can find out the length is 0x8B0FD63FF + 192 - 2, that is 37329134781.
With this length, we can write a simple c code demo to reproduce the result we obtain before. Such as:
-----------------------------
#include<stdio.h>
int main()
{
char * tmp = "";
size_t a = 37329134781;
int end = a;
size_t b = end;
printf("%zu", b)
return 0;
}
-----------------------------
> -----Original Message-----
> From: Markus Armbruster [mailto:armbru@redhat.com]
> Sent: Tuesday, July 24, 2018 4:47 PM
> To: Markus Armbruster <armbru@redhat.com>
> Cc: liujunjie (A) <liujunjie23@huawei.com>; wangxin (U)
> <wangxinxin.wang@huawei.com>; Gonglei (Arei) <arei.gonglei@huawei.com>;
> Huangweidong (C) <weidong.huang@huawei.com>; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
>
> Markus Armbruster <armbru@redhat.com> writes:
>
> > "liujunjie (A)" <liujunjie23@huawei.com> writes:
> >
> >> The stack backtrace is as follows:
> >> (gdb) bt
> >> #0 0x00007f1dc3c7b091 in _g_log_abort () from
> >> /usr/lib64/libglib-2.0.so.0
> >> #1 0x00007f1dc3c7c0bd in g_log_default_handler () from
> >> /usr/lib64/libglib-2.0.so.0
> >> #2 0x00007f1dc3c7c341 in g_logv () from /usr/lib64/libglib-2.0.so.0
> >> #3 0x00007f1dc3c7c5cf in g_log () from /usr/lib64/libglib-2.0.so.0
> >> #4 0x00007f1dc3c7ac4c in g_malloc () from
> >> /usr/lib64/libglib-2.0.so.0
> >> #5 0x00000000008300b7 in qstring_from_substr (
> >> str=0x7f13a2e67010 "00000000777b8000: 0000000003083000
> >> ----A--U-\r\n00000000777b9000: 0000000005984000
> >> ----A--U-\r\n00000000777ba000: 0000000005985000
> >> ----A--U-\r\n00000000777bb000: 0000000003086000
> >> ----A--U-\r\n00000000777bc000"..., start=start@entry=0,
> >> end=<optimized out>) at qobject/qstring.c:51
> >> #6 0x0000000000830113 in qstring_from_str (str=<optimized out>) at
> >> qobject/qstring.c:66
> >> #7 0x000000000082be98 in qobject_output_type_str (v=<optimized out>,
> name=0x89703b "unused", obj=0x7ffff0135f98, errp=<optimized out>)
> >> at qapi/qobject_output_visitor.c:172
> >> #8 0x0000000000829d2c in visit_type_str (v=v@entry=0x4d9d940,
> name=name@entry=0x89703b "unused", obj=obj@entry=0x7ffff0135f98,
> errp=errp@entry=0x7ffff0135fa8)
> >> at qapi/qapi_visit_core.c:291
> >> #9 0x0000000000576135 in qmp_marshal_output_str (
> >> ret_in=0x7f13a2e67010 "00000000777b8000: 0000000003083000
> >> ----A--U-\r\n00000000777b9000: 0000000005984000
> >> ----A--U-\r\n00000000777ba000: 0000000005985000
> >> ----A--U-\r\n00000000777bb000: 0000000003086000
> >> ----A--U-\r\n00000000777bc000"...,
> >> ret_out=ret_out@entry=0x7ffff0136068, errp=errp@entry=0x7ffff0135fe8)
> >> at qmp-marshal.c:2022
> >> #10 0x00000000005762cb in qmp_marshal_human_monitor_command
> >> (args=<optimized out>, ret=0x7ffff0136068, errp=0x7ffff0136060) at
> >> qmp-marshal.c:2059
> >> #11 0x000000000082c897 in do_qmp_dispatch
> >> (request=request@entry=0x1fcda50, errp=errp@entry=0x7ffff01360b8) at
> >> qapi/qmp_dispatch.c:114
> >> #12 0x000000000082caeb in qmp_dispatch
> >> (request=request@entry=0x1fcda50) at qapi/qmp_dispatch.c:141
> >> #13 0x000000000045e0d2 in handle_qmp_command (parser=<optimized
> out>,
> >> tokens=<optimized out>) at
> >> /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3907
> > [...]
> >
> > The code is trying to marshall the return value of
> > qmp_human_monitor_command(). It's @ret_in in
> qmp_marshal_output_str()
> > (frame#9, abbreviated by GDB), and @str in qstring_from_substr()
> > (frame#5). Also @str in qstring_from_str() (frame#6), but GDB can't
> > see it there. Sadly, GDB can't see shows qstring_from_substr()'s
> > @end, either. However, you previously examined qstring->length there:
> >
> >>> > (gdb) p/x qstring->length
> >>> > $7 = 0xffffffffb0fd64bc
> >>> > (gdb) p end
> >>> > $8 = <optimized out>
> >
> > We know
> >
> > qstring->length = end - start + 1;
> >
> > If GDB shows the true value (always in doubt for optimized code), then
> > @end must be qstring->length - 1, because @start is zero. But that's
> > not plausible at all! It's almost 16 exabyte.
> >
> > I suspect GDB is lying to you. Please show us the complete string,
> > like
> > this:
> >
> > (gdb) set print elements unlimited
> > (gdb) print str
>
> Actually, I'm interested only in the true length of @str, and the print is just a
> simple way to find it. No need to post the output of print if it's inconveniently
> long.
^ permalink raw reply
* Re: [PATCH v2] perf/core: fix a possible deadlock scenario
From: Peter Zijlstra @ 2018-07-24 9:18 UTC (permalink / raw)
To: Cong Wang
Cc: LKML, Ingo Molnar, Linus Torvalds, Arnaldo Carvalho de Melo,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, Andi Kleen
In-Reply-To: <CAM_iQpXUsVW7a0+_Z_R-k8xGEQBSKd5Oz7j5+z=G1kQHoDfCqQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 06:44:43PM -0700, Cong Wang wrote:
> On Mon, Jul 23, 2018 at 6:35 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > Hi, Peter, Andi
> >
> > While reviewing the deadlock, I find out it looks like we could have the
> > following infinite recursion too:
> >
> > perf_event_account_interrupt()
> > __perf_event_account_interrupt()
> > perf_adjust_period()
> > event->pmu->stop
> > x86_pmu_stop()
> > x86_pmu.disable()
>
> Hmm, x86_pmu_stop() calls __test_and_clear_bit(), so
> we should not call x86_pmu.disable() twice here.
Right, but since we set HES_UPTODATE after calling
x86_perf_event_update() that can in fact recurse.
Now, I don't think that'll be fatal, but it might be good to test that.
If you pick these patches:
https://lkml.kernel.org/r/20170928121823.430053219@infradead.org
use force_early_printk (and actually configure a serial early_printk)
and put a printk() in x86_pmu_stop() and then run the perf_fuzzer or
something to try and reproduce.
But paranoia suggets moving that HES_UPTODATE thing one line up.
> > intel_pmu_disable_event()
> > intel_pmu_pebs_disable()
> > intel_pmu_drain_pebs_buffer()
> > intel_pmu_drain_pebs_nhm()
> > <repeat....>
> >
> > This time is pure hardware events, attr.freq must be non-zero.
> >
> > And, we could enter this infinite recursion in NMI handler too:
> >
> > intel_pmu_handle_irq()
> > perf_event_overflow()
> > __perf_event_overflow()
> > __perf_event_account_interrupt()
> > ....
> >
> > Or this is impossible too?
I'm not sure I see this second one.. can you be a little more specific?
^ permalink raw reply
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-24 9:18 UTC (permalink / raw)
To: Michal Hocko
Cc: Vlastimil Babka, linux-mm, linux-kernel, Andrew Morton,
Baoquan He, Dave Young, Greg Kroah-Hartman, Hari Bathini,
Huang Ying, Kirill A. Shutemov, Marc-André Lureau,
Matthew Wilcox, Miles Chen, Pavel Tatashin, Petr Tesarik
In-Reply-To: <20180724085358.GG28386@dhcp22.suse.cz>
On 24.07.2018 10:53, Michal Hocko wrote:
> On Tue 24-07-18 10:46:20, David Hildenbrand wrote:
>> On 24.07.2018 09:25, Michal Hocko wrote:
>>> On Mon 23-07-18 19:20:43, David Hildenbrand wrote:
>>>> On 23.07.2018 14:30, Michal Hocko wrote:
>>>>> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
>>>>>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>>>>>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>>>>>>> So reserved pages might be access by dump tools although nobody except
>>>>>>> the owner should touch them.
>>>>>>
>>>>>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
>>>>>> recently, but IIRC pages that are backing memmap (struct pages) are also
>>>>>> PG_reserved. And you definitely do want those in the dump.
>>>>>
>>>>> You are right. reserve_bootmem_region will make all early bootmem
>>>>> allocations (including those backing memmaps) PageReserved. I have asked
>>>>> several times but I haven't seen a satisfactory answer yet. Why do we
>>>>> even care for kdump about those. If they are reserved the nobody should
>>>>> really look at those specific struct pages and manipulate them. Kdump
>>>>> tools are using a kernel interface to read the content. If the specific
>>>>> content is backed by a non-existing memory then they should simply not
>>>>> return anything.
>>>>>
>>>>
>>>> "new kernel" provides an interface to read memory from "old kernel".
>>>>
>>>> The new kernel has no idea about
>>>> - which memory was added/online in the old kernel
>>>> - where struct pages of the old kernel are and what their content is
>>>> - which memory is save to touch and which not
>>>>
>>>> Dump tools figure all that out by interpreting the VMCORE. They e.g.
>>>> identify "struct pages" and see if they should be dumped. The "new
>>>> kernel" only allows to read that memory. It cannot hinder to crash the
>>>> system (e.g. if a dump tool would try to read a hwpoison page).
>>>>
>>>> So how should the "new kernel" know if a page can be touched or not?
>>>
>>> I am sorry I am not familiar with kdump much. But from what I remember
>>> it reads from /proc/vmcore and implementation of this interface should
>>> simply return EINVAL or alike when you try to dump inaccessible memory
>>> range.
>>
>> I assume the main problem with this approach is that we would always
>> have to fallback to reading old memory from vmcore page by page. e.g.
>> makedumpfile will always try to read bigger bunches. I also assume the
>> reason HWPOISON is handled in dump tools instead of in the kernel using
>> the mechanism you describe is the case.
>
> Is falling back to page-by-page for some ranges a real problem? I mean
> most of pages will simply be there so you can go in larger chunks. Once
> you get EINVAL, you just fall back to page-by-page for that particular
> range.
>
Looking at makedumpfile code, I assume implementation wise it should be
possible. They always try to read 256 pages at a time. If we get an
-EINVAL (-EIO?) we could fallback to reading page by page.
This implies having to properly handle exceptions when accessing memory.
Not sure if that will be easy. Maybe is_ram_page() is the better
alternative, because it hinders us from trying to read invalid memory
(or memory with random content) in the first place.
Will have to think about this and look into the details.
--
Thanks,
David / dhildenb
^ permalink raw reply
* [RFT v2 00/10] pinctrl: samsung: Remove ugly hack for sharing eint_wakeup_mask
From: Marek Szyprowski @ 2018-07-24 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723175302.22535-1-krzk@kernel.org>
Hi Krzysztof,
On 2018-07-23 19:52, Krzysztof Kozlowski wrote:
> Hi All,
>
> Changes since v1
> ================
> 1. Add Tomasz's ack.
> 2. Reword description in patch 6/10.
>
>
> Tests
> =====
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable of
> suspending and resuming. I am mostly thinking about S5Pv210-based (Aria),
> Trats, Trats2 and TM2 (Exynos5433). Existing platforms should not be
> broken however changing external interrupt wakeup mask was not done
> on Exynos5433.
Works fine on Exynos5433 TM2 with some additional patches related to
suspend/resume handling of the PMU. It handles only EINT0..EINT31 pins
for now. Exynos5433 has more external interrupt wakeup lines: EINT32-63
located at banks GPF1[0..7], GPF2[0..3], GPF3[0..3], GPF4[0..7] and
GPF5[0..7]. They can be configured as wakeup sources in
EXYNOS5433_EINT_WAKEUP_MASK1 (0x062C) PMU register. Handling of them
can be added later when it will be really needed.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Description
> ===========
> The Exynos/S5Pv210 machine suspend code needs to write the external
> interrupt mask during suspend. The mask is controlled by pin controller
> driver: the exynos_wkup_irq_set_wake() in IRQ chip for these wakeup
> interrupts.
>
> Therefore pinctrl driver code exposed an exynos_get_eint_wake_mask()
> function which was later used as an extern in machine code.
>
> This is quite ugly way of combining driver and machine code,
> not portable triggering Sparse and GCC warnings.
>
>
> This might break suspend capability S5Pv210 on with older DTBs (thus
> breaks DTB compatibility), however:
> 1. just "might" because in case of using older DTB, the wakeup mask
> will not be changed during suspend and default reset value (all
> interrupts non-masked) should work,
> 2. mainline support for S5Pv210 with DTB is limited and suspend
> to RAM already might be broken.
>
>
> Dependencies
> ============
> 1. The first seven patches should be taken through one tree,
> preferably samsung-pinctrl,
> 2. The DTS patch (7/10) for S5Pv210 should go into next cycle,
> 3. The remaining patches (8-10) should go after all previous,
> so probably another release cycle.
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (10):
> pinctrl: samsung: Define suspend and resume callbacks for all banks
> and SoCs
> pinctrl: samsung: Document suspend and resume members
> pinctrl: samsung: Document hidden requirement about one external
> wakeup
> pinctrl: samsung: Add dedicated compatible for S5Pv210 wakeup
> interrupts
> ARM: exynos: Define EINT_WAKEUP_MASK registers for S5Pv210 and
> Exynos5433
> pinctrl: samsung: Write external wakeup interrupt mask
> ARM: dts: s5pv210: Switch to S5Pv210 specific pinctrl wakeup
> compatible
> ARM: s5pv210: Remove legacy setting of external wakeup interrupts
> ARM: exynos: Remove legacy setting of external wakeup interrupts
> pinctrl: samsung: Remove legacy API for handling external wakeup
> interrupts mask
>
> .../bindings/pinctrl/samsung-pinctrl.txt | 11 ++-
> arch/arm/boot/dts/s5pv210.dtsi | 2 +-
> arch/arm/mach-exynos/common.h | 2 -
> arch/arm/mach-exynos/suspend.c | 16 +++--
> arch/arm/mach-s5pv210/common.h | 1 -
> arch/arm/mach-s5pv210/pm.c | 16 +++--
> drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 16 +++++
> drivers/pinctrl/samsung/pinctrl-exynos.c | 78 +++++++++++++++++++---
> drivers/pinctrl/samsung/pinctrl-samsung.h | 11 +++
> include/linux/soc/samsung/exynos-regs-pmu.h | 8 ++-
> 10 files changed, 136 insertions(+), 25 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [RFT v2 00/10] pinctrl: samsung: Remove ugly hack for sharing eint_wakeup_mask
From: Marek Szyprowski @ 2018-07-24 9:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Tomasz Figa, Sylwester Nawrocki,
Linus Walleij, Rob Herring, Mark Rutland, Kukjin Kim,
Russell King, Kyungmin Park, linux-arm-kernel, linux-samsung-soc,
linux-gpio, devicetree, linux-kernel
Cc: Paweł Chmiel, Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar,
Pankaj Dubey
In-Reply-To: <20180723175302.22535-1-krzk@kernel.org>
Hi Krzysztof,
On 2018-07-23 19:52, Krzysztof Kozlowski wrote:
> Hi All,
>
> Changes since v1
> ================
> 1. Add Tomasz's ack.
> 2. Reword description in patch 6/10.
>
>
> Tests
> =====
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable of
> suspending and resuming. I am mostly thinking about S5Pv210-based (Aria),
> Trats, Trats2 and TM2 (Exynos5433). Existing platforms should not be
> broken however changing external interrupt wakeup mask was not done
> on Exynos5433.
Works fine on Exynos5433 TM2 with some additional patches related to
suspend/resume handling of the PMU. It handles only EINT0..EINT31 pins
for now. Exynos5433 has more external interrupt wakeup lines: EINT32-63
located at banks GPF1[0..7], GPF2[0..3], GPF3[0..3], GPF4[0..7] and
GPF5[0..7]. They can be configured as wakeup sources in
EXYNOS5433_EINT_WAKEUP_MASK1 (0x062C) PMU register. Handling of them
can be added later when it will be really needed.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Description
> ===========
> The Exynos/S5Pv210 machine suspend code needs to write the external
> interrupt mask during suspend. The mask is controlled by pin controller
> driver: the exynos_wkup_irq_set_wake() in IRQ chip for these wakeup
> interrupts.
>
> Therefore pinctrl driver code exposed an exynos_get_eint_wake_mask()
> function which was later used as an extern in machine code.
>
> This is quite ugly way of combining driver and machine code,
> not portable triggering Sparse and GCC warnings.
>
>
> This might break suspend capability S5Pv210 on with older DTBs (thus
> breaks DTB compatibility), however:
> 1. just "might" because in case of using older DTB, the wakeup mask
> will not be changed during suspend and default reset value (all
> interrupts non-masked) should work,
> 2. mainline support for S5Pv210 with DTB is limited and suspend
> to RAM already might be broken.
>
>
> Dependencies
> ============
> 1. The first seven patches should be taken through one tree,
> preferably samsung-pinctrl,
> 2. The DTS patch (7/10) for S5Pv210 should go into next cycle,
> 3. The remaining patches (8-10) should go after all previous,
> so probably another release cycle.
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (10):
> pinctrl: samsung: Define suspend and resume callbacks for all banks
> and SoCs
> pinctrl: samsung: Document suspend and resume members
> pinctrl: samsung: Document hidden requirement about one external
> wakeup
> pinctrl: samsung: Add dedicated compatible for S5Pv210 wakeup
> interrupts
> ARM: exynos: Define EINT_WAKEUP_MASK registers for S5Pv210 and
> Exynos5433
> pinctrl: samsung: Write external wakeup interrupt mask
> ARM: dts: s5pv210: Switch to S5Pv210 specific pinctrl wakeup
> compatible
> ARM: s5pv210: Remove legacy setting of external wakeup interrupts
> ARM: exynos: Remove legacy setting of external wakeup interrupts
> pinctrl: samsung: Remove legacy API for handling external wakeup
> interrupts mask
>
> .../bindings/pinctrl/samsung-pinctrl.txt | 11 ++-
> arch/arm/boot/dts/s5pv210.dtsi | 2 +-
> arch/arm/mach-exynos/common.h | 2 -
> arch/arm/mach-exynos/suspend.c | 16 +++--
> arch/arm/mach-s5pv210/common.h | 1 -
> arch/arm/mach-s5pv210/pm.c | 16 +++--
> drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 16 +++++
> drivers/pinctrl/samsung/pinctrl-exynos.c | 78 +++++++++++++++++++---
> drivers/pinctrl/samsung/pinctrl-samsung.h | 11 +++
> include/linux/soc/samsung/exynos-regs-pmu.h | 8 ++-
> 10 files changed, 136 insertions(+), 25 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* next-20180723 build: 2 failures 11 warnings (next-20180723)
From: Will Deacon @ 2018-07-24 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723181150.GF13981@sirena.org.uk>
On Mon, Jul 23, 2018 at 07:11:50PM +0100, Mark Brown wrote:
> On Mon, Jul 23, 2018 at 05:59:12PM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig with:
>
> > arm64-allmodconfig
> > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> using
>
> aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
>
> however it builds perfectly fine with
>
> aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> which honestly seems like a sensible and worthwhile upgrade at this
> point anyway given that it's a year and a half old so I'm going to do
> that for my builder (perhaps even jump on a newer version) but it seemed
> worth highlighting in case this is considered undesirable. A similar
> issue is hitting on KernelCI, we should probably look at upgrading the
> toolchain there too.
Hmm, it looks to me like this comes about because xen/privcmd.c is being
built as a module, but contains a call to set_pte_at() with a special pte:
pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), r->prot));
set_pte_at(r->mm, addr, ptep, pte);
which on arm64 contains:
if (pte_present(pte) && pte_user_exec(pte) && !pte_special(pte))
__sync_icache_dcache(pte);
so GCC 6 can optimise away the call to the non-exported symbol, but GCC 5
has trouble.
What I don't understand is why this suddenly cropped up. Did GCC 5 build
linux-next arm64 allmodconfig last week?
Cheers,
Will
^ permalink raw reply
* Re: next-20180723 build: 2 failures 11 warnings (next-20180723)
From: Will Deacon @ 2018-07-24 9:16 UTC (permalink / raw)
To: Mark Brown
Cc: linaro-kernel, kernel-build-reports, Catalin Marinas, khilman,
linux-next, matthew.hart, linux-arm-kernel
In-Reply-To: <20180723181150.GF13981@sirena.org.uk>
On Mon, Jul 23, 2018 at 07:11:50PM +0100, Mark Brown wrote:
> On Mon, Jul 23, 2018 at 05:59:12PM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig with:
>
> > arm64-allmodconfig
> > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> using
>
> aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
>
> however it builds perfectly fine with
>
> aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> which honestly seems like a sensible and worthwhile upgrade at this
> point anyway given that it's a year and a half old so I'm going to do
> that for my builder (perhaps even jump on a newer version) but it seemed
> worth highlighting in case this is considered undesirable. A similar
> issue is hitting on KernelCI, we should probably look at upgrading the
> toolchain there too.
Hmm, it looks to me like this comes about because xen/privcmd.c is being
built as a module, but contains a call to set_pte_at() with a special pte:
pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), r->prot));
set_pte_at(r->mm, addr, ptep, pte);
which on arm64 contains:
if (pte_present(pte) && pte_user_exec(pte) && !pte_special(pte))
__sync_icache_dcache(pte);
so GCC 6 can optimise away the call to the non-exported symbol, but GCC 5
has trouble.
What I don't understand is why this suddenly cropped up. Did GCC 5 build
linux-next arm64 allmodconfig last week?
Cheers,
Will
^ permalink raw reply
* Re: automation: Creating a patchwork instance to improve pre-commit build testing
From: Andrew Cooper @ 2018-07-24 9:14 UTC (permalink / raw)
To: Jan Beulich, Doug Goldstein, Lars Kurth, Wei Liu
Cc: Minios-devel, xen-devel, Iurii Artemenko, committers,
Matt Spencer
In-Reply-To: <5B56EC0002000078001D708C@prv1-mh.provo.novell.com>
On 24/07/18 10:06, Jan Beulich wrote:
>>>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
>> # How does this impact me?
>> The contribution workflow is *not* impacted by this change, but once up and
>> running the following will happen once you post a patch or patch series to
>> xen-devel:
>> * Patchwork will take patch series from the mailing list and applies it
>> * CI/DC testing is triggered
>> * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
>>
>> This does mean though that series which do not build or show other issues,
>> will likely not be reviewed until the tests pass. This would lessen the
>> burden on reviewers, as they will know whether the code submitted builds on a
>> wide array of environments.
> So how are dependencies between series intended to be dealt with? It
> is not uncommon for someone to say "applies only on top of xyz". The
> implication of "will likely not be reviewed until the tests pass" seems
> unsuitable to me in such a case.
99% of submissions aren't "applies on top of xyz".
Alternative, how about we see about not blocking underlying patches for
unreasonable periods of time?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 0/6] Symbol namespaces
From: Martijn Coenen @ 2018-07-24 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Masahiro Yamada, Michal Marek,
Geert Uytterhoeven, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
the arch/x86 maintainers, Alan Stern, Greg Kroah-Hartman,
Oliver Neukum, Jessica Yu, Stephen Boyd, Philippe Ombredanne,
Kate Stewart, Sam Ravnborg, Linux Kbuild mailing list, linux-m68k,
USB list, USB Storage list, linux-scsi, linux-arch,
Martijn Coenen, Sandeep Patil, Iliyan Malchev, Joel Fernandes
In-Reply-To: <CAK8P3a1F2j3PL2ng7xw9TbCQqwn_U+1D5ChH+v8qWVrxOfW3xw@mail.gmail.com>
Hi Arnd,
On Mon, Jul 23, 2018 at 4:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> This looks nice. I don't want to overload you with additional
> requests, but it might be good to think about how this can
> be taken further, if we want to actually convert large
> parts of the kernel to it.
No worries about overloading, I'm happy with all feedback to make this better.
> I have two ideas:
>
> - It would be nice to have a simple mechanism in Kconfig
> to put all symbols in a module into a namespace that is
> derived from KBUILD_MODNAME, to avoid having to
> annotate every symbol separately. This could be similar
> to how we ended up dealing with EXPORT_NO_SYMBOLS
> in the linux-2.4 days, with the goal of eventually having
> a namespace for each symbol. Similarly, we could pass
> a number of default namespaces through the Makefile,
> e.g. if we have a directory that has lots of drivers that all
> import the symbols from a common subsystem module.
I'm hinging on two thoughts here; I really like it because it
obviously reduces work and makes this easier to use. On the other
hand, you now have to look in multiple places to see if a symbol is
exported to a namespace/imported from a module. Perhaps it depends on
how coarse-grained the namespaces end up being. Either way, I think it
would be pretty easy to cook up patches for this.
>
> - If this is possible to implement, it would be great to have
> a way to limit the globally visible symbols in a module
> to the ones that are explicitly exported even when a that
> module is built-in rather than loadable. Not sure how this
> is best done though. A couple of things can be done with
> objcopy, or possibly by reintroducing partial linking (which
> was removed not too long ago).
If I understand you correctly, this is orthogonal to symbol
namespaces, right? Though I think there is value in doing the same
thing for symbol namespaces: right now, the only way to find out if
all modules correctly import a symbol exported to a namespace is to
run an 'allmodconfig'; not having to do that would be a win. Being
able to do the same thing for the exported symbols in the global
namespace is very similar. So yeah, I think this is a good idea and
will look into this more.
Do you think these things should be a part of these series, or can it
be a follow-up?
Thanks,
Martijn
>
> Arnd
^ permalink raw reply
* [PATCH] arm64: fix for restoring console loglevel after handling traps
From: Hari Vyas @ 2018-07-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM5rFu-_sU1eSryFR-rDF=6BxZuf_E0xBQJ8RizNKYDB+DgWOQ@mail.gmail.com>
Hi all,
On Fri, Jul 20, 2018 at 7:04 PM, Hari Vyas <hari.vyas@broadcom.com> wrote:
> On Fri, Jul 20, 2018 at 5:43 PM, Petr Mladek <pmladek@suse.com> wrote:
>> On Thu 2018-07-19 19:42:50, Hari Vyas wrote:
>>> On Thu, Jul 19, 2018 at 4:09 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> > On Thu, Jul 19, 2018 at 03:47:46PM +0530, Hari Vyas wrote:
>>> >> On Thu, Jul 19, 2018 at 3:31 PM, Sergey Senozhatsky
>>> >> <sergey.senozhatsky.work@gmail.com> wrote:
>>> >> >> @@ -694,7 +698,7 @@ void __noreturn arm64_serror_panic(struct pt_regs *regs, u32 esr)
>>> >> >> __show_regs(regs);
>>> >> >>
>>> >> >> nmi_panic(regs, "Asynchronous SError Interrupt");
>>> >> >> -
>>> >> >> + restore_console_loglevel();
>>> >> >
>>> >> > panic()
>>> >> >
>>> >> > What's the point of restore_console_loglevel() after panic()?
>>> >> >
>>> >> > -ss
>>> >> Except die(), other places restore call can be avoided but just added
>>> >> for code completeness.
>>> >
>>> > As Sergey said, panic() is *fatal*. It does not return, so it makes no
>>> > sense to place code after it.
>>> >
>>> I too pointed in cover letter. I just too added for code completeness.
>>
>> The code-completeness is not a good reason. It might cause false
>> expectation that panic() is not fatal. It would cause more harm
>> than good.
>>
>> The same is true also for die(). It should be fatal. I agree with
>> Sergey and Mark that it does not make sense to restore
>> the original level there.
>>
>> Best Regards,
>> Petr
> I can remove restore from not required (3) places.
>
> Other than that, based on discussion, bad_mode() should panic so
> better die() call itself be removed from bad_mode().
> As this(i.e. cleanup of bad_mode) is not related to raised patch so
> better one another bug/patch be raised for cleaning
> bad_mode() and probably die() too.
>
> Currently this die() is called from some other places also but not
> completely sure whether restore_console_loglevel is required
> there also or not as creating situation will be very difficult in
> normal scenario.
For tracking purpose, I have raised a separate bug for bad_mode() issue i.e.
Bug 200637 - ARM64: bad_mode() handler may not result in panic always
due to die() call in the beginning
Probable fix could be to remove die() from bad_mode() but better other confirms.
As stated, die() is called from other places also my feeling and
logically restoration is required. Please
confirm whether to close this issue without any change or proceed with
only one restore() call in die and discard at
other 3 places.
^ permalink raw reply
* Re: [PATCH] ACPI / LPSS: Avoid PM quirks on suspend and resume from S3
From: Rafael J. Wysocki @ 2018-07-24 9:13 UTC (permalink / raw)
To: Kai Heng Feng
Cc: ACPI Devel Maling List, Ulf Hansson, P HeLiOn,
Linux Kernel Mailing List, Andy Shevchenko, Mika Westerberg,
Linux PM
In-Reply-To: <ABABA247-9C33-4311-ADA5-D0D00B810C6C@canonical.com>
On Tuesday, July 24, 2018 10:46:09 AM CEST Kai Heng Feng wrote:
> Hi Rafael,
>
> > On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate
> > runtime PM and system sleep handling) introduced a system suspend
> > regression on some machines, but the only functional change made by
> > it was to cause the PM quirks in the LPSS to also be used during
> > system suspend and resume. While that should always work for
> > suspend-to-idle, it turns out to be problematic for S3
> > (suspend-to-RAM).
> >
> > To address that issue restore the previous S3 suspend and resume
> > behavior of the LPSS to avoid applying PM quirks then.
>
> The users reported that this patch does fix the S3 issue, but the S4 still
> fails.
>
> Please refer to [1] for more for user's testing result.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950/comments/60
Please ask the users to test the patch below, then, on top of the $subject one.
---
drivers/acpi/acpi_lpss.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/acpi/acpi_lpss.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -879,6 +879,7 @@ static void acpi_lpss_dismiss(struct dev
#define LPSS_GPIODEF0_DMA_LLP BIT(13)
static DEFINE_MUTEX(lpss_iosf_mutex);
+static bool lpss_iosf_d3_entered;
static void lpss_iosf_enter_d3_state(void)
{
@@ -921,6 +922,9 @@ static void lpss_iosf_enter_d3_state(voi
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
LPSS_IOSF_GPIODEF0, value1, mask1);
+
+ lpss_iosf_d3_entered = true;
+
exit:
mutex_unlock(&lpss_iosf_mutex);
}
@@ -935,6 +939,9 @@ static void lpss_iosf_exit_d3_state(void
mutex_lock(&lpss_iosf_mutex);
+ if (!lpss_iosf_d3_entered)
+ goto exit;
+
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIOEP, MBI_CR_WRITE,
LPSS_IOSF_GPIODEF0, value1, mask1);
@@ -944,13 +951,13 @@ static void lpss_iosf_exit_d3_state(void
iosf_mbi_modify(LPSS_IOSF_UNIT_LPIO1, MBI_CFG_WRITE,
LPSS_IOSF_PMCSR, value2, mask2);
+exit:
mutex_unlock(&lpss_iosf_mutex);
}
-static int acpi_lpss_suspend(struct device *dev, bool runtime)
+static int acpi_lpss_suspend(struct device *dev, bool wakeup)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
- bool wakeup = runtime || device_may_wakeup(dev);
int ret;
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
@@ -963,14 +970,14 @@ static int acpi_lpss_suspend(struct devi
* wrong status for devices being about to be powered off. See
* lpss_iosf_enter_d3_state() for further information.
*/
- if ((runtime || !pm_suspend_via_firmware()) &&
+ if (acpi_target_system_state() == ACPI_STATE_S0 &&
lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_enter_d3_state();
return ret;
}
-static int acpi_lpss_resume(struct device *dev, bool runtime)
+static int acpi_lpss_resume(struct device *dev)
{
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
@@ -979,8 +986,7 @@ static int acpi_lpss_resume(struct devic
* This call is kept first to be in symmetry with
* acpi_lpss_runtime_suspend() one.
*/
- if ((runtime || !pm_resume_via_firmware()) &&
- lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+ if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_exit_d3_state();
ret = acpi_dev_resume(dev);
@@ -1004,12 +1010,12 @@ static int acpi_lpss_suspend_late(struct
return 0;
ret = pm_generic_suspend_late(dev);
- return ret ? ret : acpi_lpss_suspend(dev, false);
+ return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
}
static int acpi_lpss_resume_early(struct device *dev)
{
- int ret = acpi_lpss_resume(dev, false);
+ int ret = acpi_lpss_resume(dev);
return ret ? ret : pm_generic_resume_early(dev);
}
@@ -1024,7 +1030,7 @@ static int acpi_lpss_runtime_suspend(str
static int acpi_lpss_runtime_resume(struct device *dev)
{
- int ret = acpi_lpss_resume(dev, true);
+ int ret = acpi_lpss_resume(dev);
return ret ? ret : pm_generic_runtime_resume(dev);
}
^ permalink raw reply
* Re: kernel BUG at mm/shmem.c:LINE!
From: Hugh Dickins @ 2018-07-24 9:12 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Hugh Dickins, syzbot, Kirill A. Shutemov, Andrew Morton,
linux-kernel, linux-mm, syzkaller-bugs
In-Reply-To: <20180723225454.GC18236@bombadil.infradead.org>
On Mon, 23 Jul 2018, Matthew Wilcox wrote:
> On Mon, Jul 23, 2018 at 03:42:22PM -0700, Hugh Dickins wrote:
> > On Mon, 23 Jul 2018, Matthew Wilcox wrote:
> > > I figured out a fix and pushed it to the 'ida' branch in
> > > git://git.infradead.org/users/willy/linux-dax.git
> >
> > Great, thanks a lot for sorting that out so quickly. But I've cloned
> > the tree and don't see today's patch, so assume you've folded the fix
> > into an existing commit? If possible, please append the diff of today's
> > fix to this thread so that we can try it out. Or if that's difficult,
> > please at least tell which files were modified, then I can probably
> > work it out from the diff of those files against mmotm.
>
> Sure! It's just this:
>
> diff --git a/lib/xarray.c b/lib/xarray.c
> index 32a9c2a6a9e9..383c410997eb 100644
> --- a/lib/xarray.c
> +++ b/lib/xarray.c
> @@ -660,6 +660,8 @@ void xas_create_range(struct xa_state *xas)
> unsigned char sibs = xas->xa_sibs;
>
> xas->xa_index |= ((sibs + 1) << shift) - 1;
> + if (!xas_top(xas->xa_node) && xas->xa_node->shift == xas->xa_shift)
> + xas->xa_offset |= sibs;
> xas->xa_shift = 0;
> xas->xa_sibs = 0;
Yes, that's a big improvement, the huge "cp" is now fine, thank you.
I've updated my xfstests tree, and tried that on mmotm with this patch.
The few failures are exactly the same as on 4.18-rc6, whether mounting
tmpfs as huge or not. But four of the tests, generic/{340,345,346,354}
crash (oops) on 4.18-rc5-mm1 + your patch above, but pass on 4.18-rc6.
That was simply with non-huge tmpfs: I just patched them out and didn't
try for whether they crash with huge tmpfs too: probably they do, but
that won't be very interesting until the non-huge crashes are fixed.
I paid no attention to where the crashes were, I was just pressing on
to skip the problem tests to get as full a run as possible, with that
list of what's problematic and needs further investigation.
To test non-huge tmpfs (as root), I wrap xfstests' check script as
follows (you'll want to mkdir or substitute somewhere else for /xft):
export FSTYP=tmpfs
export DISABLE_UDF_TEST=1
export TEST_DEV=tmpfs1:
export TEST_DIR=/xft
export SCRATCH_DEV=tmpfs2:
export SCRATCH_MNT=/mnt
mount -t $FSTYP -o size=1088M $TEST_DEV $TEST_DIR || exit $?
./check "$@" # typically "-g auto"
umount /xft /mnt 2>/dev/null
But don't bother with "-g auto" for the moment: I have workarounds in
for a few of them, generic/{027,213,449}, which we need not get into
right now (without them, two of those tests can take close to forever).
To test huge tmpfs (as root), I wrap xfstests' check script as:
export FSTYP=tmpfs
export DISABLE_UDF_TEST=1
export TEST_DEV=tmpfs1:
export TEST_DIR=/xft
export SCRATCH_DEV=tmpfs2:
export SCRATCH_MNT=/mnt
export TMPFS_MOUNT_OPTIONS="-o size=1088M,huge=always"
mount -t $FSTYP $TMPFS_MOUNT_OPTIONS $TEST_DEV $TEST_DIR || exit $?
./check "$@" # typically "-g auto"
umount /xft /mnt 2>/dev/null
Hugh
^ permalink raw reply
* [PATCH v8 2/2] hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
From: Shilpasri G Bhat @ 2018-07-24 9:13 UTC (permalink / raw)
To: mpe, linux
Cc: linuxppc-dev, linux-hwmon, linux-kernel, ego, stewart,
Shilpasri G Bhat
In-Reply-To: <1532423589-18730-1-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
OPAL firmware provides the facility for some groups of sensors to be
enabled/disabled at runtime to give the user the option of using the
system resources for collecting these sensors or not.
For example, on POWER9 systems, the On Chip Controller (OCC) gathers
various system and chip level sensors and maintains their values in
main memory.
This patch provides support for enabling/disabling the sensor groups
like power, temperature, current and voltage.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: Commit message]
---
Changes from v7:
- Use of_for_each_phandle() and of_count_phandle_with_args() to parse
through the phandle array
Documentation/hwmon/ibmpowernv | 43 +++++++-
drivers/hwmon/ibmpowernv.c | 238 +++++++++++++++++++++++++++++++++++------
2 files changed, 247 insertions(+), 34 deletions(-)
diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv
index 8826ba2..5646825 100644
--- a/Documentation/hwmon/ibmpowernv
+++ b/Documentation/hwmon/ibmpowernv
@@ -33,9 +33,48 @@ fanX_input Measured RPM value.
fanX_min Threshold RPM for alert generation.
fanX_fault 0: No fail condition
1: Failing fan
+
tempX_input Measured ambient temperature.
tempX_max Threshold ambient temperature for alert generation.
-inX_input Measured power supply voltage
+tempX_highest Historical maximum temperature
+tempX_lowest Historical minimum temperature
+tempX_enable Enable/disable all temperature sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its temperature sensors.
+ 1: Enable
+ 0: Disable
+
+inX_input Measured power supply voltage (millivolt)
inX_fault 0: No fail condition.
1: Failing power supply.
-power1_input System power consumption (microWatt)
+inX_highest Historical maximum voltage
+inX_lowest Historical minimum voltage
+inX_enable Enable/disable all voltage sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its voltage sensors.
+ 1: Enable
+ 0: Disable
+
+powerX_input Power consumption (microWatt)
+powerX_input_highest Historical maximum power
+powerX_input_lowest Historical minimum power
+powerX_enable Enable/disable all power sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its power sensors.
+ 1: Enable
+ 0: Disable
+
+currX_input Measured current (milliampere)
+currX_highest Historical maximum current
+currX_lowest Historical minimum current
+currX_enable Enable/disable all current sensors belonging to the
+ sub-group. In POWER9, this attribute corresponds to
+ each OCC. Using this attribute each OCC can be asked to
+ disable/enable all of its current sensors.
+ 1: Enable
+ 0: Disable
+
+energyX_input Cumulative energy (microJoule)
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index f829dad..8347280 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -90,11 +90,20 @@ struct sensor_data {
char label[MAX_LABEL_LEN];
char name[MAX_ATTR_LEN];
struct device_attribute dev_attr;
+ struct sensor_group_data *sgrp_data;
+};
+
+struct sensor_group_data {
+ struct mutex mutex;
+ u32 gid;
+ bool enable;
};
struct platform_data {
const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+ struct sensor_group_data *sgrp_data;
u32 sensors_count; /* Total count of sensors from each group */
+ u32 nr_sensor_groups; /* Total number of sensor groups */
};
static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
@@ -105,6 +114,9 @@ static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
ssize_t ret;
u64 x;
+ if (sdata->sgrp_data && !sdata->sgrp_data->enable)
+ return -ENODATA;
+
ret = opal_get_sensor_data_u64(sdata->id, &x);
if (ret)
@@ -120,6 +132,46 @@ static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
return sprintf(buf, "%llu\n", x);
}
+static ssize_t show_enable(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+ dev_attr);
+
+ return sprintf(buf, "%u\n", sdata->sgrp_data->enable);
+}
+
+static ssize_t store_enable(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+ dev_attr);
+ struct sensor_group_data *sgrp_data = sdata->sgrp_data;
+ int ret;
+ bool data;
+
+ ret = kstrtobool(buf, &data);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(&sgrp_data->mutex);
+ if (ret)
+ return ret;
+
+ if (data != sgrp_data->enable) {
+ ret = sensor_group_enable(sgrp_data->gid, data);
+ if (!ret)
+ sgrp_data->enable = data;
+ }
+
+ if (!ret)
+ ret = count;
+
+ mutex_unlock(&sgrp_data->mutex);
+ return ret;
+}
+
static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
char *buf)
{
@@ -292,12 +344,115 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
return ++sensor_groups[sdata->type].hwmon_index;
}
+static int init_sensor_group_data(struct platform_device *pdev,
+ struct platform_data *pdata)
+{
+ struct sensor_group_data *sgrp_data;
+ struct device_node *groups, *sgrp;
+ int count = 0, ret = 0;
+ enum sensors type;
+
+ groups = of_find_compatible_node(NULL, NULL, "ibm,opal-sensor-group");
+ if (!groups)
+ return ret;
+
+ for_each_child_of_node(groups, sgrp) {
+ type = get_sensor_type(sgrp);
+ if (type != MAX_SENSOR_TYPE)
+ pdata->nr_sensor_groups++;
+ }
+
+ if (!pdata->nr_sensor_groups)
+ goto out;
+
+ sgrp_data = devm_kcalloc(&pdev->dev, pdata->nr_sensor_groups,
+ sizeof(*sgrp_data), GFP_KERNEL);
+ if (!sgrp_data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for_each_child_of_node(groups, sgrp) {
+ u32 gid;
+
+ type = get_sensor_type(sgrp);
+ if (type == MAX_SENSOR_TYPE)
+ continue;
+
+ if (of_property_read_u32(sgrp, "sensor-group-id", &gid))
+ continue;
+
+ if (of_count_phandle_with_args(sgrp, "sensors", NULL) <= 0)
+ continue;
+
+ sensor_groups[type].attr_count++;
+ sgrp_data[count].gid = gid;
+ mutex_init(&sgrp_data[count].mutex);
+ sgrp_data[count++].enable = false;
+ }
+
+ pdata->sgrp_data = sgrp_data;
+out:
+ of_node_put(groups);
+ return ret;
+}
+
+static struct sensor_group_data *get_sensor_group(struct platform_data *pdata,
+ struct device_node *node,
+ enum sensors gtype)
+{
+ struct sensor_group_data *sgrp_data = pdata->sgrp_data;
+ struct device_node *groups, *sgrp;
+
+ groups = of_find_compatible_node(NULL, NULL, "ibm,opal-sensor-group");
+ if (!groups)
+ return NULL;
+
+ for_each_child_of_node(groups, sgrp) {
+ struct of_phandle_iterator it;
+ u32 gid;
+ int rc, i;
+ enum sensors type;
+
+ type = get_sensor_type(sgrp);
+ if (type != gtype)
+ continue;
+
+ if (of_property_read_u32(sgrp, "sensor-group-id", &gid))
+ continue;
+
+ of_for_each_phandle(&it, rc, sgrp, "sensors", NULL, 0)
+ if (it.phandle == node->phandle) {
+ of_node_put(it.node);
+ break;
+ }
+
+ if (rc)
+ continue;
+
+ for (i = 0; i < pdata->nr_sensor_groups; i++)
+ if (gid == sgrp_data[i].gid) {
+ of_node_put(sgrp);
+ of_node_put(groups);
+ return &sgrp_data[i];
+ }
+ }
+
+ of_node_put(groups);
+ return NULL;
+}
+
static int populate_attr_groups(struct platform_device *pdev)
{
struct platform_data *pdata = platform_get_drvdata(pdev);
const struct attribute_group **pgroups = pdata->attr_groups;
struct device_node *opal, *np;
enum sensors type;
+ int ret;
+
+ ret = init_sensor_group_data(pdev, pdata);
+ if (ret)
+ return ret;
opal = of_find_node_by_path("/ibm,opal/sensors");
for_each_child_of_node(opal, np) {
@@ -344,7 +499,10 @@ static int populate_attr_groups(struct platform_device *pdev)
static void create_hwmon_attr(struct sensor_data *sdata, const char *attr_name,
ssize_t (*show)(struct device *dev,
struct device_attribute *attr,
- char *buf))
+ char *buf),
+ ssize_t (*store)(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count))
{
snprintf(sdata->name, MAX_ATTR_LEN, "%s%d_%s",
sensor_groups[sdata->type].name, sdata->hwmon_index,
@@ -352,23 +510,33 @@ static void create_hwmon_attr(struct sensor_data *sdata, const char *attr_name,
sysfs_attr_init(&sdata->dev_attr.attr);
sdata->dev_attr.attr.name = sdata->name;
- sdata->dev_attr.attr.mode = S_IRUGO;
sdata->dev_attr.show = show;
+ if (store) {
+ sdata->dev_attr.store = store;
+ sdata->dev_attr.attr.mode = 0664;
+ } else {
+ sdata->dev_attr.attr.mode = 0444;
+ }
}
static void populate_sensor(struct sensor_data *sdata, int od, int hd, int sid,
const char *attr_name, enum sensors type,
const struct attribute_group *pgroup,
+ struct sensor_group_data *sgrp_data,
ssize_t (*show)(struct device *dev,
struct device_attribute *attr,
- char *buf))
+ char *buf),
+ ssize_t (*store)(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count))
{
sdata->id = sid;
sdata->type = type;
sdata->opal_index = od;
sdata->hwmon_index = hd;
- create_hwmon_attr(sdata, attr_name, show);
+ create_hwmon_attr(sdata, attr_name, show, store);
pgroup->attrs[sensor_groups[type].attr_count++] = &sdata->dev_attr.attr;
+ sdata->sgrp_data = sgrp_data;
}
static char *get_max_attr(enum sensors type)
@@ -403,24 +571,23 @@ static int create_device_attrs(struct platform_device *pdev)
const struct attribute_group **pgroups = pdata->attr_groups;
struct device_node *opal, *np;
struct sensor_data *sdata;
- u32 sensor_id;
- enum sensors type;
u32 count = 0;
- int err = 0;
+ u32 group_attr_id[MAX_SENSOR_TYPE] = {0};
- opal = of_find_node_by_path("/ibm,opal/sensors");
sdata = devm_kcalloc(&pdev->dev,
pdata->sensors_count, sizeof(*sdata),
GFP_KERNEL);
- if (!sdata) {
- err = -ENOMEM;
- goto exit_put_node;
- }
+ if (!sdata)
+ return -ENOMEM;
+ opal = of_find_node_by_path("/ibm,opal/sensors");
for_each_child_of_node(opal, np) {
+ struct sensor_group_data *sgrp_data;
const char *attr_name;
- u32 opal_index;
+ u32 opal_index, hw_id;
+ u32 sensor_id;
const char *label;
+ enum sensors type;
if (np->name == NULL)
continue;
@@ -456,14 +623,12 @@ static int create_device_attrs(struct platform_device *pdev)
opal_index = INVALID_INDEX;
}
- sdata[count].opal_index = opal_index;
- sdata[count].hwmon_index =
- get_sensor_hwmon_index(&sdata[count], sdata, count);
-
- create_hwmon_attr(&sdata[count], attr_name, show_sensor);
-
- pgroups[type]->attrs[sensor_groups[type].attr_count++] =
- &sdata[count++].dev_attr.attr;
+ hw_id = get_sensor_hwmon_index(&sdata[count], sdata, count);
+ sgrp_data = get_sensor_group(pdata, np, type);
+ populate_sensor(&sdata[count], opal_index, hw_id, sensor_id,
+ attr_name, type, pgroups[type], sgrp_data,
+ show_sensor, NULL);
+ count++;
if (!of_property_read_string(np, "label", &label)) {
/*
@@ -474,35 +639,43 @@ static int create_device_attrs(struct platform_device *pdev)
*/
make_sensor_label(np, &sdata[count], label);
- populate_sensor(&sdata[count], opal_index,
- sdata[count - 1].hwmon_index,
+ populate_sensor(&sdata[count], opal_index, hw_id,
sensor_id, "label", type, pgroups[type],
- show_label);
+ NULL, show_label, NULL);
count++;
}
if (!of_property_read_u32(np, "sensor-data-max", &sensor_id)) {
attr_name = get_max_attr(type);
- populate_sensor(&sdata[count], opal_index,
- sdata[count - 1].hwmon_index,
+ populate_sensor(&sdata[count], opal_index, hw_id,
sensor_id, attr_name, type,
- pgroups[type], show_sensor);
+ pgroups[type], sgrp_data, show_sensor,
+ NULL);
count++;
}
if (!of_property_read_u32(np, "sensor-data-min", &sensor_id)) {
attr_name = get_min_attr(type);
- populate_sensor(&sdata[count], opal_index,
- sdata[count - 1].hwmon_index,
+ populate_sensor(&sdata[count], opal_index, hw_id,
sensor_id, attr_name, type,
- pgroups[type], show_sensor);
+ pgroups[type], sgrp_data, show_sensor,
+ NULL);
+ count++;
+ }
+
+ if (sgrp_data && !sgrp_data->enable) {
+ sgrp_data->enable = true;
+ hw_id = ++group_attr_id[type];
+ populate_sensor(&sdata[count], opal_index, hw_id,
+ sgrp_data->gid, "enable", type,
+ pgroups[type], sgrp_data, show_enable,
+ store_enable);
count++;
}
}
-exit_put_node:
of_node_put(opal);
- return err;
+ return 0;
}
static int ibmpowernv_probe(struct platform_device *pdev)
@@ -517,6 +690,7 @@ static int ibmpowernv_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, pdata);
pdata->sensors_count = 0;
+ pdata->nr_sensor_groups = 0;
err = populate_attr_groups(pdev);
if (err)
return err;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v8 0/2] hwmon/powernv: Add attributes to enable/disable sensors
From: Shilpasri G Bhat @ 2018-07-24 9:13 UTC (permalink / raw)
To: mpe, linux
Cc: linuxppc-dev, linux-hwmon, linux-kernel, ego, stewart,
Shilpasri G Bhat
This patch series adds new attribute to enable or disable a sensor at
runtime.
Changes from v7:
- Use of_for_each_phandle() and of_count_phandle_with_args() to parse
through the phandle array
v7 : https://lkml.org/lkml/2018/7/20/72
v6 : https://lkml.org/lkml/2018/7/18/806
v5 : https://lkml.org/lkml/2018/7/15/15
v4 : https://lkml.org/lkml/2018/7/6/379
v3 : https://lkml.org/lkml/2018/7/5/476
v2 : https://lkml.org/lkml/2018/7/4/263
v1 : https://lkml.org/lkml/2018/3/22/214
Shilpasri G Bhat (2):
powernv:opal-sensor-groups: Add support to enable sensor groups
hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
Documentation/hwmon/ibmpowernv | 43 +++-
arch/powerpc/include/asm/opal-api.h | 1 +
arch/powerpc/include/asm/opal.h | 2 +
.../powerpc/platforms/powernv/opal-sensor-groups.c | 28 +++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
drivers/hwmon/ibmpowernv.c | 238 ++++++++++++++++++---
6 files changed, 279 insertions(+), 34 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v2] perf/core: fix a possible deadlock scenario
From: Peter Zijlstra @ 2018-07-24 9:12 UTC (permalink / raw)
To: Cong Wang
Cc: LKML, Ingo Molnar, Linus Torvalds, Arnaldo Carvalho de Melo,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, stable
In-Reply-To: <CAM_iQpWVhLZKo9j6COGkvryGrxJq6sEXzh2S-ikza2H3=pAyqw@mail.gmail.com>
On Mon, Jul 23, 2018 at 04:16:23PM -0700, Cong Wang wrote:
> > > +#define PERF_EF_NO_WAIT 0x08 /* do not wait when stopping, for
> > > + * example, waiting for a timer
> > > + */
> >
> > That's a broken comment style.
>
> It is picked by checkpatch.pl, not me, I chose a different one and got
> a complain. :)
Ignore checkpatch when it's wrong ;-)
^ permalink raw reply
* Re: linux-next-20180723: battery status funny after bootup
From: Pavel Machek @ 2018-07-24 9:12 UTC (permalink / raw)
To: Rafael J. Wysocki, lucas.magasweran
Cc: Rafael J. Wysocki, kernel list, Linux-pm mailing list, Len Brown,
ACPI Devel Maling List
In-Reply-To: <CAJZ5v0g=Ey6ZiyjA3NWS_C5zXBUydJNaKOZDbRNFYUGEc8YuaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
On Tue 2018-07-24 10:27:08, Rafael J. Wysocki wrote:
> On Mon, Jul 23, 2018 at 11:49 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > pavel@amd:~$ cat /proc/acpi/battery/BAT0/state
> > present: yes
> > capacity state: ok
> > charging state: charged
> > present rate: 0 mW
> > remaining capacity: 0 mWh
> > present voltage: 0 mV
> > pavel@amd:~$ uname -a
> > Linux amd 4.18.0-rc6-next-20180723+ #141 SMP Mon Jul 23 22:11:47 CEST
> > 2018 i686 GNU/Linux
> >
> > It will correct itself if I unplug/replug the AC adapter, I
> > believe. Gnome2 battery monitor also looks confused.
>
> There are two battery changes in linux-next now that are not present
> in the mainline
>
> 2a2aad34362b ACPI: battery: remove redundant old_present check on insertion
> 706ac4aa536f ACPI: battery: use cache_time as cache "enabled"
>
> Does reverting any of them help? Or is the problem present in the
> mainline too?
Thanks for pointers! Not it mainline, I'd notice that.
I reverted 706ac4aa536f , and on the next boot:
pavel@amd:~$ cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 37150 mWh
present voltage: 16400 mV
..plus icon was ok from the start.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 for 3.0 00/18] docker fixes (and one tcg test tweak)
From: Fam Zheng @ 2018-07-24 9:09 UTC (permalink / raw)
To: Alex Bennée
Cc: cota, Daniel P. Berrange, Philippe Mathieu-Daudé,
Richard Henderson, balrogg, aurelien, Alexander Graf,
QEMU Developers
In-Reply-To: <87efftt3jg.fsf@linaro.org>
On Tue, Jul 24, 2018 at 4:56 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Fam Zheng <famz@redhat.com> writes:
>
> > On Mon, Jul 23, 2018 at 6:03 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >>
> >> Alex Bennée <alex.bennee@linaro.org> writes:
> >>
> >> > Hi,
> >> >
> >> > I've missed the boat for today's rc1 but I'd like to get this merged
> >> > before rc2. The new docker.py change is technically new functionality
> >> > but I'm counting it as a usability bug fix as it replaces a random
> >> > back trace failure with a preemptive failure and message mentioning
> >> > binfmt_misc configuration. This would have saved Richard a lot of head
> >> > scratching as he tried to setup a powerpc-user setup to test his
> >> > setcontext fix (he had a custom binfmt_misc pointing to his src tree).
> >> >
> >> > Finally we also drop the runcom test. It was cute that it got
> >> > resurrected but it is ultimately a pointless test for something I'm
> >> > sure no one actually uses.
> >> >
> >> > There will be a follow-up RFC series after this that cleans-up some of
> >> > the rough edges when your host is not an x86_64 box but that series
> >> > won't be targeting the 3.0 release.
> >> >
> >> > : The following patches need review
> >> > : patch docker/disable debian powerpc user cross.patch
> >> > : patch docker/drop QEMU_TARGET check fallback in EXECUTABLE.patch
> >> > : patch docker/Update debootstrap script after Debian migrat.patch
> >> > : patch docker/ignore distro versioning of debootstrap.patch
> >> > : patch docker/perform basic binfmt_misc validation in docke.patch
> >> > : patch tests/tcg remove runcom test.patch
> >>
> >> Ping?
> >
> > I had questions about patch 13 and 17. Otherwise looks good.
> > Maybe you can drop them for now (including patch 9) and send the PULL for
> > the rest.
>
> I can drop/replace 13 - but 17 was there for a better reporting of a
> failure case Peter found. We can certainly expand it and be smarter in
> future iterations.
Sounds good to me.
Fam
>
>
> > I don't know if we can catch up -rc2 but I guess the testing fixes are
> > fairly safe to sneak in. :)
> >
> > (My development machine is affected by
> > an
> > office power outage, and I was
> > also
> > busy with upgrading patchew.org. Sorry for the
> >
> > late reply
> > !)
> >
> > Fam
>
>
> --
> Alex Bennée
^ permalink raw reply
* Re: [PATCH 0/4] staging: wilc1000: make use of descriptor-based interface for GPIO
From: Claudiu Beznea @ 2018-07-24 8:04 UTC (permalink / raw)
To: Ajay Singh, linux-wireless
Cc: devel, gregkh, ganesh.krishna, venkateswara.kaja, aditya.shankar,
adham.abozaeid, robh+dt, mark.rutland, linus.walleij
In-Reply-To: <1532088098-8483-1-git-send-email-ajay.kathat@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
On 20.07.2018 15:01, Ajay Singh wrote:
> This patch series contains changes mainly related to make use of
> descriptor-based interface instead of integer-based interface for GPIO.
> Modified the compatible string to use 'microchip' instead of 'atmel' prefix.
> Also added the DT binding reference file.
>
> This patch is created on top of [1] patch series.
>
> [1]. https://www.spinics.net/lists/linux-wireless/msg175360.html
>
> Ajay Singh (4):
> staging: wilc1000: remove gpio parameter from wilc_netdev_init()
> staging: wilc1000: rename variable from 'gpio' to 'gpio_irq'
> staging: wilc1000: change compatible string from atmel to microchip
> staging: wilc1000: use descriptor-based interface for GPIO
>
> drivers/staging/wilc1000/TODO | 4 ---
> drivers/staging/wilc1000/linux_wlan.c | 42 +++++++++-------------
> .../staging/wilc1000/microchip,wilc1000,sdio.txt | 32 +++++++++++++++++
> .../staging/wilc1000/microchip,wilc1000,spi.txt | 26 ++++++++++++++
> drivers/staging/wilc1000/wilc_sdio.c | 38 ++++++++++++++------
> drivers/staging/wilc1000/wilc_spi.c | 40 +++++++++++++--------
> drivers/staging/wilc1000/wilc_wfi_netdevice.h | 5 +--
> 7 files changed, 130 insertions(+), 57 deletions(-)
> create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
> create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,spi.txt
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.