* rcu_preempt caused oom
@ 2018-11-29 8:49 He, Bo
2018-11-29 13:06 ` Paul E. McKenney
2019-02-13 8:30 ` [tip:core/rcu] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt tip-bot for Zhang, Jun
0 siblings, 2 replies; 43+ messages in thread
From: He, Bo @ 2018-11-29 8:49 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, paulmck@linux.vnet.ibm.com,
josh@joshtriplett.org, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com
Cc: Zhang, Jun, Xiao, Jin, Zhang, Yanmin
Hi,
we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel.
we have done some debugs:
1. OOM is due to the filp consume too many memory: 300M vs 2G board.
2. with the 120s hung task detect, most of the tasks will block at __wait_rcu_gp: wait_for_completion(&rs_array[i].completion);
[47571.863839] Kernel panic - not syncing: hung_task: blocked tasks
[47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1
[47571.887603] Call Trace:
[47571.890547] dump_stack+0x70/0xa5
[47571.894456] panic+0xe3/0x241
[47571.897977] ? wait_for_completion_timeout+0x72/0x1b0
[47571.903830] __wait_rcu_gp+0x17b/0x180
[47571.908226] synchronize_rcu.part.76+0x38/0x50
[47571.913393] ? __call_rcu.constprop.79+0x3a0/0x3a0
[47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10
[47571.925094] synchronize_rcu+0x43/0x50
[47571.929487] evdev_detach_client+0x59/0x60
[47571.934264] evdev_release+0x4e/0xd0
[47571.938464] __fput+0xfa/0x1f0
[47571.942072] ____fput+0xe/0x10
[47571.945683] task_work_run+0x90/0xc0
[47571.949884] exit_to_usermode_loop+0x9f/0xb0
[47571.954855] do_syscall_64+0xfa/0x110
[47571.959151] entry_SYSCALL_64_after_hwframe+0x49/0xbe
3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback.
[47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB
[47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=00000000783a728b func=file_free_rcu 4354/82824
[47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf
[47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted
[47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB
[47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=0000000042c76521 func=file_free_rcu 4354/82825
[47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf
[47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted
[47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB
[47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=000000005e40fde2 func=avc_node_free 4354/82826
[47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=00000000f80fe353 func=avc_node_free 4354/82827
[47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=000000007486f400 func=avc_node_free 4354/82828
[47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=00000000b87872a8 func=avc_node_free 4354/82829
[47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=000000008c656343 func=file_free_rcu 4354/82830
[47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf
[47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted
[47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB
[47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=000000007e6c898c func=file_free_rcu 4354/82831
[47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf
[47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted
[47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB
[47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=0000000032f4f174 func=file_free_rcu 4354/82832
[47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf
Do you have any suggestions to debug the issue?
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: rcu_preempt caused oom 2018-11-29 8:49 rcu_preempt caused oom He, Bo @ 2018-11-29 13:06 ` Paul E. McKenney 2018-11-29 14:27 ` Paul E. McKenney 2019-02-13 8:30 ` [tip:core/rcu] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt tip-bot for Zhang, Jun 1 sibling, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-11-29 13:06 UTC (permalink / raw) To: He, Bo Cc: linux-kernel@vger.kernel.org, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Thu, Nov 29, 2018 at 08:49:35AM +0000, He, Bo wrote: > Hi, > we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel. > we have done some debugs: > 1. OOM is due to the filp consume too many memory: 300M vs 2G board. > 2. with the 120s hung task detect, most of the tasks will block at __wait_rcu_gp: wait_for_completion(&rs_array[i].completion); > [47571.863839] Kernel panic - not syncing: hung_task: blocked tasks > [47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1 > [47571.887603] Call Trace: > [47571.890547] dump_stack+0x70/0xa5 > [47571.894456] panic+0xe3/0x241 > [47571.897977] ? wait_for_completion_timeout+0x72/0x1b0 > [47571.903830] __wait_rcu_gp+0x17b/0x180 > [47571.908226] synchronize_rcu.part.76+0x38/0x50 > [47571.913393] ? __call_rcu.constprop.79+0x3a0/0x3a0 > [47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 > [47571.925094] synchronize_rcu+0x43/0x50 > [47571.929487] evdev_detach_client+0x59/0x60 > [47571.934264] evdev_release+0x4e/0xd0 > [47571.938464] __fput+0xfa/0x1f0 > [47571.942072] ____fput+0xe/0x10 > [47571.945683] task_work_run+0x90/0xc0 > [47571.949884] exit_to_usermode_loop+0x9f/0xb0 > [47571.954855] do_syscall_64+0xfa/0x110 > [47571.959151] entry_SYSCALL_64_after_hwframe+0x49/0xbe > 3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback. > [47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > [47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=00000000783a728b func=file_free_rcu 4354/82824 > [47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > [47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > [47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > [47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=0000000042c76521 func=file_free_rcu 4354/82825 > [47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > [47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > [47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > [47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=000000005e40fde2 func=avc_node_free 4354/82826 > [47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=00000000f80fe353 func=avc_node_free 4354/82827 > [47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=000000007486f400 func=avc_node_free 4354/82828 > [47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=00000000b87872a8 func=avc_node_free 4354/82829 > [47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=000000008c656343 func=file_free_rcu 4354/82830 > [47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > [47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > [47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > [47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=000000007e6c898c func=file_free_rcu 4354/82831 > [47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > [47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > [47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > [47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=0000000032f4f174 func=file_free_rcu 4354/82832 > [47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > Do you have any suggestions to debug the issue? If you do not already have CONFIG_RCU_BOOST=y set, could you please rebuild with that? Could you also please send your .config file? Thanx, Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-11-29 13:06 ` Paul E. McKenney @ 2018-11-29 14:27 ` Paul E. McKenney 2018-11-30 8:03 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-11-29 14:27 UTC (permalink / raw) To: He, Bo Cc: linux-kernel@vger.kernel.org, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Thu, Nov 29, 2018 at 05:06:47AM -0800, Paul E. McKenney wrote: > On Thu, Nov 29, 2018 at 08:49:35AM +0000, He, Bo wrote: > > Hi, > > we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel. > > we have done some debugs: > > 1. OOM is due to the filp consume too many memory: 300M vs 2G board. > > 2. with the 120s hung task detect, most of the tasks will block at __wait_rcu_gp: wait_for_completion(&rs_array[i].completion); Did you did see any RCU CPU stall warnings? Or have those been disabled? If they have been disabled, could you please rerun with them enabled? > > [47571.863839] Kernel panic - not syncing: hung_task: blocked tasks > > [47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1 > > [47571.887603] Call Trace: > > [47571.890547] dump_stack+0x70/0xa5 > > [47571.894456] panic+0xe3/0x241 > > [47571.897977] ? wait_for_completion_timeout+0x72/0x1b0 > > [47571.903830] __wait_rcu_gp+0x17b/0x180 > > [47571.908226] synchronize_rcu.part.76+0x38/0x50 > > [47571.913393] ? __call_rcu.constprop.79+0x3a0/0x3a0 > > [47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 > > [47571.925094] synchronize_rcu+0x43/0x50 > > [47571.929487] evdev_detach_client+0x59/0x60 > > [47571.934264] evdev_release+0x4e/0xd0 > > [47571.938464] __fput+0xfa/0x1f0 > > [47571.942072] ____fput+0xe/0x10 > > [47571.945683] task_work_run+0x90/0xc0 > > [47571.949884] exit_to_usermode_loop+0x9f/0xb0 > > [47571.954855] do_syscall_64+0xfa/0x110 > > [47571.959151] entry_SYSCALL_64_after_hwframe+0x49/0xbe This is indeed a task waiting on synchronize_rcu(). > > 3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback. > > [47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=00000000783a728b func=file_free_rcu 4354/82824 > > [47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=0000000042c76521 func=file_free_rcu 4354/82825 > > [47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=000000005e40fde2 func=avc_node_free 4354/82826 > > [47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=00000000f80fe353 func=avc_node_free 4354/82827 > > [47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=000000007486f400 func=avc_node_free 4354/82828 > > [47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=00000000b87872a8 func=avc_node_free 4354/82829 > > [47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=000000008c656343 func=file_free_rcu 4354/82830 > > [47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=000000007e6c898c func=file_free_rcu 4354/82831 > > [47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=0000000032f4f174 func=file_free_rcu 4354/82832 > > [47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf Callbacks are being queued and future grace periods to handle them are being requested, but as you say, no progress on the current grace period. Is it possible to start the trace earlier? > > Do you have any suggestions to debug the issue? > > If you do not already have CONFIG_RCU_BOOST=y set, could you please > rebuild with that? > > Could you also please send your .config file? So, to summarize: 1. If you don't have RCU CPU stall warnings enabled, please enable them. For example, please remove rcupdate.rcu_cpu_stall_suppress from the kernel boot parameters if it is there. Getting an RCU CPU stall warning would be extremely helpful. It contains many useful diagnostics. 2. If possible, please start the trace before the last grace period starts. 3. If CONFIG_RCU_BOOST=y is not set, please try setting it. 4. Please send me your .config file. Thanx, Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-11-29 14:27 ` Paul E. McKenney @ 2018-11-30 8:03 ` He, Bo 2018-11-30 14:43 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-11-30 8:03 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: linux-kernel@vger.kernel.org, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin [-- Attachment #1: Type: text/plain, Size: 6880 bytes --] Thanks for your great suggestions. After enable the CONFIG_RCU_BOOST=y, we don't reproduce the issue until now, we will keep it running and update you with the test results. The enclosed is the kernel config, here is the config I grep with the RCU, we don't enable the CONFIG_RCU_BOOST in our build. # RCU Subsystem CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # RCU Debugging CONFIG_RCU_PERF_TEST=m CONFIG_RCU_TORTURE_TEST=m CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_TRACE=y CONFIG_RCU_EQS_DEBUG=y -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Thursday, November 29, 2018 10:27 PM To: He, Bo <bo.he@intel.com> Cc: linux-kernel@vger.kernel.org; josh@joshtriplett.org; rostedt@goodmis.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> Subject: Re: rcu_preempt caused oom On Thu, Nov 29, 2018 at 05:06:47AM -0800, Paul E. McKenney wrote: > On Thu, Nov 29, 2018 at 08:49:35AM +0000, He, Bo wrote: > > Hi, > > we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel. > > we have done some debugs: > > 1. OOM is due to the filp consume too many memory: 300M vs 2G board. > > 2. with the 120s hung task detect, most of the tasks will block at > > __wait_rcu_gp: wait_for_completion(&rs_array[i].completion); Did you did see any RCU CPU stall warnings? Or have those been disabled? If they have been disabled, could you please rerun with them enabled? > > [47571.863839] Kernel panic - not syncing: hung_task: blocked tasks > > [47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1 > > [47571.887603] Call Trace: > > [47571.890547] dump_stack+0x70/0xa5 [47571.894456] > > panic+0xe3/0x241 [47571.897977] ? > > wait_for_completion_timeout+0x72/0x1b0 > > [47571.903830] __wait_rcu_gp+0x17b/0x180 [47571.908226] > > synchronize_rcu.part.76+0x38/0x50 [47571.913393] ? > > __call_rcu.constprop.79+0x3a0/0x3a0 > > [47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 > > [47571.925094] synchronize_rcu+0x43/0x50 [47571.929487] > > evdev_detach_client+0x59/0x60 [47571.934264] > > evdev_release+0x4e/0xd0 [47571.938464] __fput+0xfa/0x1f0 > > [47571.942072] ____fput+0xe/0x10 [47571.945683] > > task_work_run+0x90/0xc0 [47571.949884] > > exit_to_usermode_loop+0x9f/0xb0 [47571.954855] > > do_syscall_64+0xfa/0x110 [47571.959151] > > entry_SYSCALL_64_after_hwframe+0x49/0xbe This is indeed a task waiting on synchronize_rcu(). > > 3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback. > > [47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=00000000783a728b func=file_free_rcu 4354/82824 > > [47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=0000000042c76521 func=file_free_rcu 4354/82825 > > [47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=000000005e40fde2 func=avc_node_free 4354/82826 > > [47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=00000000f80fe353 func=avc_node_free 4354/82827 > > [47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=000000007486f400 func=avc_node_free 4354/82828 > > [47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=00000000b87872a8 func=avc_node_free 4354/82829 > > [47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=000000008c656343 func=file_free_rcu 4354/82830 > > [47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=000000007e6c898c func=file_free_rcu 4354/82831 > > [47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > [47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > [47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > [47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=0000000032f4f174 func=file_free_rcu 4354/82832 > > [47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf Callbacks are being queued and future grace periods to handle them are being requested, but as you say, no progress on the current grace period. Is it possible to start the trace earlier? > > Do you have any suggestions to debug the issue? > > If you do not already have CONFIG_RCU_BOOST=y set, could you please > rebuild with that? > > Could you also please send your .config file? So, to summarize: 1. If you don't have RCU CPU stall warnings enabled, please enable them. For example, please remove rcupdate.rcu_cpu_stall_suppress from the kernel boot parameters if it is there. Getting an RCU CPU stall warning would be extremely helpful. It contains many useful diagnostics. 2. If possible, please start the trace before the last grace period starts. 3. If CONFIG_RCU_BOOST=y is not set, please try setting it. 4. Please send me your .config file. Thanx, Paul [-- Attachment #2: kernel_config --] [-- Type: application/octet-stream, Size: 168963 bytes --] # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.19.0 Kernel Configuration # # # Compiler: x86_64-poky-linux-gcc (GCC) 7.3.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70300 CONFIG_CLANG_VERSION=0 CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="-quilt-2e5dc0ac" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME="localhost" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_ANDROID_AUTO_SUSPEND_BEHAVIOR=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_CPU_ISOLATION is not set # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y # CONFIG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_RDMA is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_BPF=y CONFIG_CGROUP_DEBUG=y CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SCHED_TUNE is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_FHANDLE is not set CONFIG_POSIX_TIMERS=y CONFIG_PRINTK=y CONFIG_PRINTK_NMI=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_BPF_SYSCALL=y # CONFIG_USERFAULTFD is not set CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y CONFIG_RSEQ=y # CONFIG_DEBUG_RSEQ is not set CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y # CONFIG_PC104 is not set # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_SLAB_MERGE_DEFAULT=y CONFIG_SLAB_FREELIST_RANDOM=y CONFIG_SYSTEM_DATA_VERIFICATION=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_FILTER_PGPROT=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_CC_HAS_SANE_STACKPROTECTOR=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_SMP=y CONFIG_X86_FEATURE_NAMES=y # CONFIG_X86_X2APIC is not set CONFIG_X86_MPPARSE=y # CONFIG_GOLDFISH is not set CONFIG_RETPOLINE=y # CONFIG_INTEL_RDT is not set # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_X86_INTEL_LPSS=y # CONFIG_X86_AMD_PLATFORM_DEVICE is not set CONFIG_IOSF_MBI=y # CONFIG_IOSF_MBI_DEBUG is not set CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_HYPERVISOR_GUEST=y # CONFIG_PARAVIRT is not set # CONFIG_JAILHOUSE_GUEST is not set CONFIG_NO_BOOTMEM=y # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_MATOM is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_INTERNODE_CACHE_SHIFT=6 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y # CONFIG_PROCESSOR_SELECT is not set CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set # CONFIG_MAXSMP is not set CONFIG_NR_CPUS_RANGE_BEGIN=2 CONFIG_NR_CPUS_RANGE_END=512 CONFIG_NR_CPUS_DEFAULT=64 CONFIG_NR_CPUS=32 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_SCHED_MC_PRIO=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y # CONFIG_X86_MCELOG_LEGACY is not set CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_X86_MCE_THRESHOLD=y # CONFIG_X86_MCE_INJECT is not set CONFIG_X86_THERMAL_VECTOR=y # # Performance monitoring # CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_PERF_EVENTS_INTEL_RAPL=y CONFIG_PERF_EVENTS_INTEL_CSTATE=y # CONFIG_PERF_EVENTS_AMD_POWER is not set CONFIG_X86_VSYSCALL_EMULATION=y CONFIG_I8K=m CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_X86_5LEVEL is not set CONFIG_X86_DIRECT_GBPAGES=y # CONFIG_X86_CPA_STATISTICS is not set CONFIG_ARCH_HAS_MEM_ENCRYPT=y # CONFIG_AMD_MEM_ENCRYPT is not set # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 # CONFIG_X86_PMEM_LEGACY is not set CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_X86_SMAP=y CONFIG_X86_INTEL_UMIP=y # CONFIG_X86_INTEL_MPX is not set CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y # CONFIG_EFI is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y # CONFIG_KEXEC is not set # CONFIG_KEXEC_FILE is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y # CONFIG_RANDOMIZE_BASE is not set CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set # CONFIG_DEBUG_HOTPLUG_CPU0 is not set # CONFIG_COMPAT_VDSO is not set # CONFIG_LEGACY_VSYSCALL_EMULATE is not set CONFIG_LEGACY_VSYSCALL_NONE=y # CONFIG_CMDLINE_BOOL is not set # CONFIG_MODIFY_LDT_SYSCALL is not set CONFIG_HAVE_LIVEPATCH=y # CONFIG_LIVEPATCH is not set CONFIG_ARCH_HAS_ADD_PAGES=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_ARCH_ENABLE_THP_MIGRATION=y # # Power management and ACPI options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_SUSPEND_SKIP_SYNC is not set # CONFIG_HIBERNATION is not set CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_AUTOSLEEP=y CONFIG_PM_WAKELOCKS=y CONFIG_PM_WAKELOCKS_LIMIT=100 CONFIG_PM_WAKELOCKS_GC=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_ADVANCED_DEBUG=y # CONFIG_PM_TEST_SUSPEND is not set CONFIG_PM_SLEEP_DEBUG=y # CONFIG_DPM_WATCHDOG is not set CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_PM_CLK=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y # CONFIG_ENERGY_MODEL is not set CONFIG_ARCH_SUPPORTS_ACPI=y CONFIG_ACPI=y CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y # CONFIG_ACPI_DEBUGGER is not set CONFIG_ACPI_SPCR_TABLE=y CONFIG_ACPI_LPIT=y CONFIG_ACPI_SLEEP=y # CONFIG_ACPI_PROCFS_POWER is not set CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_TAD is not set CONFIG_ACPI_DOCK=y CONFIG_ACPI_CPU_FREQ_PSS=y CONFIG_ACPI_PROCESSOR_CSTATE=y CONFIG_ACPI_PROCESSOR_IDLE=y CONFIG_ACPI_CPPC_LIB=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y # CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set CONFIG_ACPI_THERMAL=y CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y CONFIG_ACPI_TABLE_UPGRADE=y # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_HOTPLUG_IOAPIC=y # CONFIG_ACPI_SBS is not set # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set # CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set # CONFIG_ACPI_NFIT is not set CONFIG_HAVE_ACPI_APEI=y CONFIG_HAVE_ACPI_APEI_NMI=y CONFIG_ACPI_APEI=y # CONFIG_ACPI_APEI_GHES is not set # CONFIG_ACPI_APEI_PCIEAER is not set # CONFIG_ACPI_APEI_EINJ is not set # CONFIG_ACPI_APEI_ERST_DEBUG is not set # CONFIG_DPTF_POWER is not set CONFIG_PMIC_OPREGION=y CONFIG_CRC_PMIC_OPREGION=y CONFIG_BXT_WC_PMIC_OPREGION=y # CONFIG_ACPI_CONFIGFS is not set CONFIG_X86_PM_TIMER=y # CONFIG_SFI is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_ATTR_SET=y CONFIG_CPU_FREQ_GOV_COMMON=y # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_TIMES is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set # # CPU frequency scaling drivers # CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_ACPI_CPUFREQ_CPB=y # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_AMD_FREQ_SENSITIVITY is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_P4_CLOCKMOD is not set # # shared options # # # CPU Idle # CONFIG_CPU_IDLE=y # CONFIG_CPU_IDLE_GOV_LADDER is not set CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_INTEL_IDLE=y # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_MMCONF_FAM10H=y # CONFIG_PCI_CNB20LE_QUIRK is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y # CONFIG_PCIEAER_INJECT is not set # CONFIG_PCIE_ECRC is not set CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set # CONFIG_PCIEASPM_DEFAULT is not set CONFIG_PCIEASPM_POWERSAVE=y # CONFIG_PCIEASPM_POWER_SUPERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y # CONFIG_PCIE_DPC is not set # CONFIG_PCIE_PTM is not set CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PCI_QUIRKS=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set CONFIG_PCI_LOCKLESS_CONFIG=y # CONFIG_PCI_IOV is not set # CONFIG_PCI_PRI is not set # CONFIG_PCI_PASID is not set CONFIG_PCI_LABEL=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y # CONFIG_HOTPLUG_PCI_ACPI_IBM is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # PCI controller drivers # # # Cadence PCIe controllers support # # CONFIG_VMD is not set # # DesignWare PCI Core Support # # CONFIG_PCIE_DW_PLAT_HOST is not set # # PCI Endpoint # # CONFIG_PCI_ENDPOINT is not set # # PCI switch controller drivers # # CONFIG_PCI_SW_SWITCHTEC is not set # CONFIG_ISA_BUS is not set CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y # CONFIG_PCCARD is not set # CONFIG_RAPIDIO is not set CONFIG_X86_SYSFB=y # # Binary Emulations # CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set # CONFIG_X86_X32 is not set CONFIG_COMPAT_32=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_X86_DEV_DMA_OPS=y CONFIG_HAVE_GENERIC_GUP=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_DELL_RBU=y CONFIG_DCDBAS=y CONFIG_DMIID=y CONFIG_DMI_SYSFS=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y # CONFIG_ISCSI_IBFT_FIND is not set # CONFIG_FW_CFG_SYSFS is not set # CONFIG_GOOGLE_FIRMWARE is not set CONFIG_UEFI_CPER=y CONFIG_UEFI_CPER_X86=y # # Tegra firmware driver # CONFIG_HAVE_KVM=y CONFIG_VIRTUALIZATION=y # CONFIG_KVM is not set # CONFIG_VHOST_NET is not set # CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set # # General architecture-dependent options # CONFIG_HOTPLUG_SMT=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y CONFIG_JUMP_LABEL=y # CONFIG_STATIC_KEYS_SELFTEST is not set CONFIG_OPTPROBES=y CONFIG_KPROBES_ON_FTRACE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_KPROBES_ON_FTRACE=y CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y CONFIG_HAVE_NMI=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_ARCH_HAS_FORTIFY_SOURCE=y CONFIG_ARCH_HAS_SET_MEMORY=y CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_RSEQ=y CONFIG_HAVE_CLK=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_SECCOMP_FILTER=y CONFIG_HAVE_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y CONFIG_HAVE_ARCH_HUGE_VMAP=y CONFIG_HAVE_ARCH_SOFT_DIRTY=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_HAVE_ARCH_MMAP_RND_BITS=y CONFIG_HAVE_EXIT_THREAD=y CONFIG_ARCH_MMAP_RND_BITS=28 CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y CONFIG_HAVE_COPY_THREAD_TLS=y CONFIG_HAVE_STACK_VALIDATION=y CONFIG_HAVE_RELIABLE_STACKTRACE=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y CONFIG_COMPAT_32BIT_TIME=y CONFIG_HAVE_ARCH_VMAP_STACK=y CONFIG_VMAP_STACK=y CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y CONFIG_STRICT_KERNEL_RWX=y CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y CONFIG_STRICT_MODULE_RWX=y CONFIG_ARCH_HAS_REFCOUNT=y # CONFIG_REFCOUNT_FULL is not set CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y CONFIG_PLUGIN_HOSTCC="" CONFIG_HAVE_GCC_PLUGINS=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" # CONFIG_MODULE_COMPRESS is not set # CONFIG_TRIM_UNUSED_KSYMS is not set CONFIG_MODULES_TREE_LOOKUP=y CONFIG_BLOCK=y CONFIG_BLK_SCSI_REQUEST=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # CONFIG_BLK_DEV_ZONED is not set # CONFIG_BLK_CMDLINE_PARSER is not set # CONFIG_BLK_WBT is not set CONFIG_BLK_DEBUG_FS=y # CONFIG_BLK_SED_OPAL is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_AIX_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # CONFIG_CMDLINE_PARTITION is not set CONFIG_BLOCK_COMPAT=y CONFIG_BLK_MQ_PCI=y CONFIG_BLK_MQ_VIRTIO=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_MQ_IOSCHED_DEADLINE=y CONFIG_MQ_IOSCHED_KYBER=y # CONFIG_IOSCHED_BFQ is not set CONFIG_ASN1=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y CONFIG_QUEUED_SPINLOCKS=y CONFIG_ARCH_USE_QUEUED_RWLOCKS=y CONFIG_QUEUED_RWLOCKS=y CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y CONFIG_FREEZER=y # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ELFCORE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_BINFMT_SCRIPT=y CONFIG_BINFMT_MISC=y CONFIG_COREDUMP=y # # Memory Management options # CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMBLOCK_NODE_MAP=y CONFIG_ARCH_DISCARD_MEMBLOCK=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=8192 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y # CONFIG_MEMORY_FAILURE is not set CONFIG_TRANSPARENT_HUGEPAGE=y # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y CONFIG_ARCH_WANTS_THP_SWAP=y CONFIG_THP_SWAP=y CONFIG_TRANSPARENT_HUGE_PAGECACHE=y # CONFIG_CLEANCACHE is not set # CONFIG_FRONTSWAP is not set # CONFIG_CMA is not set # CONFIG_ZPOOL is not set # CONFIG_ZBUD is not set CONFIG_ZSMALLOC=y # CONFIG_PGTABLE_MAPPING is not set CONFIG_DEBUG_PANIC_ON_BAD_PAGE=y # CONFIG_ZSMALLOC_STAT is not set CONFIG_GENERIC_EARLY_IOREMAP=y # CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set # CONFIG_IDLE_PAGE_TRACKING is not set CONFIG_ARCH_HAS_ZONE_DEVICE=y CONFIG_FRAME_VECTOR=y CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y CONFIG_ARCH_HAS_PKEYS=y # CONFIG_PERCPU_STATS is not set # CONFIG_GUP_BENCHMARK is not set CONFIG_ARCH_HAS_PTE_SPECIAL=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y CONFIG_NET_INGRESS=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_DIAG is not set CONFIG_UNIX=y # CONFIG_UNIX_DIAG is not set # CONFIG_TLS is not set CONFIG_XFRM=y CONFIG_XFRM_ALGO=y CONFIG_XFRM_USER=y # CONFIG_XFRM_INTERFACE is not set # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=y CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set # CONFIG_XDP_SOCKETS is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE_DEMUX is not set CONFIG_NET_IP_TUNNEL=y # CONFIG_IP_MROUTE is not set CONFIG_SYN_COOKIES=y CONFIG_NET_IPVTI=y CONFIG_NET_UDP_TUNNEL=y # CONFIG_NET_FOU is not set # CONFIG_NET_FOU_IP_TUNNELS is not set # CONFIG_INET_AH is not set CONFIG_INET_ESP=y # CONFIG_INET_ESP_OFFLOAD is not set # CONFIG_INET_IPCOMP is not set CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_INET_UDP_DIAG is not set # CONFIG_INET_RAW_DIAG is not set CONFIG_INET_DIAG_DESTROY=y CONFIG_TCP_CONG_ADVANCED=y # CONFIG_TCP_CONG_BIC is not set CONFIG_TCP_CONG_CUBIC=y # CONFIG_TCP_CONG_WESTWOOD is not set # CONFIG_TCP_CONG_HTCP is not set # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_NV is not set # CONFIG_TCP_CONG_SCALABLE is not set # CONFIG_TCP_CONG_LP is not set # CONFIG_TCP_CONG_VENO is not set # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set # CONFIG_TCP_CONG_DCTCP is not set # CONFIG_TCP_CONG_CDG is not set # CONFIG_TCP_CONG_BBR is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y # CONFIG_INET6_ESP_OFFLOAD is not set CONFIG_INET6_IPCOMP=y CONFIG_IPV6_MIP6=y # CONFIG_IPV6_ILA is not set CONFIG_INET6_XFRM_TUNNEL=y CONFIG_INET6_TUNNEL=y CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set CONFIG_IPV6_VTI=y CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=y CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_IPV6_SUBTREES is not set # CONFIG_IPV6_MROUTE is not set # CONFIG_IPV6_SEG6_LWTUNNEL is not set # CONFIG_IPV6_SEG6_HMAC is not set # CONFIG_NETLABEL is not set CONFIG_ANDROID_PARANOID_NETWORK=y CONFIG_NETWORK_SECMARK=y CONFIG_NET_PTP_CLASSIFY=y # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y # # Core Netfilter Configuration # CONFIG_NETFILTER_INGRESS=y CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_FAMILY_ARP=y # CONFIG_NETFILTER_NETLINK_ACCT is not set CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y # CONFIG_NETFILTER_NETLINK_OSF is not set CONFIG_NF_CONNTRACK=y # CONFIG_NF_LOG_NETDEV is not set CONFIG_NETFILTER_CONNCOUNT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y # CONFIG_NF_CONNTRACK_ZONES is not set CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set # CONFIG_NF_CONNTRACK_LABELS is not set CONFIG_NF_CT_PROTO_DCCP=y CONFIG_NF_CT_PROTO_GRE=y CONFIG_NF_CT_PROTO_SCTP=y CONFIG_NF_CT_PROTO_UDPLITE=y CONFIG_NF_CONNTRACK_AMANDA=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_H323=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_BROADCAST=y CONFIG_NF_CONNTRACK_NETBIOS_NS=y # CONFIG_NF_CONNTRACK_SNMP is not set CONFIG_NF_CONNTRACK_PPTP=y CONFIG_NF_CONNTRACK_SANE=y CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CONNTRACK_TFTP=y CONFIG_NF_CT_NETLINK=y # CONFIG_NETFILTER_NETLINK_GLUE_CT is not set CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_NF_NAT_PROTO_DCCP=y CONFIG_NF_NAT_PROTO_UDPLITE=y CONFIG_NF_NAT_PROTO_SCTP=y CONFIG_NF_NAT_AMANDA=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y CONFIG_NF_NAT_SIP=y CONFIG_NF_NAT_TFTP=y CONFIG_NF_NAT_REDIRECT=y # CONFIG_NF_TABLES is not set CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=y CONFIG_NETFILTER_XT_CONNMARK=y # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_AUDIT=m # CONFIG_NETFILTER_XT_TARGET_CHECKSUM is not set CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_CONNMARK=y CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y # CONFIG_NETFILTER_XT_TARGET_CT is not set # CONFIG_NETFILTER_XT_TARGET_DSCP is not set # CONFIG_NETFILTER_XT_TARGET_HL is not set # CONFIG_NETFILTER_XT_TARGET_HMARK is not set CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y # CONFIG_NETFILTER_XT_TARGET_LED is not set # CONFIG_NETFILTER_XT_TARGET_LOG is not set CONFIG_NETFILTER_XT_TARGET_MARK=y CONFIG_NETFILTER_XT_NAT=y CONFIG_NETFILTER_XT_TARGET_NETMAP=y CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set # CONFIG_NETFILTER_XT_TARGET_RATEEST is not set CONFIG_NETFILTER_XT_TARGET_REDIRECT=y # CONFIG_NETFILTER_XT_TARGET_TEE is not set CONFIG_NETFILTER_XT_TARGET_TPROXY=y CONFIG_NETFILTER_XT_TARGET_TRACE=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y # CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set # # Xtables matches # # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set CONFIG_NETFILTER_XT_MATCH_BPF=y # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set # CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set CONFIG_NETFILTER_XT_MATCH_COMMENT=y # CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set # CONFIG_NETFILTER_XT_MATCH_CONNLABEL is not set CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y CONFIG_NETFILTER_XT_MATCH_CONNMARK=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y # CONFIG_NETFILTER_XT_MATCH_CPU is not set # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set # CONFIG_NETFILTER_XT_MATCH_DSCP is not set CONFIG_NETFILTER_XT_MATCH_ECN=y # CONFIG_NETFILTER_XT_MATCH_ESP is not set CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y CONFIG_NETFILTER_XT_MATCH_HELPER=y CONFIG_NETFILTER_XT_MATCH_HL=y # CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set CONFIG_NETFILTER_XT_MATCH_IPRANGE=y CONFIG_NETFILTER_XT_MATCH_L2TP=y CONFIG_NETFILTER_XT_MATCH_LENGTH=y CONFIG_NETFILTER_XT_MATCH_LIMIT=y CONFIG_NETFILTER_XT_MATCH_MAC=y CONFIG_NETFILTER_XT_MATCH_MARK=y # CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set # CONFIG_NETFILTER_XT_MATCH_OSF is not set # CONFIG_NETFILTER_XT_MATCH_OWNER is not set CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y CONFIG_NETFILTER_XT_MATCH_QTAGUID=y CONFIG_NETFILTER_XT_MATCH_QUOTA=y CONFIG_NETFILTER_XT_MATCH_QUOTA2=y CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG=y # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_RECENT is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set CONFIG_NETFILTER_XT_MATCH_SOCKET=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NETFILTER_XT_MATCH_STATISTIC=y CONFIG_NETFILTER_XT_MATCH_STRING=y # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set CONFIG_NETFILTER_XT_MATCH_TIME=y CONFIG_NETFILTER_XT_MATCH_U32=y # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_SOCKET_IPV4=y CONFIG_NF_TPROXY_IPV4=y # CONFIG_NF_DUP_IPV4 is not set # CONFIG_NF_LOG_ARP is not set # CONFIG_NF_LOG_IPV4 is not set CONFIG_NF_REJECT_IPV4=y CONFIG_NF_NAT_IPV4=y CONFIG_NF_NAT_MASQUERADE_IPV4=y CONFIG_NF_NAT_PROTO_GRE=y CONFIG_NF_NAT_PPTP=y CONFIG_NF_NAT_H323=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_AH=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_RPFILTER=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_SYNPROXY is not set CONFIG_IP_NF_NAT=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_MANGLE=y # CONFIG_IP_NF_TARGET_CLUSTERIP is not set # CONFIG_IP_NF_TARGET_ECN is not set # CONFIG_IP_NF_TARGET_TTL is not set CONFIG_IP_NF_RAW=y CONFIG_IP_NF_SECURITY=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration # CONFIG_NF_SOCKET_IPV6=y CONFIG_NF_TPROXY_IPV6=y # CONFIG_NF_DUP_IPV6 is not set CONFIG_NF_REJECT_IPV6=y # CONFIG_NF_LOG_IPV6 is not set CONFIG_NF_NAT_IPV6=y CONFIG_NF_NAT_MASQUERADE_IPV6=y CONFIG_IP6_NF_IPTABLES=y # CONFIG_IP6_NF_MATCH_AH is not set # CONFIG_IP6_NF_MATCH_EUI64 is not set # CONFIG_IP6_NF_MATCH_FRAG is not set # CONFIG_IP6_NF_MATCH_OPTS is not set # CONFIG_IP6_NF_MATCH_HL is not set CONFIG_IP6_NF_MATCH_IPV6HEADER=y # CONFIG_IP6_NF_MATCH_MH is not set CONFIG_IP6_NF_MATCH_RPFILTER=y # CONFIG_IP6_NF_MATCH_RT is not set # CONFIG_IP6_NF_MATCH_SRH is not set # CONFIG_IP6_NF_TARGET_HL is not set CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y # CONFIG_IP6_NF_TARGET_SYNPROXY is not set CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_RAW=y # CONFIG_IP6_NF_SECURITY is not set CONFIG_IP6_NF_NAT=y CONFIG_IP6_NF_TARGET_MASQUERADE=y # CONFIG_IP6_NF_TARGET_NPT is not set CONFIG_NF_DEFRAG_IPV6=y # CONFIG_BPFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_L2TP=y # CONFIG_L2TP_DEBUGFS is not set # CONFIG_L2TP_V3 is not set # CONFIG_BRIDGE is not set CONFIG_HAVE_NET_DSA=y # CONFIG_NET_DSA is not set CONFIG_VLAN_8021Q=y # CONFIG_VLAN_8021Q_GVRP is not set # CONFIG_VLAN_8021Q_MVRP is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_PHONET is not set # CONFIG_6LOWPAN is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set CONFIG_NET_SCH_HTB=y # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set # CONFIG_NET_SCH_MULTIQ is not set # CONFIG_NET_SCH_RED is not set # CONFIG_NET_SCH_SFB is not set # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_CBS is not set # CONFIG_NET_SCH_ETF is not set # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DRR is not set # CONFIG_NET_SCH_MQPRIO is not set # CONFIG_NET_SCH_SKBPRIO is not set # CONFIG_NET_SCH_CHOKE is not set # CONFIG_NET_SCH_QFQ is not set # CONFIG_NET_SCH_CODEL is not set # CONFIG_NET_SCH_FQ_CODEL is not set # CONFIG_NET_SCH_CAKE is not set CONFIG_NET_SCH_FQ=y # CONFIG_NET_SCH_HHF is not set # CONFIG_NET_SCH_PIE is not set # CONFIG_NET_SCH_INGRESS is not set # CONFIG_NET_SCH_PLUG is not set # CONFIG_NET_SCH_DEFAULT is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set # CONFIG_NET_CLS_FW is not set CONFIG_NET_CLS_U32=y # CONFIG_CLS_U32_PERF is not set # CONFIG_CLS_U32_MARK is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set # CONFIG_NET_CLS_CGROUP is not set # CONFIG_NET_CLS_BPF is not set # CONFIG_NET_CLS_FLOWER is not set # CONFIG_NET_CLS_MATCHALL is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 # CONFIG_NET_EMATCH_CMP is not set # CONFIG_NET_EMATCH_NBYTE is not set CONFIG_NET_EMATCH_U32=y # CONFIG_NET_EMATCH_META is not set # CONFIG_NET_EMATCH_TEXT is not set # CONFIG_NET_EMATCH_CANID is not set # CONFIG_NET_EMATCH_IPT is not set CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set # CONFIG_NET_ACT_GACT is not set # CONFIG_NET_ACT_MIRRED is not set # CONFIG_NET_ACT_SAMPLE is not set # CONFIG_NET_ACT_IPT is not set # CONFIG_NET_ACT_NAT is not set # CONFIG_NET_ACT_PEDIT is not set # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_ACT_CSUM is not set # CONFIG_NET_ACT_VLAN is not set # CONFIG_NET_ACT_BPF is not set # CONFIG_NET_ACT_CONNMARK is not set # CONFIG_NET_ACT_SKBMOD is not set # CONFIG_NET_ACT_IFE is not set # CONFIG_NET_ACT_TUNNEL_KEY is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set # CONFIG_OPENVSWITCH is not set # CONFIG_VSOCKETS is not set # CONFIG_NETLINK_DIAG is not set # CONFIG_MPLS is not set # CONFIG_NET_NSH is not set # CONFIG_HSR is not set # CONFIG_NET_SWITCHDEV is not set # CONFIG_NET_L3_MASTER_DEV is not set # CONFIG_NET_NCSI is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # CONFIG_CGROUP_NET_PRIO is not set # CONFIG_CGROUP_NET_CLASSID is not set CONFIG_NET_RX_BUSY_POLL=y CONFIG_BQL=y # CONFIG_BPF_JIT is not set # CONFIG_BPF_STREAM_PARSER is not set CONFIG_NET_FLOW_LIMIT=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_DROP_MONITOR is not set # CONFIG_HAMRADIO is not set CONFIG_CAN=y CONFIG_CAN_RAW=y CONFIG_CAN_BCM=y CONFIG_CAN_GW=y # # CAN Device Drivers # # CONFIG_CAN_VCAN is not set # CONFIG_CAN_VXCAN is not set CONFIG_CAN_SLCAN=y CONFIG_CAN_DEV=y CONFIG_CAN_CALC_BITTIMING=y # CONFIG_CAN_C_CAN is not set # CONFIG_CAN_CC770 is not set # CONFIG_CAN_IFI_CANFD is not set # CONFIG_CAN_M_CAN is not set # CONFIG_CAN_PEAK_PCIEFD is not set # CONFIG_CAN_SJA1000 is not set # CONFIG_CAN_SOFTING is not set # # CAN SPI interfaces # # CONFIG_CAN_HI311X is not set # CONFIG_CAN_MCP251X is not set # # CAN USB interfaces # CONFIG_CAN_8DEV_USB=y # CONFIG_CAN_EMS_USB is not set # CONFIG_CAN_ESD_USB2 is not set # CONFIG_CAN_GS_USB is not set # CONFIG_CAN_KVASER_USB is not set # CONFIG_CAN_MCBA_USB is not set # CONFIG_CAN_PEAK_USB is not set # CONFIG_CAN_UCAN is not set # CONFIG_CAN_DEBUG_DEVICES is not set CONFIG_BT=m CONFIG_BT_BREDR=y CONFIG_BT_RFCOMM=m # CONFIG_BT_RFCOMM_TTY is not set CONFIG_BT_BNEP=m # CONFIG_BT_BNEP_MC_FILTER is not set # CONFIG_BT_BNEP_PROTO_FILTER is not set CONFIG_BT_HIDP=m CONFIG_BT_HS=y CONFIG_BT_LE=y # CONFIG_BT_LEDS is not set # CONFIG_BT_SELFTEST is not set CONFIG_BT_DEBUGFS=y # # Bluetooth device drivers # CONFIG_BT_INTEL=m CONFIG_BT_BCM=m CONFIG_BT_RTL=m CONFIG_BT_HCIBTUSB=m # CONFIG_BT_HCIBTUSB_AUTOSUSPEND is not set CONFIG_BT_HCIBTUSB_BCM=y CONFIG_BT_HCIBTUSB_RTL=y # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y # CONFIG_BT_HCIUART_BCSP is not set # CONFIG_BT_HCIUART_ATH3K is not set # CONFIG_BT_HCIUART_INTEL is not set # CONFIG_BT_HCIUART_AG6XX is not set # CONFIG_BT_HCIUART_MRVL is not set # CONFIG_BT_HCIBCM203X is not set # CONFIG_BT_HCIBPA10X is not set # CONFIG_BT_HCIBFUSB is not set # CONFIG_BT_HCIVHCI is not set # CONFIG_BT_MRVL is not set CONFIG_BT_ATH3K=m # CONFIG_AF_RXRPC is not set # CONFIG_AF_KCM is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m # CONFIG_NL80211_TESTMODE is not set # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set # CONFIG_CFG80211_CERTIFICATION_ONUS is not set CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS=y CONFIG_CFG80211_DEFAULT_PS=y # CONFIG_CFG80211_DEBUGFS is not set CONFIG_CFG80211_CRDA_SUPPORT=y # CONFIG_CFG80211_WEXT is not set CONFIG_LIB80211=m # CONFIG_LIB80211_DEBUG is not set CONFIG_MAC80211=m CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y # CONFIG_MAC80211_RC_MINSTREL_VHT is not set CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" # CONFIG_MAC80211_MESH is not set CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_MESSAGE_TRACING is not set # CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_MAC80211_STA_HASH_MAX_SIZE=0 # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_PM=y CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y CONFIG_RFKILL_GPIO=m # CONFIG_NET_9P is not set # CONFIG_CAIF is not set # CONFIG_CEPH_LIB is not set # CONFIG_NFC is not set # CONFIG_PSAMPLE is not set # CONFIG_NET_IFE is not set # CONFIG_LWTUNNEL is not set CONFIG_DST_CACHE=y CONFIG_GRO_CELLS=y # CONFIG_NET_DEVLINK is not set CONFIG_MAY_USE_DEVLINK=y # CONFIG_FAILOVER is not set CONFIG_HAVE_EBPF_JIT=y # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # # Firmware loader # CONFIG_FW_LOADER=y CONFIG_EXTRA_FIRMWARE="${EXTRA_FW}" CONFIG_EXTRA_FIRMWARE_DIR="${EXTRA_FW_DIR}" CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_DEVRES=y # CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set # CONFIG_TEST_ASYNC_DRIVER_PROBE is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_GENERIC_CPU_VULNERABILITIES=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_REGMAP_SPI=y CONFIG_REGMAP_IRQ=y # CONFIG_REGMAP_SDW is not set CONFIG_DMA_SHARED_BUFFER=y # CONFIG_DMA_FENCE_TRACE is not set # # Bus devices # CONFIG_DVC_TRACE_BUS=y # CONFIG_DVC_TRACE_BUS_DEBUG is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_GNSS is not set # CONFIG_MTD is not set # CONFIG_OF is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_NULL_BLK is not set # CONFIG_BLK_DEV_FD is not set CONFIG_CDROM=y # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set CONFIG_ZRAM=y # CONFIG_ZRAM_WRITEBACK is not set # CONFIG_ZRAM_MEMORY_TRACKING is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SKD is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_VIRTIO_BLK is not set # CONFIG_BLK_DEV_RBD is not set # CONFIG_BLK_DEV_RSXX is not set # # NVME Support # # CONFIG_BLK_DEV_NVME is not set # CONFIG_NVME_FC is not set # CONFIG_NVME_TARGET is not set # # Misc devices # # CONFIG_AD525X_DPOT is not set # CONFIG_DUMMY_IRQ is not set # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_HP_ILO is not set # CONFIG_APDS9802ALS is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_SENSORS_BH1770 is not set # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_LATTICE_ECP3_CONFIG is not set # CONFIG_SRAM is not set # CONFIG_PCI_ENDPOINT_TEST is not set CONFIG_UID_SYS_STATS=y # CONFIG_UID_SYS_STATS_DEBUG is not set # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set CONFIG_EEPROM_93CX6=m # CONFIG_EEPROM_93XX46 is not set # CONFIG_EEPROM_IDT_89HPESX is not set # CONFIG_CB710_CORE is not set # # Texas Instruments shared transport line discipline # # CONFIG_TI_ST is not set # CONFIG_SENSORS_LIS3_I2C is not set # CONFIG_ALTERA_STAPL is not set CONFIG_INTEL_MEI=m CONFIG_INTEL_MEI_ME=m CONFIG_INTEL_MEI_TXE=m # CONFIG_INTEL_MEI_SPD is not set # CONFIG_VMWARE_VMCI is not set # # Intel MIC & related support # # # Intel MIC Bus Driver # # CONFIG_INTEL_MIC_BUS is not set # # SCIF Bus Driver # # CONFIG_SCIF_BUS is not set # # VOP Bus Driver # # CONFIG_VOP_BUS is not set # # Intel MIC Host Driver # # # Intel MIC Card Driver # # # SCIF Driver # # # Intel MIC Coprocessor State Management (COSM) Drivers # # # VOP Driver # # CONFIG_GENWQE is not set # CONFIG_ECHO is not set # CONFIG_MISC_RTSX_PCI is not set # CONFIG_MISC_RTSX_USB is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_MQ_DEFAULT is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_ISCSI_BOOT_SYSFS is not set # CONFIG_SCSI_CXGB3_ISCSI is not set # CONFIG_SCSI_CXGB4_ISCSI is not set # CONFIG_SCSI_BNX2_ISCSI is not set # CONFIG_BE2ISCSI is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_HPSA is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_3W_SAS is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_MVSAS is not set # CONFIG_SCSI_MVUMI is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_SCSI_ESAS2R is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_MPT3SAS is not set # CONFIG_SCSI_MPT2SAS is not set # CONFIG_SCSI_SMARTPQI is not set CONFIG_SCSI_UFSHCD=y CONFIG_SCSI_UFSHCD_PCI=y # CONFIG_SCSI_UFS_DWC_TC_PCI is not set # CONFIG_SCSI_UFSHCD_PLATFORM is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_VMWARE_PVSCSI is not set # CONFIG_SCSI_SNIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_ISCI is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_WD719X is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_PMCRAID is not set # CONFIG_SCSI_PM8001 is not set # CONFIG_SCSI_VIRTIO is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_ATA=y CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_ZPODD=y CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=m CONFIG_SATA_MOBILE_LPM_POLICY=0 CONFIG_SATA_AHCI_PLATFORM=y # CONFIG_SATA_INIC162X is not set # CONFIG_SATA_ACARD_AHCI is not set # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_SX4 is not set CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=y # CONFIG_SATA_DWC is not set # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_SVW is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set CONFIG_PATA_AMD=y # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_ATP867X is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87415 is not set CONFIG_PATA_OLDPIIX=y # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RDC is not set CONFIG_PATA_SCH=y # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set CONFIG_PATA_MPIIX=y # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_PLATFORM is not set # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # # CONFIG_PATA_ACPI is not set CONFIG_ATA_GENERIC=y # CONFIG_PATA_LEGACY is not set CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BCACHE=m # CONFIG_BCACHE_DEBUG is not set # CONFIG_BCACHE_CLOSURES_DEBUG is not set CONFIG_BLK_DEV_DM_BUILTIN=y CONFIG_BLK_DEV_DM=y # CONFIG_DM_MQ_DEFAULT is not set # CONFIG_DM_DEBUG is not set CONFIG_DM_BUFIO=y # CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set # CONFIG_DM_UNSTRIPED is not set CONFIG_DM_CRYPT=y CONFIG_DM_SNAPSHOT=y # CONFIG_DM_THIN_PROVISIONING is not set # CONFIG_DM_CACHE is not set # CONFIG_DM_WRITECACHE is not set # CONFIG_DM_ERA is not set CONFIG_DM_MIRROR=y # CONFIG_DM_LOG_USERSPACE is not set # CONFIG_DM_RAID is not set CONFIG_DM_ZERO=y # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y # CONFIG_DM_FLAKEY is not set CONFIG_DM_VERITY=y # CONFIG_DM_VERITY_HASH_PREFETCH_MIN_SIZE_128 is not set CONFIG_DM_VERITY_HASH_PREFETCH_MIN_SIZE=1 CONFIG_DM_VERITY_FEC=y # CONFIG_DM_SWITCH is not set # CONFIG_DM_LOG_WRITES is not set # CONFIG_DM_INTEGRITY is not set # CONFIG_DM_VERITY_AVB is not set # CONFIG_DM_ANDROID_VERITY is not set # CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED is not set # CONFIG_TARGET_CORE is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_FIREWIRE_NOSY is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_MII=y CONFIG_NET_CORE=y # CONFIG_BONDING is not set # CONFIG_DUMMY is not set # CONFIG_EQUALIZER is not set # CONFIG_NET_FC is not set # CONFIG_IFB is not set # CONFIG_NET_TEAM is not set # CONFIG_MACVLAN is not set # CONFIG_IPVLAN is not set # CONFIG_VXLAN is not set # CONFIG_GENEVE is not set # CONFIG_GTP is not set # CONFIG_MACSEC is not set CONFIG_NETCONSOLE=y # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_TUN=y # CONFIG_TUN_VNET_CROSS_LE is not set # CONFIG_VETH is not set # CONFIG_VIRTIO_NET is not set CONFIG_NLMON=m # CONFIG_ARCNET is not set # # CAIF transport drivers # # # Distributed Switch Architecture drivers # CONFIG_ETHERNET=y CONFIG_NET_VENDOR_3COM=y # CONFIG_VORTEX is not set # CONFIG_TYPHOON is not set CONFIG_NET_VENDOR_ADAPTEC=y # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_NET_VENDOR_AGERE is not set CONFIG_NET_VENDOR_ALACRITECH=y # CONFIG_SLICOSS is not set CONFIG_NET_VENDOR_ALTEON=y # CONFIG_ACENIC is not set # CONFIG_ALTERA_TSE is not set CONFIG_NET_VENDOR_AMAZON=y # CONFIG_ENA_ETHERNET is not set CONFIG_NET_VENDOR_AMD=y # CONFIG_AMD8111_ETH is not set # CONFIG_PCNET32 is not set # CONFIG_AMD_XGBE is not set CONFIG_NET_VENDOR_AQUANTIA=y # CONFIG_AQTION is not set # CONFIG_NET_VENDOR_ARC is not set CONFIG_NET_VENDOR_ATHEROS=y # CONFIG_ATL2 is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set # CONFIG_ATL1C is not set # CONFIG_ALX is not set # CONFIG_NET_VENDOR_AURORA is not set CONFIG_NET_VENDOR_BROADCOM=y # CONFIG_B44 is not set # CONFIG_BCMGENET is not set # CONFIG_BNX2 is not set # CONFIG_CNIC is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2X is not set # CONFIG_SYSTEMPORT is not set # CONFIG_BNXT is not set CONFIG_NET_VENDOR_BROCADE=y # CONFIG_BNA is not set CONFIG_NET_VENDOR_CADENCE=y # CONFIG_MACB is not set CONFIG_NET_VENDOR_CAVIUM=y # CONFIG_THUNDER_NIC_PF is not set # CONFIG_THUNDER_NIC_VF is not set # CONFIG_THUNDER_NIC_BGX is not set # CONFIG_THUNDER_NIC_RGX is not set CONFIG_CAVIUM_PTP=y # CONFIG_LIQUIDIO is not set # CONFIG_LIQUIDIO_VF is not set CONFIG_NET_VENDOR_CHELSIO=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y # CONFIG_ENIC is not set CONFIG_NET_VENDOR_CORTINA=y # CONFIG_CX_ECAT is not set # CONFIG_DNET is not set CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set CONFIG_NET_VENDOR_DLINK=y # CONFIG_DL2K is not set # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y # CONFIG_BE2NET is not set CONFIG_NET_VENDOR_EZCHIP=y CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_HUAWEI=y # CONFIG_HINIC is not set CONFIG_NET_VENDOR_I825XX=y CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=y CONFIG_E1000=y CONFIG_E1000E=y CONFIG_E1000E_HWTS=y CONFIG_IGB=m CONFIG_IGB_HWMON=y CONFIG_IGBVF=m # CONFIG_IXGB is not set # CONFIG_IXGBE is not set CONFIG_IXGBEVF=y # CONFIG_I40E is not set # CONFIG_I40EVF is not set # CONFIG_ICE is not set # CONFIG_FM10K is not set # CONFIG_JME is not set # CONFIG_NET_VENDOR_MARVELL is not set # CONFIG_NET_VENDOR_MELLANOX is not set # CONFIG_NET_VENDOR_MICREL is not set # CONFIG_NET_VENDOR_MICROCHIP is not set CONFIG_NET_VENDOR_MICROSEMI=y # CONFIG_NET_VENDOR_MYRI is not set # CONFIG_FEALNX is not set CONFIG_NET_VENDOR_NATSEMI=y # CONFIG_NATSEMI is not set # CONFIG_NS83820 is not set CONFIG_NET_VENDOR_NETERION=y # CONFIG_S2IO is not set # CONFIG_VXGE is not set CONFIG_NET_VENDOR_NETRONOME=y # CONFIG_NFP is not set CONFIG_NET_VENDOR_NI=y CONFIG_NET_VENDOR_8390=y CONFIG_NE2K_PCI=y CONFIG_NET_VENDOR_NVIDIA=y # CONFIG_FORCEDETH is not set # CONFIG_NET_VENDOR_OKI is not set # CONFIG_ETHOC is not set CONFIG_NET_VENDOR_PACKET_ENGINES=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_NET_VENDOR_QLOGIC is not set # CONFIG_NET_VENDOR_QUALCOMM is not set # CONFIG_NET_VENDOR_RDC is not set # CONFIG_NET_VENDOR_REALTEK is not set CONFIG_NET_VENDOR_RENESAS=y # CONFIG_NET_VENDOR_ROCKER is not set # CONFIG_NET_VENDOR_SAMSUNG is not set # CONFIG_NET_VENDOR_SEEQ is not set CONFIG_NET_VENDOR_SOLARFLARE=y # CONFIG_SFC is not set # CONFIG_SFC_FALCON is not set # CONFIG_NET_VENDOR_SILAN is not set # CONFIG_NET_VENDOR_SIS is not set # CONFIG_NET_VENDOR_SMSC is not set CONFIG_NET_VENDOR_SOCIONEXT=y # CONFIG_NET_VENDOR_STMICRO is not set # CONFIG_NET_VENDOR_SUN is not set CONFIG_NET_VENDOR_SYNOPSYS=y # CONFIG_DWC_XLGMAC is not set # CONFIG_NET_VENDOR_TEHUTI is not set # CONFIG_NET_VENDOR_TI is not set # CONFIG_NET_VENDOR_VIA is not set # CONFIG_NET_VENDOR_WIZNET is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_MDIO_DEVICE=y CONFIG_MDIO_BUS=y # CONFIG_MDIO_BCM_UNIMAC is not set CONFIG_MDIO_BITBANG=m # CONFIG_MDIO_GPIO is not set # CONFIG_MDIO_MSCC_MIIM is not set # CONFIG_MDIO_THUNDER is not set CONFIG_PHYLIB=y # CONFIG_LED_TRIGGER_PHY is not set # # MII PHY device drivers # # CONFIG_AMD_PHY is not set # CONFIG_AQUANTIA_PHY is not set # CONFIG_ASIX_PHY is not set # CONFIG_AT803X_PHY is not set # CONFIG_BCM7XXX_PHY is not set # CONFIG_BCM87XX_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_CORTINA_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_DP83822_PHY is not set # CONFIG_DP83TC811_PHY is not set # CONFIG_DP83848_PHY is not set # CONFIG_DP83867_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_INTEL_XWAY_PHY is not set # CONFIG_LSI_ET1011C_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_MARVELL_PHY is not set # CONFIG_MARVELL_10G_PHY is not set # CONFIG_MICREL_PHY is not set # CONFIG_MICROCHIP_PHY is not set # CONFIG_MICROCHIP_T1_PHY is not set # CONFIG_MICROSEMI_PHY is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_RENESAS_PHY is not set # CONFIG_ROCKCHIP_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_STE10XP is not set # CONFIG_TERANETICS_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_XILINX_GMII2RGMII is not set # CONFIG_MICREL_KS8995MA is not set CONFIG_PPP=y CONFIG_PPP_BSDCOMP=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_FILTER=y CONFIG_PPP_MPPE=y # CONFIG_PPP_MULTILINK is not set CONFIG_PPPOE=y CONFIG_PPPOL2TP=y # CONFIG_PPP_ASYNC is not set # CONFIG_PPP_SYNC_TTY is not set # CONFIG_SLIP is not set CONFIG_SLHC=y CONFIG_USB_NET_DRIVERS=y CONFIG_USB_CATC=y CONFIG_USB_KAWETH=y CONFIG_USB_PEGASUS=y CONFIG_USB_RTL8150=y # CONFIG_USB_RTL8152 is not set # CONFIG_USB_LAN78XX is not set CONFIG_USB_USBNET=y CONFIG_USB_NET_AX8817X=y CONFIG_USB_NET_AX88179_178A=y CONFIG_USB_NET_CDCETHER=y CONFIG_USB_NET_CDC_EEM=y CONFIG_USB_NET_CDC_NCM=y CONFIG_USB_NET_HUAWEI_CDC_NCM=m # CONFIG_USB_NET_CDC_MBIM is not set CONFIG_USB_NET_DM9601=y CONFIG_USB_NET_SR9700=m # CONFIG_USB_NET_SR9800 is not set CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y # CONFIG_USB_NET_GL620A is not set CONFIG_USB_NET_NET1080=y # CONFIG_USB_NET_PLUSB is not set CONFIG_USB_NET_MCS7830=y # CONFIG_USB_NET_RNDIS_HOST is not set CONFIG_USB_NET_CDC_SUBSET_ENABLE=y CONFIG_USB_NET_CDC_SUBSET=y # CONFIG_USB_ALI_M5632 is not set # CONFIG_USB_AN2720 is not set CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y # CONFIG_USB_EPSON2888 is not set # CONFIG_USB_KC2190 is not set CONFIG_USB_NET_ZAURUS=y # CONFIG_USB_NET_CX82310_ETH is not set # CONFIG_USB_NET_KALMIA is not set # CONFIG_USB_NET_QMI_WWAN is not set # CONFIG_USB_HSO is not set # CONFIG_USB_NET_INT51X1 is not set CONFIG_USB_IPHETH=y CONFIG_USB_SIERRA_NET=y # CONFIG_USB_VL600 is not set # CONFIG_USB_NET_CH9200 is not set CONFIG_WLAN=y # CONFIG_WIRELESS_WDS is not set CONFIG_WLAN_VENDOR_ADMTEK=y # CONFIG_ADM8211 is not set CONFIG_WLAN_VENDOR_ATH=y # CONFIG_ATH_DEBUG is not set # CONFIG_ATH5K is not set # CONFIG_ATH5K_PCI is not set # CONFIG_ATH9K is not set # CONFIG_ATH9K_HTC is not set # CONFIG_CARL9170 is not set # CONFIG_ATH6KL is not set # CONFIG_AR5523 is not set # CONFIG_WIL6210 is not set # CONFIG_ATH10K is not set # CONFIG_WCN36XX is not set CONFIG_WLAN_VENDOR_ATMEL=y # CONFIG_ATMEL is not set # CONFIG_AT76C50X_USB is not set CONFIG_WLAN_VENDOR_BROADCOM=y # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_BRCMSMAC is not set # CONFIG_BRCMFMAC is not set CONFIG_WLAN_VENDOR_CISCO=y # CONFIG_AIRO is not set CONFIG_WLAN_VENDOR_INTEL=y # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IWL4965 is not set # CONFIG_IWL3945 is not set # CONFIG_IWLWIFI is not set CONFIG_WLAN_VENDOR_INTERSIL=y # CONFIG_HOSTAP is not set # CONFIG_HERMES is not set # CONFIG_P54_COMMON is not set # CONFIG_PRISM54 is not set CONFIG_WLAN_VENDOR_MARVELL=y # CONFIG_LIBERTAS is not set # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_MWIFIEX is not set # CONFIG_MWL8K is not set CONFIG_WLAN_VENDOR_MEDIATEK=y # CONFIG_MT7601U is not set # CONFIG_MT76x0U is not set # CONFIG_MT76x2E is not set # CONFIG_MT76x2U is not set CONFIG_WLAN_VENDOR_RALINK=y # CONFIG_RT2X00 is not set CONFIG_WLAN_VENDOR_REALTEK=y # CONFIG_RTL8180 is not set # CONFIG_RTL8187 is not set CONFIG_RTL_CARDS=m # CONFIG_RTL8192CE is not set # CONFIG_RTL8192SE is not set # CONFIG_RTL8192DE is not set # CONFIG_RTL8723AE is not set # CONFIG_RTL8723BE is not set # CONFIG_RTL8188EE is not set # CONFIG_RTL8192EE is not set # CONFIG_RTL8821AE is not set # CONFIG_RTL8192CU is not set # CONFIG_RTL8XXXU is not set CONFIG_WLAN_VENDOR_RSI=y # CONFIG_RSI_91X is not set CONFIG_WLAN_VENDOR_ST=y # CONFIG_CW1200 is not set CONFIG_WLAN_VENDOR_TI=y # CONFIG_WL1251 is not set # CONFIG_WL12XX is not set # CONFIG_WL18XX is not set # CONFIG_WLCORE is not set CONFIG_WLAN_VENDOR_ZYDAS=y # CONFIG_USB_ZD1201 is not set # CONFIG_ZD1211RW is not set CONFIG_WLAN_VENDOR_QUANTENNA=y # CONFIG_QTNFMAC_PEARL_PCIE is not set # CONFIG_MAC80211_HWSIM is not set # CONFIG_USB_NET_RNDIS_WLAN is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set # CONFIG_VMXNET3 is not set # CONFIG_FUJITSU_ES is not set # CONFIG_NETDEVSIM is not set # CONFIG_NET_FAILOVER is not set # CONFIG_ISDN is not set # CONFIG_NVM is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_LEDS=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y CONFIG_INPUT_SPARSEKMAP=y # CONFIG_INPUT_MATRIXKMAP is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADC is not set # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set # CONFIG_KEYBOARD_ATKBD is not set # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_DLINK_DIR685 is not set # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_GPIO=y # CONFIG_KEYBOARD_GPIO_POLLED is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_TCA8418 is not set # CONFIG_KEYBOARD_MATRIX is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_LM8333 is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_SAMSUNG is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_TM2_TOUCHKEY is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y # CONFIG_MOUSE_PS2 is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_CYAPA is not set # CONFIG_MOUSE_ELAN_I2C is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_GPIO is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set # CONFIG_MOUSE_SYNAPTICS_USB is not set CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_AS5011 is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set # CONFIG_JOYSTICK_PSXPAD_SPI is not set # CONFIG_JOYSTICK_PXRC is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_USB_ACECAD is not set # CONFIG_TABLET_USB_AIPTEK is not set # CONFIG_TABLET_USB_GTCO is not set # CONFIG_TABLET_USB_HANWANG is not set # CONFIG_TABLET_USB_KBTAB is not set # CONFIG_TABLET_USB_PEGASUS is not set # CONFIG_TABLET_SERIAL_WACOM4 is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_PROPERTIES=y # CONFIG_TOUCHSCREEN_ADS7846 is not set # CONFIG_TOUCHSCREEN_AD7877 is not set # CONFIG_TOUCHSCREEN_AD7879 is not set # CONFIG_TOUCHSCREEN_ADC is not set CONFIG_TOUCHSCREEN_ATMEL_MXT=y # CONFIG_TOUCHSCREEN_ATMEL_MXT_T37 is not set # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set # CONFIG_TOUCHSCREEN_BU21013 is not set # CONFIG_TOUCHSCREEN_BU21029 is not set # CONFIG_TOUCHSCREEN_CHIPONE_ICN8505 is not set # CONFIG_TOUCHSCREEN_CY8CTMG110 is not set # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set CONFIG_TOUCHSCREEN_CYTTSP4_CORE=m CONFIG_TOUCHSCREEN_CYTTSP4_I2C=m CONFIG_TOUCHSCREEN_CYTTSP4_SPI=m # CONFIG_TOUCHSCREEN_DYNAPRO is not set # CONFIG_TOUCHSCREEN_HAMPSHIRE is not set # CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set # CONFIG_TOUCHSCREEN_EXC3000 is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_GOODIX is not set # CONFIG_TOUCHSCREEN_HIDEEP is not set # CONFIG_TOUCHSCREEN_ILI210X is not set # CONFIG_TOUCHSCREEN_S6SY761 is not set # CONFIG_TOUCHSCREEN_GUNZE is not set # CONFIG_TOUCHSCREEN_EKTF2127 is not set # CONFIG_TOUCHSCREEN_ELAN is not set # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_WACOM_I2C is not set # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set # CONFIG_TOUCHSCREEN_MMS114 is not set # CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set # CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_WDT87XX_I2C is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TSC_SERIO is not set # CONFIG_TOUCHSCREEN_TSC2004 is not set # CONFIG_TOUCHSCREEN_TSC2005 is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set # CONFIG_TOUCHSCREEN_RM_TS is not set # CONFIG_TOUCHSCREEN_SILEAD is not set # CONFIG_TOUCHSCREEN_SIS_I2C is not set # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_STMFTS is not set CONFIG_TOUCHSCREEN_SUR40=m # CONFIG_TOUCHSCREEN_SURFACE3_SPI is not set # CONFIG_TOUCHSCREEN_SX8654 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set # CONFIG_TOUCHSCREEN_ZET6223 is not set CONFIG_TOUCHSCREEN_ZFORCE=m # CONFIG_TOUCHSCREEN_ROHM_BU21023 is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_ARIZONA_HAPTICS is not set # CONFIG_INPUT_BMA150 is not set # CONFIG_INPUT_E3X0_BUTTON is not set # CONFIG_INPUT_PCSPKR is not set # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_GP2A is not set # CONFIG_INPUT_GPIO_BEEPER is not set # CONFIG_INPUT_GPIO_DECODER is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_REGULATOR_HAPTIC is not set CONFIG_INPUT_UINPUT=y # CONFIG_INPUT_GPIO is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_PWM_BEEPER is not set # CONFIG_INPUT_PWM_VIBRA is not set # CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_IMS_PCU is not set # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_SOC_BUTTON_ARRAY=y # CONFIG_INPUT_DRV260X_HAPTICS is not set # CONFIG_INPUT_DRV2665_HAPTICS is not set # CONFIG_INPUT_DRV2667_HAPTICS is not set # CONFIG_RMI4_CORE is not set # # Hardware I/O ports # # CONFIG_SERIO is not set CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_NONSTANDARD=y # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set # CONFIG_SYNCLINK_GT is not set # CONFIG_NOZOMI is not set # CONFIG_ISI is not set # CONFIG_N_HDLC is not set CONFIG_N_GSM=y CONFIG_TRACE_ROUTER=y CONFIG_TRACE_SINK=y CONFIG_CBC_LDISC=y CONFIG_DEVMEM=y CONFIG_DEVKMEM=y # # Serial drivers # CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_PNP=y # CONFIG_SERIAL_8250_FINTEK is not set CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_EXAR=y CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_8250_DW=y # CONFIG_SERIAL_8250_RT288X is not set CONFIG_SERIAL_8250_LPSS=y CONFIG_SERIAL_8250_MID=y # CONFIG_SERIAL_8250_MOXA is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX310X is not set # CONFIG_SERIAL_UARTLITE is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set # CONFIG_SERIAL_SCCNXP is not set # CONFIG_SERIAL_SC16IS7XX is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_IFX6X60 is not set # CONFIG_SERIAL_ARC is not set # CONFIG_SERIAL_RP2 is not set # CONFIG_SERIAL_FSL_LPUART is not set # CONFIG_SERIAL_DEV_BUS is not set # CONFIG_TTY_PRINTK is not set # CONFIG_VIRTIO_CONSOLE is not set # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_TIMERIOMEM is not set CONFIG_HW_RANDOM_INTEL=y # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_VIA is not set # CONFIG_HW_RANDOM_VIRTIO is not set CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set CONFIG_TCG_TPM=m CONFIG_HW_RANDOM_TPM=y CONFIG_TCG_TIS_CORE=m CONFIG_TCG_TIS=m # CONFIG_TCG_TIS_SPI is not set CONFIG_TCG_TIS_I2C_ATMEL=m CONFIG_TCG_TIS_I2C_INFINEON=m CONFIG_TCG_TIS_I2C_NUVOTON=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m CONFIG_TCG_CRB=m # CONFIG_TCG_VTPM_PROXY is not set # CONFIG_TCG_TIS_ST33ZP24_I2C is not set # CONFIG_TCG_TIS_ST33ZP24_SPI is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y # CONFIG_XILLYBUS is not set CONFIG_RPMB=y CONFIG_RPMB_INTF_DEV=y CONFIG_RPMB_SIM=m # CONFIG_VIRTIO_RPMB is not set # CONFIG_RPMB_MUX is not set CONFIG_RANDOM_TRUST_CPU=y # # I2C support # CONFIG_I2C=y CONFIG_ACPI_I2C_OPREGION=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_MUX=y # # Multiplexer I2C Chip support # # CONFIG_I2C_MUX_GPIO is not set # CONFIG_I2C_MUX_LTC4306 is not set # CONFIG_I2C_MUX_PCA9541 is not set # CONFIG_I2C_MUX_PCA954x is not set # CONFIG_I2C_MUX_REG is not set # CONFIG_I2C_MUX_MLXCPLD is not set # CONFIG_I2C_HELPER_AUTO is not set CONFIG_I2C_SMBUS=y # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y CONFIG_I2C_ISCH=y # CONFIG_I2C_ISMT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # ACPI drivers # CONFIG_I2C_SCMI=y # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_CBUS_GPIO is not set CONFIG_I2C_DESIGNWARE_CORE=y CONFIG_I2C_DESIGNWARE_PLATFORM=y # CONFIG_I2C_DESIGNWARE_SLAVE is not set CONFIG_I2C_DESIGNWARE_PCI=y CONFIG_I2C_DESIGNWARE_BAYTRAIL=y # CONFIG_I2C_EMEV2 is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_ROBOTFUZZ_OSIF is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_MLXCPLD is not set # CONFIG_I2C_STUB is not set CONFIG_I2C_SLAVE=y # CONFIG_I2C_SLAVE_EEPROM is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # CONFIG_SPI_MEM is not set # # SPI Master Controller Drivers # # CONFIG_SPI_ALTERA is not set # CONFIG_SPI_AXI_SPI_ENGINE is not set # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_CADENCE is not set # CONFIG_SPI_DESIGNWARE is not set # CONFIG_SPI_GPIO is not set # CONFIG_SPI_OC_TINY is not set CONFIG_SPI_PXA2XX=y CONFIG_SPI_PXA2XX_PCI=y # CONFIG_SPI_ROCKCHIP is not set # CONFIG_SPI_SC18IS602 is not set # CONFIG_SPI_XCOMM is not set # CONFIG_SPI_XILINX is not set # CONFIG_SPI_ZYNQMP_GQSPI is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_LOOPBACK_TEST is not set # CONFIG_SPI_TLE62X0 is not set # CONFIG_SPI_SLAVE is not set # CONFIG_SPMI is not set # CONFIG_HSI is not set CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set # # PPS clients support # # CONFIG_PPS_CLIENT_KTIMER is not set # CONFIG_PPS_CLIENT_LDISC is not set # CONFIG_PPS_CLIENT_GPIO is not set # # PPS generators support # # # PTP clock support # CONFIG_PTP_1588_CLOCK=y # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_PINCTRL=y CONFIG_PINMUX=y CONFIG_PINCONF=y CONFIG_GENERIC_PINCONF=y # CONFIG_DEBUG_PINCTRL is not set # CONFIG_PINCTRL_AMD is not set # CONFIG_PINCTRL_MCP23S08 is not set # CONFIG_PINCTRL_SX150X is not set CONFIG_PINCTRL_BAYTRAIL=y CONFIG_PINCTRL_CHERRYVIEW=y CONFIG_PINCTRL_INTEL=y CONFIG_PINCTRL_BROXTON=y # CONFIG_PINCTRL_CANNONLAKE is not set # CONFIG_PINCTRL_CEDARFORK is not set # CONFIG_PINCTRL_DENVERTON is not set # CONFIG_PINCTRL_GEMINILAKE is not set # CONFIG_PINCTRL_ICELAKE is not set # CONFIG_PINCTRL_LEWISBURG is not set # CONFIG_PINCTRL_SUNRISEPOINT is not set CONFIG_GPIOLIB=y CONFIG_GPIOLIB_FASTPATH_LIMIT=512 CONFIG_GPIO_ACPI=y CONFIG_GPIOLIB_IRQCHIP=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y # # Memory mapped GPIO drivers # # CONFIG_GPIO_AMDPT is not set # CONFIG_GPIO_DWAPB is not set # CONFIG_GPIO_EXAR is not set # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_ICH is not set CONFIG_GPIO_LYNXPOINT=y # CONFIG_GPIO_MB86S7X is not set # CONFIG_GPIO_MOCKUP is not set # CONFIG_GPIO_VX855 is not set # # Port-mapped I/O GPIO drivers # # CONFIG_GPIO_F7188X is not set # CONFIG_GPIO_IT87 is not set # CONFIG_GPIO_SCH is not set # CONFIG_GPIO_SCH311X is not set # CONFIG_GPIO_WINBOND is not set # CONFIG_GPIO_WS16C48 is not set # # I2C GPIO expanders # # CONFIG_GPIO_ADP5588 is not set # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_TPIC2810 is not set # # MFD GPIO expanders # CONFIG_GPIO_ARIZONA=y # CONFIG_GPIO_CRYSTAL_COVE is not set CONFIG_GPIO_WHISKEY_COVE=y # # PCI GPIO expanders # # CONFIG_GPIO_AMD8111 is not set # CONFIG_GPIO_BT8XX is not set # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_PCI_IDIO_16 is not set # CONFIG_GPIO_PCIE_IDIO_24 is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders # # CONFIG_GPIO_MAX3191X is not set # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MC33880 is not set # CONFIG_GPIO_PISOSR is not set # CONFIG_GPIO_XRA1403 is not set # # USB GPIO expanders # # CONFIG_W1 is not set # CONFIG_POWER_AVS is not set # CONFIG_POWER_RESET is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set CONFIG_GENERIC_ADC_BATTERY=m # CONFIG_TEST_POWER is not set # CONFIG_CHARGER_ADP5061 is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2781 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_SBS is not set # CONFIG_CHARGER_SBS is not set # CONFIG_MANAGER_SBS is not set # CONFIG_BATTERY_BQ27XXX is not set # CONFIG_BATTERY_MAX17040 is not set CONFIG_BATTERY_MAX17042=y CONFIG_CHARGER_ISP1704=m # CONFIG_CHARGER_MAX8903 is not set # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_MANAGER is not set # CONFIG_CHARGER_LTC3651 is not set # CONFIG_CHARGER_BQ2415X is not set # CONFIG_CHARGER_BQ24190 is not set # CONFIG_CHARGER_BQ24257 is not set # CONFIG_CHARGER_BQ24735 is not set CONFIG_CHARGER_BQ25890=y CONFIG_CHARGER_SMB347=y # CONFIG_BATTERY_GAUGE_LTC2941 is not set # CONFIG_CHARGER_RT9455 is not set CONFIG_HWMON=y # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7314 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7310 is not set # CONFIG_SENSORS_ADT7410 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_K10TEMP is not set # CONFIG_SENSORS_FAM15H_POWER is not set # CONFIG_SENSORS_APPLESMC is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ASPEED is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_DS1621 is not set CONFIG_SENSORS_DELL_SMM=m # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_FTSTEUTATES is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_G762 is not set # CONFIG_SENSORS_HIH6130 is not set CONFIG_SENSORS_IIO_HWMON=y # CONFIG_SENSORS_I5500 is not set CONFIG_SENSORS_CORETEMP=y # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_POWR1220 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LTC2945 is not set # CONFIG_SENSORS_LTC2990 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4222 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4260 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_MAX1111 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX197 is not set # CONFIG_SENSORS_MAX31722 is not set # CONFIG_SENSORS_MAX6621 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_MAX6697 is not set # CONFIG_SENSORS_MAX31790 is not set # CONFIG_SENSORS_MCP3021 is not set # CONFIG_SENSORS_TC654 is not set # CONFIG_SENSORS_ADCXX is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM70 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LM95234 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set # CONFIG_SENSORS_NCT6683 is not set # CONFIG_SENSORS_NCT6775 is not set # CONFIG_SENSORS_NCT7802 is not set # CONFIG_SENSORS_NCT7904 is not set # CONFIG_SENSORS_NPCM7XX is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT15 is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SHT3x is not set # CONFIG_SENSORS_SHTC1 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set CONFIG_SENSORS_SCH56XX_COMMON=m CONFIG_SENSORS_SCH5627=m CONFIG_SENSORS_SCH5636=m # CONFIG_SENSORS_STTS751 is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_ADC128D818 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_ADS7871 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_INA209 is not set # CONFIG_SENSORS_INA2XX is not set # CONFIG_SENSORS_INA3221 is not set # CONFIG_SENSORS_TC74 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP103 is not set # CONFIG_SENSORS_TMP108 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_VIA_CPUTEMP is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83773G is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_XGENE is not set # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set # CONFIG_SENSORS_ATK0110 is not set CONFIG_THERMAL=y # CONFIG_THERMAL_STATISTICS is not set CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0 CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_WRITABLE_TRIPS=y CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set # CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set # CONFIG_THERMAL_GOV_FAIR_SHARE is not set CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_BANG_BANG=y CONFIG_THERMAL_GOV_USER_SPACE=y # CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set # CONFIG_CLOCK_THERMAL is not set # CONFIG_DEVFREQ_THERMAL is not set # CONFIG_THERMAL_EMULATION is not set CONFIG_INTEL_POWERCLAMP=y CONFIG_X86_PKG_TEMP_THERMAL=y CONFIG_INTEL_SOC_DTS_IOSF_CORE=y CONFIG_INTEL_SOC_DTS_THERMAL=m # # ACPI INT340X thermal drivers # CONFIG_INT340X_THERMAL=y CONFIG_ACPI_THERMAL_REL=y # CONFIG_INT3406_THERMAL is not set # CONFIG_INTEL_BXT_PMIC_THERMAL is not set # CONFIG_INTEL_PCH_THERMAL is not set # CONFIG_GENERIC_ADC_THERMAL is not set # # Trusty # CONFIG_TRUSTY=y CONFIG_TRUSTY_LOG=y CONFIG_TRUSTY_VIRTIO=y CONFIG_TRUSTY_VIRTIO_IPC=y CONFIG_TRUSTY_BACKUP_TIMER=m CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y # CONFIG_WATCHDOG_SYSFS is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set # CONFIG_WDAT_WDT is not set # CONFIG_XILINX_WATCHDOG is not set # CONFIG_ZIIRAVE_WATCHDOG is not set # CONFIG_CADENCE_WATCHDOG is not set # CONFIG_DW_WATCHDOG is not set # CONFIG_MAX63XX_WATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_EBC_C384_WDT is not set # CONFIG_F71808E_WDT is not set # CONFIG_SP5100_TCO is not set # CONFIG_SBC_FITPC2_WATCHDOG is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_IE6XX_WDT is not set CONFIG_ITCO_WDT=y # CONFIG_ITCO_NO_NMI_INTR is not set # CONFIG_ITCO_VENDOR_SUPPORT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_IT87_WDT is not set # CONFIG_HP_WATCHDOG is not set # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_NV_TCO is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC_SCH311X_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_VIA_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # CONFIG_INTEL_MEI_WDT is not set # CONFIG_NI903X_WDT is not set # CONFIG_NIC7018_WDT is not set # CONFIG_MEN_A21_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # # Watchdog Pretimeout Governors # # CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set CONFIG_SSB_POSSIBLE=y # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y CONFIG_BCMA=m CONFIG_BCMA_HOST_PCI_POSSIBLE=y CONFIG_BCMA_HOST_PCI=y # CONFIG_BCMA_HOST_SOC is not set CONFIG_BCMA_DRIVER_PCI=y # CONFIG_BCMA_DRIVER_GMAC_CMN is not set # CONFIG_BCMA_DRIVER_GPIO is not set # CONFIG_BCMA_DEBUG is not set # # Multifunction device drivers # CONFIG_MFD_CORE=y # CONFIG_MFD_AS3711 is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_AAT2870_CORE is not set # CONFIG_MFD_BCM590XX is not set # CONFIG_MFD_BD9571MWV is not set # CONFIG_MFD_AXP20X_I2C is not set # CONFIG_MFD_CROS_EC is not set # CONFIG_MFD_MADERA is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_DA9052_SPI is not set # CONFIG_MFD_DA9052_I2C is not set # CONFIG_MFD_DA9055 is not set # CONFIG_MFD_DA9062 is not set # CONFIG_MFD_DA9063 is not set # CONFIG_MFD_DA9150 is not set # CONFIG_MFD_DLN2 is not set # CONFIG_MFD_MC13XXX_SPI is not set # CONFIG_MFD_MC13XXX_I2C is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_HTC_I2CPLD is not set # CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set CONFIG_LPC_ICH=y CONFIG_LPC_SCH=y CONFIG_INTEL_SOC_PMIC=y CONFIG_INTEL_SOC_PMIC_BXTWC=y # CONFIG_INTEL_SOC_PMIC_CHTWC is not set # CONFIG_INTEL_SOC_PMIC_CHTDC_TI is not set CONFIG_MFD_INTEL_LPSS=y CONFIG_MFD_INTEL_LPSS_ACPI=y CONFIG_MFD_INTEL_LPSS_PCI=y # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_KEMPLD is not set # CONFIG_MFD_88PM800 is not set # CONFIG_MFD_88PM805 is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_MAX14577 is not set # CONFIG_MFD_MAX77693 is not set # CONFIG_MFD_MAX77843 is not set # CONFIG_MFD_MAX8907 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_MT6397 is not set # CONFIG_MFD_MENF21BMC is not set # CONFIG_EZX_PCAP is not set # CONFIG_MFD_VIPERBOARD is not set # CONFIG_MFD_RETU is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_RT5033 is not set # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_MFD_SKY81452 is not set # CONFIG_MFD_SMSC is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_SYSCON is not set # CONFIG_MFD_TI_AM335X_TSCADC is not set # CONFIG_MFD_LP3943 is not set # CONFIG_MFD_LP8788 is not set # CONFIG_MFD_TI_LMU is not set # CONFIG_MFD_PALMAS is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65086 is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS68470 is not set # CONFIG_MFD_TI_LP873X is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_MFD_TPS65912_SPI is not set # CONFIG_MFD_TPS80031 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_TWL6040_CORE is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_VX855 is not set CONFIG_MFD_ARIZONA=y CONFIG_MFD_ARIZONA_I2C=m # CONFIG_MFD_ARIZONA_SPI is not set # CONFIG_MFD_CS47L24 is not set # CONFIG_MFD_WM5102 is not set CONFIG_MFD_WM5110=y # CONFIG_MFD_WM8997 is not set CONFIG_MFD_WM8998=y # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM831X_SPI is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set # CONFIG_REGULATOR_88PG86X is not set # CONFIG_REGULATOR_ACT8865 is not set # CONFIG_REGULATOR_AD5398 is not set # CONFIG_REGULATOR_ARIZONA_LDO1 is not set # CONFIG_REGULATOR_ARIZONA_MICSUPP is not set # CONFIG_REGULATOR_DA9210 is not set # CONFIG_REGULATOR_DA9211 is not set # CONFIG_REGULATOR_FAN53555 is not set CONFIG_REGULATOR_GPIO=y # CONFIG_REGULATOR_ISL9305 is not set # CONFIG_REGULATOR_ISL6271A is not set # CONFIG_REGULATOR_LP3971 is not set # CONFIG_REGULATOR_LP3972 is not set # CONFIG_REGULATOR_LP872X is not set # CONFIG_REGULATOR_LP8755 is not set # CONFIG_REGULATOR_LTC3589 is not set # CONFIG_REGULATOR_LTC3676 is not set # CONFIG_REGULATOR_MAX1586 is not set # CONFIG_REGULATOR_MAX8649 is not set # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8952 is not set # CONFIG_REGULATOR_MT6311 is not set # CONFIG_REGULATOR_PFUZE100 is not set # CONFIG_REGULATOR_PV88060 is not set # CONFIG_REGULATOR_PV88080 is not set # CONFIG_REGULATOR_PV88090 is not set # CONFIG_REGULATOR_PWM is not set # CONFIG_REGULATOR_TPS51632 is not set # CONFIG_REGULATOR_TPS62360 is not set # CONFIG_REGULATOR_TPS65023 is not set # CONFIG_REGULATOR_TPS6507X is not set # CONFIG_REGULATOR_TPS65132 is not set # CONFIG_REGULATOR_TPS6524X is not set CONFIG_RC_CORE=y CONFIG_RC_MAP=y # CONFIG_LIRC is not set CONFIG_RC_DECODERS=y CONFIG_IR_NEC_DECODER=y CONFIG_IR_RC5_DECODER=y CONFIG_IR_RC6_DECODER=y CONFIG_IR_JVC_DECODER=y CONFIG_IR_SONY_DECODER=y CONFIG_IR_SANYO_DECODER=y CONFIG_IR_SHARP_DECODER=y CONFIG_IR_MCE_KBD_DECODER=y CONFIG_IR_XMP_DECODER=y # CONFIG_IR_IMON_DECODER is not set # CONFIG_RC_DEVICES is not set CONFIG_MEDIA_SUPPORT=y # # Multimedia core support # CONFIG_MEDIA_CAMERA_SUPPORT=y # CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set # CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set CONFIG_MEDIA_RADIO_SUPPORT=y # CONFIG_MEDIA_SDR_SUPPORT is not set # CONFIG_MEDIA_CEC_SUPPORT is not set CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_V4L2=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set # CONFIG_VIDEO_PCI_SKELETON is not set CONFIG_V4L2_FWNODE=m # # Media drivers # CONFIG_MEDIA_USB_SUPPORT=y # # Webcam devices # CONFIG_USB_VIDEO_CLASS=y CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y # CONFIG_USB_GSPCA is not set # CONFIG_USB_PWC is not set # CONFIG_VIDEO_CPIA2 is not set # CONFIG_USB_ZR364XX is not set # CONFIG_USB_STKWEBCAM is not set # CONFIG_USB_S2255 is not set # CONFIG_VIDEO_USBTV is not set # # Webcam, TV (analog/digital) USB devices # # CONFIG_VIDEO_EM28XX is not set CONFIG_MEDIA_PCI_SUPPORT=y # # Media capture support # # CONFIG_VIDEO_SOLO6X10 is not set # CONFIG_VIDEO_TW5864 is not set # CONFIG_VIDEO_TW68 is not set # CONFIG_VIDEO_TW686X is not set CONFIG_VIDEO_INTEL_IPU=y CONFIG_VIDEO_INTEL_IPU4=y # CONFIG_VIDEO_INTEL_IPU4P is not set CONFIG_VIDEO_INTEL_IPU_SOC=y CONFIG_VIDEO_INTEL_IPU_FW_LIB=y # CONFIG_VIDEO_INTEL_IPU_WERROR is not set # CONFIG_VIDEO_IPU3_CIO2 is not set CONFIG_V4L_PLATFORM_DRIVERS=y # CONFIG_VIDEO_CAFE_CCIC is not set # CONFIG_VIDEO_CADENCE is not set # CONFIG_SOC_CAMERA is not set # CONFIG_INTEL_IPU4_BXT_P_PDATA is not set CONFIG_INTEL_IPU4_BXT_GP_PDATA=y # CONFIG_INTEL_IPU4_AR023Z is not set # CONFIG_INTEL_IPU4_OV13860 is not set # CONFIG_INTEL_IPU4_OV9281 is not set # CONFIG_INTEL_IPU4_OV10635 is not set # CONFIG_INTEL_IPU4_AR0231AT is not set # CONFIG_INTEL_IPU4_OV10640 is not set # CONFIG_INTEL_IPU4_ADV7481 is not set # CONFIG_INTEL_IPU4_ADV7481_EVAL is not set # CONFIG_V4L_MEM2MEM_DRIVERS is not set # CONFIG_V4L_TEST_DRIVERS is not set # # Supported MMC/SDIO adapters # CONFIG_RADIO_ADAPTERS=y # CONFIG_RADIO_SI470X is not set # CONFIG_RADIO_SI4713 is not set # CONFIG_USB_MR800 is not set # CONFIG_USB_DSBR is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_SHARK is not set # CONFIG_RADIO_SHARK2 is not set # CONFIG_USB_KEENE is not set # CONFIG_USB_RAREMONO is not set # CONFIG_USB_MA901 is not set # CONFIG_RADIO_TEA5764 is not set # CONFIG_RADIO_SAA7706H is not set # CONFIG_RADIO_TEF6862 is not set # CONFIG_RADIO_WL1273 is not set # # Texas Instruments WL128x FM driver (ST based) # # CONFIG_CYPRESS_FIRMWARE is not set CONFIG_VIDEOBUF2_CORE=y CONFIG_VIDEOBUF2_V4L2=y CONFIG_VIDEOBUF2_MEMOPS=y CONFIG_VIDEOBUF2_DMA_CONTIG=y CONFIG_VIDEOBUF2_VMALLOC=y CONFIG_VIDEOBUF2_DMA_SG=m # # Media ancillary drivers (tuners, sensors, i2c, spi, frontends) # # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set CONFIG_MEDIA_ATTACH=y CONFIG_VIDEO_IR_I2C=y # # I2C Encoders, decoders, sensors and other helper chips # # # Audio decoders, processors and mixers # # CONFIG_VIDEO_TVAUDIO is not set # CONFIG_VIDEO_TDA7432 is not set # CONFIG_VIDEO_TDA9840 is not set # CONFIG_VIDEO_TDA1997X is not set # CONFIG_VIDEO_TEA6415C is not set # CONFIG_VIDEO_TEA6420 is not set # CONFIG_VIDEO_MSP3400 is not set # CONFIG_VIDEO_CS3308 is not set # CONFIG_VIDEO_CS5345 is not set # CONFIG_VIDEO_CS53L32A is not set # CONFIG_VIDEO_TLV320AIC23B is not set # CONFIG_VIDEO_UDA1342 is not set # CONFIG_VIDEO_WM8775 is not set # CONFIG_VIDEO_WM8739 is not set # CONFIG_VIDEO_VP27SMPX is not set # CONFIG_VIDEO_SONY_BTF_MPX is not set # # RDS decoders # # CONFIG_VIDEO_SAA6588 is not set # # Video decoders # # CONFIG_VIDEO_ADV7180 is not set # CONFIG_VIDEO_ADV7183 is not set # CONFIG_VIDEO_ADV7604 is not set # CONFIG_VIDEO_ADV7842 is not set # CONFIG_VIDEO_BT819 is not set # CONFIG_VIDEO_BT856 is not set # CONFIG_VIDEO_BT866 is not set # CONFIG_VIDEO_KS0127 is not set # CONFIG_VIDEO_ML86V7667 is not set # CONFIG_VIDEO_AD5820 is not set # CONFIG_VIDEO_AK7375 is not set # CONFIG_VIDEO_DW9714 is not set # CONFIG_VIDEO_DW9807_VCM is not set # CONFIG_VIDEO_SAA7110 is not set # CONFIG_VIDEO_SAA711X is not set # CONFIG_VIDEO_TC358743 is not set # CONFIG_VIDEO_TVP514X is not set # CONFIG_VIDEO_TVP5150 is not set # CONFIG_VIDEO_TVP7002 is not set # CONFIG_VIDEO_TW2804 is not set # CONFIG_VIDEO_TW9903 is not set # CONFIG_VIDEO_TW9906 is not set # CONFIG_VIDEO_TW9910 is not set # CONFIG_VIDEO_VPX3220 is not set # # Video and audio decoders # # CONFIG_VIDEO_SAA717X is not set # CONFIG_VIDEO_CX25840 is not set # # Video encoders # # CONFIG_VIDEO_SAA7127 is not set # CONFIG_VIDEO_SAA7185 is not set # CONFIG_VIDEO_ADV7170 is not set # CONFIG_VIDEO_ADV7175 is not set # CONFIG_VIDEO_ADV7343 is not set # CONFIG_VIDEO_ADV7393 is not set # CONFIG_VIDEO_ADV7511 is not set # CONFIG_VIDEO_AD9389B is not set # CONFIG_VIDEO_AK881X is not set # CONFIG_VIDEO_THS8200 is not set # # Camera sensor devices # CONFIG_VIDEO_SMIAPP_PLL=m # CONFIG_VIDEO_IMX258 is not set # CONFIG_VIDEO_IMX274 is not set # CONFIG_VIDEO_OV2640 is not set # CONFIG_VIDEO_OV2659 is not set # CONFIG_VIDEO_OV2680 is not set # CONFIG_VIDEO_OV2685 is not set # CONFIG_VIDEO_OV5647 is not set # CONFIG_VIDEO_OV6650 is not set # CONFIG_VIDEO_OV5670 is not set # CONFIG_VIDEO_OV5695 is not set # CONFIG_VIDEO_OV7251 is not set # CONFIG_VIDEO_OV772X is not set # CONFIG_VIDEO_OV7640 is not set # CONFIG_VIDEO_OV7670 is not set # CONFIG_VIDEO_OV7740 is not set # CONFIG_VIDEO_OV9650 is not set # CONFIG_VIDEO_OV13858 is not set # CONFIG_VIDEO_VS6624 is not set # CONFIG_VIDEO_MT9M032 is not set # CONFIG_VIDEO_MT9M111 is not set # CONFIG_VIDEO_MT9P031 is not set # CONFIG_VIDEO_MT9T001 is not set # CONFIG_VIDEO_MT9T112 is not set # CONFIG_VIDEO_MT9V011 is not set # CONFIG_VIDEO_MT9V032 is not set # CONFIG_VIDEO_MT9V111 is not set # CONFIG_VIDEO_SR030PC30 is not set # CONFIG_VIDEO_NOON010PC30 is not set # CONFIG_VIDEO_M5MOLS is not set # CONFIG_VIDEO_RJ54N1 is not set # CONFIG_VIDEO_S5K6AA is not set # CONFIG_VIDEO_S5K6A3 is not set # CONFIG_VIDEO_S5K4ECGX is not set # CONFIG_VIDEO_S5K5BAF is not set CONFIG_VIDEO_SMIAPP=m # CONFIG_VIDEO_ET8EK8 is not set CONFIG_VIDEO_CRLMODULE=y # CONFIG_VIDEO_S5C73M3 is not set # # Flash devices # # CONFIG_VIDEO_ADP1653 is not set # CONFIG_VIDEO_LM3560 is not set # CONFIG_VIDEO_LM3646 is not set # # Video improvement chips # # CONFIG_VIDEO_UPD64031A is not set # CONFIG_VIDEO_UPD64083 is not set # # Audio/Video compression chips # # CONFIG_VIDEO_SAA6752HS is not set # # SDR tuner chips # # # Miscellaneous helper chips # # CONFIG_VIDEO_THS7303 is not set # CONFIG_VIDEO_M52790 is not set # CONFIG_VIDEO_I2C is not set # CONFIG_VIDEO_TI964 is not set # CONFIG_VIDEO_TI960 is not set # CONFIG_VIDEO_MAX9286 is not set # # Sensors used on soc_camera driver # # # SPI helper chips # # CONFIG_VIDEO_GS1662 is not set # # Media SPI Adapters # CONFIG_MEDIA_TUNER=y # # Customize TV tuners # # CONFIG_MEDIA_TUNER_SIMPLE is not set CONFIG_MEDIA_TUNER_TDA18250=m # CONFIG_MEDIA_TUNER_TDA8290 is not set # CONFIG_MEDIA_TUNER_TDA827X is not set # CONFIG_MEDIA_TUNER_TDA18271 is not set # CONFIG_MEDIA_TUNER_TDA9887 is not set # CONFIG_MEDIA_TUNER_TEA5761 is not set # CONFIG_MEDIA_TUNER_TEA5767 is not set # CONFIG_MEDIA_TUNER_MSI001 is not set # CONFIG_MEDIA_TUNER_MT20XX is not set # CONFIG_MEDIA_TUNER_MT2060 is not set # CONFIG_MEDIA_TUNER_MT2063 is not set # CONFIG_MEDIA_TUNER_MT2266 is not set # CONFIG_MEDIA_TUNER_MT2131 is not set # CONFIG_MEDIA_TUNER_QT1010 is not set # CONFIG_MEDIA_TUNER_XC2028 is not set # CONFIG_MEDIA_TUNER_XC5000 is not set # CONFIG_MEDIA_TUNER_XC4000 is not set # CONFIG_MEDIA_TUNER_MXL5005S is not set # CONFIG_MEDIA_TUNER_MXL5007T is not set # CONFIG_MEDIA_TUNER_MC44S803 is not set # CONFIG_MEDIA_TUNER_MAX2165 is not set # CONFIG_MEDIA_TUNER_TDA18218 is not set # CONFIG_MEDIA_TUNER_FC0011 is not set # CONFIG_MEDIA_TUNER_FC0012 is not set # CONFIG_MEDIA_TUNER_FC0013 is not set # CONFIG_MEDIA_TUNER_TDA18212 is not set # CONFIG_MEDIA_TUNER_E4000 is not set # CONFIG_MEDIA_TUNER_FC2580 is not set # CONFIG_MEDIA_TUNER_M88RS6000T is not set # CONFIG_MEDIA_TUNER_TUA9001 is not set # CONFIG_MEDIA_TUNER_SI2157 is not set # CONFIG_MEDIA_TUNER_IT913X is not set # CONFIG_MEDIA_TUNER_R820T is not set # CONFIG_MEDIA_TUNER_MXL301RF is not set # CONFIG_MEDIA_TUNER_QM1D1C0042 is not set CONFIG_MEDIA_TUNER_QM1D1B0004=m # # Customise DVB Frontends # # # Tools to develop new frontends # # # Graphics support # CONFIG_AGP=y # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_SIS is not set # CONFIG_AGP_VIA is not set CONFIG_INTEL_GTT=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y CONFIG_DRM=y CONFIG_DRM_MIPI_DSI=y # CONFIG_DRM_DP_AUX_CHARDEV is not set # CONFIG_DRM_DEBUG_MM is not set # CONFIG_DRM_DEBUG_SELFTEST is not set CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100 # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set # CONFIG_DRM_DP_CEC is not set CONFIG_DRM_TTM=y # # I2C encoder or helper chips # # CONFIG_DRM_I2C_CH7006 is not set # CONFIG_DRM_I2C_SIL164 is not set # CONFIG_DRM_I2C_NXP_TDA998X is not set # CONFIG_DRM_I2C_NXP_TDA9950 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_AMDGPU is not set # # ACP (Audio CoProcessor) Configuration # # # AMD Library routines # # CONFIG_DRM_NOUVEAU is not set CONFIG_DRM_I915=y # CONFIG_DRM_I915_ALPHA_SUPPORT is not set CONFIG_DRM_I915_CAPTURE_ERROR=y CONFIG_DRM_I915_COMPRESS_ERROR=y # CONFIG_DRM_I915_MEMTRACK is not set CONFIG_DRM_I915_USERPTR=y # CONFIG_DRM_I915_GVT is not set CONFIG_DRM_I915_LOAD_ASYNC_SUPPORT=y # # drm/i915 Debugging # # CONFIG_DRM_I915_WERROR is not set # CONFIG_DRM_I915_DEBUG is not set # CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set # CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set # CONFIG_DRM_I915_DEBUG_GUC is not set # CONFIG_DRM_I915_SELFTEST is not set CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS=y # CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set # CONFIG_DRM_VGEM is not set # CONFIG_DRM_VKMS is not set # CONFIG_DRM_VMWGFX is not set # CONFIG_DRM_GMA500 is not set # CONFIG_DRM_UDL is not set # CONFIG_DRM_AST is not set # CONFIG_DRM_MGAG200 is not set # CONFIG_DRM_CIRRUS_QEMU is not set # CONFIG_DRM_QXL is not set CONFIG_DRM_BOCHS=y # CONFIG_DRM_VIRTIO_GPU is not set CONFIG_DRM_PANEL=y # # Display Panels # # CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN is not set CONFIG_DRM_BRIDGE=y CONFIG_DRM_PANEL_BRIDGE=y # # Display Interface Bridges # # CONFIG_DRM_ANALOGIX_ANX78XX is not set # CONFIG_DRM_HISI_HIBMC is not set # CONFIG_DRM_TINYDRM is not set # CONFIG_DRM_LEGACY is not set CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y # # Frame buffer Devices # CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_CMDLINE=y CONFIG_FB_NOTIFY=y CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_OPENCORES is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I740 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_IBM_GXT4500 is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_FB_SIMPLE=y # CONFIG_FB_SM712 is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_LCD_L4F00242T03 is not set # CONFIG_LCD_LMS283GF05 is not set # CONFIG_LCD_LTV350QV is not set # CONFIG_LCD_ILI922X is not set # CONFIG_LCD_ILI9320 is not set # CONFIG_LCD_TDO24M is not set # CONFIG_LCD_VGG2432A4 is not set CONFIG_LCD_PLATFORM=m # CONFIG_LCD_S6E63M0 is not set # CONFIG_LCD_LD9040 is not set # CONFIG_LCD_AMS369FG06 is not set # CONFIG_LCD_LMS501KF03 is not set # CONFIG_LCD_HX8357 is not set # CONFIG_LCD_OTM3225A is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=m # CONFIG_BACKLIGHT_PWM is not set # CONFIG_BACKLIGHT_APPLE is not set # CONFIG_BACKLIGHT_PM8941_WLED is not set # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set CONFIG_BACKLIGHT_LM3630A=m # CONFIG_BACKLIGHT_LM3639 is not set # CONFIG_BACKLIGHT_LP855X is not set CONFIG_BACKLIGHT_GPIO=m CONFIG_BACKLIGHT_LV5207LP=m CONFIG_BACKLIGHT_BD6107=m # CONFIG_BACKLIGHT_ARCXCNN is not set CONFIG_HDMI=y # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_DUMMY_CONSOLE_COLUMNS=80 CONFIG_DUMMY_CONSOLE_ROWS=25 # CONFIG_FRAMEBUFFER_CONSOLE is not set # CONFIG_LOGO is not set CONFIG_SOUND=y CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_HWDEP=m CONFIG_SND_SEQ_DEVICE=y CONFIG_SND_RAWMIDI=y CONFIG_SND_COMPRESS_OFFLOAD=y CONFIG_SND_JACK=y CONFIG_SND_JACK_INPUT_DEV=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_PCM_TIMER=y CONFIG_SND_HRTIMER=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_MAX_CARDS=32 CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_PROC_FS=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y # CONFIG_SND_DEBUG is not set CONFIG_SND_DMA_SGBUF=y CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_SEQ_MIDI_EVENT=m CONFIG_SND_SEQ_MIDI=m CONFIG_SND_DRIVERS=y # CONFIG_SND_PCSP is not set CONFIG_SND_DUMMY=m # CONFIG_SND_ALOOP is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set CONFIG_SND_PCI=y # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ASIHPI is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CTXFI is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_INDIGOIOX is not set # CONFIG_SND_INDIGODJX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_LOLA is not set # CONFIG_SND_LX6464ES is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SE6X is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # # HD-Audio # # CONFIG_SND_HDA_INTEL is not set CONFIG_SND_HDA_CORE=m CONFIG_SND_HDA_DSP_LOADER=y CONFIG_SND_HDA_COMPONENT=y CONFIG_SND_HDA_I915=y CONFIG_SND_HDA_EXT_CORE=m CONFIG_SND_HDA_PREALLOC_SIZE=64 # CONFIG_SND_SPI is not set CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m # CONFIG_SND_USB_UA101 is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # CONFIG_SND_USB_US122L is not set # CONFIG_SND_USB_6FIRE is not set CONFIG_SND_USB_HIFACE=m # CONFIG_SND_BCD2000 is not set # CONFIG_SND_USB_POD is not set # CONFIG_SND_USB_PODHD is not set # CONFIG_SND_USB_TONEPORT is not set # CONFIG_SND_USB_VARIAX is not set CONFIG_SND_SOC=y CONFIG_SND_SOC_COMPRESS=y CONFIG_SND_SOC_TOPOLOGY=y CONFIG_SND_SOC_ACPI=y # CONFIG_SND_SOC_AMD_ACP is not set # CONFIG_SND_ATMEL_SOC is not set # CONFIG_SND_DESIGNWARE_I2S is not set # # SoC Audio for Freescale CPUs # # # Common SoC Audio options for Freescale CPUs: # # CONFIG_SND_SOC_FSL_ASRC is not set # CONFIG_SND_SOC_FSL_SAI is not set # CONFIG_SND_SOC_FSL_SSI is not set # CONFIG_SND_SOC_FSL_SPDIF is not set # CONFIG_SND_SOC_FSL_ESAI is not set # CONFIG_SND_SOC_IMX_AUDMUX is not set # CONFIG_SND_I2S_HI6210_I2S is not set # CONFIG_SND_SOC_IMG is not set CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y CONFIG_SND_SST_IPC=y CONFIG_SND_SST_IPC_ACPI=y CONFIG_SND_SOC_INTEL_SST=m # CONFIG_SND_SOC_INTEL_HASWELL is not set CONFIG_SND_SST_ATOM_HIFI2_PLATFORM=y # CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI is not set CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI=y CONFIG_SND_SOC_INTEL_SKYLAKE=m CONFIG_SND_SOC_ACPI_INTEL_MATCH=y # CONFIG_SND_SOC_INTEL_CNL_FPGA is not set # CONFIG_SND_SOC_SDW_AGGM1M2 is not set CONFIG_SND_SOC_INTEL_MACH=y # CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH is not set # CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH is not set # CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH is not set # CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH is not set # CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH is not set # CONFIG_SND_SOC_INTEL_CHT_BSW_NAU8824_MACH is not set # CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH is not set # CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH is not set # CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set # CONFIG_SND_SOC_INTEL_SKL_RT286_MACH is not set # CONFIG_SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH is not set # CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH is not set # CONFIG_SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH is not set # CONFIG_SND_SOC_INTEL_BXT_RT298_MACH is not set # CONFIG_SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH is not set # CONFIG_SND_SOC_INTEL_KBL_RT5663_RT5514_MAX98927_MACH is not set # CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98357A_MACH is not set # CONFIG_SND_SOC_INTEL_GLK_RT5682_MAX98357A_MACH is not set # CONFIG_SND_SOC_INTEL_CNL_CS42L42_MACH is not set # CONFIG_SND_SOC_INTEL_CNL_RT700_MACH is not set # CONFIG_SND_SOC_INTEL_CNL_SVFPGA_MACH is not set # CONFIG_SND_SOC_INTEL_CNL_RT274_MACH is not set # CONFIG_SND_SOC_INTEL_ICL_RT274_MACH is not set CONFIG_SND_SOC_INTEL_BXT_TDF8532_MACH=m # CONFIG_SND_SOC_INTEL_BXT_ULL_MACH is not set # CONFIG_SND_SOC_INTEL_KBLR_RT298_MACH is not set # CONFIG_SND_SOC_INTEL_BXTP_IVI_RSE_MACH is not set # CONFIG_SND_SOC_INTEL_BXTP_IVI_HU_MACH is not set # CONFIG_SND_SOC_INTEL_BXTP_IVI_M3_MACH is not set # CONFIG_SND_SOC_INTEL_BXTP_IVI_GENERIC_MACH is not set # # STMicroelectronics STM32 SOC audio support # # CONFIG_SND_SOC_XTFPGA_I2S is not set # CONFIG_ZX_TDM is not set CONFIG_SND_SOC_I2C_AND_SPI=y # # CODEC drivers # # CONFIG_SND_SOC_AC97_CODEC is not set # CONFIG_SND_SOC_ADAU1701 is not set # CONFIG_SND_SOC_ADAU1761_I2C is not set # CONFIG_SND_SOC_ADAU1761_SPI is not set # CONFIG_SND_SOC_ADAU7002 is not set # CONFIG_SND_SOC_AK4104 is not set # CONFIG_SND_SOC_AK4458 is not set # CONFIG_SND_SOC_AK4554 is not set # CONFIG_SND_SOC_AK4613 is not set # CONFIG_SND_SOC_AK4642 is not set # CONFIG_SND_SOC_AK5386 is not set # CONFIG_SND_SOC_AK5558 is not set # CONFIG_SND_SOC_ALC5623 is not set # CONFIG_SND_SOC_BD28623 is not set # CONFIG_SND_SOC_BT_SCO is not set # CONFIG_SND_SOC_CS35L32 is not set # CONFIG_SND_SOC_CS35L33 is not set # CONFIG_SND_SOC_CS35L34 is not set # CONFIG_SND_SOC_CS35L35 is not set # CONFIG_SND_SOC_CS42L42 is not set # CONFIG_SND_SOC_SVFPGA is not set # CONFIG_SND_SOC_SVFPGA_SDW is not set # CONFIG_SND_SOC_SVFPGA_I2C is not set # CONFIG_SND_SOC_CS42L51_I2C is not set # CONFIG_SND_SOC_CS42L52 is not set # CONFIG_SND_SOC_CS42L56 is not set # CONFIG_SND_SOC_CS42L73 is not set # CONFIG_SND_SOC_CS4265 is not set # CONFIG_SND_SOC_CS4270 is not set # CONFIG_SND_SOC_CS4271_I2C is not set # CONFIG_SND_SOC_CS4271_SPI is not set # CONFIG_SND_SOC_CS42XX8_I2C is not set # CONFIG_SND_SOC_CS43130 is not set # CONFIG_SND_SOC_CS4349 is not set # CONFIG_SND_SOC_CS53L30 is not set # CONFIG_SND_SOC_ES7134 is not set # CONFIG_SND_SOC_ES7241 is not set # CONFIG_SND_SOC_ES8316 is not set # CONFIG_SND_SOC_ES8328_I2C is not set # CONFIG_SND_SOC_ES8328_SPI is not set # CONFIG_SND_SOC_GTM601 is not set # CONFIG_SND_SOC_INNO_RK3036 is not set # CONFIG_SND_SOC_MAX98504 is not set # CONFIG_SND_SOC_MAX9867 is not set # CONFIG_SND_SOC_MAX98927 is not set # CONFIG_SND_SOC_MAX98373 is not set # CONFIG_SND_SOC_MAX9860 is not set # CONFIG_SND_SOC_MSM8916_WCD_DIGITAL is not set # CONFIG_SND_SOC_PCM1681 is not set # CONFIG_SND_SOC_PCM1789_I2C is not set # CONFIG_SND_SOC_PCM179X_I2C is not set # CONFIG_SND_SOC_PCM179X_SPI is not set # CONFIG_SND_SOC_PCM186X_I2C is not set # CONFIG_SND_SOC_PCM186X_SPI is not set # CONFIG_SND_SOC_PCM3168A_I2C is not set # CONFIG_SND_SOC_PCM3168A_SPI is not set # CONFIG_SND_SOC_PCM512x_I2C is not set # CONFIG_SND_SOC_PCM512x_SPI is not set # CONFIG_SND_SOC_RT5616 is not set # CONFIG_SND_SOC_RT5631 is not set # CONFIG_SND_SOC_RT700 is not set # CONFIG_SND_SOC_RT700_SDW is not set # CONFIG_SND_SOC_SGTL5000 is not set # CONFIG_SND_SOC_SIMPLE_AMPLIFIER is not set # CONFIG_SND_SOC_SIRF_AUDIO_CODEC is not set # CONFIG_SND_SOC_SPDIF is not set # CONFIG_SND_SOC_SSM2305 is not set # CONFIG_SND_SOC_SSM2602_SPI is not set # CONFIG_SND_SOC_SSM2602_I2C is not set # CONFIG_SND_SOC_SSM4567 is not set # CONFIG_SND_SOC_STA32X is not set # CONFIG_SND_SOC_STA350 is not set # CONFIG_SND_SOC_STI_SAS is not set # CONFIG_SND_SOC_TAS2552 is not set # CONFIG_SND_SOC_TAS5086 is not set # CONFIG_SND_SOC_TAS571X is not set # CONFIG_SND_SOC_TAS5720 is not set # CONFIG_SND_SOC_TAS6424 is not set # CONFIG_SND_SOC_TDA7419 is not set CONFIG_SND_SOC_TDF8532=m # CONFIG_SND_SOC_TFA9879 is not set # CONFIG_SND_SOC_TLV320AIC23_I2C is not set # CONFIG_SND_SOC_TLV320AIC23_SPI is not set # CONFIG_SND_SOC_TLV320AIC31XX is not set # CONFIG_SND_SOC_TLV320AIC32X4_I2C is not set # CONFIG_SND_SOC_TLV320AIC32X4_SPI is not set # CONFIG_SND_SOC_TLV320AIC3X is not set # CONFIG_SND_SOC_TS3A227E is not set # CONFIG_SND_SOC_TSCS42XX is not set # CONFIG_SND_SOC_TSCS454 is not set # CONFIG_SND_SOC_WM8510 is not set # CONFIG_SND_SOC_WM8523 is not set # CONFIG_SND_SOC_WM8524 is not set # CONFIG_SND_SOC_WM8580 is not set # CONFIG_SND_SOC_WM8711 is not set # CONFIG_SND_SOC_WM8728 is not set # CONFIG_SND_SOC_WM8731 is not set # CONFIG_SND_SOC_WM8737 is not set # CONFIG_SND_SOC_WM8741 is not set # CONFIG_SND_SOC_WM8750 is not set # CONFIG_SND_SOC_WM8753 is not set # CONFIG_SND_SOC_WM8770 is not set # CONFIG_SND_SOC_WM8776 is not set # CONFIG_SND_SOC_WM8782 is not set # CONFIG_SND_SOC_WM8804_I2C is not set # CONFIG_SND_SOC_WM8804_SPI is not set # CONFIG_SND_SOC_WM8903 is not set # CONFIG_SND_SOC_WM8960 is not set # CONFIG_SND_SOC_WM8962 is not set # CONFIG_SND_SOC_WM8974 is not set # CONFIG_SND_SOC_WM8978 is not set # CONFIG_SND_SOC_WM8985 is not set # CONFIG_SND_SOC_ZX_AUD96P22 is not set # CONFIG_SND_SOC_MAX9759 is not set # CONFIG_SND_SOC_MT6351 is not set # CONFIG_SND_SOC_NAU8540 is not set # CONFIG_SND_SOC_NAU8810 is not set # CONFIG_SND_SOC_NAU8824 is not set # CONFIG_SND_SOC_TPA6130A2 is not set # CONFIG_SND_SIMPLE_CARD is not set CONFIG_SND_X86=y # CONFIG_HDMI_LPE_AUDIO is not set # # HID support # CONFIG_HID=y # CONFIG_HID_BATTERY_STRENGTH is not set CONFIG_HIDRAW=y CONFIG_UHID=y CONFIG_HID_GENERIC=y # # Special HID drivers # CONFIG_HID_A4TECH=y # CONFIG_HID_ACCUTOUCH is not set # CONFIG_HID_ACRUX is not set CONFIG_HID_APPLE=y # CONFIG_HID_APPLEIR is not set # CONFIG_HID_ASUS is not set # CONFIG_HID_AUREAL is not set CONFIG_HID_BELKIN=y # CONFIG_HID_BETOP_FF is not set CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y # CONFIG_HID_CORSAIR is not set # CONFIG_HID_COUGAR is not set # CONFIG_HID_PRODIKEYS is not set # CONFIG_HID_CMEDIA is not set # CONFIG_HID_CP2112 is not set CONFIG_HID_CYPRESS=y # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set # CONFIG_HID_ELAN is not set # CONFIG_HID_ELECOM is not set CONFIG_HID_ELO=m CONFIG_HID_EZKEY=y # CONFIG_HID_GEMBIRD is not set # CONFIG_HID_GFRM is not set # CONFIG_HID_HOLTEK is not set # CONFIG_HID_GOOGLE_HAMMER is not set # CONFIG_HID_GT683R is not set # CONFIG_HID_KEYTOUCH is not set # CONFIG_HID_KYE is not set # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set # CONFIG_HID_GYRATION is not set # CONFIG_HID_ICADE is not set # CONFIG_HID_ITE is not set # CONFIG_HID_JABRA is not set # CONFIG_HID_TWINHAN is not set CONFIG_HID_KENSINGTON=y # CONFIG_HID_LCPOWER is not set # CONFIG_HID_LED is not set # CONFIG_HID_LENOVO is not set CONFIG_HID_LOGITECH=y # CONFIG_HID_LOGITECH_DJ is not set # CONFIG_HID_LOGITECH_HIDPP is not set CONFIG_LOGITECH_FF=y # CONFIG_LOGIRUMBLEPAD2_FF is not set # CONFIG_LOGIG940_FF is not set CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=m # CONFIG_HID_MAYFLASH is not set # CONFIG_HID_REDRAGON is not set CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=y # CONFIG_HID_NTI is not set CONFIG_HID_NTRIG=m # CONFIG_HID_ORTEK is not set # CONFIG_HID_PANTHERLORD is not set # CONFIG_HID_PENMOUNT is not set # CONFIG_HID_PETALYNX is not set # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PLANTRONICS is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_RETRODE is not set # CONFIG_HID_ROCCAT is not set # CONFIG_HID_SAITEK is not set # CONFIG_HID_SAMSUNG is not set # CONFIG_HID_SONY is not set # CONFIG_HID_SPEEDLINK is not set # CONFIG_HID_STEAM is not set # CONFIG_HID_STEELSERIES is not set # CONFIG_HID_SUNPLUS is not set # CONFIG_HID_RMI is not set # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set # CONFIG_HID_TIVO is not set # CONFIG_HID_TOPSEED is not set # CONFIG_HID_THINGM is not set # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_UDRAW_PS3 is not set # CONFIG_HID_WACOM is not set # CONFIG_HID_WIIMOTE is not set CONFIG_HID_XINMO=m # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set CONFIG_HID_SENSOR_HUB=m # CONFIG_HID_SENSOR_CUSTOM_SENSOR is not set # CONFIG_HID_ALPS is not set # # USB HID support # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # I2C HID support # CONFIG_I2C_HID=m # # Intel ISH HID support # # CONFIG_INTEL_ISH_HID is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y CONFIG_USB_PCI=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # # CONFIG_USB_DEFAULT_PERSIST is not set CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_OTG=y # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set CONFIG_USB_OTG_FSM=y # CONFIG_USB_LEDS_TRIGGER_USBPORT is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # CONFIG_USB_C67X00_HCD=y CONFIG_USB_XHCI_HCD=m # CONFIG_USB_XHCI_DBGCAP is not set CONFIG_USB_XHCI_PCI=m CONFIG_USB_XHCI_PLATFORM=m CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_PCI=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set CONFIG_USB_OXU210HP_HCD=y CONFIG_USB_ISP116X_HCD=y CONFIG_USB_FOTG210_HCD=m # CONFIG_USB_MAX3421_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_PCI is not set # CONFIG_USB_OHCI_HCD_PLATFORM is not set CONFIG_USB_UHCI_HCD=y CONFIG_USB_SL811_HCD=y # CONFIG_USB_SL811_HCD_ISO is not set CONFIG_USB_R8A66597_HCD=y # CONFIG_USB_HCD_BCMA is not set # CONFIG_USB_HCD_TEST_MODE is not set # # USB Device Class drivers # CONFIG_USB_ACM=y CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_REALTEK=y CONFIG_REALTEK_AUTOPM=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USBIP_CORE is not set # CONFIG_USB_MUSB_HDRC is not set CONFIG_USB_DWC3=m CONFIG_USB_DWC3_ULPI=y # CONFIG_USB_DWC3_HOST is not set CONFIG_USB_DWC3_GADGET=y # CONFIG_USB_DWC3_DUAL_ROLE is not set # # Platform Glue Driver Support # CONFIG_USB_DWC3_PCI=m CONFIG_USB_DWC3_HAPS=m CONFIG_USB_DWC2=y # CONFIG_USB_DWC2_HOST is not set # # Gadget/Dual-role mode requires USB Gadget support to be enabled # CONFIG_USB_DWC2_PERIPHERAL=y # CONFIG_USB_DWC2_DUAL_ROLE is not set # CONFIG_USB_DWC2_PCI is not set # CONFIG_USB_DWC2_DEBUG is not set # CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set # CONFIG_USB_CHIPIDEA is not set # CONFIG_USB_ISP1760 is not set # # USB port drivers # CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_SIMPLE is not set # CONFIG_USB_SERIAL_AIRCABLE is not set CONFIG_USB_SERIAL_ARK3116=y CONFIG_USB_SERIAL_BELKIN=y CONFIG_USB_SERIAL_CH341=y CONFIG_USB_SERIAL_WHITEHEAT=y CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y CONFIG_USB_SERIAL_CP210X=y # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set CONFIG_USB_SERIAL_FTDI_SIO=y # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set CONFIG_USB_SERIAL_F81232=y # CONFIG_USB_SERIAL_F8153X is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_IUU is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set CONFIG_USB_SERIAL_MCT_U232=y # CONFIG_USB_SERIAL_METRO is not set CONFIG_USB_SERIAL_MOS7720=y CONFIG_USB_SERIAL_MOS7840=y # CONFIG_USB_SERIAL_MXUPORT is not set # CONFIG_USB_SERIAL_NAVMAN is not set CONFIG_USB_SERIAL_PL2303=y CONFIG_USB_SERIAL_OTI6858=y # CONFIG_USB_SERIAL_QCAUX is not set # CONFIG_USB_SERIAL_QUALCOMM is not set CONFIG_USB_SERIAL_SPCP8X5=y # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set # CONFIG_USB_SERIAL_SYMBOL is not set CONFIG_USB_SERIAL_TI=y # CONFIG_USB_SERIAL_CYBERJACK is not set CONFIG_USB_SERIAL_XIRCOM=y CONFIG_USB_SERIAL_WWAN=y CONFIG_USB_SERIAL_OPTION=y # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_OPTICON is not set # CONFIG_USB_SERIAL_XSENS_MT is not set # CONFIG_USB_SERIAL_WISHBONE is not set CONFIG_USB_SERIAL_SSU100=y # CONFIG_USB_SERIAL_QT2 is not set # CONFIG_USB_SERIAL_UPD78F0730 is not set # CONFIG_USB_SERIAL_DEBUG is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_EHSET_TEST_FIXTURE is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set CONFIG_USB_EZUSB_FX2=y # CONFIG_USB_HUB_USB251XB is not set # CONFIG_USB_HSIC_USB3503 is not set # CONFIG_USB_HSIC_USB4604 is not set # CONFIG_USB_LINK_LAYER_TEST is not set # CONFIG_USB_CHAOSKEY is not set # # USB Physical Layer drivers # CONFIG_USB_PHY=y CONFIG_NOP_USB_XCEIV=y # CONFIG_USB_GPIO_VBUS is not set # CONFIG_USB_ISP1301 is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set # CONFIG_USB_GADGET_DEBUG_FS is not set CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 # CONFIG_U_SERIAL_CONSOLE is not set # # USB Peripheral Controller # # CONFIG_USB_FOTG210_UDC is not set # CONFIG_USB_GR_UDC is not set # CONFIG_USB_R8A66597 is not set # CONFIG_USB_PXA27X is not set # CONFIG_USB_MV_UDC is not set # CONFIG_USB_MV_U3D is not set # CONFIG_USB_M66592 is not set # CONFIG_USB_BDC_UDC is not set # CONFIG_USB_AMD5536UDC is not set # CONFIG_USB_NET2272 is not set # CONFIG_USB_NET2280 is not set # CONFIG_USB_GOKU is not set # CONFIG_USB_EG20T is not set # CONFIG_USB_DUMMY_HCD is not set CONFIG_USB_LIBCOMPOSITE=y CONFIG_USB_F_ACM=y CONFIG_USB_U_SERIAL=y CONFIG_USB_U_ETHER=y CONFIG_USB_F_SERIAL=y CONFIG_USB_F_NCM=y CONFIG_USB_F_RNDIS=y CONFIG_USB_F_MASS_STORAGE=y CONFIG_USB_F_FS=y CONFIG_USB_F_MIDI=y CONFIG_USB_F_HID=y CONFIG_USB_F_AUDIO_SRC=y CONFIG_USB_F_ACC=y CONFIG_USB_F_DVCTRACE=y CONFIG_USB_CONFIGFS=y CONFIG_USB_CONFIGFS_SERIAL=y CONFIG_USB_CONFIGFS_ACM=y # CONFIG_USB_CONFIGFS_OBEX is not set CONFIG_USB_CONFIGFS_NCM=y # CONFIG_USB_CONFIGFS_ECM is not set # CONFIG_USB_CONFIGFS_ECM_SUBSET is not set CONFIG_USB_CONFIGFS_RNDIS=y # CONFIG_USB_CONFIGFS_EEM is not set CONFIG_USB_CONFIGFS_MASS_STORAGE=y # CONFIG_USB_CONFIGFS_F_LB_SS is not set CONFIG_USB_CONFIGFS_F_FS=y CONFIG_USB_CONFIGFS_F_ACC=y CONFIG_USB_CONFIGFS_F_AUDIO_SRC=y CONFIG_USB_CONFIGFS_UEVENT=y # CONFIG_USB_CONFIGFS_F_UAC1 is not set # CONFIG_USB_CONFIGFS_F_UAC1_LEGACY is not set # CONFIG_USB_CONFIGFS_F_UAC2 is not set CONFIG_USB_CONFIGFS_F_MIDI=y CONFIG_USB_CONFIGFS_F_HID=y # CONFIG_USB_CONFIGFS_F_UVC is not set # CONFIG_USB_CONFIGFS_F_PRINTER is not set CONFIG_USB_CONFIGFS_F_DVCTRACE=y # CONFIG_USB_ZERO is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ETH is not set # CONFIG_USB_G_NCM is not set # CONFIG_USB_GADGETFS is not set # CONFIG_USB_FUNCTIONFS is not set # CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set # CONFIG_USB_G_ACM_MS is not set # CONFIG_USB_G_MULTI is not set # CONFIG_USB_G_HID is not set # CONFIG_USB_G_DBGP is not set # CONFIG_USB_G_WEBCAM is not set CONFIG_TYPEC=y CONFIG_TYPEC_TCPM=y CONFIG_TYPEC_TCPCI=y # CONFIG_TYPEC_RT1711H is not set # CONFIG_TYPEC_FUSB302 is not set # CONFIG_TYPEC_WCOVE is not set # CONFIG_TYPEC_UCSI is not set # CONFIG_TYPEC_TPS6598X is not set # # USB Type-C Multiplexer/DeMultiplexer Switch support # # CONFIG_TYPEC_MUX_PI3USB30532 is not set # # USB Type-C Alternate Mode drivers # # CONFIG_TYPEC_DP_ALTMODE is not set CONFIG_USB_ROLES_INTEL_XHCI=y # CONFIG_USB_LED_TRIG is not set CONFIG_USB_ULPI_BUS=y CONFIG_USB_ROLE_SWITCH=y # CONFIG_UWB is not set CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=16 # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_DEBUG is not set CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PCI=y # CONFIG_MMC_RICOH_MMC is not set CONFIG_MMC_SDHCI_ACPI=y # CONFIG_MMC_SDHCI_PLTFM is not set # CONFIG_MMC_WBSD is not set # CONFIG_MMC_TIFM_SD is not set # CONFIG_MMC_SPI is not set # CONFIG_MMC_CB710 is not set # CONFIG_MMC_VIA_SDMMC is not set # CONFIG_MMC_VUB300 is not set # CONFIG_MMC_USHC is not set # CONFIG_MMC_USDHI6ROL0 is not set CONFIG_MMC_CQHCI=y # CONFIG_MMC_TOSHIBA_PCI is not set # CONFIG_MMC_MTK is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # CONFIG_LEDS_CLASS_FLASH is not set # CONFIG_LEDS_BRIGHTNESS_HW_CHANGED is not set # # LED drivers # # CONFIG_LEDS_APU is not set # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_LM3642 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_GPIO is not set # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_LP3952 is not set # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set # CONFIG_LEDS_LP5562 is not set # CONFIG_LEDS_LP8501 is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_PCA963X is not set # CONFIG_LEDS_DAC124S085 is not set # CONFIG_LEDS_PWM is not set # CONFIG_LEDS_REGULATOR is not set # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_TCA6507 is not set # CONFIG_LEDS_TLC591XX is not set # CONFIG_LEDS_LM355x is not set # # LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM) # # CONFIG_LEDS_BLINKM is not set # CONFIG_LEDS_MLXCPLD is not set # CONFIG_LEDS_MLXREG is not set # CONFIG_LEDS_USER is not set # CONFIG_LEDS_NIC78BX is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y # CONFIG_LEDS_TRIGGER_TIMER is not set # CONFIG_LEDS_TRIGGER_ONESHOT is not set # CONFIG_LEDS_TRIGGER_DISK is not set # CONFIG_LEDS_TRIGGER_HEARTBEAT is not set # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set # CONFIG_LEDS_TRIGGER_CPU is not set # CONFIG_LEDS_TRIGGER_ACTIVITY is not set # CONFIG_LEDS_TRIGGER_GPIO is not set # CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set # # iptables trigger is under Netfilter config (LED target) # # CONFIG_LEDS_TRIGGER_TRANSIENT is not set # CONFIG_LEDS_TRIGGER_CAMERA is not set # CONFIG_LEDS_TRIGGER_PANIC is not set # CONFIG_LEDS_TRIGGER_NETDEV is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC_ATOMIC_SCRUB=y CONFIG_EDAC_SUPPORT=y # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_MC146818_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC=y CONFIG_RTC_SYSTOHC_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set CONFIG_RTC_NVMEM=y # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_ABB5ZES3 is not set # CONFIG_RTC_DRV_ABX80X is not set # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8523 is not set # CONFIG_RTC_DRV_PCF85063 is not set # CONFIG_RTC_DRV_PCF85363 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8010 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV8803 is not set # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T93 is not set # CONFIG_RTC_DRV_M41T94 is not set # CONFIG_RTC_DRV_DS1302 is not set # CONFIG_RTC_DRV_DS1305 is not set # CONFIG_RTC_DRV_DS1343 is not set # CONFIG_RTC_DRV_DS1347 is not set # CONFIG_RTC_DRV_DS1390 is not set # CONFIG_RTC_DRV_MAX6916 is not set # CONFIG_RTC_DRV_R9701 is not set # CONFIG_RTC_DRV_RX4581 is not set # CONFIG_RTC_DRV_RX6110 is not set # CONFIG_RTC_DRV_RS5C348 is not set # CONFIG_RTC_DRV_MAX6902 is not set # CONFIG_RTC_DRV_PCF2123 is not set # CONFIG_RTC_DRV_MCP795 is not set CONFIG_RTC_I2C_AND_SPI=y # # SPI and I2C RTC drivers # # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_PCF2127 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1685_FAMILY is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_DS2404 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # # CONFIG_RTC_DRV_FTRTC010 is not set # # HID Sensor RTC drivers # # CONFIG_RTC_DRV_HID_SENSOR_TIME is not set CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=y CONFIG_DMA_ACPI=y # CONFIG_ALTERA_MSGDMA is not set CONFIG_INTEL_IDMA64=y # CONFIG_INTEL_IOATDMA is not set # CONFIG_QCOM_HIDMA_MGMT is not set # CONFIG_QCOM_HIDMA is not set CONFIG_DW_DMAC_CORE=y CONFIG_DW_DMAC=y CONFIG_DW_DMAC_PCI=y CONFIG_HSU_DMA=y # # DMA Clients # # CONFIG_ASYNC_TX_DMA is not set # CONFIG_DMATEST is not set # # DMABUF options # CONFIG_SYNC_FILE=y # CONFIG_SW_SYNC is not set # CONFIG_HYPER_DMABUF is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # CONFIG_VFIO is not set CONFIG_VIRT_DRIVERS=y # CONFIG_VBOXGUEST is not set CONFIG_VIRTIO=y CONFIG_VIRTIO_MENU=y # CONFIG_VIRTIO_PCI is not set # CONFIG_VIRTIO_BALLOON is not set # CONFIG_VIRTIO_INPUT is not set # CONFIG_VIRTIO_MMIO is not set # # Microsoft Hyper-V guest support # # CONFIG_HYPERV is not set CONFIG_STAGING=y # CONFIG_PRISM2_USB is not set # CONFIG_COMEDI is not set CONFIG_RTL8192U=m CONFIG_RTLLIB=m CONFIG_RTLLIB_CRYPTO_CCMP=m CONFIG_RTLLIB_CRYPTO_TKIP=m CONFIG_RTLLIB_CRYPTO_WEP=m CONFIG_RTL8192E=m # CONFIG_RTL8723BS is not set CONFIG_R8712U=m # CONFIG_R8188EU is not set # CONFIG_R8822BE is not set # CONFIG_RTS5208 is not set # CONFIG_VT6655 is not set # CONFIG_VT6656 is not set # # IIO staging drivers # # # Accelerometers # # CONFIG_ADIS16203 is not set # CONFIG_ADIS16240 is not set # # Analog to digital converters # # CONFIG_AD7606 is not set # CONFIG_AD7780 is not set # CONFIG_AD7816 is not set # CONFIG_AD7192 is not set # CONFIG_AD7280 is not set # # Analog digital bi-direction converters # # CONFIG_ADT7316 is not set # # Capacitance to digital converters # # CONFIG_AD7150 is not set # CONFIG_AD7152 is not set # CONFIG_AD7746 is not set # # Direct Digital Synthesis # # CONFIG_AD9832 is not set # CONFIG_AD9834 is not set # # Network Analyzer, Impedance Converters # # CONFIG_AD5933 is not set # # Active energy metering IC # # CONFIG_ADE7854 is not set # # Resolver to digital converters # # CONFIG_AD2S90 is not set # CONFIG_AD2S1210 is not set # CONFIG_FB_SM750 is not set # CONFIG_FB_XGI is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_STAGING_MEDIA is not set # # Android # CONFIG_ASHMEM=y # CONFIG_ANDROID_VSOC is not set CONFIG_SYNC=y CONFIG_ANDROID_FWDATA=y # CONFIG_ION is not set CONFIG_ABL_BOOTLOADER_CONTROL=y # CONFIG_SEND_SLCAN_ENABLE is not set # CONFIG_SBL_BOOTLOADER_CONTROL is not set # CONFIG_VSBL_BOOTLOADER_CONTROL is not set CONFIG_LTE_GDM724X=m # CONFIG_DGNC is not set # CONFIG_GS_FPGABOOT is not set # CONFIG_UNISYSSPAR is not set # CONFIG_FB_TFT is not set # CONFIG_WILC1000_SDIO is not set # CONFIG_WILC1000_SPI is not set # CONFIG_MOST is not set # CONFIG_KS7010 is not set # CONFIG_GREYBUS is not set # CONFIG_DRM_VBOXVIDEO is not set # CONFIG_PI433 is not set # CONFIG_MTK_MMC is not set # # Gasket devices # # CONFIG_STAGING_GASKET_FRAMEWORK is not set # CONFIG_XIL_AXIS_FIFO is not set # CONFIG_EROFS_FS is not set CONFIG_X86_PLATFORM_DEVICES=y # CONFIG_ACER_WIRELESS is not set # CONFIG_ACERHDF is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_DELL_SMBIOS is not set # CONFIG_DELL_SMO8800 is not set # CONFIG_DELL_RBTN is not set # CONFIG_FUJITSU_LAPTOP is not set # CONFIG_FUJITSU_TABLET is not set # CONFIG_GPD_POCKET_FAN is not set # CONFIG_HP_WIRELESS is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_INTEL_MENLOW is not set # CONFIG_EEEPC_LAPTOP is not set # CONFIG_ASUS_WIRELESS is not set # CONFIG_ACPI_WMI is not set # CONFIG_TOPSTAR_LAPTOP is not set # CONFIG_TOSHIBA_BT_RFKILL is not set # CONFIG_TOSHIBA_HAPS is not set # CONFIG_ACPI_CMPC is not set # CONFIG_INTEL_INT0002_VGPIO is not set # CONFIG_INTEL_HID_EVENT is not set # CONFIG_INTEL_VBTN is not set # CONFIG_INTEL_IPS is not set # CONFIG_INTEL_PMC_CORE is not set # CONFIG_IBM_RTL is not set # CONFIG_SAMSUNG_LAPTOP is not set # CONFIG_INTEL_OAKTRAIL is not set # CONFIG_SAMSUNG_Q10 is not set # CONFIG_APPLE_GMUX is not set CONFIG_INTEL_RST=y # CONFIG_INTEL_SMARTCONNECT is not set # CONFIG_PVPANIC is not set CONFIG_INTEL_PMC_IPC=y # CONFIG_INTEL_BXTWC_PMIC_TMU is not set # CONFIG_SURFACE_PRO3_BUTTON is not set # CONFIG_SURFACE_3_BUTTON is not set CONFIG_INTEL_PUNIT_IPC=y CONFIG_INTEL_TELEMETRY=y # CONFIG_MLX_PLATFORM is not set # CONFIG_INTEL_TURBO_MAX_3 is not set # CONFIG_I2C_MULTI_INSTANTIATE is not set # CONFIG_INTEL_PSTORE_PRAM is not set CONFIG_INTEL_TASKS_DUMP=y CONFIG_PMC_ATOM=y # CONFIG_CHROME_PLATFORMS is not set # CONFIG_MELLANOX_PLATFORM is not set CONFIG_CLKDEV_LOOKUP=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_COMMON_CLK=y # # Common Clock Framework # # CONFIG_COMMON_CLK_MAX9485 is not set # CONFIG_COMMON_CLK_SI5351 is not set # CONFIG_COMMON_CLK_SI544 is not set # CONFIG_COMMON_CLK_CDCE706 is not set # CONFIG_COMMON_CLK_CS2000_CP is not set # CONFIG_COMMON_CLK_PWM is not set # CONFIG_HWSPINLOCK is not set # # Clock Source drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y CONFIG_MAILBOX=y CONFIG_PCC=y # CONFIG_ALTERA_MBOX is not set CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y # # Generic IOMMU Pagetable Support # # CONFIG_IOMMU_DEBUGFS is not set # CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set CONFIG_IOMMU_IOVA=y # CONFIG_AMD_IOMMU is not set CONFIG_DMAR_TABLE=y CONFIG_INTEL_IOMMU=y # CONFIG_INTEL_IOMMU_SVM is not set CONFIG_INTEL_IOMMU_DEFAULT_ON=y CONFIG_INTEL_IOMMU_FLOPPY_WA=y # CONFIG_IRQ_REMAP is not set # # Remoteproc drivers # # CONFIG_REMOTEPROC is not set # # Rpmsg drivers # # CONFIG_RPMSG_QCOM_GLINK_RPM is not set # CONFIG_RPMSG_VIRTIO is not set # # SOC (System On Chip) specific Drivers # # # Amlogic SoC drivers # # # Broadcom SoC drivers # # # NXP/Freescale QorIQ SoC drivers # # # i.MX SoC drivers # # # Qualcomm SoC drivers # # CONFIG_SOC_TI is not set # # Xilinx SoC drivers # # CONFIG_XILINX_VCU is not set CONFIG_PM_DEVFREQ=y # # DEVFREQ Governors # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y # CONFIG_DEVFREQ_GOV_PERFORMANCE is not set # CONFIG_DEVFREQ_GOV_POWERSAVE is not set # CONFIG_DEVFREQ_GOV_USERSPACE is not set # CONFIG_DEVFREQ_GOV_PASSIVE is not set # # DEVFREQ Drivers # # CONFIG_PM_DEVFREQ_EVENT is not set CONFIG_EXTCON=y # # Extcon Device Drivers # # CONFIG_EXTCON_ADC_JACK is not set CONFIG_EXTCON_ARIZONA=y CONFIG_EXTCON_GPIO=y # CONFIG_EXTCON_INTEL_INT3496 is not set # CONFIG_EXTCON_MAX3355 is not set # CONFIG_EXTCON_RT8973A is not set # CONFIG_EXTCON_SM5502 is not set # CONFIG_EXTCON_USB_GPIO is not set # CONFIG_MEMORY is not set CONFIG_IIO=y CONFIG_IIO_BUFFER=y # CONFIG_IIO_BUFFER_CB is not set # CONFIG_IIO_BUFFER_HW_CONSUMER is not set CONFIG_IIO_KFIFO_BUF=y CONFIG_IIO_TRIGGERED_BUFFER=y # CONFIG_IIO_CONFIGFS is not set CONFIG_IIO_TRIGGER=y CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 # CONFIG_IIO_SW_DEVICE is not set # CONFIG_IIO_SW_TRIGGER is not set # # Accelerometers # # CONFIG_ADIS16201 is not set # CONFIG_ADIS16209 is not set # CONFIG_ADXL345_I2C is not set # CONFIG_ADXL345_SPI is not set CONFIG_BMA180=m # CONFIG_BMA220 is not set CONFIG_BMC150_ACCEL=y CONFIG_BMC150_ACCEL_I2C=y CONFIG_BMC150_ACCEL_SPI=y # CONFIG_DA280 is not set # CONFIG_DA311 is not set # CONFIG_DMARD09 is not set # CONFIG_DMARD10 is not set CONFIG_HID_SENSOR_ACCEL_3D=m # CONFIG_IIO_CROS_EC_ACCEL_LEGACY is not set CONFIG_IIO_ST_ACCEL_3AXIS=y CONFIG_IIO_ST_ACCEL_I2C_3AXIS=y CONFIG_IIO_ST_ACCEL_SPI_3AXIS=y # CONFIG_KXSD9 is not set CONFIG_KXCJK1013=y # CONFIG_MC3230 is not set # CONFIG_MMA7455_I2C is not set # CONFIG_MMA7455_SPI is not set # CONFIG_MMA7660 is not set # CONFIG_MMA8452 is not set # CONFIG_MMA9551 is not set # CONFIG_MMA9553 is not set # CONFIG_MXC4005 is not set # CONFIG_MXC6255 is not set # CONFIG_SCA3000 is not set # CONFIG_STK8312 is not set # CONFIG_STK8BA50 is not set # # Analog to digital converters # # CONFIG_AD7266 is not set # CONFIG_AD7291 is not set # CONFIG_AD7298 is not set # CONFIG_AD7476 is not set # CONFIG_AD7766 is not set # CONFIG_AD7791 is not set # CONFIG_AD7793 is not set # CONFIG_AD7887 is not set # CONFIG_AD7923 is not set # CONFIG_AD799X is not set # CONFIG_CC10001_ADC is not set # CONFIG_HI8435 is not set # CONFIG_HX711 is not set # CONFIG_INA2XX_ADC is not set # CONFIG_LTC2471 is not set # CONFIG_LTC2485 is not set # CONFIG_LTC2497 is not set # CONFIG_MAX1027 is not set # CONFIG_MAX11100 is not set # CONFIG_MAX1118 is not set # CONFIG_MAX1363 is not set # CONFIG_MAX9611 is not set CONFIG_MCP320X=m # CONFIG_MCP3422 is not set CONFIG_NAU7802=m # CONFIG_TI_ADC081C is not set # CONFIG_TI_ADC0832 is not set # CONFIG_TI_ADC084S021 is not set # CONFIG_TI_ADC12138 is not set # CONFIG_TI_ADC108S102 is not set # CONFIG_TI_ADC128S052 is not set # CONFIG_TI_ADC161S626 is not set # CONFIG_TI_ADS1015 is not set # CONFIG_TI_ADS7950 is not set # CONFIG_TI_TLC4541 is not set # # Analog Front Ends # # # Amplifiers # # CONFIG_AD8366 is not set # # Chemical Sensors # # CONFIG_ATLAS_PH_SENSOR is not set # CONFIG_BME680 is not set # CONFIG_CCS811 is not set # CONFIG_IAQCORE is not set # CONFIG_VZ89X is not set # # Hid Sensor IIO Common # CONFIG_HID_SENSOR_IIO_COMMON=m CONFIG_HID_SENSOR_IIO_TRIGGER=m # # SSP Sensor Common # # CONFIG_IIO_SSP_SENSORHUB is not set CONFIG_IIO_ST_SENSORS_I2C=y CONFIG_IIO_ST_SENSORS_SPI=y CONFIG_IIO_ST_SENSORS_CORE=y # # Counters # # # Digital to analog converters # # CONFIG_AD5064 is not set # CONFIG_AD5360 is not set # CONFIG_AD5380 is not set # CONFIG_AD5421 is not set # CONFIG_AD5446 is not set # CONFIG_AD5449 is not set # CONFIG_AD5592R is not set # CONFIG_AD5593R is not set # CONFIG_AD5504 is not set # CONFIG_AD5624R_SPI is not set # CONFIG_LTC2632 is not set # CONFIG_AD5686_SPI is not set # CONFIG_AD5696_I2C is not set # CONFIG_AD5755 is not set # CONFIG_AD5758 is not set # CONFIG_AD5761 is not set # CONFIG_AD5764 is not set # CONFIG_AD5791 is not set # CONFIG_AD7303 is not set # CONFIG_AD8801 is not set # CONFIG_DS4424 is not set # CONFIG_M62332 is not set # CONFIG_MAX517 is not set # CONFIG_MCP4725 is not set # CONFIG_MCP4922 is not set # CONFIG_TI_DAC082S085 is not set # CONFIG_TI_DAC5571 is not set # # IIO dummy driver # # # Frequency Synthesizers DDS/PLL # # # Clock Generator/Distribution # # CONFIG_AD9523 is not set # # Phase-Locked Loop (PLL) frequency synthesizers # # CONFIG_ADF4350 is not set # # Digital gyroscope sensors # # CONFIG_ADIS16080 is not set # CONFIG_ADIS16130 is not set # CONFIG_ADIS16136 is not set # CONFIG_ADIS16260 is not set # CONFIG_ADXRS450 is not set CONFIG_BMG160=y CONFIG_BMG160_I2C=y CONFIG_BMG160_SPI=y CONFIG_HID_SENSOR_GYRO_3D=m # CONFIG_MPU3050_I2C is not set CONFIG_IIO_ST_GYRO_3AXIS=y CONFIG_IIO_ST_GYRO_I2C_3AXIS=y CONFIG_IIO_ST_GYRO_SPI_3AXIS=y # CONFIG_ITG3200 is not set # # Health Sensors # # # Heart Rate Monitors # # CONFIG_AFE4403 is not set # CONFIG_AFE4404 is not set # CONFIG_MAX30100 is not set # CONFIG_MAX30102 is not set # # Humidity sensors # # CONFIG_AM2315 is not set # CONFIG_DHT11 is not set # CONFIG_HDC100X is not set # CONFIG_HID_SENSOR_HUMIDITY is not set # CONFIG_HTS221 is not set # CONFIG_HTU21 is not set # CONFIG_SI7005 is not set # CONFIG_SI7020 is not set # # Inertial measurement units # # CONFIG_ADIS16400 is not set # CONFIG_ADIS16480 is not set # CONFIG_BMI160_I2C is not set # CONFIG_BMI160_SPI is not set CONFIG_KMX61=y # CONFIG_INV_MPU6050_I2C is not set # CONFIG_INV_MPU6050_SPI is not set # CONFIG_IIO_ST_LSM6DSX is not set # # Light sensors # CONFIG_ACPI_ALS=y # CONFIG_ADJD_S311 is not set # CONFIG_AL3320A is not set # CONFIG_APDS9300 is not set # CONFIG_APDS9960 is not set # CONFIG_BH1750 is not set # CONFIG_BH1780 is not set CONFIG_CM32181=y CONFIG_CM3232=y # CONFIG_CM3323 is not set CONFIG_CM36651=m # CONFIG_GP2AP020A00F is not set # CONFIG_SENSORS_ISL29018 is not set # CONFIG_SENSORS_ISL29028 is not set # CONFIG_ISL29125 is not set CONFIG_HID_SENSOR_ALS=m # CONFIG_HID_SENSOR_PROX is not set CONFIG_JSA1212=m # CONFIG_RPR0521 is not set # CONFIG_LTR501 is not set # CONFIG_LV0104CS is not set # CONFIG_MAX44000 is not set # CONFIG_OPT3001 is not set # CONFIG_PA12203001 is not set # CONFIG_SI1133 is not set # CONFIG_SI1145 is not set # CONFIG_STK3310 is not set # CONFIG_ST_UVIS25 is not set # CONFIG_TCS3414 is not set # CONFIG_TCS3472 is not set # CONFIG_SENSORS_TSL2563 is not set # CONFIG_TSL2583 is not set # CONFIG_TSL2772 is not set # CONFIG_TSL4531 is not set # CONFIG_US5182D is not set # CONFIG_VCNL4000 is not set # CONFIG_VEML6070 is not set # CONFIG_VL6180 is not set # CONFIG_ZOPT2201 is not set # # Magnetometer sensors # CONFIG_AK8975=m CONFIG_AK09911=m # CONFIG_BMC150_MAGN_I2C is not set # CONFIG_BMC150_MAGN_SPI is not set # CONFIG_MAG3110 is not set CONFIG_HID_SENSOR_MAGNETOMETER_3D=m # CONFIG_MMC35240 is not set CONFIG_IIO_ST_MAGN_3AXIS=y CONFIG_IIO_ST_MAGN_I2C_3AXIS=y CONFIG_IIO_ST_MAGN_SPI_3AXIS=y # CONFIG_SENSORS_HMC5843_I2C is not set # CONFIG_SENSORS_HMC5843_SPI is not set # # Multiplexers # # # Inclinometer sensors # CONFIG_HID_SENSOR_INCLINOMETER_3D=m # CONFIG_HID_SENSOR_DEVICE_ROTATION is not set # # Triggers - standalone # CONFIG_IIO_INTERRUPT_TRIGGER=y CONFIG_IIO_SYSFS_TRIGGER=y # # Digital potentiometers # # CONFIG_AD5272 is not set # CONFIG_DS1803 is not set # CONFIG_MAX5481 is not set # CONFIG_MAX5487 is not set # CONFIG_MCP4018 is not set # CONFIG_MCP4131 is not set # CONFIG_MCP4531 is not set # CONFIG_TPL0102 is not set # # Digital potentiostats # # CONFIG_LMP91000 is not set # # Pressure sensors # # CONFIG_ABP060MG is not set # CONFIG_BMP280 is not set # CONFIG_HID_SENSOR_PRESS is not set # CONFIG_HP03 is not set # CONFIG_MPL115_I2C is not set # CONFIG_MPL115_SPI is not set # CONFIG_MPL3115 is not set # CONFIG_MS5611 is not set # CONFIG_MS5637 is not set CONFIG_IIO_ST_PRESS=y CONFIG_IIO_ST_PRESS_I2C=y CONFIG_IIO_ST_PRESS_SPI=y # CONFIG_T5403 is not set # CONFIG_HP206C is not set # CONFIG_ZPA2326 is not set # # Lightning sensors # # CONFIG_AS3935 is not set # # Proximity and distance sensors # # CONFIG_ISL29501 is not set # CONFIG_LIDAR_LITE_V2 is not set # CONFIG_RFD77402 is not set # CONFIG_SRF04 is not set # CONFIG_SX9500 is not set # CONFIG_SRF08 is not set # # Resolver to digital converters # # CONFIG_AD2S1200 is not set # # Temperature sensors # # CONFIG_MAXIM_THERMOCOUPLE is not set # CONFIG_HID_SENSOR_TEMP is not set # CONFIG_MLX90614 is not set # CONFIG_MLX90632 is not set CONFIG_TMP006=m # CONFIG_TMP007 is not set # CONFIG_TSYS01 is not set # CONFIG_TSYS02D is not set # CONFIG_NTB is not set # CONFIG_VME_BUS is not set CONFIG_PWM=y CONFIG_PWM_SYSFS=y # CONFIG_PWM_CRC is not set CONFIG_PWM_LPSS=y CONFIG_PWM_LPSS_PCI=y # CONFIG_PWM_LPSS_PLATFORM is not set # CONFIG_PWM_PCA9685 is not set # # IRQ chip support # CONFIG_ARM_GIC_MAX_NR=1 # CONFIG_IPACK_BUS is not set # CONFIG_RESET_CONTROLLER is not set # CONFIG_FMC is not set # # PHY Subsystem # CONFIG_GENERIC_PHY=y # CONFIG_BCM_KONA_USB2_PHY is not set # CONFIG_PHY_PXA_28NM_HSIC is not set # CONFIG_PHY_PXA_28NM_USB2 is not set # CONFIG_PHY_CPCAP_USB is not set # CONFIG_PHY_QCOM_USB_HS is not set # CONFIG_PHY_QCOM_USB_HSIC is not set # CONFIG_PHY_SAMSUNG_USB2 is not set # CONFIG_PHY_TUSB1210 is not set CONFIG_POWERCAP=y CONFIG_INTEL_RAPL=y # CONFIG_IDLE_INJECT is not set # CONFIG_MCB is not set # # Performance monitor support # CONFIG_RAS=y # CONFIG_THUNDERBOLT is not set # # Android # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder" # CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set # CONFIG_LIBNVDIMM is not set CONFIG_DAX=y # CONFIG_DEV_DAX is not set CONFIG_NVMEM=y # # HW tracing support # CONFIG_STM=y CONFIG_STM_PROTO_BASIC=y CONFIG_STM_PROTO_SYS_T=y # CONFIG_STM_DUMMY is not set CONFIG_STM_SOURCE_CONSOLE=y # CONFIG_STM_SOURCE_HEARTBEAT is not set # CONFIG_STM_SOURCE_FTRACE is not set CONFIG_INTEL_TH=y CONFIG_INTEL_TH_PCI=y # CONFIG_INTEL_TH_ACPI is not set CONFIG_INTEL_TH_GTH=y CONFIG_INTEL_TH_STH=y CONFIG_INTEL_TH_MSU=y CONFIG_INTEL_TH_MSU_DVC=y # CONFIG_INTEL_TH_MSU_DVC_DEBUG is not set CONFIG_INTEL_TH_PTI=y # CONFIG_INTEL_TH_DEBUG is not set CONFIG_INTEL_TH_EARLY_PRINTK=y # CONFIG_FPGA is not set CONFIG_PM_OPP=y CONFIG_SDW=y CONFIG_SDW_CNL=y # CONFIG_SDW_MAXIM_SLAVE is not set # CONFIG_UNISYS_VISORBUS is not set # CONFIG_SIOX is not set # CONFIG_SLIMBUS is not set # CONFIG_LEGACY_ENERGY_MODEL_DT is not set # # File systems # CONFIG_DCACHE_WORD_ACCESS=y CONFIG_FS_IOMAP=y # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT2=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_EXT4_ENCRYPTION=y CONFIG_EXT4_FS_ENCRYPTION=y # CONFIG_EXT4_DEBUG is not set CONFIG_JBD2=y # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set # CONFIG_F2FS_FS is not set # CONFIG_FS_DAX is not set CONFIG_FS_POSIX_ACL=y # CONFIG_EXPORTFS_BLOCK_OPS is not set CONFIG_FILE_LOCKING=y CONFIG_MANDATORY_FILE_LOCKING=y CONFIG_FS_ENCRYPTION=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y # CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y # CONFIG_AUTOFS4_FS is not set # CONFIG_AUTOFS_FS is not set CONFIG_FUSE_FS=y # CONFIG_CUSE is not set # CONFIG_OVERLAY_FS is not set # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FAT_DEFAULT_UTF8 is not set # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y # CONFIG_PROC_CHILDREN is not set CONFIG_PROC_UID=y CONFIG_KERNFS=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_MEMFD_CREATE=y CONFIG_CONFIGFS_FS=y CONFIG_MISC_FILESYSTEMS=y # CONFIG_ORANGEFS_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_ECRYPT_FS is not set CONFIG_SDCARD_FS=y # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_SQUASHFS=y CONFIG_SQUASHFS_FILE_CACHE=y # CONFIG_SQUASHFS_FILE_DIRECT is not set # CONFIG_SQUASHFS_DECOMP_SINGLE is not set CONFIG_SQUASHFS_DECOMP_MULTI=y # CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZ4=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y # CONFIG_SQUASHFS_ZSTD is not set # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set CONFIG_SQUASHFS_EMBEDDED=y CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX6FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_PSTORE=y CONFIG_PSTORE_DEFLATE_COMPRESS=y # CONFIG_PSTORE_LZO_COMPRESS is not set # CONFIG_PSTORE_LZ4_COMPRESS is not set # CONFIG_PSTORE_LZ4HC_COMPRESS is not set # CONFIG_PSTORE_842_COMPRESS is not set # CONFIG_PSTORE_ZSTD_COMPRESS is not set CONFIG_PSTORE_COMPRESS=y CONFIG_PSTORE_DEFLATE_COMPRESS_DEFAULT=y CONFIG_PSTORE_COMPRESS_DEFAULT="deflate" CONFIG_PSTORE_CONSOLE=y # CONFIG_PSTORE_PMSG is not set # CONFIG_PSTORE_FTRACE is not set CONFIG_PSTORE_RAM=y # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_CEPH_FS is not set CONFIG_CIFS=y # CONFIG_CIFS_STATS2 is not set CONFIG_CIFS_ALLOW_INSECURE_LEGACY=y CONFIG_CIFS_WEAK_PW_HASH=y # CONFIG_CIFS_UPCALL is not set # CONFIG_CIFS_XATTR is not set CONFIG_CIFS_DEBUG=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_DEBUG_DUMP_KEYS is not set # CONFIG_CIFS_DFS_UPCALL is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_MAC_ROMAN is not set # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set # CONFIG_NLS_MAC_CROATIAN is not set # CONFIG_NLS_MAC_CYRILLIC is not set # CONFIG_NLS_MAC_GAELIC is not set # CONFIG_NLS_MAC_GREEK is not set # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set # CONFIG_NLS_MAC_ROMANIAN is not set # CONFIG_NLS_MAC_TURKISH is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_COMPAT=y # CONFIG_PERSISTENT_KEYRINGS is not set CONFIG_BIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set # CONFIG_KEY_DH_OPERATIONS is not set # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY_PERF_EVENTS_RESTRICT=y CONFIG_SECURITY=y CONFIG_SECURITY_WRITABLE_HOOKS=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y # CONFIG_PAGE_TABLE_ISOLATION is not set # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_PATH is not set # CONFIG_INTEL_TXT is not set CONFIG_LSM_MMAP_MIN_ADDR=65536 CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y CONFIG_HARDENED_USERCOPY=y CONFIG_HARDENED_USERCOPY_FALLBACK=y # CONFIG_HARDENED_USERCOPY_PAGESPAN is not set # CONFIG_FORTIFY_SOURCE is not set # CONFIG_STATIC_USERMODEHELPER is not set CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_SECURITY_LOADPIN is not set # CONFIG_SECURITY_YAMA is not set # CONFIG_INTEGRITY is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_RNG_DEFAULT=y CONFIG_CRYPTO_AKCIPHER2=y CONFIG_CRYPTO_AKCIPHER=y CONFIG_CRYPTO_KPP2=y CONFIG_CRYPTO_KPP=m CONFIG_CRYPTO_ACOMP2=y CONFIG_CRYPTO_RSA=y # CONFIG_CRYPTO_DH is not set CONFIG_CRYPTO_ECDH=m CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y # CONFIG_CRYPTO_MCRYPTD is not set CONFIG_CRYPTO_AUTHENC=y # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_SIMD=y CONFIG_CRYPTO_GLUE_HELPER_X86=y CONFIG_CRYPTO_ENGINE=m # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=y CONFIG_CRYPTO_GCM=y # CONFIG_CRYPTO_CHACHA20POLY1305 is not set # CONFIG_CRYPTO_AEGIS128 is not set # CONFIG_CRYPTO_AEGIS128L is not set # CONFIG_CRYPTO_AEGIS256 is not set # CONFIG_CRYPTO_AEGIS128_AESNI_SSE2 is not set # CONFIG_CRYPTO_AEGIS128L_AESNI_SSE2 is not set # CONFIG_CRYPTO_AEGIS256_AESNI_SSE2 is not set # CONFIG_CRYPTO_MORUS640 is not set # CONFIG_CRYPTO_MORUS640_SSE2 is not set # CONFIG_CRYPTO_MORUS1280 is not set # CONFIG_CRYPTO_MORUS1280_SSE2 is not set # CONFIG_CRYPTO_MORUS1280_AVX2 is not set CONFIG_CRYPTO_SEQIV=y CONFIG_CRYPTO_ECHAINIV=y # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CFB is not set CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=y # CONFIG_CRYPTO_PCBC is not set CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_KEYWRAP is not set # # Hash modes # CONFIG_CRYPTO_CMAC=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_VMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=y CONFIG_CRYPTO_CRC32=y # CONFIG_CRYPTO_CRC32_PCLMUL is not set CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y CONFIG_CRYPTO_GHASH=y # CONFIG_CRYPTO_POLY1305 is not set # CONFIG_CRYPTO_POLY1305_X86_64 is not set CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y # CONFIG_CRYPTO_SHA256_SSSE3 is not set # CONFIG_CRYPTO_SHA512_SSSE3 is not set # CONFIG_CRYPTO_SHA1_MB is not set # CONFIG_CRYPTO_SHA256_MB is not set # CONFIG_CRYPTO_SHA512_MB is not set CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y # CONFIG_CRYPTO_SHA3 is not set # CONFIG_CRYPTO_SM3 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set # # Ciphers # CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_TI is not set CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=y # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_BLOWFISH_COMMON=y CONFIG_CRYPTO_BLOWFISH_X86_64=y # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAMELLIA_X86_64 is not set # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_DES3_EDE_X86_64 is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_CHACHA20 is not set # CONFIG_CRYPTO_CHACHA20_X86_64 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set # CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set # CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set # CONFIG_CRYPTO_SM4 is not set # CONFIG_CRYPTO_SPECK is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y CONFIG_CRYPTO_TWOFISH_X86_64=y CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y CONFIG_CRYPTO_TWOFISH_AVX_X86_64=y # # Compression # CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_LZO=y # CONFIG_CRYPTO_842 is not set CONFIG_CRYPTO_LZ4=y CONFIG_CRYPTO_LZ4HC=y # CONFIG_CRYPTO_ZSTD is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_DRBG_MENU=y CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_JITTERENTROPY=y # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set # CONFIG_CRYPTO_USER_API_RNG is not set # CONFIG_CRYPTO_USER_API_AEAD is not set CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_PADLOCK is not set # CONFIG_CRYPTO_DEV_CCP is not set # CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set # CONFIG_CRYPTO_DEV_QAT_C3XXX is not set # CONFIG_CRYPTO_DEV_QAT_C62X is not set # CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set # CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set # CONFIG_CRYPTO_DEV_QAT_C62XVF is not set # CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set CONFIG_CRYPTO_DEV_VIRTIO=m CONFIG_ASYMMETRIC_KEY_TYPE=y CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y CONFIG_X509_CERTIFICATE_PARSER=y CONFIG_PKCS7_MESSAGE_PARSER=y CONFIG_PKCS7_TEST_KEY=y # CONFIG_SIGNED_PE_FILE_VERIFICATION is not set # # Certificates for signature checking # CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set # CONFIG_SECONDARY_TRUSTED_KEYRING is not set # CONFIG_SYSTEM_BLACKLIST_KEYRING is not set CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_BITREVERSE=y CONFIG_RATIONAL=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_NET_UTILS=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_HAS_FAST_MULTIPLIER=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC64=m # CONFIG_CRC4 is not set # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y CONFIG_CRC8=y # CONFIG_RANDOM32_SELFTEST is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_LZ4_COMPRESS=y CONFIG_LZ4HC_COMPRESS=y CONFIG_LZ4_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y # CONFIG_XZ_DEC_POWERPC is not set # CONFIG_XZ_DEC_IA64 is not set # CONFIG_XZ_DEC_ARM is not set # CONFIG_XZ_DEC_ARMTHUMB is not set # CONFIG_XZ_DEC_SPARC is not set CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_LZ4=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=y CONFIG_TEXTSEARCH_BM=y CONFIG_TEXTSEARCH_FSM=y CONFIG_INTERVAL_TREE=y CONFIG_RADIX_TREE_MULTIORDER=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y CONFIG_HAS_DMA=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DMA_DIRECT_OPS=y CONFIG_SWIOTLB=y CONFIG_SGL_ALLOC=y CONFIG_IOMMU_HELPER=y CONFIG_CHECK_SIGNATURE=y CONFIG_CPU_RMAP=y CONFIG_DQL=y CONFIG_GLOB=y # CONFIG_GLOB_SELFTEST is not set CONFIG_NLATTR=y CONFIG_CLZ_TAB=y CONFIG_CORDIC=m # CONFIG_DDR is not set # CONFIG_IRQ_POLL is not set CONFIG_MPILIB=y CONFIG_OID_REGISTRY=y CONFIG_SG_POOL=y CONFIG_ARCH_HAS_SG_CHAIN=y CONFIG_ARCH_HAS_PMEM_API=y CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y CONFIG_ARCH_HAS_UACCESS_MCSAFE=y CONFIG_SBITMAP=y # CONFIG_STRING_SELFTEST is not set # # Kernel hacking # # # printk and dmesg options # CONFIG_PRINTK_TIME=y CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 CONFIG_CONSOLE_LOGLEVEL_QUIET=4 CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 # CONFIG_BOOT_PRINTK_DELAY is not set CONFIG_DYNAMIC_DEBUG=y # # Compile-time checks and compiler options # CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_GDB_SCRIPTS is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_READABLE_ASM is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_SECTION_MISMATCH_WARN_ONLY=y CONFIG_FRAME_POINTER=y CONFIG_STACK_VALIDATION=y # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_MAGIC_SYSRQ_SERIAL=y CONFIG_DEBUG_KERNEL=y # # Memory Debugging # # CONFIG_PAGE_EXTENSION is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_PAGE_POISONING is not set # CONFIG_DEBUG_PAGE_REF is not set # CONFIG_DEBUG_RODATA_TEST is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=4000 # CONFIG_DEBUG_KMEMLEAK_TEST is not set CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_VM is not set CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y # CONFIG_DEBUG_VIRTUAL is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_PER_CPU_MAPS is not set CONFIG_HAVE_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_HAVE_ARCH_KASAN=y # CONFIG_KASAN is not set CONFIG_ARCH_HAS_KCOV=y CONFIG_CC_HAS_SANCOV_TRACE_PC=y # CONFIG_KCOV is not set # CONFIG_DEBUG_SHIRQ is not set # # Debug Lockups and Hangs # CONFIG_LOCKUP_DETECTOR=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 CONFIG_HARDLOCKUP_DETECTOR_PERF=y CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 CONFIG_DETECT_HUNG_TASK=y CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1 # CONFIG_WQ_WATCHDOG is not set CONFIG_PANIC_ON_OOPS=y CONFIG_PANIC_ON_OOPS_VALUE=1 CONFIG_PANIC_TIMEOUT=10 CONFIG_SCHED_DEBUG=y CONFIG_SCHED_INFO=y CONFIG_SCHEDSTATS=y CONFIG_SCHED_STACK_END_CHECK=y # CONFIG_DEBUG_TIMEKEEPING is not set CONFIG_DEBUG_PREEMPT=y # # Lock Debugging (spinlocks, mutexes, etc...) # CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set # CONFIG_DEBUG_RWSEMS is not set CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y # CONFIG_DEBUG_LOCKDEP is not set CONFIG_DEBUG_ATOMIC_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_LOCK_TORTURE_TEST is not set # CONFIG_WW_MUTEX_SELFTEST is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_STACKTRACE=y # CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_LIST=y # CONFIG_DEBUG_PI_LIST is not set CONFIG_DEBUG_SG=y CONFIG_DEBUG_NOTIFIERS=y CONFIG_DEBUG_CREDENTIALS=y # # RCU Debugging # CONFIG_TORTURE_TEST=m CONFIG_RCU_PERF_TEST=m CONFIG_RCU_TORTURE_TEST=m CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RCU_TRACE=y CONFIG_RCU_EQS_DEBUG=y # CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set CONFIG_FUNCTION_ERROR_INJECTION=y # CONFIG_FAULT_INJECTION is not set CONFIG_LATENCYTOP=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_FENTRY=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_TRACE_CLOCK=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_PREEMPTIRQ_TRACEPOINTS=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_PREEMPTIRQ_EVENTS is not set CONFIG_IRQSOFF_TRACER=y # CONFIG_PREEMPT_TRACER is not set CONFIG_SCHED_TRACER=y # CONFIG_HWLAT_TRACER is not set CONFIG_FTRACE_SYSCALLS=y CONFIG_TRACER_SNAPSHOT=y CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_STACK_TRACER is not set CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENTS=y # CONFIG_KPROBE_EVENTS_ON_NOTRACE is not set # CONFIG_UPROBE_EVENTS is not set CONFIG_BPF_EVENTS=y CONFIG_PROBE_EVENTS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y # CONFIG_FUNCTION_PROFILER is not set # CONFIG_BPF_KPROBE_OVERRIDE is not set CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set # CONFIG_HIST_TRIGGERS is not set # CONFIG_TRACEPOINT_BENCHMARK is not set # CONFIG_RING_BUFFER_BENCHMARK is not set # CONFIG_RING_BUFFER_STARTUP_TEST is not set # CONFIG_PREEMPTIRQ_DELAY_TEST is not set # CONFIG_TRACE_EVAL_MAP_FILE is not set CONFIG_TRACING_EVENTS_GPIO=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_DMA_API_DEBUG is not set CONFIG_RUNTIME_TESTING_MENU=y # CONFIG_LKDTM is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_TEST_SORT is not set # CONFIG_KPROBES_SANITY_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_RBTREE_TEST is not set # CONFIG_INTERVAL_TREE_TEST is not set # CONFIG_PERCPU_TEST is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_TEST_HEXDUMP is not set # CONFIG_TEST_STRING_HELPERS is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_TEST_PRINTF is not set # CONFIG_TEST_BITMAP is not set # CONFIG_TEST_BITFIELD is not set # CONFIG_TEST_UUID is not set # CONFIG_TEST_OVERFLOW is not set # CONFIG_TEST_RHASHTABLE is not set # CONFIG_TEST_HASH is not set # CONFIG_TEST_IDA is not set # CONFIG_TEST_LKM is not set # CONFIG_TEST_USER_COPY is not set # CONFIG_TEST_BPF is not set # CONFIG_FIND_BIT_BENCHMARK is not set # CONFIG_TEST_FIRMWARE is not set # CONFIG_TEST_SYSCTL is not set # CONFIG_TEST_UDELAY is not set # CONFIG_TEST_STATIC_KEYS is not set # CONFIG_TEST_KMOD is not set # CONFIG_TEST_MEMCAT_P is not set # CONFIG_MEMTEST is not set # CONFIG_BUG_ON_DATA_CORRUPTION is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y # CONFIG_UBSAN is not set CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y # CONFIG_STRICT_DEVMEM is not set CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_EARLY_PRINTK_USB=y CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y # CONFIG_EARLY_PRINTK_USB_XDBC is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_WX is not set CONFIG_DOUBLEFAULT=y # CONFIG_DEBUG_TLBFLUSH is not set # CONFIG_IOMMU_DEBUG is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_X86_DECODER_SELFTEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # CONFIG_DEBUG_ENTRY is not set # CONFIG_DEBUG_NMI_SELFTEST is not set CONFIG_X86_DEBUG_FPU=y # CONFIG_PUNIT_ATOM_DEBUG is not set # CONFIG_UNWINDER_ORC is not set CONFIG_UNWINDER_FRAME_POINTER=y # CONFIG_UNWINDER_GUESS is not set ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-11-30 8:03 ` He, Bo @ 2018-11-30 14:43 ` Paul E. McKenney 2018-11-30 15:16 ` Steven Rostedt 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-11-30 14:43 UTC (permalink / raw) To: He, Bo Cc: linux-kernel@vger.kernel.org, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Fri, Nov 30, 2018 at 08:03:38AM +0000, He, Bo wrote: > Thanks for your great suggestions. > After enable the CONFIG_RCU_BOOST=y, we don't reproduce the issue until now, we will keep it running and update you with the test results. > > The enclosed is the kernel config, here is the config I grep with the RCU, we don't enable the CONFIG_RCU_BOOST in our build. > # RCU Subsystem > CONFIG_PREEMPT_RCU=y > # CONFIG_RCU_EXPERT is not set > CONFIG_SRCU=y > CONFIG_TREE_SRCU=y > CONFIG_TASKS_RCU=y > CONFIG_RCU_STALL_COMMON=y > CONFIG_RCU_NEED_SEGCBLIST=y > # RCU Debugging > CONFIG_RCU_PERF_TEST=m > CONFIG_RCU_TORTURE_TEST=m > CONFIG_RCU_CPU_STALL_TIMEOUT=21 > CONFIG_RCU_TRACE=y > CONFIG_RCU_EQS_DEBUG=y Thank you! What likely happened is that a low-priority RCU reader was preempted indefinitely. Though I would have expected an RCU CPU stall warning in that case, so it might well be that something else is going on. Could you please send me your list of kernel boot parameters? They usually appear near the start of your console output. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, November 29, 2018 10:27 PM > To: He, Bo <bo.he@intel.com> > Cc: linux-kernel@vger.kernel.org; josh@joshtriplett.org; rostedt@goodmis.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Nov 29, 2018 at 05:06:47AM -0800, Paul E. McKenney wrote: > > On Thu, Nov 29, 2018 at 08:49:35AM +0000, He, Bo wrote: > > > Hi, > > > we test on kernel 4.19.0 on android, after run more than 24 Hours monkey stress test, we see OOM on 1/10 2G memory board, the issue is not seen on the 4.14 kernel. > > > we have done some debugs: > > > 1. OOM is due to the filp consume too many memory: 300M vs 2G board. > > > 2. with the 120s hung task detect, most of the tasks will block at > > > __wait_rcu_gp: wait_for_completion(&rs_array[i].completion); > > Did you did see any RCU CPU stall warnings? Or have those been disabled? > If they have been disabled, could you please rerun with them enabled? > > > > [47571.863839] Kernel panic - not syncing: hung_task: blocked tasks > > > [47571.875446] CPU: 1 PID: 13626 Comm: FinalizerDaemon Tainted: G U O 4.19.0-quilt-2e5dc0ac-gf3f313245eb6 #1 > > > [47571.887603] Call Trace: > > > [47571.890547] dump_stack+0x70/0xa5 [47571.894456] > > > panic+0xe3/0x241 [47571.897977] ? > > > wait_for_completion_timeout+0x72/0x1b0 > > > [47571.903830] __wait_rcu_gp+0x17b/0x180 [47571.908226] > > > synchronize_rcu.part.76+0x38/0x50 [47571.913393] ? > > > __call_rcu.constprop.79+0x3a0/0x3a0 > > > [47571.918948] ? __bpf_trace_rcu_invoke_callback+0x10/0x10 > > > [47571.925094] synchronize_rcu+0x43/0x50 [47571.929487] > > > evdev_detach_client+0x59/0x60 [47571.934264] > > > evdev_release+0x4e/0xd0 [47571.938464] __fput+0xfa/0x1f0 > > > [47571.942072] ____fput+0xe/0x10 [47571.945683] > > > task_work_run+0x90/0xc0 [47571.949884] > > > exit_to_usermode_loop+0x9f/0xb0 [47571.954855] > > > do_syscall_64+0xfa/0x110 [47571.959151] > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > This is indeed a task waiting on synchronize_rcu(). > > > > 3. after enable the rcu trace, we don't see rcu_quiescent_state_report trace in a long time, we see rcu_callback: rcu_preempt will never response with the rcu_invoke_callback. > > > [47572.040668] ps-12388 1d..1 47566097572us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > > [47572.040707] ps-12388 1d... 47566097621us : rcu_callback: rcu_preempt rhp=00000000783a728b func=file_free_rcu 4354/82824 > > > [47572.040734] ps-12388 1d..1 47566097622us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > > [47572.040756] ps-12388 1d..1 47566097623us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > > [47572.040778] ps-12388 1d..1 47566097623us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > > [47572.040802] ps-12388 1d... 47566097674us : rcu_callback: rcu_preempt rhp=0000000042c76521 func=file_free_rcu 4354/82825 > > > [47572.040824] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > > [47572.040847] ps-12388 1d..1 47566097676us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > > [47572.040868] ps-12388 1d..1 47566097676us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > > [47572.040895] ps-12388 1d..1 47566097716us : rcu_callback: rcu_preempt rhp=000000005e40fde2 func=avc_node_free 4354/82826 > > > [47572.040919] ps-12388 1d..1 47566097735us : rcu_callback: rcu_preempt rhp=00000000f80fe353 func=avc_node_free 4354/82827 > > > [47572.040943] ps-12388 1d..1 47566097758us : rcu_callback: rcu_preempt rhp=000000007486f400 func=avc_node_free 4354/82828 > > > [47572.040967] ps-12388 1d..1 47566097760us : rcu_callback: rcu_preempt rhp=00000000b87872a8 func=avc_node_free 4354/82829 > > > [47572.040990] ps-12388 1d... 47566097789us : rcu_callback: rcu_preempt rhp=000000008c656343 func=file_free_rcu 4354/82830 > > > [47572.041013] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > > [47572.041036] ps-12388 1d..1 47566097790us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > > [47572.041057] ps-12388 1d..1 47566097791us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > > [47572.041081] ps-12388 1d... 47566097871us : rcu_callback: rcu_preempt rhp=000000007e6c898c func=file_free_rcu 4354/82831 > > > [47572.041103] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > > [47572.041126] ps-12388 1d..1 47566097872us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Prestarted > > > [47572.041147] ps-12388 1d..1 47566097873us : rcu_grace_period: rcu_preempt 23716088 AccWaitCB > > > [47572.041170] ps-12388 1d... 47566097945us : rcu_callback: rcu_preempt rhp=0000000032f4f174 func=file_free_rcu 4354/82832 > > > [47572.041193] ps-12388 1d..1 47566097946us : rcu_future_grace_period: rcu_preempt 23716088 23716092 0 0 3 Startleaf > > Callbacks are being queued and future grace periods to handle them are being requested, but as you say, no progress on the current grace period. > > Is it possible to start the trace earlier? > > > > Do you have any suggestions to debug the issue? > > > > If you do not already have CONFIG_RCU_BOOST=y set, could you please > > rebuild with that? > > > > Could you also please send your .config file? > > So, to summarize: > > 1. If you don't have RCU CPU stall warnings enabled, > please enable them. For example, please remove > rcupdate.rcu_cpu_stall_suppress from the kernel boot > parameters if it is there. > > Getting an RCU CPU stall warning would be extremely > helpful. It contains many useful diagnostics. > > 2. If possible, please start the trace before the last > grace period starts. > > 3. If CONFIG_RCU_BOOST=y is not set, please try setting it. > > 4. Please send me your .config file. > > Thanx, Paul > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-11-30 14:43 ` Paul E. McKenney @ 2018-11-30 15:16 ` Steven Rostedt 2018-11-30 15:18 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Steven Rostedt @ 2018-11-30 15:16 UTC (permalink / raw) To: Paul E. McKenney Cc: He, Bo, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > Could you please send me your list of kernel boot parameters? They > usually appear near the start of your console output. Or just: cat /proc/cmdline -- Steve ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-11-30 15:16 ` Steven Rostedt @ 2018-11-30 15:18 ` He, Bo 2018-11-30 16:49 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-11-30 15:18 UTC (permalink / raw) To: Steven Rostedt, Paul E. McKenney Cc: linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin Here is the kernel cmdline: Kernel command line: androidboot.acpio_idx=0 androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03-userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt loglevel=4 androidboot.hardware=gordon_peak firmware_class.path=/vendor/firmware relative_sleep_states=1 enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/properties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 ramoops.record_size=0x4000 ramoops.console_size=0x1000000 ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 drm.vblankoffdelay= -----Original Message----- From: Steven Rostedt <rostedt@goodmis.org> Sent: Friday, November 30, 2018 11:17 PM To: Paul E. McKenney <paulmck@linux.ibm.com> Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> Subject: Re: rcu_preempt caused oom On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > Could you please send me your list of kernel boot parameters? They > usually appear near the start of your console output. Or just: cat /proc/cmdline -- Steve ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-11-30 15:18 ` He, Bo @ 2018-11-30 16:49 ` Paul E. McKenney 2018-12-03 7:44 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-11-30 16:49 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > Here is the kernel cmdline: Thank you! > Kernel command line: androidboot.acpio_idx=0 androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03-userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt loglevel=4 androidboot.hardware=gordon_peak firmware_class.path=/vendor/firmware relative_sleep_states=1 enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/properties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 ramoops.record_size=0x4000 ramoops.console_size=0x1000000 ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 drm.vblankoffdelay= And no sign of any suppression of RCU CPU stall warnings. Hmmm... It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: rcupdate.rcu_cpu_stall_timeout=7 This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. Thanx, Paul > -----Original Message----- > From: Steven Rostedt <rostedt@goodmis.org> > Sent: Friday, November 30, 2018 11:17 PM > To: Paul E. McKenney <paulmck@linux.ibm.com> > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Fri, 30 Nov 2018 06:43:17 -0800 > "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > > > Could you please send me your list of kernel boot parameters? They > > usually appear near the start of your console output. > > Or just: cat /proc/cmdline > > -- Steve > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-11-30 16:49 ` Paul E. McKenney @ 2018-12-03 7:44 ` He, Bo 2018-12-03 13:56 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-03 7:44 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. echo 1 > /proc/sys/kernel/panic_on_rcu_stall -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Saturday, December 1, 2018 12:49 AM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> Subject: Re: rcu_preempt caused oom On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > Here is the kernel cmdline: Thank you! > Kernel command line: androidboot.acpio_idx=0 > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03- > userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > loglevel=4 androidboot.hardware=gordon_peak > firmware_class.path=/vendor/firmware relative_sleep_states=1 > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/prope > rties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > drm.vblankoffdelay= And no sign of any suppression of RCU CPU stall warnings. Hmmm... It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: rcupdate.rcu_cpu_stall_timeout=7 This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. Thanx, Paul > -----Original Message----- > From: Steven Rostedt <rostedt@goodmis.org> > Sent: Friday, November 30, 2018 11:17 PM > To: Paul E. McKenney <paulmck@linux.ibm.com> > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Fri, 30 Nov 2018 06:43:17 -0800 > "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > > > Could you please send me your list of kernel boot parameters? They > > usually appear near the start of your console output. > > Or just: cat /proc/cmdline > > -- Steve > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-03 7:44 ` He, Bo @ 2018-12-03 13:56 ` Paul E. McKenney 2018-12-04 7:50 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-03 13:56 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > echo 1 > /proc/sys/kernel/panic_on_rcu_stall Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Saturday, December 1, 2018 12:49 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > Here is the kernel cmdline: > > Thank you! > > > Kernel command line: androidboot.acpio_idx=0 > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03- > > userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green > > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > loglevel=4 androidboot.hardware=gordon_peak > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/prope > > rties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > drm.vblankoffdelay= > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > rcupdate.rcu_cpu_stall_timeout=7 > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > Thanx, Paul > > > -----Original Message----- > > From: Steven Rostedt <rostedt@goodmis.org> > > Sent: Friday, November 30, 2018 11:17 PM > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, 30 Nov 2018 06:43:17 -0800 > > "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > > > > > Could you please send me your list of kernel boot parameters? They > > > usually appear near the start of your console output. > > > > Or just: cat /proc/cmdline > > > > -- Steve > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-03 13:56 ` Paul E. McKenney @ 2018-12-04 7:50 ` He, Bo 2018-12-04 19:49 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-04 7:50 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A [-- Attachment #1: Type: text/plain, Size: 4485 bytes --] Hi, Paul: the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: echo 1 > /proc/sys/kernel/panic_on_rcu_stall echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Monday, December 3, 2018 9:57 PM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> Subject: Re: rcu_preempt caused oom On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > echo 1 > /proc/sys/kernel/panic_on_rcu_stall Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Saturday, December 1, 2018 12:49 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > Here is the kernel cmdline: > > Thank you! > > > Kernel command line: androidboot.acpio_idx=0 > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_0 > > 3- userdebug androidboot.diskbus=00.0 > > androidboot.verifiedbootstate=green > > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > loglevel=4 androidboot.hardware=gordon_peak > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/pro > > pe rties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > drm.vblankoffdelay= > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > rcupdate.rcu_cpu_stall_timeout=7 > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > Thanx, Paul > > > -----Original Message----- > > From: Steven Rostedt <rostedt@goodmis.org> > > Sent: Friday, November 30, 2018 11:17 PM > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, 30 Nov 2018 06:43:17 -0800 > > "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > > > > > Could you please send me your list of kernel boot parameters? > > > They usually appear near the start of your console output. > > > > Or just: cat /proc/cmdline > > > > -- Steve > > > [-- Attachment #2: apanic_console --] [-- Type: application/octet-stream, Size: 27309 bytes --] ------ dmesg-ramoops-0 ------ Panic#1 Part1 <3>[13779.153223] audit: rate limit exceeded <4>[13780.160353] audit: audit_lost=690440 audit_rate_limit=5 audit_backlog_limit=64 <3>[13780.170352] audit: rate limit exceeded <14>[13780.226545] init: starting service 'debug_agent'... <14>[13780.405660] init: Service 'debug_agent' (pid 32351) exited with status 70 <14>[13780.416447] init: Sending signal 9 to service 'debug_agent' (pid 32351) process group... <14>[13780.430939] libprocessgroup: Successfully killed process cgroup uid 0 pid 32351 in 0ms <4>[13781.177110] audit: audit_lost=690499 audit_rate_limit=5 audit_backlog_limit=64 <3>[13781.187444] audit: rate limit exceeded <4>[13782.192568] audit: audit_lost=690555 audit_rate_limit=5 audit_backlog_limit=64 <3>[13782.201014] audit: rate limit exceeded <4>[13783.194380] audit: audit_lost=690610 audit_rate_limit=5 audit_backlog_limit=64 <3>[13783.203275] audit: rate limit exceeded <4>[13784.210115] audit: audit_lost=690666 audit_rate_limit=5 audit_backlog_limit=64 <3>[13784.220006] audit: rate limit exceeded <4>[13785.212464] audit: audit_lost=690721 audit_rate_limit=5 audit_backlog_limit=64 <3>[13785.221243] audit: rate limit exceeded <14>[13785.236808] init: starting service 'debug_agent'... <14>[13785.386785] init: Service 'debug_agent' (pid 32385) exited with status 70 <14>[13785.396580] init: Sending signal 9 to service 'debug_agent' (pid 32385) process group... <14>[13785.408053] libprocessgroup: Successfully killed process cgroup uid 0 pid 32385 in 0ms <4>[13786.227043] audit: audit_lost=690777 audit_rate_limit=5 audit_backlog_limit=64 <3>[13786.235884] audit: rate limit exceeded <3>[13786.701052] intel-ipu4-isys intel-ipu4-isys0: s_stream adv7481-cvbs binner a (ext) <14>[13790.255779] init: starting service 'debug_agent'... <14>[13790.365917] init: Service 'debug_agent' (pid 32448) exited with status 70 <14>[13790.373604] init: Sending signal 9 to service 'debug_agent' (pid 32448) process group... <14>[13790.382956] libprocessgroup: Successfully killed process cgroup uid 0 pid 32448 in 0ms <4>[13791.396951] audit: audit_lost=690794 audit_rate_limit=5 audit_backlog_limit=64 <3>[13791.405795] audit: rate limit exceeded <4>[13792.411961] audit: audit_lost=690850 audit_rate_limit=5 audit_backlog_limit=64 <3>[13792.420716] audit: rate limit exceeded <4>[13793.439561] audit: audit_lost=690905 audit_rate_limit=5 audit_backlog_limit=64 <3>[13793.449001] audit: rate limit exceeded <4>[13794.442841] audit: audit_lost=690961 audit_rate_limit=5 audit_backlog_limit=64 <3>[13794.455426] audit: rate limit exceeded <14>[13795.267814] init: starting service 'debug_agent'... <4>[13795.443212] audit: audit_lost=691016 audit_rate_limit=5 audit_backlog_limit=64 <3>[13795.466740] audit: rate limit exceeded <14>[13795.712849] init: Service 'debug_agent' (pid 32494) exited with status 70 <14>[13795.731214] init: Sending signal 9 to service 'debug_agent' (pid 32494) process group... <14>[13795.771418] libprocessgroup: Successfully killed process cgroup uid 0 pid 32494 in 0ms <4>[13796.459042] audit: audit_lost=691071 audit_rate_limit=5 audit_backlog_limit=64 <3>[13796.479003] audit: rate limit exceeded <4>[13797.475675] audit: audit_lost=691126 audit_rate_limit=5 audit_backlog_limit=64 <3>[13797.489237] audit: rate limit exceeded <4>[13798.493091] audit: audit_lost=691183 audit_rate_limit=5 audit_backlog_limit=64 <3>[13798.501914] audit: rate limit exceeded <4>[13799.511328] audit: audit_lost=691239 audit_rate_limit=5 audit_backlog_limit=64 <3>[13799.519963] audit: rate limit exceeded <14>[13800.280513] init: starting service 'debug_agent'... <14>[13800.476693] init: Service 'debug_agent' (pid 32532) exited with status 70 <14>[13800.485982] init: Sending signal 9 to service 'debug_agent' (pid 32532) process group... <14>[13800.497504] libprocessgroup: Successfully killed process cgroup uid 0 pid 32532 in 0ms <4>[13800.514712] audit: audit_lost=691294 audit_rate_limit=5 audit_backlog_limit=64 <3>[13800.524315] audit: rate limit exceeded <4>[13801.528136] audit: audit_lost=691351 audit_rate_limit=5 audit_backlog_limit=64 <3>[13801.538799] audit: rate limit exceeded <4>[13802.543316] audit: audit_lost=691406 audit_rate_limit=5 audit_backlog_limit=64 <3>[13802.553984] audit: rate limit exceeded <4>[13803.560072] audit: audit_lost=691463 audit_rate_limit=5 audit_backlog_limit=64 <3>[13803.569167] audit: rate limit exceeded <4>[13804.560215] audit: audit_lost=691518 audit_rate_limit=5 audit_backlog_limit=64 <3>[13804.569185] audit: rate limit exceeded <14>[13805.293556] init: starting service 'debug_agent'... <14>[13805.422010] init: Service 'debug_agent' (pid 32562) exited with status 70 <14>[13805.433406] init: Sending signal 9 to service 'debug_agent' (pid 32562) process group... <14>[13805.445611] libprocessgroup: Successfully killed process cgroup uid 0 pid 32562 in 0ms <4>[13805.561516] audit: audit_lost=691573 audit_rate_limit=5 audit_backlog_limit=64 <3>[13805.571786] audit: rate limit exceeded <4>[13806.577300] audit: audit_lost=691629 audit_rate_limit=5 audit_backlog_limit=64 <3>[13806.586640] audit: rate limit exceeded <4>[13807.594459] audit: audit_lost=691685 audit_rate_limit=5 audit_backlog_limit=64 <3>[13807.604212] audit: rate limit exceeded <4>[13808.596727] audit: audit_lost=691745 audit_rate_limit=5 audit_backlog_limit=64 <3>[13808.609646] audit: rate limit exceeded <4>[13809.609380] audit: audit_lost=691801 audit_rate_limit=5 audit_backlog_limit=64 <3>[13809.619058] audit: rate limit exceeded <14>[13810.304952] init: starting service 'debug_agent'... <14>[13810.455048] init: Service 'debug_agent' (pid 32593) exited with status 70 <14>[13810.463918] init: Sending signal 9 to service 'debug_agent' (pid 32593) process group... <14>[13810.487131] libprocessgroup: Successfully killed process cgroup uid 0 pid 32593 in 2ms <4>[13810.628468] audit: audit_lost=691856 audit_rate_limit=5 audit_backlog_limit=64 <3>[13810.637055] audit: rate limit exceeded <4>[13811.643048] audit: audit_lost=691912 audit_rate_limit=5 audit_backlog_limit=64 <3>[13811.652366] audit: rate limit exceeded <4>[13812.643229] audit: audit_lost=691967 audit_rate_limit=5 audit_backlog_limit=64 <3>[13812.653405] audit: rate limit exceeded <4>[13813.645780] audit: audit_lost=692022 audit_rate_limit=5 audit_backlog_limit=64 <3>[13813.654312] audit: rate limit exceeded <4>[13814.661025] audit: audit_lost=692078 audit_rate_limit=5 audit_backlog_limit=64 <3>[13814.669532] audit: rate limit exceeded <14>[13815.315636] init: starting service 'debug_agent'... <14>[13815.447292] init: Service 'debug_agent' (pid 32623) exited with status 70 <14>[13815.455732] init: Sending signal 9 to service 'debug_agent' (pid 32623) process group... <14>[13815.468066] libprocessgroup: Successfully killed process cgroup uid 0 pid 32623 in 0ms <4>[13815.675966] audit: audit_lost=692134 audit_rate_limit=5 audit_backlog_limit=64 <3>[13815.684463] audit: rate limit exceeded <4>[13816.677400] audit: audit_lost=692190 audit_rate_limit=5 audit_backlog_limit=64 <3>[13816.686615] audit: rate limit exceeded <4>[13817.695655] audit: audit_lost=692246 audit_rate_limit=5 audit_backlog_limit=64 <3>[13817.717991] audit: rate limit exceeded <4>[13818.712874] audit: audit_lost=692302 audit_rate_limit=5 audit_backlog_limit=64 <3>[13818.728206] audit: rate limit exceeded <4>[13819.725729] audit: audit_lost=692357 audit_rate_limit=5 audit_backlog_limit=64 <3>[13819.734949] audit: rate limit exceeded <14>[13820.326753] init: starting service 'debug_agent'... <14>[13820.464581] init: Service 'debug_agent' (pid 32650) exited with status 70 <14>[13820.474653] init: Sending signal 9 to service 'debug_agent' (pid 32650) process group... <14>[13820.490546] libprocessgroup: Successfully killed process cgroup uid 0 pid 32650 in 3ms <4>[13820.727000] audit: audit_lost=692412 audit_rate_limit=5 audit_backlog_limit=64 <3>[13820.735698] audit: rate limit exceeded <4>[13821.742526] audit: audit_lost=692468 audit_rate_limit=5 audit_backlog_limit=64 <3>[13821.751341] audit: rate limit exceeded <4>[13822.759612] audit: audit_lost=692524 audit_rate_limit=5 audit_backlog_limit=64 <3>[13822.776570] audit: rate limit exceeded <4>[13823.760243] audit: audit_lost=692579 audit_rate_limit=5 audit_backlog_limit=64 <3>[13823.769395] audit: rate limit exceeded <4>[13824.779654] audit: audit_lost=692636 audit_rate_limit=5 audit_backlog_limit=64 <3>[13824.789612] audit: rate limit exceeded <14>[13825.344336] init: starting service 'debug_agent'... <14>[13825.519300] init: Service 'debug_agent' (pid 32684) exited with status 70 <14>[13825.527660] init: Sending signal 9 to service 'debug_agent' (pid 32684) process group... <14>[13825.538718] libprocessgroup: Successfully killed process cgroup uid 0 pid 32684 in 0ms <4>[13825.793346] audit: audit_lost=692697 audit_rate_limit=5 audit_backlog_limit=64 <3>[13825.801998] audit: rate limit exceeded <4>[13826.794136] audit: audit_lost=692752 audit_rate_limit=5 audit_backlog_limit=64 <3>[13826.804085] audit: rate limit exceeded <4>[13827.811982] audit: audit_lost=692808 audit_rate_limit=5 audit_backlog_limit=64 <3>[13827.827172] audit: rate limit exceeded <4>[13828.827196] audit: audit_lost=692864 audit_rate_limit=5 audit_backlog_limit=64 <3>[13828.836416] audit: rate limit exceeded <4>[13829.842615] audit: audit_lost=692921 audit_rate_limit=5 audit_backlog_limit=64 <3>[13829.852802] audit: rate limit exceeded <14>[13830.355797] init: starting service 'debug_agent'... <14>[13830.507622] init: Service 'debug_agent' (pid 32708) exited with status 70 <14>[13830.516886] init: Sending signal 9 to service 'debug_agent' (pid 32708) process group... <14>[13830.528319] libprocessgroup: Successfully killed process cgroup uid 0 pid 32708 in 0ms <4>[13830.844066] audit: audit_lost=692977 audit_rate_limit=5 audit_backlog_limit=64 <3>[13830.852696] audit: rate limit exceeded <4>[13831.845320] audit: audit_lost=693032 audit_rate_limit=5 audit_backlog_limit=64 <3>[13831.854157] audit: rate limit exceeded <4>[13832.861568] audit: audit_lost=693088 audit_rate_limit=5 audit_backlog_limit=64 <3>[13832.870825] audit: rate limit exceeded <4>[13833.878482] audit: audit_lost=693147 audit_rate_limit=5 audit_backlog_limit=64 <3>[13833.887073] audit: rate limit exceeded <4>[13834.892508] audit: audit_lost=693203 audit_rate_limit=5 audit_backlog_limit=64 <3>[13834.911311] audit: rate limit exceeded <14>[13835.372761] init: starting service 'debug_agent'... <14>[13835.497950] init: Service 'debug_agent' (pid 32743) exited with status 70 <14>[13835.506290] init: Sending signal 9 to service 'debug_agent' (pid 32743) process group... <14>[13835.544709] libprocessgroup: Successfully killed process cgroup uid 0 pid 32743 in 0ms <4>[13835.893585] audit: audit_lost=693258 audit_rate_limit=5 audit_backlog_limit=64 <3>[13835.902003] audit: rate limit exceeded <4>[13836.910635] audit: audit_lost=693314 audit_rate_limit=5 audit_backlog_limit=64 <3>[13836.919291] audit: rate limit exceeded <4>[13837.926840] audit: audit_lost=693370 audit_rate_limit=5 audit_backlog_limit=64 <3>[13837.936410] audit: rate limit exceeded <4>[13838.927836] audit: audit_lost=693425 audit_rate_limit=5 audit_backlog_limit=64 <3>[13838.936387] audit: rate limit exceeded <4>[13839.942410] audit: audit_lost=693481 audit_rate_limit=5 audit_backlog_limit=64 <3>[13839.955044] audit: rate limit exceeded <14>[13840.386753] init: starting service 'debug_agent'... <14>[13840.549743] init: Service 'debug_agent' (pid 302) exited with status 70 <14>[13840.558129] init: Sending signal 9 to service 'debug_agent' (pid 302) process group... <14>[13840.568512] libprocessgroup: Successfully killed process cgroup uid 0 pid 302 in 0ms <4>[13840.943739] audit: audit_lost=693536 audit_rate_limit=5 audit_backlog_limit=64 <3>[13840.953269] audit: rate limit exceeded <4>[13841.961141] audit: audit_lost=693592 audit_rate_limit=5 audit_backlog_limit=64 <3>[13841.971791] audit: rate limit exceeded <4>[13842.975810] audit: audit_lost=693648 audit_rate_limit=5 audit_backlog_limit=64 <3>[13842.984162] audit: rate limit exceeded <4>[13843.977643] audit: audit_lost=693703 audit_rate_limit=5 audit_backlog_limit=64 <3>[13843.986506] audit: rate limit exceeded <4>[13844.995081] audit: audit_lost=693759 audit_rate_limit=5 audit_backlog_limit=64 <3>[13845.003677] audit: rate limit exceeded <14>[13845.397711] init: starting service 'debug_agent'... <14>[13845.526363] init: Service 'debug_agent' (pid 332) exited with status 70 <14>[13845.535698] init: Sending signal 9 to service 'debug_agent' (pid 332) process group... <14>[13845.547495] libprocessgroup: Successfully killed process cgroup uid 0 pid 332 in 0ms <4>[13846.011447] audit: audit_lost=693816 audit_rate_limit=5 audit_backlog_limit=64 <3>[13846.020434] audit: rate limit exceeded <4>[13847.028494] audit: audit_lost=693873 audit_rate_limit=5 audit_backlog_limit=64 <3>[13847.037375] audit: rate limit exceeded <4>[13848.045169] audit: audit_lost=693929 audit_rate_limit=5 audit_backlog_limit=64 <3>[13848.054529] audit: rate limit exceeded <4>[13849.059433] audit: audit_lost=693985 audit_rate_limit=5 audit_backlog_limit=64 <3>[13849.067955] audit: rate limit exceeded <4>[13850.060928] audit: audit_lost=694040 audit_rate_limit=5 audit_backlog_limit=64 <3>[13850.070003] audit: rate limit exceeded <14>[13850.410677] init: starting service 'debug_agent'... <14>[13850.732984] init: Service 'debug_agent' (pid 360) exited with status 70 <14>[13850.753351] init: Sending signal 9 to service 'debug_agent' (pid 360) process group... <14>[13850.820582] libprocessgroup: Successfully killed process cgroup uid 0 pid 360 in 0ms <4>[13851.061351] audit: audit_lost=694095 audit_rate_limit=5 audit_backlog_limit=64 <3>[13851.071257] audit: rate limit exceeded <4>[13852.077328] audit: audit_lost=694154 audit_rate_limit=5 audit_backlog_limit=64 <3>[13852.085920] audit: rate limit exceeded <4>[13853.092773] audit: audit_lost=694214 audit_rate_limit=5 audit_backlog_limit=64 <3>[13853.101070] audit: rate limit exceeded <4>[13854.095234] audit: audit_lost=694270 audit_rate_limit=5 audit_backlog_limit=64 <3>[13854.103829] audit: rate limit exceeded <4>[13855.109947] audit: audit_lost=694331 audit_rate_limit=5 audit_backlog_limit=64 <3>[13855.120427] audit: rate limit exceeded <14>[13855.432648] init: starting service 'debug_agent'... <14>[13855.634504] init: Service 'debug_agent' (pid 387) exited with status 70 <14>[13855.644675] init: Sending signal 9 to service 'debug_agent' (pid 387) process group... <14>[13855.656458] libprocessgroup: Successfully killed process cgroup uid 0 pid 387 in 0ms <4>[13856.112386] audit: audit_lost=694386 audit_rate_limit=5 audit_backlog_limit=64 <3>[13856.121557] audit: rate limit exceeded <4>[13857.126623] audit: audit_lost=694442 audit_rate_limit=5 audit_backlog_limit=64 <3>[13857.135652] audit: rate limit exceeded <4>[13858.127810] audit: audit_lost=694498 audit_rate_limit=5 audit_backlog_limit=64 <3>[13858.136341] audit: rate limit exceeded <4>[13859.129530] audit: audit_lost=694554 audit_rate_limit=5 audit_backlog_limit=64 <3>[13859.138166] audit: rate limit exceeded <4>[13860.145078] audit: audit_lost=694610 audit_rate_limit=5 audit_backlog_limit=64 <3>[13860.153935] audit: rate limit exceeded <14>[13860.441830] init: starting service 'debug_agent'... <14>[13860.601134] init: Service 'debug_agent' (pid 414) exited with status 70 <14>[13860.610755] init: Sending signal 9 to service 'debug_agent' (pid 414) process group... <14>[13860.621474] libprocessgroup: Successfully killed process cgroup uid 0 pid 414 in 0ms <4>[13861.169824] audit: audit_lost=694666 audit_rate_limit=5 audit_backlog_limit=64 <3>[13861.202945] audit: rate limit exceeded <4>[13862.177060] audit: audit_lost=694720 audit_rate_limit=5 audit_backlog_limit=64 <3>[13862.185738] audit: rate limit exceeded <4>[13863.194052] audit: audit_lost=694776 audit_rate_limit=5 audit_backlog_limit=64 <3>[13863.202758] audit: rate limit exceeded <4>[13864.209941] audit: audit_lost=694832 audit_rate_limit=5 audit_backlog_limit=64 <3>[13864.218780] audit: rate limit exceeded <4>[13865.211058] audit: audit_lost=694888 audit_rate_limit=5 audit_backlog_limit=64 <3>[13865.220721] audit: rate limit exceeded <14>[13865.454811] init: starting service 'debug_agent'... <14>[13865.572718] init: Service 'debug_agent' (pid 448) exited with status 70 <14>[13865.582906] init: Sending signal 9 to service 'debug_agent' (pid 448) process group... <14>[13865.594547] libprocessgroup: Successfully killed process cgroup uid 0 pid 448 in 0ms <4>[13866.212522] audit: audit_lost=694945 audit_rate_limit=5 audit_backlog_limit=64 <3>[13866.221481] audit: rate limit exceeded <4>[13867.227152] audit: audit_lost=695001 audit_rate_limit=5 audit_backlog_limit=64 <3>[13867.235522] audit: rate limit exceeded <4>[13868.243206] audit: audit_lost=695057 audit_rate_limit=5 audit_backlog_limit=64 <3>[13868.251965] audit: rate limit exceeded <4>[13869.244651] audit: audit_lost=695112 audit_rate_limit=5 audit_backlog_limit=64 <3>[13869.254940] audit: rate limit exceeded <4>[13870.259690] audit: audit_lost=695168 audit_rate_limit=5 audit_backlog_limit=64 <3>[13870.270167] audit: rate limit exceeded <14>[13870.467541] init: starting service 'debug_agent'... <14>[13870.612948] init: Service 'debug_agent' (pid 481) exited with status 70 <14>[13870.620736] init: Sending signal 9 to service 'debug_agent' (pid 481) process group... <14>[13870.632327] libprocessgroup: Successfully killed process cgroup uid 0 pid 481 in 0ms <4>[13871.261120] audit: audit_lost=695223 audit_rate_limit=5 audit_backlog_limit=64 <3>[13871.270606] audit: rate limit exceeded <4>[13872.276046] audit: audit_lost=695281 audit_rate_limit=5 audit_backlog_limit=64 <3>[13872.286339] audit: rate limit exceeded <4>[13873.277860] audit: audit_lost=695336 audit_rate_limit=5 audit_backlog_limit=64 <3>[13873.287489] audit: rate limit exceeded <4>[13874.292882] audit: audit_lost=695393 audit_rate_limit=5 audit_backlog_limit=64 <3>[13874.301065] audit: rate limit exceeded <4>[13875.293241] audit: audit_lost=695449 audit_rate_limit=5 audit_backlog_limit=64 <3>[13875.302590] audit: rate limit exceeded <14>[13875.478478] init: starting service 'debug_agent'... <14>[13875.665932] init: Service 'debug_agent' (pid 512) exited with status 70 <14>[13875.676231] init: Sending signal 9 to service 'debug_agent' (pid 512) process group... <14>[13875.685775] libprocessgroup: Successfully killed process cgroup uid 0 pid 512 in 0ms <4>[13876.311255] audit: audit_lost=695506 audit_rate_limit=5 audit_backlog_limit=64 <3>[13876.320814] audit: rate limit exceeded <4>[13877.313172] audit: audit_lost=695561 audit_rate_limit=5 audit_backlog_limit=64 <3>[13877.321768] audit: rate limit exceeded <4>[13878.327050] audit: audit_lost=695617 audit_rate_limit=5 audit_backlog_limit=64 <3>[13878.335978] audit: rate limit exceeded <4>[13879.329021] audit: audit_lost=695674 audit_rate_limit=5 audit_backlog_limit=64 <3>[13879.338237] audit: rate limit exceeded <4>[13880.347326] audit: audit_lost=695730 audit_rate_limit=5 audit_backlog_limit=64 <3>[13880.356289] audit: rate limit exceeded <14>[13880.492764] init: starting service 'debug_agent'... <14>[13880.747150] init: Service 'debug_agent' (pid 538) exited with status 70 <14>[13880.756815] init: Sending signal 9 to service 'debug_agent' (pid 538) process group... <14>[13880.767225] libprocessgroup: Successfully killed process cgroup uid 0 pid 538 in 0ms <4>[13881.362440] audit: audit_lost=695785 audit_rate_limit=5 audit_backlog_limit=64 <3>[13881.371331] audit: rate limit exceeded <4>[13882.377090] audit: audit_lost=695841 audit_rate_limit=5 audit_backlog_limit=64 <3>[13882.386774] audit: rate limit exceeded <4>[13883.393187] audit: audit_lost=695897 audit_rate_limit=5 audit_backlog_limit=64 <3>[13883.401579] audit: rate limit exceeded <4>[13884.412118] audit: audit_lost=695953 audit_rate_limit=5 audit_backlog_limit=64 <3>[13884.421990] audit: rate limit exceeded <4>[13885.428599] audit: audit_lost=696010 audit_rate_limit=5 audit_backlog_limit=64 <3>[13885.437122] audit: rate limit exceeded <14>[13885.506650] init: starting service 'debug_agent'... <14>[13885.649646] init: Service 'debug_agent' (pid 565) exited with status 70 <14>[13885.659804] init: Sending signal 9 to service 'debug_agent' (pid 565) process group... <14>[13885.686166] libprocessgroup: Successfully killed process cgroup uid 0 pid 565 in 6ms <4>[13886.443539] audit: audit_lost=696066 audit_rate_limit=5 audit_backlog_limit=64 <3>[13886.452681] audit: rate limit exceeded <3>[13886.548406] INFO: task queued-work-loo:4180 blocked for more than 120 seconds. <3>[13886.558676] Tainted: G U O 4.19.0-quilt-2e5dc0ac-g3ca10ab2c008 #1 <3>[13886.568214] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. <6>[13886.578470] queued-work-loo D 0 4180 2724 0x80000106 <4>[13886.585683] Call Trace: <4>[13886.589044] __schedule+0x29c/0x890 <4>[13886.594184] ? check_preempt_wakeup+0x12a/0x220 <4>[13886.600340] ? wait_for_completion+0x109/0x1a0 <4>[13886.606223] schedule+0x36/0x90 <4>[13886.610890] schedule_timeout+0x1fc/0x3a0 <4>[13886.617191] ? __switch_to_asm+0x40/0x70 <4>[13886.622443] ? __switch_to_asm+0x34/0x70 <4>[13886.626947] ? __switch_to_asm+0x40/0x70 <4>[13886.631894] ? __switch_to_asm+0x34/0x70 <4>[13886.637400] ? rcu_accelerate_cbs+0x60/0x180 <4>[13886.643576] ? wait_for_completion+0x109/0x1a0 <4>[13886.648913] wait_for_completion+0x131/0x1a0 <4>[13886.653804] ? wake_up_process+0x20/0x20 <4>[13886.659789] __wait_rcu_gp+0x126/0x160 <4>[13886.664841] synchronize_rcu+0x7b/0x90 <4>[13886.669326] ? __call_rcu.constprop.72+0x1a0/0x1a0 <4>[13886.676295] ? __bpf_trace_rcu_utilization+0x10/0x10 <4>[13886.682591] namespace_unlock+0x6a/0x80 <4>[13886.687653] drop_collected_mounts+0x52/0x60 <4>[13886.693975] put_mnt_ns+0x1f/0x40 <4>[13886.698256] free_nsproxy+0x1b/0xa0 <4>[13886.702601] switch_task_namespaces+0x6c/0x80 <4>[13886.709062] exit_task_namespaces+0x10/0x20 <4>[13886.714497] do_exit+0x306/0xbc0 <4>[13886.718276] do_group_exit+0x4a/0xc0 <4>[13886.722496] get_signal+0x26c/0x610 <4>[13886.728166] ? preempt_count_add+0x85/0xd0 <4>[13886.733325] do_signal+0x37/0x6d0 <4>[13886.737266] ? preempt_schedule+0x20/0x30 <4>[13886.743021] ? wake_up_process+0x20/0x20 <4>[13886.748322] exit_to_usermode_loop+0x5d/0xb0 <4>[13886.753363] do_syscall_64+0xe8/0x100 <4>[13886.759313] entry_SYSCALL_64_after_hwframe+0x44/0xa9 <4>[13886.765729] RIP: 0033:0x70c95bf3faaa <4>[13886.769948] Code: Bad RIP value. <4>[13886.773603] RSP: 002b:000070c8c2177d28 EFLAGS: 00000246 ORIG_RAX: 0000000000000119 <4>[13886.784068] RAX: fffffffffffffffc RBX: 00000000ffffffff RCX: 000070c95bf3faaa <4>[13886.793839] RDX: 0000000000000010 RSI: 000070c8c2177d80 RDI: 0000000000000024 <4>[13886.802888] RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000008 <4>[13886.812601] R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000000000 <4>[13886.821703] R13: 000000007fffffff R14: 000070c8d7ae5080 R15: 0000000000000000 <4>[13886.832208] NMI backtrace for cpu 0 <4>[13886.836141] CPU: 0 PID: 341 Comm: khungtaskd Tainted: G U O 4.19.0-quilt-2e5dc0ac-g3ca10ab2c008 #1 <4>[13886.847419] Call Trace: <4>[13886.850156] dump_stack+0x4f/0x65 <4>[13886.853856] nmi_cpu_backtrace+0x91/0xa0 <4>[13886.858239] ? lapic_can_unplug_cpu+0xa0/0xa0 <4>[13886.863106] nmi_trigger_cpumask_backtrace+0xb4/0x100 <4>[13886.868748] arch_trigger_cpumask_backtrace+0x19/0x20 <4>[13886.874392] watchdog+0x284/0x410 <4>[13886.878094] kthread+0x12c/0x150 <4>[13886.881697] ? reset_hung_task_detector+0x20/0x20 <4>[13886.886951] ? kthread_create_worker_on_cpu+0x70/0x70 <4>[13886.892596] ret_from_fork+0x35/0x40 <6>[13886.896625] Sending NMI from CPU 0 to CPUs 1: <4>[13886.901697] NMI backtrace for cpu 1 <4>[13886.901700] CPU: 1 PID: 2915 Comm: HwBinder:2835_1 Tainted: G U O 4.19.0-quilt-2e5dc0ac-g3ca10ab2c008 #1 <4>[13886.901701] RIP: 0010:__rcu_read_lock+0x0/0x20 <4>[13886.901703] Code: 00 48 83 bb a8 00 00 00 00 75 0b 48 8b 53 50 48 85 d2 41 0f 94 c4 48 89 c6 48 89 df e8 d9 31 b6 00 44 89 e0 5b 41 5c 5d c3 90 <0f> 1f 44 00 00 55 48 89 e5 65 48 8b 04 25 c0 4d 01 00 83 80 80 03 <4>[13886.901705] RSP: 0018:ffffac60409a7b60 EFLAGS: 00000046 <4>[13886.901707] RAX: 0000000000000000 RBX: ffff8c325d8b8140 RCX: ffffffffffb52908 <4>[13886.901708] RDX: 000003e461738a03 RSI: ffffffff96b07cec RDI: ffffffff96ae8226 <4>[13886.901709] RBP: ffffac60409a7b90 R08: 0000000000000000 R09: 0000000000021280 <4>[13886.901739] R10: ffffac60409a7c00 R11: 000000000000000b R12: 0000000000017448 <4>[13886.901740] R13: ffff8c3278aa1b40 R14: ffff8c325d8b80c0 R15: ffff8c325d8b80c0 <4>[13886.901741] FS: 00007db24f9a1588(0000) GS:ffff8c3278a80000(0000) knlGS:0000000000000000 <4>[13886.901741] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[13886.901742] CR2: 0000767f40c026b0 CR3: 000000006f7fc000 CR4: 00000000003406e0 <4>[13886.901743] Call Trace: <4>[13886.901743] ? update_curr+0xc5/0x1c0 <4>[13886.901744] dequeue_task_fair+0x42/0x1140 <4>[13886.901745] deactivate_task+0x4a/0xe0 <4>[13886.901745] ? update_rq_clock+0x30/0x80 <4>[13886.901746] __schedule+0xf5/0x890 <4>[13886.901747] schedule+0x36/0x90 <4>[13886.901747] binder_thread_read+0x960/0x1280 <4>[13886.901748] ? binder_alloc_free_buf+0x2a/0x30 <4>[13886.901749] ? finish_wait+0x90/0x90 <4>[13886.901749] ? __might_sleep+0x4a/0x80 <4>[13886.901750] binder_ioctl+0x803/0xb2c <4>[13886.901751] do_vfs_ioctl+0xa9/0x6e0 <4>[13886.901751] ksys_ioctl+0x75/0x80 <4>[13886.901752] __x64_sys_ioctl+0x1a/0x20 <4>[13886.901753] do_syscall_64+0x4d/0x100 <4>[13886.901753] entry_SYSCALL_64_after_hwframe+0x44/0xa9 <4>[13886.901754] RIP: 0033:0x7db25207ebe7 <4>[13886.901756] Code: 00 00 00 b8 60 00 00 00 0f 05 48 3d 01 f0 ff ff 72 09 f7 d8 89 c7 e8 c8 fc ff ff c3 0f 1f 80 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 72 09 f7 d8 89 c7 e8 a8 fc ff ff c3 0f 1f 80 00 <4>[13886.901756] RSP: 002b:00007db24f9a1288 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 <4>[13886.901758] RAX: ffffffffffffffda RBX: 00007db25081f000 RCX: 00007db25207ebe7 <4>[13886.901759] RDX: 00007db24f9a1378 RSI: 00000000c0306201 RDI: 0000000000000003 <4>[13886.901760] RBP: 0000000000000000 R08: 00007db251041140 R09: 0000000000000000 <4>[13886.901760] R10: 0000000000000000 R11: 0000000000000206 R12: 00007db25081f138 <4>[13886.901761] R13: 00007db24f9a1378 R14: 00007db25081f0b0 R15: 0000000000000000 <0>[13886.902710] Kernel panic - not syncing: hung_task: blocked tasks <4>[13887.163284] CPU: 0 PID: 341 Comm: khungtaskd Tainted: G U O 4.19.0-quilt-2e5dc0ac-g3ca10ab2c008 #1 <4>[13887.174557] Call Trace: <4>[13887.177287] dump_stack+0x4f/0x65 <4>[13887.180990] panic+0xde/0x231 <4>[13887.184301] watchdog+0x290/0x410 <4>[13887.188003] kthread+0x12c/0x150 <4>[13887.191606] ? reset_hung_task_detector+0x20/0x20 <4>[13887.196859] ? kthread_create_worker_on_cpu+0x70/0x70 <4>[13887.202503] ret_from_fork+0x35/0x40 <6>[13887.206920] reboot: panic mode set: p,w <0>[13887.211218] Kernel Offset: 0x14000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-04 7:50 ` He, Bo @ 2018-12-04 19:49 ` Paul E. McKenney 2018-12-05 8:42 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-04 19:49 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > Hi, Paul: > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout Not necessarily. If there is an RCU CPU stall warning, blocking within __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. Does that sound likely? Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Monday, December 3, 2018 9:57 PM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Saturday, December 1, 2018 12:49 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > Here is the kernel cmdline: > > > > Thank you! > > > > > Kernel command line: androidboot.acpio_idx=0 > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_0 > > > 3- userdebug androidboot.diskbus=00.0 > > > androidboot.verifiedbootstate=green > > > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > > loglevel=4 androidboot.hardware=gordon_peak > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/pro > > > pe rties/android/ pstore.backend=ramoops memmap=0x1400000$0x50000000 > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > drm.vblankoffdelay= > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Steven Rostedt <rostedt@goodmis.org> > > > Sent: Friday, November 30, 2018 11:17 PM > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 > > > "Paul E. McKenney" <paulmck@linux.ibm.com> wrote: > > > > > > > Could you please send me your list of kernel boot parameters? > > > > They usually appear near the start of your console output. > > > > > > Or just: cat /proc/cmdline > > > > > > -- Steve > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-04 19:49 ` Paul E. McKenney @ 2018-12-05 8:42 ` He, Bo 2018-12-05 17:44 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-05 8:42 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. I will do more experiments and keep you update once we have more findings: 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Wednesday, December 5, 2018 3:50 AM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> Subject: Re: rcu_preempt caused oom On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > Hi, Paul: > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout Not necessarily. If there is an RCU CPU stall warning, blocking within __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. Does that sound likely? Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Monday, December 3, 2018 9:57 PM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > <yanmin.zhang@intel.com> > Subject: Re: rcu_preempt caused oom > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Saturday, December 1, 2018 12:49 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > Here is the kernel cmdline: > > > > Thank you! > > > > > Kernel command line: androidboot.acpio_idx=0 > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06 > > > _0 > > > 3- userdebug androidboot.diskbus=00.0 > > > androidboot.verifiedbootstate=green > > > androidboot.bootreason=power-on > > > androidboot.serialno=R1J56L6006a7bb > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > > loglevel=4 androidboot.hardware=gordon_peak > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/p > > > ro pe rties/android/ pstore.backend=ramoops > > > memmap=0x1400000$0x50000000 > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > drm.vblankoffdelay= > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Steven Rostedt <rostedt@goodmis.org> > > > Sent: Friday, November 30, 2018 11:17 PM > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, > > > Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > <paulmck@linux.ibm.com> wrote: > > > > > > > Could you please send me your list of kernel boot parameters? > > > > They usually appear near the start of your console output. > > > > > > Or just: cat /proc/cmdline > > > > > > -- Steve > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-05 8:42 ` He, Bo @ 2018-12-05 17:44 ` Paul E. McKenney [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A16C46@SHSMSX104.ccr.corp.intel.com> 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-05 17:44 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Wed, Dec 05, 2018 at 08:42:54AM +0000, He, Bo wrote: > I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . > Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. Hmmm... Well, the tasks could in theory be waiting on a blocking mutex. But in practice the grace-period kthreads wait on events, so that makes no sense. Is it possible for you to dump out the grace-period kthread's stack, for example, with sysreq-t? (Steve might know a better way to do this.) > I will do more experiments and keep you update once we have more findings: > 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. That sounds like a most excellent experiment! > 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". As noted earlier, to see something interesting, you will need to start the ftrace before the grace period starts. This would probably mean having ftrace running before starting the test. Starting the ftrace after the hang commences is unlikely to produce useful information. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Wednesday, December 5, 2018 3:50 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > > Hi, Paul: > > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout > > Not necessarily. If there is an RCU CPU stall warning, blocking within > __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. > > CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. > > Does that sound likely? > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Monday, December 3, 2018 9:57 PM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Saturday, December 1, 2018 12:49 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > > Here is the kernel cmdline: > > > > > > Thank you! > > > > > > > Kernel command line: androidboot.acpio_idx=0 > > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06 > > > > _0 > > > > 3- userdebug androidboot.diskbus=00.0 > > > > androidboot.verifiedbootstate=green > > > > androidboot.bootreason=power-on > > > > androidboot.serialno=R1J56L6006a7bb > > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > > > loglevel=4 androidboot.hardware=gordon_peak > > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/p > > > > ro pe rties/android/ pstore.backend=ramoops > > > > memmap=0x1400000$0x50000000 > > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > > drm.vblankoffdelay= > > > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > Sent: Friday, November 30, 2018 11:17 PM > > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, > > > > Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > > <paulmck@linux.ibm.com> wrote: > > > > > > > > > Could you please send me your list of kernel boot parameters? > > > > > They usually appear near the start of your console output. > > > > > > > > Or just: cat /proc/cmdline > > > > > > > > -- Steve > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CD6925E8781EFD4D8E11882D20FC406D52A16C46@SHSMSX104.ccr.corp.intel.com>]
* Re: rcu_preempt caused oom [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A16C46@SHSMSX104.ccr.corp.intel.com> @ 2018-12-06 17:38 ` Paul E. McKenney [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A180C5@SHSMSX104.ccr.corp.intel.com> 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-06 17:38 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Thu, Dec 06, 2018 at 01:23:01PM +0000, He, Bo wrote: > 1. The test is positive after set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST, the issue is not reproduced until now. > 2. Here is previous log enable the ftrace_dump, and we can get 4 seconds ftrace. The panic log was triggered with the enclosed debug patch, replaced the wait_for_completion(&rs_array[i].completion) with wait_for_completion_timeout(&rs_array[i].completion, 3*HZ) in __wait_rcu_gp(). The logs enabled the lockdep to dump the locks, and dump all tasks backtrace. Thank you for collecting this information! (By the way, the usual downside of the priority increase is increased context-switch rate and thus CPU overhead.) And all three grace-period kthreads are blocked apparently in their top-level loops (though inlining and all that). There are quite a few preemptions ("72738.702815: rcu_preempt_task: rcu_preempt"), but they are all blocking the next grace period (29041008), not the current one (29041004). And the "rcu_unlock_preempted_task" trace records flag the current grace-period sequence number as 29041004, which means that there is no grace period in progress, that is, RCU is idle. Which explains why there is no RCU CPU stall warning -- after all, if there is no grace period in flight, it is not possible to stall that non-existent grace period. That also could explain why increasing the priority of the grace-period kthreads gets things going again. There have been a great number of requests for a new grace period (for example, "rcu_future_grace_period: rcu_preempt 29041004 29041008 0 0 3 Startleaf"), so as soon as the grace-period kthread wakes up, a new grace period will start. Except that the rcu_preempt task says "I" rather than "R", as you noted in an earlier email. And there should have been multiple attempts to wake up the grace-period kthread, because there are lots of callbacks queued as in 136,045 of them ("rcu_callback: rcu_preempt rhp=0000000066f735c9 func=file_free_rcu 2811/136045"). Which is of course why you are seeing the OOM. So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" In the past, there was a scheduler bug that could cause that, but that was -way- before the v4.19 that you are running. More recently, there have been timer-related problems, but those only happened while a grace period was active, and where also long before v4.19. Hmmm... One possibility is that you have somehow managed to invoke call_rcu() with interrupts disabled, which would in turn disable the extra wakeups that RCU sends when it sees excessive numbers of callbacks. Except that in that case, boosting the priority wouldn't help. Besides, the scheduling-clock interrupt should also check for this, and should push things forward if need be. If RCU managed to put all of its callbacks into the RCU_NEXT_READY_TAIL bucket on all CPUs, that would defeat the wakeup-if-no-grace-period checks (RCU is supposed to have started the relevant grace period before putting callbacks into that bucket). But that cannot be the case here, because new callbacks are being enqueued throughout, and these would then trigger RCU's start-a-new-grace-period checks. But it would be good to confirm that this is actually working like I would expect it to. Could you please add scheduler wakeup to your tracing, if possible, only displaying those sent to the rcu_preempt task? Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, December 6, 2018 1:45 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Wed, Dec 05, 2018 at 08:42:54AM +0000, He, Bo wrote: > > I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . > > Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. > > Hmmm... Well, the tasks could in theory be waiting on a blocking mutex. > But in practice the grace-period kthreads wait on events, so that makes no sense. > > Is it possible for you to dump out the grace-period kthread's stack, for example, with sysreq-t? (Steve might know a better way to do this.) > > > I will do more experiments and keep you update once we have more findings: > > 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. > > That sounds like a most excellent experiment! > > > 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". > > As noted earlier, to see something interesting, you will need to start the ftrace before the grace period starts. This would probably mean having ftrace running before starting the test. Starting the ftrace after the hang commences is unlikely to produce useful information. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Wednesday, December 5, 2018 3:50 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > > > Hi, Paul: > > > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout > > > > Not necessarily. If there is an RCU CPU stall warning, blocking > > within > > __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. > > > > CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. > > > > Does that sound likely? > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Monday, December 3, 2018 9:57 PM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > > > > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > > > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Saturday, December 1, 2018 12:49 AM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > > > Here is the kernel cmdline: > > > > > > > > Thank you! > > > > > > > > > Kernel command line: androidboot.acpio_idx=0 > > > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger- > > > > > 06 > > > > > _0 > > > > > 3- userdebug androidboot.diskbus=00.0 > > > > > androidboot.verifiedbootstate=green > > > > > androidboot.bootreason=power-on > > > > > androidboot.serialno=R1J56L6006a7bb > > > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > > > > > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > > > > > loglevel=4 androidboot.hardware=gordon_peak > > > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00 > > > > > /p ro pe rties/android/ pstore.backend=ramoops > > > > > memmap=0x1400000$0x50000000 > > > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > > > drm.vblankoffdelay= > > > > > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > > Sent: Friday, November 30, 2018 11:17 PM > > > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, > > > > > Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > > > <paulmck@linux.ibm.com> wrote: > > > > > > > > > > > Could you please send me your list of kernel boot parameters? > > > > > > They usually appear near the start of your console output. > > > > > > > > > > Or just: cat /proc/cmdline > > > > > > > > > > -- Steve > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CD6925E8781EFD4D8E11882D20FC406D52A180C5@SHSMSX104.ccr.corp.intel.com>]
* Re: rcu_preempt caused oom [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A180C5@SHSMSX104.ccr.corp.intel.com> @ 2018-12-07 14:11 ` Paul E. McKenney 2018-12-09 19:56 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-07 14:11 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Fri, Dec 07, 2018 at 08:25:09AM +0000, He, Bo wrote: > Bad news, the issue is still reproduced after 61 Hours monkey test on 1/6 boards with the CONFIG_RCU_BOOST=y, and the issue is not seen on kernel 4.14, the CONFIG_RCU_BOOST is also not enabled in our kernel 4.14 config. > Here enclosed is the logs. > > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" > maybe it's not schedule issue, I have two suspects: > we can see tons of grace_period with 117392312: > [219346.919405, 0] showmap-31232 [000] d..1 219346.136035: rcu_future_grace_period: rcu_preempt 117392312 117392316 0 0 3 Startleaf > [219346.919417, 0] showmap-31232 [000] d..1 219346.136036: rcu_future_grace_period: rcu_preempt 117392312 117392316 0 0 3 Prestarted > [219346.919429, 0] showmap-31232 [000] d..1 219346.136036: rcu_grace_period: rcu_preempt 117392312 AccWaitCB > > "Startleaf" means start the grace period, "Prestarted" means the grace period is already started or other conditions blocked, RCU_GP_FLAG_INIT should follow the "Startedroot", then the kthread can be wakeup. Yes, when "Startleaf" is followed by "Prestarted", that means that we reached an rcu_node structure that is already aware that the requested grace period is needed. Breaking down the relevant "if" statement in rcu_start_this_gp(): if (ULONG_CMP_GE(rnp->gp_seq_needed, gp_seq_req) || // A. GP already requested at this rcu_node rcu_seq_started(&rnp->gp_seq, gp_seq_req) || // B. The requested grace period already started (rnp != rnp_start && rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))) { // C. Leaf rcu_node recorded request, and // some grace period is in progress A: In this case, the "Startedroot" should be taken care of by some other thread, or one of B or C held earlier. B: This cannot be the case, because your earlier trace showed that the requested grace period had not started. C: This cannot be the case because both traces above are on the leaf rcu_node structure. If it were the case, the currently running grace period would notice the need for the requested grace period when it ended, and would start the grace period at that time. So you are saying that your trace goes back far enough to capture the very first "Startleaf" for this new grace period, and you don't ever see a "Startedroot"? This would be OK if the later "Startedleaf" showed up at that point. If you do have such a trace, could you please send it to me (or post it somewhere and send me the URL)? In any case, this code has bee reworked recently, so I will take a closer look, which will take some time. Please feel free to continue to do so as well, of course! > I do experiment to dump the backtrace, the rcu_quiescent_state_report is called in softirq context: > <idle>-0 [000] dNs2 24471.669280: rcu_quiescent_state_report: rcu_preempt 3562401 1>0 0 0 3 0 > <idle>-0 [000] dNs2 24471.669293: <stack trace> > => rcu_report_qs_rnp+0x1e2/0x2a0 > => rcu_process_callbacks+0x2f1/0x3c0 > => __do_softirq+0x12a/0x386 > => irq_exit+0xb1/0xc0 > => smp_apic_timer_interrupt+0xd4/0x1e0 > => apic_timer_interrupt+0xf/0x20 > => cpuidle_enter_state+0xb1/0x340 > => cpuidle_enter+0x17/0x20 > => call_cpuidle+0x23/0x40 > => do_idle+0x1ed/0x250 > => cpu_startup_entry+0x73/0x80 > => rest_init+0xf3/0x100 > => start_kernel+0x46f/0x490 > => x86_64_start_reservations+0x2a/0x2c > => x86_64_start_kernel+0x72/0x75 > => secondary_startup_64+0xa4/0xb0 > rcu_report_qs_rnp=>rcu_report_qs_rdp > > and in the rcu_report_qs_rdp(), rcu_report_qs_rnp is follow the rcu_accelerate_cbs, we can see AccWaitCB log, but can't see rcu_quiescent_state_report, mostly it's due to condition rnp->qsmask & mask blocked. > > static void > rcu_report_qs_rdp(int cpu, struct rcu_state *rsp, struct rcu_data *rdp) > { > ... > if ((rnp->qsmask & mask) == 0) { > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > } else { > rdp->core_needs_qs = false; > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > if (needwake) > rcu_gp_kthread_wake(rsp); > } > } This is a completely different code path. The rcu_start_this_gp() function is trying to start a new grace period. In contrast, this rcu_report_qs_rdp() function reports a quiescent state for a currently running grace period. In your earlier trace, there was no currently running grace period, so rcu_report_qs_rdp() exiting early is expected behavior. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Friday, December 7, 2018 1:38 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 06, 2018 at 01:23:01PM +0000, He, Bo wrote: > > 1. The test is positive after set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST, the issue is not reproduced until now. > > 2. Here is previous log enable the ftrace_dump, and we can get 4 seconds ftrace. The panic log was triggered with the enclosed debug patch, replaced the wait_for_completion(&rs_array[i].completion) with wait_for_completion_timeout(&rs_array[i].completion, 3*HZ) in __wait_rcu_gp(). The logs enabled the lockdep to dump the locks, and dump all tasks backtrace. > > Thank you for collecting this information! > > (By the way, the usual downside of the priority increase is increased context-switch rate and thus CPU overhead.) > > And all three grace-period kthreads are blocked apparently in their top-level loops (though inlining and all that). There are quite a few preemptions ("72738.702815: rcu_preempt_task: rcu_preempt"), but they are all blocking the next grace period (29041008), not the current one (29041004). And the "rcu_unlock_preempted_task" trace records flag the current grace-period sequence number as 29041004, which means that there is no grace period in progress, that is, RCU is idle. > > Which explains why there is no RCU CPU stall warning -- after all, if there is no grace period in flight, it is not possible to stall that non-existent grace period. > > That also could explain why increasing the priority of the grace-period kthreads gets things going again. There have been a great number of requests for a new grace period (for example, "rcu_future_grace_period: > rcu_preempt 29041004 29041008 0 0 3 Startleaf"), so as soon as the grace-period kthread wakes up, a new grace period will start. > > Except that the rcu_preempt task says "I" rather than "R", as you noted in an earlier email. > > And there should have been multiple attempts to wake up the grace-period kthread, because there are lots of callbacks queued as in 136,045 of them ("rcu_callback: rcu_preempt rhp=0000000066f735c9 func=file_free_rcu 2811/136045"). Which is of course why you are seeing the OOM. > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" In the past, there was a scheduler bug that could cause that, but that was -way- before the v4.19 that you are running. More recently, there have been timer-related problems, but those only happened while a grace period was active, and where also long before v4.19. > > Hmmm... One possibility is that you have somehow managed to invoke > call_rcu() with interrupts disabled, which would in turn disable the extra wakeups that RCU sends when it sees excessive numbers of callbacks. > Except that in that case, boosting the priority wouldn't help. Besides, the scheduling-clock interrupt should also check for this, and should push things forward if need be. > > If RCU managed to put all of its callbacks into the RCU_NEXT_READY_TAIL bucket on all CPUs, that would defeat the wakeup-if-no-grace-period checks (RCU is supposed to have started the relevant grace period before putting callbacks into that bucket). But that cannot be the case here, because new callbacks are being enqueued throughout, and these would then trigger RCU's start-a-new-grace-period checks. > > But it would be good to confirm that this is actually working like I would expect it to. Could you please add scheduler wakeup to your tracing, if possible, only displaying those sent to the rcu_preempt task? > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Thursday, December 6, 2018 1:45 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Wed, Dec 05, 2018 at 08:42:54AM +0000, He, Bo wrote: > > > I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . > > > Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. > > > > Hmmm... Well, the tasks could in theory be waiting on a blocking mutex. > > But in practice the grace-period kthreads wait on events, so that makes no sense. > > > > Is it possible for you to dump out the grace-period kthread's stack, > > for example, with sysreq-t? (Steve might know a better way to do > > this.) > > > > > I will do more experiments and keep you update once we have more findings: > > > 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. > > > > That sounds like a most excellent experiment! > > > > > 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". > > > > As noted earlier, to see something interesting, you will need to start the ftrace before the grace period starts. This would probably mean having ftrace running before starting the test. Starting the ftrace after the hang commences is unlikely to produce useful information. > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Wednesday, December 5, 2018 3:50 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > > > > Hi, Paul: > > > > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout > > > > > > Not necessarily. If there is an RCU CPU stall warning, blocking > > > within > > > __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. > > > > > > CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. > > > > > > Does that sound likely? > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Monday, December 3, 2018 9:57 PM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > > > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > > > > > > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > > > > > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > > > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Sent: Saturday, December 1, 2018 12:49 AM > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > Zhang, Yanmin <yanmin.zhang@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > > > > Here is the kernel cmdline: > > > > > > > > > > Thank you! > > > > > > > > > > > Kernel command line: androidboot.acpio_idx=0 > > > > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinge > > > > > > r- > > > > > > 06 > > > > > > _0 > > > > > > 3- userdebug androidboot.diskbus=00.0 > > > > > > androidboot.verifiedbootstate=green > > > > > > androidboot.bootreason=power-on > > > > > > androidboot.serialno=R1J56L6006a7bb > > > > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr > > > > > > nopti ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off > > > > > > gpt > > > > > > loglevel=4 androidboot.hardware=gordon_peak > > > > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001: > > > > > > 00 /p ro pe rties/android/ pstore.backend=ramoops > > > > > > memmap=0x1400000$0x50000000 > > > > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > > > > drm.vblankoffdelay= > > > > > > > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > > > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > > > > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > > > > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > > > > > > > Thanx, Paul > > > > > > > > > > > -----Original Message----- > > > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > > > Sent: Friday, November 30, 2018 11:17 PM > > > > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; > > > > > > Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > > > > <yanmin.zhang@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > > > > <paulmck@linux.ibm.com> wrote: > > > > > > > > > > > > > Could you please send me your list of kernel boot parameters? > > > > > > > They usually appear near the start of your console output. > > > > > > > > > > > > Or just: cat /proc/cmdline > > > > > > > > > > > > -- Steve > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-07 14:11 ` Paul E. McKenney @ 2018-12-09 19:56 ` Paul E. McKenney 2018-12-10 6:56 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-09 19:56 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Fri, Dec 07, 2018 at 06:11:31AM -0800, Paul E. McKenney wrote: > On Fri, Dec 07, 2018 at 08:25:09AM +0000, He, Bo wrote: > > Bad news, the issue is still reproduced after 61 Hours monkey test on 1/6 boards with the CONFIG_RCU_BOOST=y, and the issue is not seen on kernel 4.14, the CONFIG_RCU_BOOST is also not enabled in our kernel 4.14 config. > > Here enclosed is the logs. > > > > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" > > maybe it's not schedule issue, I have two suspects: > > we can see tons of grace_period with 117392312: > > [219346.919405, 0] showmap-31232 [000] d..1 219346.136035: rcu_future_grace_period: rcu_preempt 117392312 117392316 0 0 3 Startleaf > > [219346.919417, 0] showmap-31232 [000] d..1 219346.136036: rcu_future_grace_period: rcu_preempt 117392312 117392316 0 0 3 Prestarted > > [219346.919429, 0] showmap-31232 [000] d..1 219346.136036: rcu_grace_period: rcu_preempt 117392312 AccWaitCB > > > > "Startleaf" means start the grace period, "Prestarted" means the grace period is already started or other conditions blocked, RCU_GP_FLAG_INIT should follow the "Startedroot", then the kthread can be wakeup. > > Yes, when "Startleaf" is followed by "Prestarted", that means that we > reached an rcu_node structure that is already aware that the requested > grace period is needed. Breaking down the relevant "if" statement in > rcu_start_this_gp(): > > if (ULONG_CMP_GE(rnp->gp_seq_needed, gp_seq_req) || > // A. GP already requested at this rcu_node > rcu_seq_started(&rnp->gp_seq, gp_seq_req) || > // B. The requested grace period already started > (rnp != rnp_start && > rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))) { > // C. Leaf rcu_node recorded request, and > // some grace period is in progress > > A: In this case, the "Startedroot" should be taken care of by some > other thread, or one of B or C held earlier. > > B: This cannot be the case, because your earlier trace showed that > the requested grace period had not started. > > C: This cannot be the case because both traces above are on the > leaf rcu_node structure. If it were the case, the currently > running grace period would notice the need for the requested > grace period when it ended, and would start the grace period > at that time. > > So you are saying that your trace goes back far enough to capture the > very first "Startleaf" for this new grace period, and you don't ever see a > "Startedroot"? This would be OK if the later "Startedleaf" showed up at > that point. If you do have such a trace, could you please send it to me > (or post it somewhere and send me the URL)? > > In any case, this code has bee reworked recently, so I will take a closer > look, which will take some time. Please feel free to continue to do so > as well, of course! Hmmm... Could you please build with CONFIG_PROVE_RCU=y and run the original (for example, CONFIG_RCU_BOOST=n)? I would expect this to trigger the warning in rcu_check_gp_start_stall(). Of course, if it does not trigger, that would be valuable information as well. Thanx, Paul > > I do experiment to dump the backtrace, the rcu_quiescent_state_report is called in softirq context: > > <idle>-0 [000] dNs2 24471.669280: rcu_quiescent_state_report: rcu_preempt 3562401 1>0 0 0 3 0 > > <idle>-0 [000] dNs2 24471.669293: <stack trace> > > => rcu_report_qs_rnp+0x1e2/0x2a0 > > => rcu_process_callbacks+0x2f1/0x3c0 > > => __do_softirq+0x12a/0x386 > > => irq_exit+0xb1/0xc0 > > => smp_apic_timer_interrupt+0xd4/0x1e0 > > => apic_timer_interrupt+0xf/0x20 > > => cpuidle_enter_state+0xb1/0x340 > > => cpuidle_enter+0x17/0x20 > > => call_cpuidle+0x23/0x40 > > => do_idle+0x1ed/0x250 > > => cpu_startup_entry+0x73/0x80 > > => rest_init+0xf3/0x100 > > => start_kernel+0x46f/0x490 > > => x86_64_start_reservations+0x2a/0x2c > > => x86_64_start_kernel+0x72/0x75 > > => secondary_startup_64+0xa4/0xb0 > > rcu_report_qs_rnp=>rcu_report_qs_rdp > > > > and in the rcu_report_qs_rdp(), rcu_report_qs_rnp is follow the rcu_accelerate_cbs, we can see AccWaitCB log, but can't see rcu_quiescent_state_report, mostly it's due to condition rnp->qsmask & mask blocked. > > > > static void > > rcu_report_qs_rdp(int cpu, struct rcu_state *rsp, struct rcu_data *rdp) > > { > > ... > > if ((rnp->qsmask & mask) == 0) { > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > } else { > > rdp->core_needs_qs = false; > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > } > > } > > This is a completely different code path. The rcu_start_this_gp() > function is trying to start a new grace period. In contrast, this > rcu_report_qs_rdp() function reports a quiescent state for a currently > running grace period. In your earlier trace, there was no currently > running grace period, so rcu_report_qs_rdp() exiting early is expected > behavior. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Friday, December 7, 2018 1:38 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 06, 2018 at 01:23:01PM +0000, He, Bo wrote: > > > 1. The test is positive after set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST, the issue is not reproduced until now. > > > 2. Here is previous log enable the ftrace_dump, and we can get 4 seconds ftrace. The panic log was triggered with the enclosed debug patch, replaced the wait_for_completion(&rs_array[i].completion) with wait_for_completion_timeout(&rs_array[i].completion, 3*HZ) in __wait_rcu_gp(). The logs enabled the lockdep to dump the locks, and dump all tasks backtrace. > > > > Thank you for collecting this information! > > > > (By the way, the usual downside of the priority increase is increased context-switch rate and thus CPU overhead.) > > > > And all three grace-period kthreads are blocked apparently in their top-level loops (though inlining and all that). There are quite a few preemptions ("72738.702815: rcu_preempt_task: rcu_preempt"), but they are all blocking the next grace period (29041008), not the current one (29041004). And the "rcu_unlock_preempted_task" trace records flag the current grace-period sequence number as 29041004, which means that there is no grace period in progress, that is, RCU is idle. > > > > Which explains why there is no RCU CPU stall warning -- after all, if there is no grace period in flight, it is not possible to stall that non-existent grace period. > > > > That also could explain why increasing the priority of the grace-period kthreads gets things going again. There have been a great number of requests for a new grace period (for example, "rcu_future_grace_period: > > rcu_preempt 29041004 29041008 0 0 3 Startleaf"), so as soon as the grace-period kthread wakes up, a new grace period will start. > > > > Except that the rcu_preempt task says "I" rather than "R", as you noted in an earlier email. > > > > And there should have been multiple attempts to wake up the grace-period kthread, because there are lots of callbacks queued as in 136,045 of them ("rcu_callback: rcu_preempt rhp=0000000066f735c9 func=file_free_rcu 2811/136045"). Which is of course why you are seeing the OOM. > > > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" In the past, there was a scheduler bug that could cause that, but that was -way- before the v4.19 that you are running. More recently, there have been timer-related problems, but those only happened while a grace period was active, and where also long before v4.19. > > > > Hmmm... One possibility is that you have somehow managed to invoke > > call_rcu() with interrupts disabled, which would in turn disable the extra wakeups that RCU sends when it sees excessive numbers of callbacks. > > Except that in that case, boosting the priority wouldn't help. Besides, the scheduling-clock interrupt should also check for this, and should push things forward if need be. > > > > If RCU managed to put all of its callbacks into the RCU_NEXT_READY_TAIL bucket on all CPUs, that would defeat the wakeup-if-no-grace-period checks (RCU is supposed to have started the relevant grace period before putting callbacks into that bucket). But that cannot be the case here, because new callbacks are being enqueued throughout, and these would then trigger RCU's start-a-new-grace-period checks. > > > > But it would be good to confirm that this is actually working like I would expect it to. Could you please add scheduler wakeup to your tracing, if possible, only displaying those sent to the rcu_preempt task? > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Thursday, December 6, 2018 1:45 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Wed, Dec 05, 2018 at 08:42:54AM +0000, He, Bo wrote: > > > > I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . > > > > Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. > > > > > > Hmmm... Well, the tasks could in theory be waiting on a blocking mutex. > > > But in practice the grace-period kthreads wait on events, so that makes no sense. > > > > > > Is it possible for you to dump out the grace-period kthread's stack, > > > for example, with sysreq-t? (Steve might know a better way to do > > > this.) > > > > > > > I will do more experiments and keep you update once we have more findings: > > > > 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. > > > > > > That sounds like a most excellent experiment! > > > > > > > 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". > > > > > > As noted earlier, to see something interesting, you will need to start the ftrace before the grace period starts. This would probably mean having ftrace running before starting the test. Starting the ftrace after the hang commences is unlikely to produce useful information. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Wednesday, December 5, 2018 3:50 AM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > > > > > Hi, Paul: > > > > > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout > > > > > > > > Not necessarily. If there is an RCU CPU stall warning, blocking > > > > within > > > > __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. > > > > > > > > CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. > > > > > > > > Does that sound likely? > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Sent: Monday, December 3, 2018 9:57 PM > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > > Yanmin <yanmin.zhang@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > > > > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > > > > > > > > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > > > > > > > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > > > > > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > > > > > > > > > Thanx, Paul > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Sent: Saturday, December 1, 2018 12:49 AM > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > > Zhang, Yanmin <yanmin.zhang@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > > > > > Here is the kernel cmdline: > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > Kernel command line: androidboot.acpio_idx=0 > > > > > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinge > > > > > > > r- > > > > > > > 06 > > > > > > > _0 > > > > > > > 3- userdebug androidboot.diskbus=00.0 > > > > > > > androidboot.verifiedbootstate=green > > > > > > > androidboot.bootreason=power-on > > > > > > > androidboot.serialno=R1J56L6006a7bb > > > > > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > > > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr > > > > > > > nopti ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off > > > > > > > gpt > > > > > > > loglevel=4 androidboot.hardware=gordon_peak > > > > > > > firmware_class.path=/vendor/firmware relative_sleep_states=1 > > > > > > > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > > > > > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001: > > > > > > > 00 /p ro pe rties/android/ pstore.backend=ramoops > > > > > > > memmap=0x1400000$0x50000000 > > > > > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > > > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > > > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 vga=current > > > > > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > > > > > drm.vblankoffdelay= > > > > > > > > > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > > > > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > > > > > > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > > > > > > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > > > > Sent: Friday, November 30, 2018 11:17 PM > > > > > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > Cc: He, Bo <bo.he@intel.com>; linux-kernel@vger.kernel.org; > > > > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > > > > jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; > > > > > > > Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > > > > > <yanmin.zhang@intel.com> > > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > > > > > <paulmck@linux.ibm.com> wrote: > > > > > > > > > > > > > > > Could you please send me your list of kernel boot parameters? > > > > > > > > They usually appear near the start of your console output. > > > > > > > > > > > > > > Or just: cat /proc/cmdline > > > > > > > > > > > > > > -- Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-09 19:56 ` Paul E. McKenney @ 2018-12-10 6:56 ` He, Bo 2018-12-11 0:38 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-10 6:56 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A [-- Attachment #1: Type: text/plain, Size: 19855 bytes --] Hi, We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. I also enclosed the config and the debug patches for you review. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Monday, December 10, 2018 3:56 AM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> Subject: Re: rcu_preempt caused oom On Fri, Dec 07, 2018 at 06:11:31AM -0800, Paul E. McKenney wrote: > On Fri, Dec 07, 2018 at 08:25:09AM +0000, He, Bo wrote: > > Bad news, the issue is still reproduced after 61 Hours monkey test on 1/6 boards with the CONFIG_RCU_BOOST=y, and the issue is not seen on kernel 4.14, the CONFIG_RCU_BOOST is also not enabled in our kernel 4.14 config. > > Here enclosed is the logs. > > > > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" > > maybe it's not schedule issue, I have two suspects: > > we can see tons of grace_period with 117392312: > > [219346.919405, 0] showmap-31232 [000] d..1 219346.136035: > > rcu_future_grace_period: rcu_preempt 117392312 117392316 0 0 3 > > Startleaf [219346.919417, 0] showmap-31232 [000] d..1 > > 219346.136036: rcu_future_grace_period: rcu_preempt 117392312 > > 117392316 0 0 3 Prestarted [219346.919429, 0] showmap-31232 [000] > > d..1 219346.136036: rcu_grace_period: rcu_preempt 117392312 > > AccWaitCB > > > > "Startleaf" means start the grace period, "Prestarted" means the grace period is already started or other conditions blocked, RCU_GP_FLAG_INIT should follow the "Startedroot", then the kthread can be wakeup. > > Yes, when "Startleaf" is followed by "Prestarted", that means that we > reached an rcu_node structure that is already aware that the requested > grace period is needed. Breaking down the relevant "if" statement in > rcu_start_this_gp(): > > if (ULONG_CMP_GE(rnp->gp_seq_needed, gp_seq_req) || > // A. GP already requested at this rcu_node > rcu_seq_started(&rnp->gp_seq, gp_seq_req) || > // B. The requested grace period already started > (rnp != rnp_start && > rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))) { > // C. Leaf rcu_node recorded request, and > // some grace period is in progress > > A: In this case, the "Startedroot" should be taken care of by some > other thread, or one of B or C held earlier. > > B: This cannot be the case, because your earlier trace showed that > the requested grace period had not started. > > C: This cannot be the case because both traces above are on the > leaf rcu_node structure. If it were the case, the currently > running grace period would notice the need for the requested > grace period when it ended, and would start the grace period > at that time. > > So you are saying that your trace goes back far enough to capture the > very first "Startleaf" for this new grace period, and you don't ever > see a "Startedroot"? This would be OK if the later "Startedleaf" > showed up at that point. If you do have such a trace, could you > please send it to me (or post it somewhere and send me the URL)? > > In any case, this code has bee reworked recently, so I will take a > closer look, which will take some time. Please feel free to continue > to do so as well, of course! Hmmm... Could you please build with CONFIG_PROVE_RCU=y and run the original (for example, CONFIG_RCU_BOOST=n)? I would expect this to trigger the warning in rcu_check_gp_start_stall(). Of course, if it does not trigger, that would be valuable information as well. Thanx, Paul > > I do experiment to dump the backtrace, the rcu_quiescent_state_report is called in softirq context: > > <idle>-0 [000] dNs2 24471.669280: rcu_quiescent_state_report: rcu_preempt 3562401 1>0 0 0 3 0 > > <idle>-0 [000] dNs2 24471.669293: <stack trace> > > => rcu_report_qs_rnp+0x1e2/0x2a0 > > => rcu_process_callbacks+0x2f1/0x3c0 => __do_softirq+0x12a/0x386 > > => irq_exit+0xb1/0xc0 => smp_apic_timer_interrupt+0xd4/0x1e0 > > => apic_timer_interrupt+0xf/0x20 > > => cpuidle_enter_state+0xb1/0x340 > > => cpuidle_enter+0x17/0x20 > > => call_cpuidle+0x23/0x40 > > => do_idle+0x1ed/0x250 > > => cpu_startup_entry+0x73/0x80 > > => rest_init+0xf3/0x100 > > => start_kernel+0x46f/0x490 > > => x86_64_start_reservations+0x2a/0x2c > > => x86_64_start_kernel+0x72/0x75 > > => secondary_startup_64+0xa4/0xb0 > > rcu_report_qs_rnp=>rcu_report_qs_rdp > > > > and in the rcu_report_qs_rdp(), rcu_report_qs_rnp is follow the rcu_accelerate_cbs, we can see AccWaitCB log, but can't see rcu_quiescent_state_report, mostly it's due to condition rnp->qsmask & mask blocked. > > > > static void > > rcu_report_qs_rdp(int cpu, struct rcu_state *rsp, struct rcu_data > > *rdp) { ... > > if ((rnp->qsmask & mask) == 0) { > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > } else { > > rdp->core_needs_qs = false; > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > } > > } > > This is a completely different code path. The rcu_start_this_gp() > function is trying to start a new grace period. In contrast, this > rcu_report_qs_rdp() function reports a quiescent state for a currently > running grace period. In your earlier trace, there was no currently > running grace period, so rcu_report_qs_rdp() exiting early is expected > behavior. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Friday, December 7, 2018 1:38 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 06, 2018 at 01:23:01PM +0000, He, Bo wrote: > > > 1. The test is positive after set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST, the issue is not reproduced until now. > > > 2. Here is previous log enable the ftrace_dump, and we can get 4 seconds ftrace. The panic log was triggered with the enclosed debug patch, replaced the wait_for_completion(&rs_array[i].completion) with wait_for_completion_timeout(&rs_array[i].completion, 3*HZ) in __wait_rcu_gp(). The logs enabled the lockdep to dump the locks, and dump all tasks backtrace. > > > > Thank you for collecting this information! > > > > (By the way, the usual downside of the priority increase is > > increased context-switch rate and thus CPU overhead.) > > > > And all three grace-period kthreads are blocked apparently in their top-level loops (though inlining and all that). There are quite a few preemptions ("72738.702815: rcu_preempt_task: rcu_preempt"), but they are all blocking the next grace period (29041008), not the current one (29041004). And the "rcu_unlock_preempted_task" trace records flag the current grace-period sequence number as 29041004, which means that there is no grace period in progress, that is, RCU is idle. > > > > Which explains why there is no RCU CPU stall warning -- after all, if there is no grace period in flight, it is not possible to stall that non-existent grace period. > > > > That also could explain why increasing the priority of the grace-period kthreads gets things going again. There have been a great number of requests for a new grace period (for example, "rcu_future_grace_period: > > rcu_preempt 29041004 29041008 0 0 3 Startleaf"), so as soon as the grace-period kthread wakes up, a new grace period will start. > > > > Except that the rcu_preempt task says "I" rather than "R", as you noted in an earlier email. > > > > And there should have been multiple attempts to wake up the grace-period kthread, because there are lots of callbacks queued as in 136,045 of them ("rcu_callback: rcu_preempt rhp=0000000066f735c9 func=file_free_rcu 2811/136045"). Which is of course why you are seeing the OOM. > > > > So the question becomes "Why is the grace-period kthread being awakened so many times, but not actually waking up?" In the past, there was a scheduler bug that could cause that, but that was -way- before the v4.19 that you are running. More recently, there have been timer-related problems, but those only happened while a grace period was active, and where also long before v4.19. > > > > Hmmm... One possibility is that you have somehow managed to invoke > > call_rcu() with interrupts disabled, which would in turn disable the extra wakeups that RCU sends when it sees excessive numbers of callbacks. > > Except that in that case, boosting the priority wouldn't help. Besides, the scheduling-clock interrupt should also check for this, and should push things forward if need be. > > > > If RCU managed to put all of its callbacks into the RCU_NEXT_READY_TAIL bucket on all CPUs, that would defeat the wakeup-if-no-grace-period checks (RCU is supposed to have started the relevant grace period before putting callbacks into that bucket). But that cannot be the case here, because new callbacks are being enqueued throughout, and these would then trigger RCU's start-a-new-grace-period checks. > > > > But it would be good to confirm that this is actually working like I would expect it to. Could you please add scheduler wakeup to your tracing, if possible, only displaying those sent to the rcu_preempt task? > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Thursday, December 6, 2018 1:45 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Wed, Dec 05, 2018 at 08:42:54AM +0000, He, Bo wrote: > > > > I double checked the .config, we don't enable CONFIG_NO_HZ_FULL . > > > > Our previous logs can dump all the task backtrace, and kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks) are all in "I" state not in "R" state, my understandings are if it's the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, the kthreads should be in R state. > > > > > > Hmmm... Well, the tasks could in theory be waiting on a blocking mutex. > > > But in practice the grace-period kthreads wait on events, so that makes no sense. > > > > > > Is it possible for you to dump out the grace-period kthread's > > > stack, for example, with sysreq-t? (Steve might know a better way > > > to do > > > this.) > > > > > > > I will do more experiments and keep you update once we have more findings: > > > > 1. set the kthread priority to SCHED_FIFO without CONFIG_RCU_BOOST and see if the issue can reproduce. > > > > > > That sounds like a most excellent experiment! > > > > > > > 2. check more ftrace to double confirm why there is no trace_rcu_quiescent_state_report and most of the trace_rcu_grace_period are in "AccWaitCB". > > > > > > As noted earlier, to see something interesting, you will need to start the ftrace before the grace period starts. This would probably mean having ftrace running before starting the test. Starting the ftrace after the hang commences is unlikely to produce useful information. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Wednesday, December 5, 2018 3:50 AM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > <jie.a.bai@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Tue, Dec 04, 2018 at 07:50:04AM +0000, He, Bo wrote: > > > > > Hi, Paul: > > > > > the enclosed is the log trigger the 120s hung_task_panic without other debug patches, the hung task is blocked at __wait_rcu_gp, it means the rcu_cpu_stall can't detect the scenario: > > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > echo 7 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout > > > > > > > > Not necessarily. If there is an RCU CPU stall warning, blocking > > > > within > > > > __wait_rcu_gp() is expected behavior. It is possible that the problem is that although the grace period is completing as required, the callbacks are not being invoked in a timely fashion. And that could happen if you had CONFIG_NO_HZ_FULL and a bunch of nohz_full CPUs, or, alternatively, callback offloading enabled. But I don't see these in your previous emails. Another possible cause is that the grace-period kthread is being delayed, so that the grace period never starts. This seems unlikely, but it is the only thing thus far that matches the symptoms. > > > > > > > > CONFIG_RCU_BOOST=y has the side-effect of causing RCU's kthreads to be run at SCHED_FIFO priority 1, and that would help in the case where RCU's grace-period kthread (the rcu_preempt, rcu_sched, and rcu_bh tasks, all of which execute in the rcu_gp_kthread() function) was being starved of CPU time. > > > > > > > > Does that sound likely? > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Sent: Monday, December 3, 2018 9:57 PM > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > Zhang, Yanmin <yanmin.zhang@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Mon, Dec 03, 2018 at 07:44:03AM +0000, He, Bo wrote: > > > > > > Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. > > > > > > > > > > Very good, that is encouraging. Perhaps I should think about making CONFIG_RCU_BOOST=y the default for CONFIG_PREEMPT in mainline, at least for architectures for which rt_mutexes are implemented. > > > > > > > > > > > We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. > > > > > > echo 1 > /proc/sys/kernel/panic_on_rcu_stall > > > > > > > > > > Looking forward to seeing what is going on! Of course, to reproduce, you will need to again build with CONFIG_RCU_BOOST=n. > > > > > > > > > > Thanx, Paul > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Sent: Saturday, December 1, 2018 12:49 AM > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; > > > > > > Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > > > > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Fri, Nov 30, 2018 at 03:18:58PM +0000, He, Bo wrote: > > > > > > > Here is the kernel cmdline: > > > > > > > > > > > > Thank you! > > > > > > > > > > > > > Kernel command line: androidboot.acpio_idx=0 > > > > > > > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelfl > > > > > > > inge > > > > > > > r- > > > > > > > 06 > > > > > > > _0 > > > > > > > 3- userdebug androidboot.diskbus=00.0 > > > > > > > androidboot.verifiedbootstate=green > > > > > > > androidboot.bootreason=power-on > > > > > > > androidboot.serialno=R1J56L6006a7bb > > > > > > > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > > > > > > > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr > > > > > > > nopti ftrace_dump_on_oops trace_buf_size=1024K > > > > > > > intel_iommu=off gpt > > > > > > > loglevel=4 androidboot.hardware=gordon_peak > > > > > > > firmware_class.path=/vendor/firmware > > > > > > > relative_sleep_states=1 > > > > > > > enforcing=0 androidboot.selinux=permissive > > > > > > > cpu_init_udelay=10 > > > > > > > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001: > > > > > > > 00 /p ro pe rties/android/ pstore.backend=ramoops > > > > > > > memmap=0x1400000$0x50000000 > > > > > > > ramoops.mem_address=0x50000000 ramoops.mem_size=0x1400000 > > > > > > > ramoops.record_size=0x4000 ramoops.console_size=0x1000000 > > > > > > > ramoops.ftrace_size=0x10000 ramoops.dump_oops=1 > > > > > > > vga=current > > > > > > > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > > > > > > > drm.vblankoffdelay= > > > > > > > > > > > > And no sign of any suppression of RCU CPU stall warnings. Hmmm... > > > > > > It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: > > > > > > > > > > > > rcupdate.rcu_cpu_stall_timeout=7 > > > > > > > > > > > > This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > > > > Sent: Friday, November 30, 2018 11:17 PM > > > > > > > To: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > Cc: He, Bo <bo.he@intel.com>; > > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; > > > > > > > Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > > > > > > <jin.xiao@intel.com>; Zhang, Yanmin > > > > > > > <yanmin.zhang@intel.com> > > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > > > On Fri, 30 Nov 2018 06:43:17 -0800 "Paul E. McKenney" > > > > > > > <paulmck@linux.ibm.com> wrote: > > > > > > > > > > > > > > > Could you please send me your list of kernel boot parameters? > > > > > > > > They usually appear near the start of your console output. > > > > > > > > > > > > > > Or just: cat /proc/cmdline > > > > > > > > > > > > > > -- Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [-- Attachment #2: 0001-add-rcu-hung-task-detect.patch --] [-- Type: application/octet-stream, Size: 1065 bytes --] From 523a10e8fa16283ef5e50fcb9462999f2bcaf7a2 Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sat, 24 Nov 2018 13:30:40 +0800 Subject: [PATCH 1/2] add rcu hung task detect Change-Id: If8791c7f4f250b44c04927c1f5c0ca82f2fadc01 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/update.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index 39cb23d..81db882 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -362,8 +362,13 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array, for (j = 0; j < i; j++) if (crcu_array[j] == crcu_array[i]) break; - if (j == i) - wait_for_completion(&rs_array[i].completion); + if (j == i) { + trace_printk("bobo: start wait for rcu gp\n"); + if(!wait_for_completion_timeout(&rs_array[i].completion, 3*HZ)) + panic("hung_task: blocked tasks in rcu"); + trace_printk("bobo: finish wait for rcu gp\n"); + + } destroy_rcu_head_on_stack(&rs_array[i].head); } } -- 2.7.4 [-- Attachment #3: 0002-rcu-detect-the-preempt_rcu-hang.patch --] [-- Type: application/octet-stream, Size: 3745 bytes --] From 11ca4ed152e9ab9b0853fe65c630eb092ba49c05 Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH 2/2] rcu: detect the preempt_rcu hang Change-Id: I2c059ffe7d8b3ef8ab5f2cb246dff24a729555f1 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 34 ++++++++++++++++++++++++++++------ kernel/rcu/update.c | 4 +++- 2 files changed, 31 insertions(+), 7 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index a7ff53d..0a7e83c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -61,6 +61,7 @@ #include <linux/trace_events.h> #include <linux/suspend.h> #include <linux/ftrace.h> +#include <linux/sched/clock.h> #include "tree.h" #include "rcu.h" @@ -637,11 +638,13 @@ void show_rcu_gp_kthreads(void) struct rcu_state *rsp; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + pr_info("%s: wait state: %d ->state: %#lx gp_flags: %d rsp: gp_seq = %lu\n", + rsp->name, rsp->gp_state, rsp->gp_kthread->state, rsp->gp_flags, rsp->gp_seq); rcu_for_each_node_breadth_first(rsp, rnp) { - if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) + if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) { + pr_info("\trsp->gp_seq %lu is ge rnp->gp_seq_needed %lu\n", rsp->gp_seq, rnp->gp_seq_needed); continue; + } pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", rnp->grplo, rnp->grphi, rnp->gp_seq, rnp->gp_seq_needed); @@ -651,8 +654,11 @@ void show_rcu_gp_kthreads(void) rdp = per_cpu_ptr(rsp->rda, cpu); if (rdp->gpwrap || ULONG_CMP_GE(rsp->gp_seq, - rdp->gp_seq_needed)) + rdp->gp_seq_needed)) { + pr_info("\tcpu %d rdp->gpwrap = %d rsp->gp_seq %lu is ge rdp->gp_seq_needed %lu\n", + cpu, rdp->gpwrap, rsp->gp_seq, rdp->gp_seq_needed); continue; + } pr_info("\tcpu %d ->gp_seq_needed %lu\n", cpu, rdp->gp_seq_needed); } @@ -2153,8 +2159,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2163,8 +2174,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index 81db882..63f761a 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -364,8 +364,10 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array, break; if (j == i) { trace_printk("bobo: start wait for rcu gp\n"); - if(!wait_for_completion_timeout(&rs_array[i].completion, 3*HZ)) + if(!wait_for_completion_timeout(&rs_array[i].completion, 2*HZ)) { + show_rcu_gp_kthreads(); panic("hung_task: blocked tasks in rcu"); + } trace_printk("bobo: finish wait for rcu gp\n"); } -- 2.7.4 [-- Attachment #4: config.gz --] [-- Type: application/x-gzip, Size: 37463 bytes --] ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-10 6:56 ` He, Bo @ 2018-12-11 0:38 ` Paul E. McKenney 2018-12-11 4:46 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-11 0:38 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > Hi, > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > I also enclosed the config and the debug patches for you review. I instead suggest the (lightly tested) debug patch shown below, which tracks wakeups of RCU's grace-period kthreads and dumps them out if a given requested grace period fails to start. Again, it is necessary to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. Thanx, Paul ------------------------------------------------------------------------ commit 2a3826f15adaf92d046c80e38d090ecff5403807 Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..7daaef57d905 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) +{ + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) +{ + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -1774,8 +1791,8 @@ static void rcu_accelerate_cbs_unlocked(struct rcu_state *rsp, raw_spin_lock_rcu_node(rnp); /* irqs already disabled. */ needwake = rcu_accelerate_cbs(rsp, rnp, rdp); raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ - if (needwake) - rcu_gp_kthread_wake(rsp); + /* if (needwake) + rcu_gp_kthread_wake(rsp); */ } /* @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-11 0:38 ` Paul E. McKenney @ 2018-12-11 4:46 ` Paul E. McKenney 2018-12-11 5:29 ` He, Bo 2018-12-12 1:37 ` He, Bo 0 siblings, 2 replies; 43+ messages in thread From: Paul E. McKenney @ 2018-12-11 4:46 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote: > On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > > Hi, > > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > > I also enclosed the config and the debug patches for you review. > > I instead suggest the (lightly tested) debug patch shown below, which > tracks wakeups of RCU's grace-period kthreads and dumps them out if a > given requested grace period fails to start. Again, it is necessary to > build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. Right. This time without commenting out the wakeup as a test of the diagnostic. :-/ Please use the patch below instead of the one that I sent in my previous email. Thanx, Paul ------------------------------------------------------------------------ commit adfc7dff659495a3433d5084256be59eee0ac6df Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) +{ + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) +{ + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ ^ permalink raw reply related [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-11 4:46 ` Paul E. McKenney @ 2018-12-11 5:29 ` He, Bo 2018-12-12 1:37 ` He, Bo 1 sibling, 0 replies; 43+ messages in thread From: He, Bo @ 2018-12-11 5:29 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A sure, we will update the new patch to run the test. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Tuesday, December 11, 2018 12:47 PM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> Subject: Re: rcu_preempt caused oom On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote: > On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > > Hi, > > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > > I also enclosed the config and the debug patches for you review. > > I instead suggest the (lightly tested) debug patch shown below, which > tracks wakeups of RCU's grace-period kthreads and dumps them out if a > given requested grace period fails to start. Again, it is necessary > to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. Right. This time without commenting out the wakeup as a test of the diagnostic. :-/ Please use the patch below instead of the one that I sent in my previous email. Thanx, Paul ------------------------------------------------------------------------ commit adfc7dff659495a3433d5084256be59eee0ac6df Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) { + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) { + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-11 4:46 ` Paul E. McKenney 2018-12-11 5:29 ` He, Bo @ 2018-12-12 1:37 ` He, Bo 2018-12-12 2:24 ` Paul E. McKenney 1 sibling, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-12 1:37 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A [-- Attachment #1: Type: text/plain, Size: 8114 bytes --] We reproduced the issue panic in hung_task with the patch "Improve diagnostics for failed RCU grace-period start", but unfortunately maybe it's due to the loglevel, the show_rcu_gp_kthreads doesn't print any logs, we will improve the build and run the test to double check. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Tuesday, December 11, 2018 12:47 PM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> Subject: Re: rcu_preempt caused oom On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote: > On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > > Hi, > > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > > I also enclosed the config and the debug patches for you review. > > I instead suggest the (lightly tested) debug patch shown below, which > tracks wakeups of RCU's grace-period kthreads and dumps them out if a > given requested grace period fails to start. Again, it is necessary > to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. Right. This time without commenting out the wakeup as a test of the diagnostic. :-/ Please use the patch below instead of the one that I sent in my previous email. Thanx, Paul ------------------------------------------------------------------------ commit adfc7dff659495a3433d5084256be59eee0ac6df Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) { + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) { + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ [-- Attachment #2: console-ramoops_20111111154601.txt.gz --] [-- Type: application/x-gzip, Size: 160582 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-12 1:37 ` He, Bo @ 2018-12-12 2:24 ` Paul E. McKenney [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A192C3@SHSMSX104.ccr.corp.intel.com> 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-12 2:24 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Wed, Dec 12, 2018 at 01:37:40AM +0000, He, Bo wrote: > We reproduced the issue panic in hung_task with the patch "Improve diagnostics for failed RCU grace-period start", but unfortunately maybe it's due to the loglevel, the show_rcu_gp_kthreads doesn't print any logs, we will improve the build and run the test to double check. Well, at least the diagnostics didn't prevent the problem from happening. ;-) Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Tuesday, December 11, 2018 12:47 PM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote: > > On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > > > Hi, > > > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > > > I also enclosed the config and the debug patches for you review. > > > > I instead suggest the (lightly tested) debug patch shown below, which > > tracks wakeups of RCU's grace-period kthreads and dumps them out if a > > given requested grace period fails to start. Again, it is necessary > > to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. > > Right. This time without commenting out the wakeup as a test of the diagnostic. :-/ > > Please use the patch below instead of the one that I sent in my previous email. > > Thanx, Paul > > ------------------------------------------------------------------------ > > commit adfc7dff659495a3433d5084256be59eee0ac6df > Author: Paul E. McKenney <paulmck@linux.ibm.com> > Date: Mon Dec 10 16:33:59 2018 -0800 > > rcu: Improve diagnostics for failed RCU grace-period start > > Backported from v4.21/v5.0 > > If a grace period fails to start (for example, because you commented > out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() > will invoke rcu_check_gp_start_stall(), which will notice and complain. > However, this complaint is lacking crucial debugging information such > as when the last wakeup executed and what the value of ->gp_seq was at > that time. This commit therefore removes the current pr_alert() from > rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), > which has been updated to print the needed information, which is collected > by rcu_gp_kthread_wake(). > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) > } > EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); > > +/* > + * Convert a ->gp_state value to a character string. > + */ > +static const char *gp_state_getname(short gs) { > + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) > + return "???"; > + return gp_state_names[gs]; > +} > + > +/* > + * Return the root node of the specified rcu_state structure. > + */ > +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) { > + return &rsp->node[0]; > +} > + > /* > * Show the state of the grace-period kthreads. > */ > void show_rcu_gp_kthreads(void) > { > int cpu; > + unsigned long j; > + unsigned long ja; > + unsigned long jr; > + unsigned long jw; > struct rcu_data *rdp; > struct rcu_node *rnp; > struct rcu_state *rsp; > > + j = jiffies; > for_each_rcu_flavor(rsp) { > - pr_info("%s: wait state: %d ->state: %#lx\n", > - rsp->name, rsp->gp_state, rsp->gp_kthread->state); > + ja = j - READ_ONCE(rsp->gp_activity); > + jr = j - READ_ONCE(rsp->gp_req_activity); > + jw = j - READ_ONCE(rsp->gp_wake_time); > + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", > + rsp->name, gp_state_getname(rsp->gp_state), > + rsp->gp_state, > + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, > + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), > + (long)READ_ONCE(rsp->gp_seq), > + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), > + READ_ONCE(rsp->gp_flags)); > rcu_for_each_node_breadth_first(rsp, rnp) { > if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) > continue; > - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", > - rnp->grplo, rnp->grphi, rnp->gp_seq, > - rnp->gp_seq_needed); > + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", > + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, > + (long)rnp->gp_seq_needed); > if (!rcu_is_leaf_node(rnp)) > continue; > for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) > ULONG_CMP_GE(rsp->gp_seq, > rdp->gp_seq_needed)) > continue; > - pr_info("\tcpu %d ->gp_seq_needed %lu\n", > - cpu, rdp->gp_seq_needed); > + pr_info("\tcpu %d ->gp_seq_needed %ld\n", > + cpu, (long)rdp->gp_seq_needed); > } > } > /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); > > -/* > - * Return the root node of the specified rcu_state structure. > - */ > -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ > - return &rsp->node[0]; > -} > - > /* > * Enter an RCU extended quiescent state, which can be either the > * idle loop or adaptive-tickless usermode execution. > @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) > rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } > > -/* > - * Convert a ->gp_state value to a character string. > - */ > -static const char *gp_state_getname(short gs) -{ > - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) > - return "???"; > - return gp_state_names[gs]; > -} > - > /* > * Complain about starvation of grace-period kthread. > */ > @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > * Don't do a self-awaken, and don't bother awakening when there is > * nothing for the grace-period kthread to do (as in several CPUs > * raced to awaken, and we lost), and finally don't try to awaken > - * a kthread that has not yet been created. > + * a kthread that has not yet been created. If all those checks are > + * passed, track some debug information and awaken. > */ > static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) > !READ_ONCE(rsp->gp_flags) || > !rsp->gp_kthread) > return; > + WRITE_ONCE(rsp->gp_wake_time, jiffies); > + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); > swake_up_one(&rsp->gp_wq); > } > > @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > return; > } > - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", > - __func__, (long)READ_ONCE(rsp->gp_seq), > - (long)READ_ONCE(rnp_root->gp_seq_needed), > - j - rsp->gp_req_activity, j - rsp->gp_activity, > - rsp->gp_flags, rsp->gp_state, rsp->name, > - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); > WARN_ON(1); > if (rnp_root != rnp) > raw_spin_unlock_rcu_node(rnp_root); > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > + show_rcu_gp_kthreads(); > } > > /* > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 > --- a/kernel/rcu/tree.h > +++ b/kernel/rcu/tree.h > @@ -327,6 +327,8 @@ struct rcu_state { > struct swait_queue_head gp_wq; /* Where GP task waits. */ > short gp_flags; /* Commands for GP task. */ > short gp_state; /* GP kthread sleep state. */ > + unsigned long gp_wake_time; /* Last GP kthread wake. */ > + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ > > /* End of fields guarded by root rcu_node's lock. */ > > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CD6925E8781EFD4D8E11882D20FC406D52A192C3@SHSMSX104.ccr.corp.intel.com>]
* Re: rcu_preempt caused oom [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A192C3@SHSMSX104.ccr.corp.intel.com> @ 2018-12-12 15:42 ` Paul E. McKenney 2018-12-12 21:03 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-12 15:42 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. Strange. Are the systems responsive to sysrq keys once failure occurs? If so, I will provide you a sysrq-R or some such to dump out the RCU state. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Wednesday, December 12, 2018 10:25 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Wed, Dec 12, 2018 at 01:37:40AM +0000, He, Bo wrote: > > We reproduced the issue panic in hung_task with the patch "Improve diagnostics for failed RCU grace-period start", but unfortunately maybe it's due to the loglevel, the show_rcu_gp_kthreads doesn't print any logs, we will improve the build and run the test to double check. > > Well, at least the diagnostics didn't prevent the problem from happening. ;-) > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Tuesday, December 11, 2018 12:47 PM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Mon, Dec 10, 2018 at 04:38:38PM -0800, Paul E. McKenney wrote: > > > On Mon, Dec 10, 2018 at 06:56:18AM +0000, He, Bo wrote: > > > > Hi, > > > > We have start the test with the CONFIG_PROVE_RCU=y, and also add one 2s to detect the preempt rcu hang, hope we can get more useful logs tomorrow. > > > > I also enclosed the config and the debug patches for you review. > > > > > > I instead suggest the (lightly tested) debug patch shown below, > > > which tracks wakeups of RCU's grace-period kthreads and dumps them > > > out if a given requested grace period fails to start. Again, it is > > > necessary to build with CONFIG_PROVE_RCU=y, that is, with CONFIG_PROVE_LOCKING=y. > > > > Right. This time without commenting out the wakeup as a test of the > > diagnostic. :-/ > > > > Please use the patch below instead of the one that I sent in my previous email. > > > > Thanx, Paul > > > > ---------------------------------------------------------------------- > > -- > > > > commit adfc7dff659495a3433d5084256be59eee0ac6df > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > Date: Mon Dec 10 16:33:59 2018 -0800 > > > > rcu: Improve diagnostics for failed RCU grace-period start > > > > Backported from v4.21/v5.0 > > > > If a grace period fails to start (for example, because you commented > > out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() > > will invoke rcu_check_gp_start_stall(), which will notice and complain. > > However, this complaint is lacking crucial debugging information such > > as when the last wakeup executed and what the value of ->gp_seq was at > > that time. This commit therefore removes the current pr_alert() from > > rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), > > which has been updated to print the needed information, which is collected > > by rcu_gp_kthread_wake(). > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > 0b760c1369f7..4bcd8753e293 100644 > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) > > } > > EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); > > > > +/* > > + * Convert a ->gp_state value to a character string. > > + */ > > +static const char *gp_state_getname(short gs) { > > + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) > > + return "???"; > > + return gp_state_names[gs]; > > +} > > + > > +/* > > + * Return the root node of the specified rcu_state structure. > > + */ > > +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) { > > + return &rsp->node[0]; > > +} > > + > > /* > > * Show the state of the grace-period kthreads. > > */ > > void show_rcu_gp_kthreads(void) > > { > > int cpu; > > + unsigned long j; > > + unsigned long ja; > > + unsigned long jr; > > + unsigned long jw; > > struct rcu_data *rdp; > > struct rcu_node *rnp; > > struct rcu_state *rsp; > > > > + j = jiffies; > > for_each_rcu_flavor(rsp) { > > - pr_info("%s: wait state: %d ->state: %#lx\n", > > - rsp->name, rsp->gp_state, rsp->gp_kthread->state); > > + ja = j - READ_ONCE(rsp->gp_activity); > > + jr = j - READ_ONCE(rsp->gp_req_activity); > > + jw = j - READ_ONCE(rsp->gp_wake_time); > > + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", > > + rsp->name, gp_state_getname(rsp->gp_state), > > + rsp->gp_state, > > + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, > > + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), > > + (long)READ_ONCE(rsp->gp_seq), > > + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), > > + READ_ONCE(rsp->gp_flags)); > > rcu_for_each_node_breadth_first(rsp, rnp) { > > if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) > > continue; > > - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", > > - rnp->grplo, rnp->grphi, rnp->gp_seq, > > - rnp->gp_seq_needed); > > + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", > > + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, > > + (long)rnp->gp_seq_needed); > > if (!rcu_is_leaf_node(rnp)) > > continue; > > for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) > > ULONG_CMP_GE(rsp->gp_seq, > > rdp->gp_seq_needed)) > > continue; > > - pr_info("\tcpu %d ->gp_seq_needed %lu\n", > > - cpu, rdp->gp_seq_needed); > > + pr_info("\tcpu %d ->gp_seq_needed %ld\n", > > + cpu, (long)rdp->gp_seq_needed); > > } > > } > > /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void > > rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } > > EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); > > > > -/* > > - * Return the root node of the specified rcu_state structure. > > - */ > > -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ > > - return &rsp->node[0]; > > -} > > - > > /* > > * Enter an RCU extended quiescent state, which can be either the > > * idle loop or adaptive-tickless usermode execution. > > @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) > > rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } > > > > -/* > > - * Convert a ->gp_state value to a character string. > > - */ > > -static const char *gp_state_getname(short gs) -{ > > - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) > > - return "???"; > > - return gp_state_names[gs]; > > -} > > - > > /* > > * Complain about starvation of grace-period kthread. > > */ > > @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > > * Don't do a self-awaken, and don't bother awakening when there is > > * nothing for the grace-period kthread to do (as in several CPUs > > * raced to awaken, and we lost), and finally don't try to awaken > > - * a kthread that has not yet been created. > > + * a kthread that has not yet been created. If all those checks are > > + * passed, track some debug information and awaken. > > */ > > static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) > > !READ_ONCE(rsp->gp_flags) || > > !rsp->gp_kthread) > > return; > > + WRITE_ONCE(rsp->gp_wake_time, jiffies); > > + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); > > swake_up_one(&rsp->gp_wq); > > } > > > > @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > return; > > } > > - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", > > - __func__, (long)READ_ONCE(rsp->gp_seq), > > - (long)READ_ONCE(rnp_root->gp_seq_needed), > > - j - rsp->gp_req_activity, j - rsp->gp_activity, > > - rsp->gp_flags, rsp->gp_state, rsp->name, > > - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); > > WARN_ON(1); > > if (rnp_root != rnp) > > raw_spin_unlock_rcu_node(rnp_root); > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > + show_rcu_gp_kthreads(); > > } > > > > /* > > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index > > 4e74df768c57..0e051d9b5f1a 100644 > > --- a/kernel/rcu/tree.h > > +++ b/kernel/rcu/tree.h > > @@ -327,6 +327,8 @@ struct rcu_state { > > struct swait_queue_head gp_wq; /* Where GP task waits. */ > > short gp_flags; /* Commands for GP task. */ > > short gp_state; /* GP kthread sleep state. */ > > + unsigned long gp_wake_time; /* Last GP kthread wake. */ > > + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ > > > > /* End of fields guarded by root rcu_node's lock. */ > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-12 15:42 ` Paul E. McKenney @ 2018-12-12 21:03 ` Paul E. McKenney 2018-12-12 23:13 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-12 21:03 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > Strange. > > Are the systems responsive to sysrq keys once failure occurs? If so, I will > provide you a sysrq-R or some such to dump out the RCU state. Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. Thanx, Paul ------------------------------------------------------------------------ commit adfc7dff659495a3433d5084256be59eee0ac6df Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) +{ + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) +{ + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ ^ permalink raw reply related [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-12 21:03 ` Paul E. McKenney @ 2018-12-12 23:13 ` He, Bo 2018-12-13 0:12 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-12 23:13 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. Please correct me if I have something wrong. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Thursday, December 13, 2018 5:03 AM To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> Subject: Re: rcu_preempt caused oom On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > Strange. > > Are the systems responsive to sysrq keys once failure occurs? If so, > I will provide you a sysrq-R or some such to dump out the RCU state. Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. Thanx, Paul ------------------------------------------------------------------------ commit adfc7dff659495a3433d5084256be59eee0ac6df Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Mon Dec 10 16:33:59 2018 -0800 rcu: Improve diagnostics for failed RCU grace-period start Backported from v4.21/v5.0 If a grace period fails to start (for example, because you commented out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core() will invoke rcu_check_gp_start_stall(), which will notice and complain. However, this complaint is lacking crucial debugging information such as when the last wakeup executed and what the value of ->gp_seq was at that time. This commit therefore removes the current pr_alert() from rcu_check_gp_start_stall(), instead invoking show_rcu_gp_kthreads(), which has been updated to print the needed information, which is collected by rcu_gp_kthread_wake(). Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..4bcd8753e293 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -626,25 +626,57 @@ void rcu_sched_force_quiescent_state(void) } EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state); +/* + * Convert a ->gp_state value to a character string. + */ +static const char *gp_state_getname(short gs) { + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) + return "???"; + return gp_state_names[gs]; +} + +/* + * Return the root node of the specified rcu_state structure. + */ +static struct rcu_node *rcu_get_root(struct rcu_state *rsp) { + return &rsp->node[0]; +} + /* * Show the state of the grace-period kthreads. */ void show_rcu_gp_kthreads(void) { int cpu; + unsigned long j; + unsigned long ja; + unsigned long jr; + unsigned long jw; struct rcu_data *rdp; struct rcu_node *rnp; struct rcu_state *rsp; + j = jiffies; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + ja = j - READ_ONCE(rsp->gp_activity); + jr = j - READ_ONCE(rsp->gp_req_activity); + jw = j - READ_ONCE(rsp->gp_wake_time); + pr_info("%s: wait state: %s(%d) ->state: %#lx delta ->gp_activity %lu ->gp_req_activity %lu ->gp_wake_time %lu ->gp_wake_seq %ld ->gp_seq %ld ->gp_seq_needed %ld ->gp_flags %#x\n", + rsp->name, gp_state_getname(rsp->gp_state), + rsp->gp_state, + rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL, + ja, jr, jw, (long)READ_ONCE(rsp->gp_wake_seq), + (long)READ_ONCE(rsp->gp_seq), + (long)READ_ONCE(rcu_get_root(rsp)->gp_seq_needed), + READ_ONCE(rsp->gp_flags)); rcu_for_each_node_breadth_first(rsp, rnp) { if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) continue; - pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", - rnp->grplo, rnp->grphi, rnp->gp_seq, - rnp->gp_seq_needed); + pr_info("\trcu_node %d:%d ->gp_seq %ld ->gp_seq_needed %ld\n", + rnp->grplo, rnp->grphi, (long)rnp->gp_seq, + (long)rnp->gp_seq_needed); if (!rcu_is_leaf_node(rnp)) continue; for_each_leaf_node_possible_cpu(rnp, cpu) { @@ -653,8 +685,8 @@ void show_rcu_gp_kthreads(void) ULONG_CMP_GE(rsp->gp_seq, rdp->gp_seq_needed)) continue; - pr_info("\tcpu %d ->gp_seq_needed %lu\n", - cpu, rdp->gp_seq_needed); + pr_info("\tcpu %d ->gp_seq_needed %ld\n", + cpu, (long)rdp->gp_seq_needed); } } /* sched_show_task(rsp->gp_kthread); */ @@ -690,14 +722,6 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type, int *flags, } EXPORT_SYMBOL_GPL(rcutorture_get_gp_data); -/* - * Return the root node of the specified rcu_state structure. - */ -static struct rcu_node *rcu_get_root(struct rcu_state *rsp) -{ - return &rsp->node[0]; -} - /* * Enter an RCU extended quiescent state, which can be either the * idle loop or adaptive-tickless usermode execution. @@ -1285,16 +1309,6 @@ static void record_gp_stall_check_time(struct rcu_state *rsp) rsp->n_force_qs_gpstart = READ_ONCE(rsp->n_force_qs); } -/* - * Convert a ->gp_state value to a character string. - */ -static const char *gp_state_getname(short gs) -{ - if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names)) - return "???"; - return gp_state_names[gs]; -} - /* * Complain about starvation of grace-period kthread. */ @@ -1693,7 +1707,8 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) * Don't do a self-awaken, and don't bother awakening when there is * nothing for the grace-period kthread to do (as in several CPUs * raced to awaken, and we lost), and finally don't try to awaken - * a kthread that has not yet been created. + * a kthread that has not yet been created. If all those checks are + * passed, track some debug information and awaken. */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { @@ -1701,6 +1716,8 @@ static void rcu_gp_kthread_wake(struct rcu_state *rsp) !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; + WRITE_ONCE(rsp->gp_wake_time, jiffies); + WRITE_ONCE(rsp->gp_wake_seq, READ_ONCE(rsp->gp_seq)); swake_up_one(&rsp->gp_wq); } @@ -2802,16 +2819,11 @@ rcu_check_gp_start_stall(struct rcu_state *rsp, struct rcu_node *rnp, raw_spin_unlock_irqrestore_rcu_node(rnp, flags); return; } - pr_alert("%s: g%ld->%ld gar:%lu ga:%lu f%#x gs:%d %s->state:%#lx\n", - __func__, (long)READ_ONCE(rsp->gp_seq), - (long)READ_ONCE(rnp_root->gp_seq_needed), - j - rsp->gp_req_activity, j - rsp->gp_activity, - rsp->gp_flags, rsp->gp_state, rsp->name, - rsp->gp_kthread ? rsp->gp_kthread->state : 0x1ffffL); WARN_ON(1); if (rnp_root != rnp) raw_spin_unlock_rcu_node(rnp_root); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); + show_rcu_gp_kthreads(); } /* diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4e74df768c57..0e051d9b5f1a 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -327,6 +327,8 @@ struct rcu_state { struct swait_queue_head gp_wq; /* Where GP task waits. */ short gp_flags; /* Commands for GP task. */ short gp_state; /* GP kthread sleep state. */ + unsigned long gp_wake_time; /* Last GP kthread wake. */ + unsigned long gp_wake_seq; /* ->gp_seq at ^^^. */ /* End of fields guarded by root rcu_node's lock. */ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-12 23:13 ` He, Bo @ 2018-12-13 0:12 ` Paul E. McKenney 2018-12-13 2:11 ` Zhang, Jun 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-13 0:12 UTC (permalink / raw) To: He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Zhang, Jun, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > Please correct me if I have something wrong. That would be because I sent you the wrong patch, apologies! :-/ Please instead see the one below, which does add sysrq_rcu. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, December 13, 2018 5:03 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > Strange. > > > > Are the systems responsive to sysrq keys once failure occurs? If so, > > I will provide you a sysrq-R or some such to dump out the RCU state. > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. ------------------------------------------------------------------------ commit 04b6245c8458e8725f4169e62912c1fadfdf8141 Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Wed Dec 12 16:10:09 2018 -0800 rcu: Add sysrq rcu_node-dump capability Backported from v4.21/v5.0 Life is hard if RCU manages to get stuck without triggering RCU CPU stall warnings or triggering the rcu_check_gp_start_stall() checks for failing to start a grace period. This commit therefore adds a boot-time-selectable sysrq key (commandeering "y") that allows manually dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter must be set for this sysrq to be available. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..e9392a9d6291 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -61,6 +61,7 @@ #include <linux/trace_events.h> #include <linux/suspend.h> #include <linux/ftrace.h> +#include <linux/sysrq.h> #include "tree.h" #include "rcu.h" @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in use. */ /* panic() on RCU Stall sysctl. */ int sysctl_panic_on_rcu_stall __read_mostly; +/* Commandeer a sysrq key to dump RCU's tree. */ +static bool sysrq_rcu; +module_param(sysrq_rcu, bool, 0444); /* * The rcu_scheduler_active variable is initialized to the value @@ -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); +/* Dump grace-period-request information due to commandeered sysrq. */ +static void sysrq_show_rcu(int key) +{ + show_rcu_gp_kthreads(); +} + +static struct sysrq_key_op sysrq_rcudump_op = { + .handler = sysrq_show_rcu, + .help_msg = "show-rcu(y)", + .action_msg = "Show RCU tree", + .enable_mask = SYSRQ_ENABLE_DUMP, +}; + +static int __init rcu_sysrq_init(void) +{ + if (sysrq_rcu) + return register_sysrq_key('y', &sysrq_rcudump_op); + return 0; +} +early_initcall(rcu_sysrq_init); + /* * Send along grace-period-related data for rcutorture diagnostics. */ ^ permalink raw reply related [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-13 0:12 ` Paul E. McKenney @ 2018-12-13 2:11 ` Zhang, Jun 2018-12-13 2:42 ` Paul E. McKenney 2019-02-13 8:31 ` [tip:core/rcu] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() tip-bot for Zhang, Jun 0 siblings, 2 replies; 43+ messages in thread From: Zhang, Jun @ 2018-12-13 2:11 UTC (permalink / raw) To: paulmck@linux.ibm.com, He, Bo Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J Hello, Paul I think the next patch is better. Because ULONG_CMP_GE could cause double write, which has risk that write back old value. Please help review. I don't test it. If you agree, we will test it. Thanks! diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1..c00f34e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, zero_cpu_stall_ticks(rdp); } rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) || rdp->gpwrap) rdp->gp_seq_needed = rnp->gp_seq_needed; WRITE_ONCE(rdp->gpwrap, false); rcu_gpnum_ovf(rnp, rdp); -----Original Message----- From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] Sent: Thursday, December 13, 2018 08:12 To: He, Bo <bo.he@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> Subject: Re: rcu_preempt caused oom On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > Please correct me if I have something wrong. That would be because I sent you the wrong patch, apologies! :-/ Please instead see the one below, which does add sysrq_rcu. Thanx, Paul > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, December 13, 2018 5:03 AM > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > Subject: Re: rcu_preempt caused oom > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > Strange. > > > > Are the systems responsive to sysrq keys once failure occurs? If > > so, I will provide you a sysrq-R or some such to dump out the RCU state. > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. ------------------------------------------------------------------------ commit 04b6245c8458e8725f4169e62912c1fadfdf8141 Author: Paul E. McKenney <paulmck@linux.ibm.com> Date: Wed Dec 12 16:10:09 2018 -0800 rcu: Add sysrq rcu_node-dump capability Backported from v4.21/v5.0 Life is hard if RCU manages to get stuck without triggering RCU CPU stall warnings or triggering the rcu_check_gp_start_stall() checks for failing to start a grace period. This commit therefore adds a boot-time-selectable sysrq key (commandeering "y") that allows manually dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter must be set for this sysrq to be available. Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..e9392a9d6291 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -61,6 +61,7 @@ #include <linux/trace_events.h> #include <linux/suspend.h> #include <linux/ftrace.h> +#include <linux/sysrq.h> #include "tree.h" #include "rcu.h" @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in use. */ /* panic() on RCU Stall sysctl. */ int sysctl_panic_on_rcu_stall __read_mostly; +/* Commandeer a sysrq key to dump RCU's tree. */ static bool sysrq_rcu; +module_param(sysrq_rcu, bool, 0444); /* * The rcu_scheduler_active variable is initialized to the value @@ -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); +/* Dump grace-period-request information due to commandeered sysrq. */ +static void sysrq_show_rcu(int key) { + show_rcu_gp_kthreads(); +} + +static struct sysrq_key_op sysrq_rcudump_op = { + .handler = sysrq_show_rcu, + .help_msg = "show-rcu(y)", + .action_msg = "Show RCU tree", + .enable_mask = SYSRQ_ENABLE_DUMP, +}; + +static int __init rcu_sysrq_init(void) +{ + if (sysrq_rcu) + return register_sysrq_key('y', &sysrq_rcudump_op); + return 0; +} +early_initcall(rcu_sysrq_init); + /* * Send along grace-period-related data for rcutorture diagnostics. */ ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-13 2:11 ` Zhang, Jun @ 2018-12-13 2:42 ` Paul E. McKenney [not found] ` <88DC34334CA3444C85D647DBFA962C2735AD5F9E@SHSMSX104.ccr.corp.intel.com> 2019-02-13 8:31 ` [tip:core/rcu] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() tip-bot for Zhang, Jun 1 sibling, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-13 2:42 UTC (permalink / raw) To: Zhang, Jun Cc: He, Bo, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > Hello, Paul > > I think the next patch is better. > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > Please help review. > I don't test it. If you agree, we will test it. Just to make sure that I understand, you are worried about something like the following, correct? o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed and finds them equal. o At just this time something like rcu_start_this_gp() assigns a new (larger) value to rdp->gp_seq_needed. o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the old value. This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. Of course, there could be bugs. For example: o __note_gp_changes() might be called on a different CPU than that corresponding to rdp. You can check this with something like: WARN_ON_ONCE(rdp->cpu != smp_processor_id()); o The same things could happen with rcu_start_this_gp(), and the above WARN_ON_ONCE() would work there as well. o rcutree_prepare_cpu() is a special case, but is irrelevant unless you are doing CPU-hotplug operations. (It can run on a CPU other than rdp->cpu, but only at times when rdp->cpu is offline.) o Interrupts might not really be disabled. That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. So why not just test it anyway? If it makes the bug go away, I will be surprised, but it would not be the first surprise for me. ;-) Thanx, Paul > Thanks! > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 0b760c1..c00f34e 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > zero_cpu_stall_ticks(rdp); > } > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) || rdp->gpwrap) > rdp->gp_seq_needed = rnp->gp_seq_needed; > WRITE_ONCE(rdp->gpwrap, false); > rcu_gpnum_ovf(rnp, rdp); > > > -----Original Message----- > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > Sent: Thursday, December 13, 2018 08:12 > To: He, Bo <bo.he@intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > Please correct me if I have something wrong. > > That would be because I sent you the wrong patch, apologies! :-/ > > Please instead see the one below, which does add sysrq_rcu. > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Thursday, December 13, 2018 5:03 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > Strange. > > > > > > Are the systems responsive to sysrq keys once failure occurs? If > > > so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > ------------------------------------------------------------------------ > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > Author: Paul E. McKenney <paulmck@linux.ibm.com> > Date: Wed Dec 12 16:10:09 2018 -0800 > > rcu: Add sysrq rcu_node-dump capability > > Backported from v4.21/v5.0 > > Life is hard if RCU manages to get stuck without triggering RCU CPU > stall warnings or triggering the rcu_check_gp_start_stall() checks > for failing to start a grace period. This commit therefore adds a > boot-time-selectable sysrq key (commandeering "y") that allows manually > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > must be set for this sysrq to be available. > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..e9392a9d6291 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -61,6 +61,7 @@ > #include <linux/trace_events.h> > #include <linux/suspend.h> > #include <linux/ftrace.h> > +#include <linux/sysrq.h> > > #include "tree.h" > #include "rcu.h" > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in use. */ > /* panic() on RCU Stall sysctl. */ > int sysctl_panic_on_rcu_stall __read_mostly; > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool sysrq_rcu; > +module_param(sysrq_rcu, bool, 0444); > > /* > * The rcu_scheduler_active variable is initialized to the value @@ -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > +/* Dump grace-period-request information due to commandeered sysrq. */ > +static void sysrq_show_rcu(int key) { > + show_rcu_gp_kthreads(); > +} > + > +static struct sysrq_key_op sysrq_rcudump_op = { > + .handler = sysrq_show_rcu, > + .help_msg = "show-rcu(y)", > + .action_msg = "Show RCU tree", > + .enable_mask = SYSRQ_ENABLE_DUMP, > +}; > + > +static int __init rcu_sysrq_init(void) > +{ > + if (sysrq_rcu) > + return register_sysrq_key('y', &sysrq_rcudump_op); > + return 0; > +} > +early_initcall(rcu_sysrq_init); > + > /* > * Send along grace-period-related data for rcutorture diagnostics. > */ > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <88DC34334CA3444C85D647DBFA962C2735AD5F9E@SHSMSX104.ccr.corp.intel.com>]
* Re: rcu_preempt caused oom [not found] ` <88DC34334CA3444C85D647DBFA962C2735AD5F9E@SHSMSX104.ccr.corp.intel.com> @ 2018-12-13 4:40 ` Paul E. McKenney [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A197EC@SHSMSX104.ccr.corp.intel.com> 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-13 4:40 UTC (permalink / raw) To: Zhang, Jun Cc: He, Bo, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > Ok, we will test it, thanks! But please also try the sysrq-y with the earlier patch after a hang! Thanx, Paul > -----Original Message----- > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > Sent: Thursday, December 13, 2018 10:43 > To: Zhang, Jun <jun.zhang@intel.com> > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > Hello, Paul > > > > I think the next patch is better. > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > Please help review. > > I don't test it. If you agree, we will test it. > > Just to make sure that I understand, you are worried about something like the following, correct? > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > and finds them equal. > > o At just this time something like rcu_start_this_gp() assigns a new > (larger) value to rdp->gp_seq_needed. > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > old value. > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > Of course, there could be bugs. For example: > > o __note_gp_changes() might be called on a different CPU than that > corresponding to rdp. You can check this with something like: > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > o The same things could happen with rcu_start_this_gp(), and the > above WARN_ON_ONCE() would work there as well. > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > you are doing CPU-hotplug operations. (It can run on a CPU other > than rdp->cpu, but only at times when rdp->cpu is offline.) > > o Interrupts might not really be disabled. > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > So why not just test it anyway? If it makes the bug go away, I will be surprised, but it would not be the first surprise for me. ;-) > > Thanx, Paul > > > Thanks! > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > 0b760c1..c00f34e 100644 > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > zero_cpu_stall_ticks(rdp); > > } > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) || > > + rdp->gpwrap) > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > WRITE_ONCE(rdp->gpwrap, false); > > rcu_gpnum_ovf(rnp, rdp); > > > > > > -----Original Message----- > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > Sent: Thursday, December 13, 2018 08:12 > > To: He, Bo <bo.he@intel.com> > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J > > <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > Please correct me if I have something wrong. > > > > That would be because I sent you the wrong patch, apologies! :-/ > > > > Please instead see the one below, which does add sysrq_rcu. > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Thursday, December 13, 2018 5:03 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > Strange. > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? If > > > > so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > ---------------------------------------------------------------------- > > -- > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > rcu: Add sysrq rcu_node-dump capability > > > > Backported from v4.21/v5.0 > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > for failing to start a grace period. This commit therefore adds a > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > must be set for this sysrq to be available. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > 0b760c1369f7..e9392a9d6291 100644 > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -61,6 +61,7 @@ > > #include <linux/trace_events.h> > > #include <linux/suspend.h> > > #include <linux/ftrace.h> > > +#include <linux/sysrq.h> > > > > #include "tree.h" > > #include "rcu.h" > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in > > use. */ > > /* panic() on RCU Stall sysctl. */ > > int sysctl_panic_on_rcu_stall __read_mostly; > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > /* > > * The rcu_scheduler_active variable is initialized to the value @@ > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > +*/ static void sysrq_show_rcu(int key) { > > + show_rcu_gp_kthreads(); > > +} > > + > > +static struct sysrq_key_op sysrq_rcudump_op = { > > + .handler = sysrq_show_rcu, > > + .help_msg = "show-rcu(y)", > > + .action_msg = "Show RCU tree", > > + .enable_mask = SYSRQ_ENABLE_DUMP, > > +}; > > + > > +static int __init rcu_sysrq_init(void) { > > + if (sysrq_rcu) > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > + return 0; > > +} > > +early_initcall(rcu_sysrq_init); > > + > > /* > > * Send along grace-period-related data for rcutorture diagnostics. > > */ > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <CD6925E8781EFD4D8E11882D20FC406D52A197EC@SHSMSX104.ccr.corp.intel.com>]
* Re: rcu_preempt caused oom [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A197EC@SHSMSX104.ccr.corp.intel.com> @ 2018-12-13 18:11 ` Paul E. McKenney 2018-12-14 1:30 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-13 18:11 UTC (permalink / raw) To: He, Bo Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 This is quite helpful, thank you! The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: 1. Because rcu_check_gp_start_stall() is only ever invoked from RCU_SOFTIRQ, it is possible that softirqs are stalled for whatever reason. 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock interrupt handler, it is possible that the scheduler tick has somehow been disabled. Traces from earlier runs showed a great deal of RCU callbacks queued, which would have caused RCU to refuse to allow the scheduler tick to be disabled, even if the corresponding CPU was idle. 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given that you are building for a battery-powered device) and all of the CPU's callbacks are lazy. Except that your earlier traces showed lots of non-lazy callbacks. Besides, even if all callbacks were lazy, there would still be a scheduling-clock interrupt every six seconds, and there are quite a few six-second intervals in a two-minute watchdog timeout. But if we cannot find the problem quickly, I will likely ask you to try reproducing with CONFIG_FAST_NO_HZ=n. This could be thought of as bisecting the RCU code looking for the bug. The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. I did check this in current -rcu, but you are instead running v4.19, so I should also check there. The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: o rcu_accelerate_cbs_unlocked(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ if (needwake) rcu_gp_kthread_wake(rsp); o rcu_advance_cbs(), which returns the value returned by rcu_accelerate_cbs(), thus pushing the problem off to its callers, which are called out below. o __note_gp_changes(), which also returns the value returned by rcu_accelerate_cbs(), thus pushing the problem off to its callers, which are called out below. o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period kthreads such as the rcu_preempt task. Therefore, this function never needs to awaken the rcu_preempt task, because the fact that this function is executing means that this task is already awake. (Also, as noted above, we can eliminate this code from consideration because this task is known to have been sleeping at the last time that the RCU_GP_FLAG_INIT bit was set.) o rcu_report_qs_rdp(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); /* ^^^ Released rnp->lock */ if (needwake) rcu_gp_kthread_wake(rsp); o rcu_prepare_for_idle(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ if (needwake) rcu_gp_kthread_wake(rsp); Now for rcu_advance_cbs(): o __note_gp_changes(), which which also returns the value returned by rcu_advance_cbs(), thus pushing the problem off to its callers, which are called out below. o rcu_migrate_callbacks(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || rcu_advance_cbs(rsp, rnp_root, my_rdp); rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != !rcu_segcblist_n_cbs(&my_rdp->cblist)); raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); if (needwake) rcu_gp_kthread_wake(rsp); Now for __note_gp_changes(): o note_gp_changes(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = __note_gp_changes(rsp, rnp, rdp); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); if (needwake) rcu_gp_kthread_wake(rsp); o rcu_gp_init() which is only ever invoked by RCU grace-period kthreads such as the rcu_preempt task, which makes wakeups unnecessary, just as for rcu_gp_cleanup() above. o rcu_gp_cleanup(), ditto. So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. Thanx, Paul ------------------------------------------------------------------------ lockdep complaint: ------------------------------------------------------------------------ [ 2.895507] ====================================================== [ 2.895511] WARNING: possible circular locking dependency detected [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U [ 2.895521] ------------------------------------------------------ [ 2.895525] earlyEvs/1839 is trying to acquire lock: [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895546] [ 2.895546] but task is already holding lock: [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 [ 2.895561] [ 2.895561] which lock already depends on the new lock. [ 2.895561] [ 2.895566] [ 2.895566] the existing dependency chain (in reverse order) is: [ 2.895570] [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: [ 2.895583] __mutex_lock+0x80/0x9a0 [ 2.895588] mutex_lock_nested+0x1b/0x20 [ 2.895593] media_device_register_entity+0x92/0x1e0 [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 [ 2.895608] isys_probe+0x6cb/0xed0 [ 2.895613] ipu_bus_probe+0xfd/0x2e0 [ 2.895620] really_probe+0x268/0x3d0 [ 2.895625] driver_probe_device+0x11a/0x130 [ 2.895630] __device_attach_driver+0x86/0x100 [ 2.895635] bus_for_each_drv+0x6e/0xb0 [ 2.895640] __device_attach+0xdf/0x160 [ 2.895645] device_initial_probe+0x13/0x20 [ 2.895650] bus_probe_device+0xa6/0xc0 [ 2.895655] deferred_probe_work_func+0x88/0xe0 [ 2.895661] process_one_work+0x220/0x5c0 [ 2.895665] worker_thread+0x1da/0x3b0 [ 2.895670] kthread+0x12c/0x150 [ 2.895675] ret_from_fork+0x3a/0x50 [ 2.895678] [ 2.895678] -> #0 (&asd->mutex){+.+.}: [ 2.895688] lock_acquire+0x95/0x1a0 [ 2.895693] __mutex_lock+0x80/0x9a0 [ 2.895698] mutex_lock_nested+0x1b/0x20 [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 [ 2.895728] csi2_link_validate+0xc6/0x220 [ 2.895733] __media_pipeline_start+0x15b/0x2f0 [ 2.895738] media_pipeline_start+0x33/0x50 [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 [ 2.895748] start_streaming+0x186/0x3a0 [ 2.895753] vb2_start_streaming+0x6d/0x130 [ 2.895758] vb2_core_streamon+0x108/0x140 [ 2.895762] vb2_streamon+0x29/0x50 [ 2.895767] vb2_ioctl_streamon+0x42/0x50 [ 2.895772] v4l_streamon+0x20/0x30 [ 2.895776] __video_do_ioctl+0x1af/0x3c0 [ 2.895781] video_usercopy+0x27e/0x7e0 [ 2.895785] video_ioctl2+0x15/0x20 [ 2.895789] v4l2_ioctl+0x49/0x50 [ 2.895794] do_video_ioctl+0x93c/0x2360 [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c [ 2.895821] [ 2.895821] other info that might help us debug this: [ 2.895821] [ 2.895826] Possible unsafe locking scenario: [ 2.895826] [ 2.895830] CPU0 CPU1 [ 2.895833] ---- ---- [ 2.895836] lock(&mdev->graph_mutex); [ 2.895842] lock(&asd->mutex); [ 2.895847] lock(&mdev->graph_mutex); [ 2.895852] lock(&asd->mutex); [ 2.895857] [ 2.895857] *** DEADLOCK *** [ 2.895857] [ 2.895863] 3 locks held by earlyEvs/1839: [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 [ 2.895896] [ 2.895896] stack backtrace: [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 [ 2.895907] Call Trace: [ 2.895915] dump_stack+0x70/0xa5 [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 [ 2.895927] __lock_acquire+0x1284/0x1340 [ 2.895931] ? __lock_acquire+0x2b5/0x1340 [ 2.895940] lock_acquire+0x95/0x1a0 [ 2.895945] ? lock_acquire+0x95/0x1a0 [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895961] __mutex_lock+0x80/0x9a0 [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895971] ? crlmodule_get_format+0x43/0x50 [ 2.895979] mutex_lock_nested+0x1b/0x20 [ 2.895984] ? mutex_lock_nested+0x1b/0x20 [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 [ 2.896011] ? crlmodule_get_format+0x2a/0x50 [ 2.896018] ? find_held_lock+0x35/0xa0 [ 2.896023] ? crlmodule_get_format+0x43/0x50 [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 [ 2.896042] ? mutex_unlock+0x12/0x20 [ 2.896046] ? crlmodule_get_format+0x43/0x50 [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 [ 2.896070] ? kernel_text_address+0xc4/0x100 [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 [ 2.896085] ? kernel_text_address+0xc4/0x100 [ 2.896092] ? __lock_acquire+0x1106/0x1340 [ 2.896096] ? __lock_acquire+0x1169/0x1340 [ 2.896103] csi2_link_validate+0xc6/0x220 [ 2.896110] ? __lock_is_held+0x5a/0xa0 [ 2.896115] ? mark_held_locks+0x58/0x80 [ 2.896122] ? __kmalloc+0x207/0x2e0 [ 2.896127] ? __lock_is_held+0x5a/0xa0 [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 [ 2.896139] ? __kmalloc+0x2a3/0x2e0 [ 2.896144] ? media_pipeline_start+0x28/0x50 [ 2.896150] ? __media_entity_enum_init+0x33/0x70 [ 2.896155] ? csi2_has_route+0x18/0x20 [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 [ 2.896166] __media_pipeline_start+0x15b/0x2f0 [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 [ 2.896179] media_pipeline_start+0x33/0x50 [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 [ 2.896191] ? __lock_acquire+0x132e/0x1340 [ 2.896198] ? __lock_acquire+0x2b5/0x1340 [ 2.896204] ? lock_acquire+0x95/0x1a0 [ 2.896209] ? start_streaming+0x5c/0x3a0 [ 2.896215] ? start_streaming+0x5c/0x3a0 [ 2.896221] ? __mutex_lock+0x391/0x9a0 [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 [ 2.896233] ? find_held_lock+0x35/0xa0 [ 2.896238] ? v4l_enable_media_source+0x57/0x70 [ 2.896245] start_streaming+0x186/0x3a0 [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 [ 2.896257] vb2_start_streaming+0x6d/0x130 [ 2.896262] ? vb2_start_streaming+0x6d/0x130 [ 2.896267] vb2_core_streamon+0x108/0x140 [ 2.896273] vb2_streamon+0x29/0x50 [ 2.896278] vb2_ioctl_streamon+0x42/0x50 [ 2.896284] v4l_streamon+0x20/0x30 [ 2.896288] __video_do_ioctl+0x1af/0x3c0 [ 2.896296] ? __might_fault+0x85/0x90 [ 2.896302] video_usercopy+0x27e/0x7e0 [ 2.896307] ? copy_overflow+0x20/0x20 [ 2.896313] ? find_held_lock+0x35/0xa0 [ 2.896319] ? __might_fault+0x3e/0x90 [ 2.896325] video_ioctl2+0x15/0x20 [ 2.896330] v4l2_ioctl+0x49/0x50 [ 2.896335] do_video_ioctl+0x93c/0x2360 [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c [ 2.896377] RIP: 0023:0xf7e79b79 [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ------------------------------------------------------------------------ > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, December 13, 2018 12:40 PM > To: Zhang, Jun <jun.zhang@intel.com> > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > Ok, we will test it, thanks! > > But please also try the sysrq-y with the earlier patch after a hang! > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > Sent: Thursday, December 13, 2018 10:43 > > To: Zhang, Jun <jun.zhang@intel.com> > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie > > A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > Hello, Paul > > > > > > I think the next patch is better. > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > Please help review. > > > I don't test it. If you agree, we will test it. > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > and finds them equal. > > > > o At just this time something like rcu_start_this_gp() assigns a new > > (larger) value to rdp->gp_seq_needed. > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > old value. > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > Of course, there could be bugs. For example: > > > > o __note_gp_changes() might be called on a different CPU than that > > corresponding to rdp. You can check this with something like: > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > o The same things could happen with rcu_start_this_gp(), and the > > above WARN_ON_ONCE() would work there as well. > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > you are doing CPU-hotplug operations. (It can run on a CPU other > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > o Interrupts might not really be disabled. > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > So why not just test it anyway? If it makes the bug go away, I will > > be surprised, but it would not be the first surprise for me. ;-) > > > > Thanx, Paul > > > > > Thanks! > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > 0b760c1..c00f34e 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > zero_cpu_stall_ticks(rdp); > > > } > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) || > > > + rdp->gpwrap) > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > WRITE_ONCE(rdp->gpwrap, false); > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > -----Original Message----- > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > Sent: Thursday, December 13, 2018 08:12 > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi > > > J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > Please correct me if I have something wrong. > > > > > > That would be because I sent you the wrong patch, apologies! :-/ > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > Strange. > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > -------------------------------------------------------------------- > > > -- > > > -- > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > Backported from v4.21/v5.0 > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > for failing to start a grace period. This commit therefore adds a > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > must be set for this sysrq to be available. > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > 0b760c1369f7..e9392a9d6291 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -61,6 +61,7 @@ > > > #include <linux/trace_events.h> > > > #include <linux/suspend.h> > > > #include <linux/ftrace.h> > > > +#include <linux/sysrq.h> > > > > > > #include "tree.h" > > > #include "rcu.h" > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes in > > > use. */ > > > /* panic() on RCU Stall sysctl. */ > > > int sysctl_panic_on_rcu_stall __read_mostly; > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > /* > > > * The rcu_scheduler_active variable is initialized to the value @@ > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > +*/ static void sysrq_show_rcu(int key) { > > > + show_rcu_gp_kthreads(); > > > +} > > > + > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > + .handler = sysrq_show_rcu, > > > + .help_msg = "show-rcu(y)", > > > + .action_msg = "Show RCU tree", > > > + .enable_mask = SYSRQ_ENABLE_DUMP, > > > +}; > > > + > > > +static int __init rcu_sysrq_init(void) { > > > + if (sysrq_rcu) > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > + return 0; > > > +} > > > +early_initcall(rcu_sysrq_init); > > > + > > > /* > > > * Send along grace-period-related data for rcutorture diagnostics. > > > */ > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-13 18:11 ` Paul E. McKenney @ 2018-12-14 1:30 ` He, Bo 2018-12-14 2:15 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-14 1:30 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: Here is the grep from .config: egrep "HZ|RCU" .config CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y # RCU Subsystem CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 # CONFIG_MACHZ_WDT is not set # RCU Debugging CONFIG_PROVE_RCU=y CONFIG_RCU_PERF_TEST=m CONFIG_RCU_TORTURE_TEST=m CONFIG_RCU_CPU_STALL_TIMEOUT=7 CONFIG_RCU_TRACE=y CONFIG_RCU_EQS_DEBUG=y -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Friday, December 14, 2018 2:12 AM To: He, Bo <bo.he@intel.com> Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> Subject: Re: rcu_preempt caused oom On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 This is quite helpful, thank you! The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: 1. Because rcu_check_gp_start_stall() is only ever invoked from RCU_SOFTIRQ, it is possible that softirqs are stalled for whatever reason. 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock interrupt handler, it is possible that the scheduler tick has somehow been disabled. Traces from earlier runs showed a great deal of RCU callbacks queued, which would have caused RCU to refuse to allow the scheduler tick to be disabled, even if the corresponding CPU was idle. 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given that you are building for a battery-powered device) and all of the CPU's callbacks are lazy. Except that your earlier traces showed lots of non-lazy callbacks. Besides, even if all callbacks were lazy, there would still be a scheduling-clock interrupt every six seconds, and there are quite a few six-second intervals in a two-minute watchdog timeout. But if we cannot find the problem quickly, I will likely ask you to try reproducing with CONFIG_FAST_NO_HZ=n. This could be thought of as bisecting the RCU code looking for the bug. The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. I did check this in current -rcu, but you are instead running v4.19, so I should also check there. The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: o rcu_accelerate_cbs_unlocked(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ if (needwake) rcu_gp_kthread_wake(rsp); o rcu_advance_cbs(), which returns the value returned by rcu_accelerate_cbs(), thus pushing the problem off to its callers, which are called out below. o __note_gp_changes(), which also returns the value returned by rcu_accelerate_cbs(), thus pushing the problem off to its callers, which are called out below. o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period kthreads such as the rcu_preempt task. Therefore, this function never needs to awaken the rcu_preempt task, because the fact that this function is executing means that this task is already awake. (Also, as noted above, we can eliminate this code from consideration because this task is known to have been sleeping at the last time that the RCU_GP_FLAG_INIT bit was set.) o rcu_report_qs_rdp(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); /* ^^^ Released rnp->lock */ if (needwake) rcu_gp_kthread_wake(rsp); o rcu_prepare_for_idle(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_accelerate_cbs(rsp, rnp, rdp); raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ if (needwake) rcu_gp_kthread_wake(rsp); Now for rcu_advance_cbs(): o __note_gp_changes(), which which also returns the value returned by rcu_advance_cbs(), thus pushing the problem off to its callers, which are called out below. o rcu_migrate_callbacks(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || rcu_advance_cbs(rsp, rnp_root, my_rdp); rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != !rcu_segcblist_n_cbs(&my_rdp->cblist)); raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); if (needwake) rcu_gp_kthread_wake(rsp); Now for __note_gp_changes(): o note_gp_changes(), which does the following, thus properly awakening the rcu_preempt task when needed: needwake = __note_gp_changes(rsp, rnp, rdp); raw_spin_unlock_irqrestore_rcu_node(rnp, flags); if (needwake) rcu_gp_kthread_wake(rsp); o rcu_gp_init() which is only ever invoked by RCU grace-period kthreads such as the rcu_preempt task, which makes wakeups unnecessary, just as for rcu_gp_cleanup() above. o rcu_gp_cleanup(), ditto. So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. Thanx, Paul ------------------------------------------------------------------------ lockdep complaint: ------------------------------------------------------------------------ [ 2.895507] ====================================================== [ 2.895511] WARNING: possible circular locking dependency detected [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U [ 2.895521] ------------------------------------------------------ [ 2.895525] earlyEvs/1839 is trying to acquire lock: [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895546] [ 2.895546] but task is already holding lock: [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 [ 2.895561] [ 2.895561] which lock already depends on the new lock. [ 2.895561] [ 2.895566] [ 2.895566] the existing dependency chain (in reverse order) is: [ 2.895570] [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: [ 2.895583] __mutex_lock+0x80/0x9a0 [ 2.895588] mutex_lock_nested+0x1b/0x20 [ 2.895593] media_device_register_entity+0x92/0x1e0 [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 [ 2.895608] isys_probe+0x6cb/0xed0 [ 2.895613] ipu_bus_probe+0xfd/0x2e0 [ 2.895620] really_probe+0x268/0x3d0 [ 2.895625] driver_probe_device+0x11a/0x130 [ 2.895630] __device_attach_driver+0x86/0x100 [ 2.895635] bus_for_each_drv+0x6e/0xb0 [ 2.895640] __device_attach+0xdf/0x160 [ 2.895645] device_initial_probe+0x13/0x20 [ 2.895650] bus_probe_device+0xa6/0xc0 [ 2.895655] deferred_probe_work_func+0x88/0xe0 [ 2.895661] process_one_work+0x220/0x5c0 [ 2.895665] worker_thread+0x1da/0x3b0 [ 2.895670] kthread+0x12c/0x150 [ 2.895675] ret_from_fork+0x3a/0x50 [ 2.895678] [ 2.895678] -> #0 (&asd->mutex){+.+.}: [ 2.895688] lock_acquire+0x95/0x1a0 [ 2.895693] __mutex_lock+0x80/0x9a0 [ 2.895698] mutex_lock_nested+0x1b/0x20 [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 [ 2.895728] csi2_link_validate+0xc6/0x220 [ 2.895733] __media_pipeline_start+0x15b/0x2f0 [ 2.895738] media_pipeline_start+0x33/0x50 [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 [ 2.895748] start_streaming+0x186/0x3a0 [ 2.895753] vb2_start_streaming+0x6d/0x130 [ 2.895758] vb2_core_streamon+0x108/0x140 [ 2.895762] vb2_streamon+0x29/0x50 [ 2.895767] vb2_ioctl_streamon+0x42/0x50 [ 2.895772] v4l_streamon+0x20/0x30 [ 2.895776] __video_do_ioctl+0x1af/0x3c0 [ 2.895781] video_usercopy+0x27e/0x7e0 [ 2.895785] video_ioctl2+0x15/0x20 [ 2.895789] v4l2_ioctl+0x49/0x50 [ 2.895794] do_video_ioctl+0x93c/0x2360 [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c [ 2.895821] [ 2.895821] other info that might help us debug this: [ 2.895821] [ 2.895826] Possible unsafe locking scenario: [ 2.895826] [ 2.895830] CPU0 CPU1 [ 2.895833] ---- ---- [ 2.895836] lock(&mdev->graph_mutex); [ 2.895842] lock(&asd->mutex); [ 2.895847] lock(&mdev->graph_mutex); [ 2.895852] lock(&asd->mutex); [ 2.895857] [ 2.895857] *** DEADLOCK *** [ 2.895857] [ 2.895863] 3 locks held by earlyEvs/1839: [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 [ 2.895896] [ 2.895896] stack backtrace: [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 [ 2.895907] Call Trace: [ 2.895915] dump_stack+0x70/0xa5 [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 [ 2.895927] __lock_acquire+0x1284/0x1340 [ 2.895931] ? __lock_acquire+0x2b5/0x1340 [ 2.895940] lock_acquire+0x95/0x1a0 [ 2.895945] ? lock_acquire+0x95/0x1a0 [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895961] __mutex_lock+0x80/0x9a0 [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895971] ? crlmodule_get_format+0x43/0x50 [ 2.895979] mutex_lock_nested+0x1b/0x20 [ 2.895984] ? mutex_lock_nested+0x1b/0x20 [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 [ 2.896011] ? crlmodule_get_format+0x2a/0x50 [ 2.896018] ? find_held_lock+0x35/0xa0 [ 2.896023] ? crlmodule_get_format+0x43/0x50 [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 [ 2.896042] ? mutex_unlock+0x12/0x20 [ 2.896046] ? crlmodule_get_format+0x43/0x50 [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 [ 2.896070] ? kernel_text_address+0xc4/0x100 [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 [ 2.896085] ? kernel_text_address+0xc4/0x100 [ 2.896092] ? __lock_acquire+0x1106/0x1340 [ 2.896096] ? __lock_acquire+0x1169/0x1340 [ 2.896103] csi2_link_validate+0xc6/0x220 [ 2.896110] ? __lock_is_held+0x5a/0xa0 [ 2.896115] ? mark_held_locks+0x58/0x80 [ 2.896122] ? __kmalloc+0x207/0x2e0 [ 2.896127] ? __lock_is_held+0x5a/0xa0 [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 [ 2.896139] ? __kmalloc+0x2a3/0x2e0 [ 2.896144] ? media_pipeline_start+0x28/0x50 [ 2.896150] ? __media_entity_enum_init+0x33/0x70 [ 2.896155] ? csi2_has_route+0x18/0x20 [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 [ 2.896166] __media_pipeline_start+0x15b/0x2f0 [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 [ 2.896179] media_pipeline_start+0x33/0x50 [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 [ 2.896191] ? __lock_acquire+0x132e/0x1340 [ 2.896198] ? __lock_acquire+0x2b5/0x1340 [ 2.896204] ? lock_acquire+0x95/0x1a0 [ 2.896209] ? start_streaming+0x5c/0x3a0 [ 2.896215] ? start_streaming+0x5c/0x3a0 [ 2.896221] ? __mutex_lock+0x391/0x9a0 [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 [ 2.896233] ? find_held_lock+0x35/0xa0 [ 2.896238] ? v4l_enable_media_source+0x57/0x70 [ 2.896245] start_streaming+0x186/0x3a0 [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 [ 2.896257] vb2_start_streaming+0x6d/0x130 [ 2.896262] ? vb2_start_streaming+0x6d/0x130 [ 2.896267] vb2_core_streamon+0x108/0x140 [ 2.896273] vb2_streamon+0x29/0x50 [ 2.896278] vb2_ioctl_streamon+0x42/0x50 [ 2.896284] v4l_streamon+0x20/0x30 [ 2.896288] __video_do_ioctl+0x1af/0x3c0 [ 2.896296] ? __might_fault+0x85/0x90 [ 2.896302] video_usercopy+0x27e/0x7e0 [ 2.896307] ? copy_overflow+0x20/0x20 [ 2.896313] ? find_held_lock+0x35/0xa0 [ 2.896319] ? __might_fault+0x3e/0x90 [ 2.896325] video_ioctl2+0x15/0x20 [ 2.896330] v4l2_ioctl+0x49/0x50 [ 2.896335] do_video_ioctl+0x93c/0x2360 [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c [ 2.896377] RIP: 0023:0xf7e79b79 [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ------------------------------------------------------------------------ > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Thursday, December 13, 2018 12:40 PM > To: Zhang, Jun <jun.zhang@intel.com> > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie > A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > Ok, we will test it, thanks! > > But please also try the sysrq-y with the earlier patch after a hang! > > Thanx, Paul > > > -----Original Message----- > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > Sent: Thursday, December 13, 2018 10:43 > > To: Zhang, Jun <jun.zhang@intel.com> > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, > > Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > Hello, Paul > > > > > > I think the next patch is better. > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > Please help review. > > > I don't test it. If you agree, we will test it. > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > and finds them equal. > > > > o At just this time something like rcu_start_this_gp() assigns a new > > (larger) value to rdp->gp_seq_needed. > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > old value. > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > Of course, there could be bugs. For example: > > > > o __note_gp_changes() might be called on a different CPU than that > > corresponding to rdp. You can check this with something like: > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > o The same things could happen with rcu_start_this_gp(), and the > > above WARN_ON_ONCE() would work there as well. > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > you are doing CPU-hotplug operations. (It can run on a CPU other > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > o Interrupts might not really be disabled. > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > So why not just test it anyway? If it makes the bug go away, I will > > be surprised, but it would not be the first surprise for me. ;-) > > > > Thanx, Paul > > > > > Thanks! > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > 0b760c1..c00f34e 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > zero_cpu_stall_ticks(rdp); > > > } > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) > > > + || > > > + rdp->gpwrap) > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > WRITE_ONCE(rdp->gpwrap, false); > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > -----Original Message----- > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > Sent: Thursday, December 13, 2018 08:12 > > > To: He, Bo <bo.he@intel.com> > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > Sun, Yi J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > Please correct me if I have something wrong. > > > > > > That would be because I sent you the wrong patch, apologies! :-/ > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > <jie.a.bai@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > Strange. > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > ------------------------------------------------------------------ > > > -- > > > -- > > > -- > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > Backported from v4.21/v5.0 > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > for failing to start a grace period. This commit therefore adds a > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > must be set for this sysrq to be available. > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > 0b760c1369f7..e9392a9d6291 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -61,6 +61,7 @@ > > > #include <linux/trace_events.h> > > > #include <linux/suspend.h> > > > #include <linux/ftrace.h> > > > +#include <linux/sysrq.h> > > > > > > #include "tree.h" > > > #include "rcu.h" > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes > > > in use. */ > > > /* panic() on RCU Stall sysctl. */ int sysctl_panic_on_rcu_stall > > > __read_mostly; > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > /* > > > * The rcu_scheduler_active variable is initialized to the value > > > @@ > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > +*/ static void sysrq_show_rcu(int key) { > > > + show_rcu_gp_kthreads(); > > > +} > > > + > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > + .handler = sysrq_show_rcu, > > > + .help_msg = "show-rcu(y)", > > > + .action_msg = "Show RCU tree", > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > + > > > +static int __init rcu_sysrq_init(void) { > > > + if (sysrq_rcu) > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > + return 0; > > > +} > > > +early_initcall(rcu_sysrq_init); > > > + > > > /* > > > * Send along grace-period-related data for rcutorture diagnostics. > > > */ > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-14 1:30 ` He, Bo @ 2018-12-14 2:15 ` Paul E. McKenney 2018-12-14 2:40 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-14 2:15 UTC (permalink / raw) To: He, Bo Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Fri, Dec 14, 2018 at 01:30:04AM +0000, He, Bo wrote: > as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: Yes, you are correct, CONFIG_RCU_FAST_NO_HZ. OK, you do not have it set, which means several code paths can be ignored. Also CONFIG_HZ=1000, so 300 second delay. Thanx, Paul > Here is the grep from .config: > egrep "HZ|RCU" .config > CONFIG_NO_HZ_COMMON=y > # CONFIG_HZ_PERIODIC is not set > CONFIG_NO_HZ_IDLE=y > # CONFIG_NO_HZ_FULL is not set > CONFIG_NO_HZ=y > # RCU Subsystem > CONFIG_PREEMPT_RCU=y > # CONFIG_RCU_EXPERT is not set > CONFIG_SRCU=y > CONFIG_TREE_SRCU=y > CONFIG_TASKS_RCU=y > CONFIG_RCU_STALL_COMMON=y > CONFIG_RCU_NEED_SEGCBLIST=y > # CONFIG_HZ_100 is not set > # CONFIG_HZ_250 is not set > # CONFIG_HZ_300 is not set > CONFIG_HZ_1000=y > CONFIG_HZ=1000 > # CONFIG_MACHZ_WDT is not set > # RCU Debugging > CONFIG_PROVE_RCU=y > CONFIG_RCU_PERF_TEST=m > CONFIG_RCU_TORTURE_TEST=m > CONFIG_RCU_CPU_STALL_TIMEOUT=7 > CONFIG_RCU_TRACE=y > CONFIG_RCU_EQS_DEBUG=y > > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Friday, December 14, 2018 2:12 AM > To: He, Bo <bo.he@intel.com> > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 > > This is quite helpful, thank you! > > The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. > The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. > > The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. > The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. > > But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: > > 1. Because rcu_check_gp_start_stall() is only ever invoked from > RCU_SOFTIRQ, it is possible that softirqs are stalled for > whatever reason. > > 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock > interrupt handler, it is possible that the scheduler tick has > somehow been disabled. Traces from earlier runs showed a great > deal of RCU callbacks queued, which would have caused RCU to > refuse to allow the scheduler tick to be disabled, even if the > corresponding CPU was idle. > > 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given > that you are building for a battery-powered device) and all of the > CPU's callbacks are lazy. Except that your earlier traces showed > lots of non-lazy callbacks. Besides, even if all callbacks were > lazy, there would still be a scheduling-clock interrupt every > six seconds, and there are quite a few six-second intervals > in a two-minute watchdog timeout. > > But if we cannot find the problem quickly, I will likely ask > you to try reproducing with CONFIG_FAST_NO_HZ=n. This could > be thought of as bisecting the RCU code looking for the bug. > > The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? > One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. > > Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. > > You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. > > Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. > I did check this in current -rcu, but you are instead running v4.19, so I should also check there. > > The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. > Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). > > The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: > > o rcu_accelerate_cbs_unlocked(), which does the following, thus > properly awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_advance_cbs(), which returns the value returned by > rcu_accelerate_cbs(), thus pushing the problem off to its > callers, which are called out below. > > o __note_gp_changes(), which also returns the value returned by > rcu_accelerate_cbs(), thus pushing the problem off to its callers, > which are called out below. > > o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period > kthreads such as the rcu_preempt task. Therefore, this function > never needs to awaken the rcu_preempt task, because the fact > that this function is executing means that this task is already > awake. (Also, as noted above, we can eliminate this code from > consideration because this task is known to have been sleeping > at the last time that the RCU_GP_FLAG_INIT bit was set.) > > o rcu_report_qs_rdp(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > /* ^^^ Released rnp->lock */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_prepare_for_idle(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > Now for rcu_advance_cbs(): > > o __note_gp_changes(), which which also returns the value returned > by rcu_advance_cbs(), thus pushing the problem off to its callers, > which are called out below. > > o rcu_migrate_callbacks(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || > rcu_advance_cbs(rsp, rnp_root, my_rdp); > rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != > !rcu_segcblist_n_cbs(&my_rdp->cblist)); > raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); > if (needwake) > rcu_gp_kthread_wake(rsp); > > Now for __note_gp_changes(): > > o note_gp_changes(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = __note_gp_changes(rsp, rnp, rdp); > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_gp_init() which is only ever invoked by RCU grace-period > kthreads such as the rcu_preempt task, which makes wakeups > unnecessary, just as for rcu_gp_cleanup() above. > > o rcu_gp_cleanup(), ditto. > > So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. > > Thanx, Paul > > ------------------------------------------------------------------------ > lockdep complaint: > ------------------------------------------------------------------------ > > [ 2.895507] ====================================================== > [ 2.895511] WARNING: possible circular locking dependency detected > [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U > [ 2.895521] ------------------------------------------------------ > [ 2.895525] earlyEvs/1839 is trying to acquire lock: > [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895546] > [ 2.895546] but task is already holding lock: > [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > [ 2.895561] > [ 2.895561] which lock already depends on the new lock. > [ 2.895561] > [ 2.895566] > [ 2.895566] the existing dependency chain (in reverse order) is: > [ 2.895570] > [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: > [ 2.895583] __mutex_lock+0x80/0x9a0 > [ 2.895588] mutex_lock_nested+0x1b/0x20 > [ 2.895593] media_device_register_entity+0x92/0x1e0 > [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 > [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 > [ 2.895608] isys_probe+0x6cb/0xed0 > [ 2.895613] ipu_bus_probe+0xfd/0x2e0 > [ 2.895620] really_probe+0x268/0x3d0 > [ 2.895625] driver_probe_device+0x11a/0x130 > [ 2.895630] __device_attach_driver+0x86/0x100 > [ 2.895635] bus_for_each_drv+0x6e/0xb0 > [ 2.895640] __device_attach+0xdf/0x160 > [ 2.895645] device_initial_probe+0x13/0x20 > [ 2.895650] bus_probe_device+0xa6/0xc0 > [ 2.895655] deferred_probe_work_func+0x88/0xe0 > [ 2.895661] process_one_work+0x220/0x5c0 > [ 2.895665] worker_thread+0x1da/0x3b0 > [ 2.895670] kthread+0x12c/0x150 > [ 2.895675] ret_from_fork+0x3a/0x50 > [ 2.895678] > [ 2.895678] -> #0 (&asd->mutex){+.+.}: > [ 2.895688] lock_acquire+0x95/0x1a0 > [ 2.895693] __mutex_lock+0x80/0x9a0 > [ 2.895698] mutex_lock_nested+0x1b/0x20 > [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 > [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 > [ 2.895728] csi2_link_validate+0xc6/0x220 > [ 2.895733] __media_pipeline_start+0x15b/0x2f0 > [ 2.895738] media_pipeline_start+0x33/0x50 > [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 > [ 2.895748] start_streaming+0x186/0x3a0 > [ 2.895753] vb2_start_streaming+0x6d/0x130 > [ 2.895758] vb2_core_streamon+0x108/0x140 > [ 2.895762] vb2_streamon+0x29/0x50 > [ 2.895767] vb2_ioctl_streamon+0x42/0x50 > [ 2.895772] v4l_streamon+0x20/0x30 > [ 2.895776] __video_do_ioctl+0x1af/0x3c0 > [ 2.895781] video_usercopy+0x27e/0x7e0 > [ 2.895785] video_ioctl2+0x15/0x20 > [ 2.895789] v4l2_ioctl+0x49/0x50 > [ 2.895794] do_video_ioctl+0x93c/0x2360 > [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 > [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 > [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 > [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c > [ 2.895821] > [ 2.895821] other info that might help us debug this: > [ 2.895821] > [ 2.895826] Possible unsafe locking scenario: > [ 2.895826] > [ 2.895830] CPU0 CPU1 > [ 2.895833] ---- ---- > [ 2.895836] lock(&mdev->graph_mutex); > [ 2.895842] lock(&asd->mutex); > [ 2.895847] lock(&mdev->graph_mutex); > [ 2.895852] lock(&asd->mutex); > [ 2.895857] > [ 2.895857] *** DEADLOCK *** > [ 2.895857] > [ 2.895863] 3 locks held by earlyEvs/1839: > [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 > [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 > [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > [ 2.895896] > [ 2.895896] stack backtrace: > [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 > [ 2.895907] Call Trace: > [ 2.895915] dump_stack+0x70/0xa5 > [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 > [ 2.895927] __lock_acquire+0x1284/0x1340 > [ 2.895931] ? __lock_acquire+0x2b5/0x1340 > [ 2.895940] lock_acquire+0x95/0x1a0 > [ 2.895945] ? lock_acquire+0x95/0x1a0 > [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895961] __mutex_lock+0x80/0x9a0 > [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895971] ? crlmodule_get_format+0x43/0x50 > [ 2.895979] mutex_lock_nested+0x1b/0x20 > [ 2.895984] ? mutex_lock_nested+0x1b/0x20 > [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 > [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.896011] ? crlmodule_get_format+0x2a/0x50 > [ 2.896018] ? find_held_lock+0x35/0xa0 > [ 2.896023] ? crlmodule_get_format+0x43/0x50 > [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 > [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 > [ 2.896042] ? mutex_unlock+0x12/0x20 > [ 2.896046] ? crlmodule_get_format+0x43/0x50 > [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 > [ 2.896070] ? kernel_text_address+0xc4/0x100 > [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 > [ 2.896085] ? kernel_text_address+0xc4/0x100 > [ 2.896092] ? __lock_acquire+0x1106/0x1340 > [ 2.896096] ? __lock_acquire+0x1169/0x1340 > [ 2.896103] csi2_link_validate+0xc6/0x220 > [ 2.896110] ? __lock_is_held+0x5a/0xa0 > [ 2.896115] ? mark_held_locks+0x58/0x80 > [ 2.896122] ? __kmalloc+0x207/0x2e0 > [ 2.896127] ? __lock_is_held+0x5a/0xa0 > [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 > [ 2.896139] ? __kmalloc+0x2a3/0x2e0 > [ 2.896144] ? media_pipeline_start+0x28/0x50 > [ 2.896150] ? __media_entity_enum_init+0x33/0x70 > [ 2.896155] ? csi2_has_route+0x18/0x20 > [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 > [ 2.896166] __media_pipeline_start+0x15b/0x2f0 > [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 > [ 2.896179] media_pipeline_start+0x33/0x50 > [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 > [ 2.896191] ? __lock_acquire+0x132e/0x1340 > [ 2.896198] ? __lock_acquire+0x2b5/0x1340 > [ 2.896204] ? lock_acquire+0x95/0x1a0 > [ 2.896209] ? start_streaming+0x5c/0x3a0 > [ 2.896215] ? start_streaming+0x5c/0x3a0 > [ 2.896221] ? __mutex_lock+0x391/0x9a0 > [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 > [ 2.896233] ? find_held_lock+0x35/0xa0 > [ 2.896238] ? v4l_enable_media_source+0x57/0x70 > [ 2.896245] start_streaming+0x186/0x3a0 > [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 > [ 2.896257] vb2_start_streaming+0x6d/0x130 > [ 2.896262] ? vb2_start_streaming+0x6d/0x130 > [ 2.896267] vb2_core_streamon+0x108/0x140 > [ 2.896273] vb2_streamon+0x29/0x50 > [ 2.896278] vb2_ioctl_streamon+0x42/0x50 > [ 2.896284] v4l_streamon+0x20/0x30 > [ 2.896288] __video_do_ioctl+0x1af/0x3c0 > [ 2.896296] ? __might_fault+0x85/0x90 > [ 2.896302] video_usercopy+0x27e/0x7e0 > [ 2.896307] ? copy_overflow+0x20/0x20 > [ 2.896313] ? find_held_lock+0x35/0xa0 > [ 2.896319] ? __might_fault+0x3e/0x90 > [ 2.896325] video_ioctl2+0x15/0x20 > [ 2.896330] v4l2_ioctl+0x49/0x50 > [ 2.896335] do_video_ioctl+0x93c/0x2360 > [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 > [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 > [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 > [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 > [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 > [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c > [ 2.896377] RIP: 0023:0xf7e79b79 > [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 > [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 > [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c > [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 > [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > ------------------------------------------------------------------------ > > > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Thursday, December 13, 2018 12:40 PM > > To: Zhang, Jun <jun.zhang@intel.com> > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie > > A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > > Ok, we will test it, thanks! > > > > But please also try the sysrq-y with the earlier patch after a hang! > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > Sent: Thursday, December 13, 2018 10:43 > > > To: Zhang, Jun <jun.zhang@intel.com> > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, > > > Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > > Hello, Paul > > > > > > > > I think the next patch is better. > > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > > Please help review. > > > > I don't test it. If you agree, we will test it. > > > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > > and finds them equal. > > > > > > o At just this time something like rcu_start_this_gp() assigns a new > > > (larger) value to rdp->gp_seq_needed. > > > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > > old value. > > > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > > > Of course, there could be bugs. For example: > > > > > > o __note_gp_changes() might be called on a different CPU than that > > > corresponding to rdp. You can check this with something like: > > > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > > > o The same things could happen with rcu_start_this_gp(), and the > > > above WARN_ON_ONCE() would work there as well. > > > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > > you are doing CPU-hotplug operations. (It can run on a CPU other > > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > > > o Interrupts might not really be disabled. > > > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > > > So why not just test it anyway? If it makes the bug go away, I will > > > be surprised, but it would not be the first surprise for me. ;-) > > > > > > Thanx, Paul > > > > > > > Thanks! > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > 0b760c1..c00f34e 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > > zero_cpu_stall_ticks(rdp); > > > > } > > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) > > > > + || > > > > + rdp->gpwrap) > > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > > WRITE_ONCE(rdp->gpwrap, false); > > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > Sent: Thursday, December 13, 2018 08:12 > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, Jun > > > > <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > > Sun, Yi J <yi.j.sun@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > > Please correct me if I have something wrong. > > > > > > > > That would be because I sent you the wrong patch, apologies! :-/ > > > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > <jie.a.bai@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > > > Strange. > > > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > -- > > > > -- > > > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > > > Backported from v4.21/v5.0 > > > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > > for failing to start a grace period. This commit therefore adds a > > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > > must be set for this sysrq to be available. > > > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > 0b760c1369f7..e9392a9d6291 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -61,6 +61,7 @@ > > > > #include <linux/trace_events.h> > > > > #include <linux/suspend.h> > > > > #include <linux/ftrace.h> > > > > +#include <linux/sysrq.h> > > > > > > > > #include "tree.h" > > > > #include "rcu.h" > > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # rcu_nodes > > > > in use. */ > > > > /* panic() on RCU Stall sysctl. */ int sysctl_panic_on_rcu_stall > > > > __read_mostly; > > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > > > /* > > > > * The rcu_scheduler_active variable is initialized to the value > > > > @@ > > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > > +*/ static void sysrq_show_rcu(int key) { > > > > + show_rcu_gp_kthreads(); > > > > +} > > > > + > > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > > + .handler = sysrq_show_rcu, > > > > + .help_msg = "show-rcu(y)", > > > > + .action_msg = "Show RCU tree", > > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > > + > > > > +static int __init rcu_sysrq_init(void) { > > > > + if (sysrq_rcu) > > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > > + return 0; > > > > +} > > > > +early_initcall(rcu_sysrq_init); > > > > + > > > > /* > > > > * Send along grace-period-related data for rcutorture diagnostics. > > > > */ > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-14 2:15 ` Paul E. McKenney @ 2018-12-14 2:40 ` He, Bo 2018-12-14 5:10 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-14 2:40 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J [-- Attachment #1: Type: text/plain, Size: 31711 bytes --] another experiment we have done with the enclosed debug patch, and also have more rcu trace event enable but without CONFIG_RCU_BOOST config, we don't reproduce the issue after 90 Hours until now on 10 boards(the issue should reproduce on one night per previous experience). the purposes are to capture the more rcu event trace close to the issue happen, because I check the __wait_rcu_gp is not always in running, so we think even it trigger the panic for 3s timeout, the issue is already happened before 3s. And Actually the rsp->gp_flags = 1, but RCU_GP_WAIT_GPS(1) ->state: 0x402, it means the kthread is not schedule for 300s but the RCU_GP_FLAG_INIT is set. What's your ideas? --------------------------------------------------------------------------------------------------------------------------------- - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } -------------------------------------------------------------------------------------- -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Friday, December 14, 2018 10:15 AM To: He, Bo <bo.he@intel.com> Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> Subject: Re: rcu_preempt caused oom On Fri, Dec 14, 2018 at 01:30:04AM +0000, He, Bo wrote: > as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: Yes, you are correct, CONFIG_RCU_FAST_NO_HZ. OK, you do not have it set, which means several code paths can be ignored. Also CONFIG_HZ=1000, so 300 second delay. Thanx, Paul > Here is the grep from .config: > egrep "HZ|RCU" .config > CONFIG_NO_HZ_COMMON=y > # CONFIG_HZ_PERIODIC is not set > CONFIG_NO_HZ_IDLE=y > # CONFIG_NO_HZ_FULL is not set > CONFIG_NO_HZ=y > # RCU Subsystem > CONFIG_PREEMPT_RCU=y > # CONFIG_RCU_EXPERT is not set > CONFIG_SRCU=y > CONFIG_TREE_SRCU=y > CONFIG_TASKS_RCU=y > CONFIG_RCU_STALL_COMMON=y > CONFIG_RCU_NEED_SEGCBLIST=y > # CONFIG_HZ_100 is not set > # CONFIG_HZ_250 is not set > # CONFIG_HZ_300 is not set > CONFIG_HZ_1000=y > CONFIG_HZ=1000 > # CONFIG_MACHZ_WDT is not set > # RCU Debugging > CONFIG_PROVE_RCU=y > CONFIG_RCU_PERF_TEST=m > CONFIG_RCU_TORTURE_TEST=m > CONFIG_RCU_CPU_STALL_TIMEOUT=7 > CONFIG_RCU_TRACE=y > CONFIG_RCU_EQS_DEBUG=y > > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Friday, December 14, 2018 2:12 AM > To: He, Bo <bo.he@intel.com> > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J > <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 > > This is quite helpful, thank you! > > The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. > The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. > > The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. > The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. > > But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: > > 1. Because rcu_check_gp_start_stall() is only ever invoked from > RCU_SOFTIRQ, it is possible that softirqs are stalled for > whatever reason. > > 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock > interrupt handler, it is possible that the scheduler tick has > somehow been disabled. Traces from earlier runs showed a great > deal of RCU callbacks queued, which would have caused RCU to > refuse to allow the scheduler tick to be disabled, even if the > corresponding CPU was idle. > > 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given > that you are building for a battery-powered device) and all of the > CPU's callbacks are lazy. Except that your earlier traces showed > lots of non-lazy callbacks. Besides, even if all callbacks were > lazy, there would still be a scheduling-clock interrupt every > six seconds, and there are quite a few six-second intervals > in a two-minute watchdog timeout. > > But if we cannot find the problem quickly, I will likely ask > you to try reproducing with CONFIG_FAST_NO_HZ=n. This could > be thought of as bisecting the RCU code looking for the bug. > > The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? > One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. > > Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. > > You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. > > Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. > I did check this in current -rcu, but you are instead running v4.19, so I should also check there. > > The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. > Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). > > The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: > > o rcu_accelerate_cbs_unlocked(), which does the following, thus > properly awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_advance_cbs(), which returns the value returned by > rcu_accelerate_cbs(), thus pushing the problem off to its > callers, which are called out below. > > o __note_gp_changes(), which also returns the value returned by > rcu_accelerate_cbs(), thus pushing the problem off to its callers, > which are called out below. > > o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period > kthreads such as the rcu_preempt task. Therefore, this function > never needs to awaken the rcu_preempt task, because the fact > that this function is executing means that this task is already > awake. (Also, as noted above, we can eliminate this code from > consideration because this task is known to have been sleeping > at the last time that the RCU_GP_FLAG_INIT bit was set.) > > o rcu_report_qs_rdp(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > /* ^^^ Released rnp->lock */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_prepare_for_idle(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > if (needwake) > rcu_gp_kthread_wake(rsp); > > Now for rcu_advance_cbs(): > > o __note_gp_changes(), which which also returns the value returned > by rcu_advance_cbs(), thus pushing the problem off to its callers, > which are called out below. > > o rcu_migrate_callbacks(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || > rcu_advance_cbs(rsp, rnp_root, my_rdp); > rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != > !rcu_segcblist_n_cbs(&my_rdp->cblist)); > raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); > if (needwake) > rcu_gp_kthread_wake(rsp); > > Now for __note_gp_changes(): > > o note_gp_changes(), which does the following, thus properly > awakening the rcu_preempt task when needed: > > needwake = __note_gp_changes(rsp, rnp, rdp); > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > if (needwake) > rcu_gp_kthread_wake(rsp); > > o rcu_gp_init() which is only ever invoked by RCU grace-period > kthreads such as the rcu_preempt task, which makes wakeups > unnecessary, just as for rcu_gp_cleanup() above. > > o rcu_gp_cleanup(), ditto. > > So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. > > Thanx, Paul > > ---------------------------------------------------------------------- > -- > lockdep complaint: > ---------------------------------------------------------------------- > -- > > [ 2.895507] ====================================================== > [ 2.895511] WARNING: possible circular locking dependency detected > [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U > [ 2.895521] ------------------------------------------------------ > [ 2.895525] earlyEvs/1839 is trying to acquire lock: > [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895546] > [ 2.895546] but task is already holding lock: > [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > [ 2.895561] > [ 2.895561] which lock already depends on the new lock. > [ 2.895561] > [ 2.895566] > [ 2.895566] the existing dependency chain (in reverse order) is: > [ 2.895570] > [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: > [ 2.895583] __mutex_lock+0x80/0x9a0 > [ 2.895588] mutex_lock_nested+0x1b/0x20 > [ 2.895593] media_device_register_entity+0x92/0x1e0 > [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 > [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 > [ 2.895608] isys_probe+0x6cb/0xed0 > [ 2.895613] ipu_bus_probe+0xfd/0x2e0 > [ 2.895620] really_probe+0x268/0x3d0 > [ 2.895625] driver_probe_device+0x11a/0x130 > [ 2.895630] __device_attach_driver+0x86/0x100 > [ 2.895635] bus_for_each_drv+0x6e/0xb0 > [ 2.895640] __device_attach+0xdf/0x160 > [ 2.895645] device_initial_probe+0x13/0x20 > [ 2.895650] bus_probe_device+0xa6/0xc0 > [ 2.895655] deferred_probe_work_func+0x88/0xe0 > [ 2.895661] process_one_work+0x220/0x5c0 > [ 2.895665] worker_thread+0x1da/0x3b0 > [ 2.895670] kthread+0x12c/0x150 > [ 2.895675] ret_from_fork+0x3a/0x50 > [ 2.895678] > [ 2.895678] -> #0 (&asd->mutex){+.+.}: > [ 2.895688] lock_acquire+0x95/0x1a0 > [ 2.895693] __mutex_lock+0x80/0x9a0 > [ 2.895698] mutex_lock_nested+0x1b/0x20 > [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 > [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 > [ 2.895728] csi2_link_validate+0xc6/0x220 > [ 2.895733] __media_pipeline_start+0x15b/0x2f0 > [ 2.895738] media_pipeline_start+0x33/0x50 > [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 > [ 2.895748] start_streaming+0x186/0x3a0 > [ 2.895753] vb2_start_streaming+0x6d/0x130 > [ 2.895758] vb2_core_streamon+0x108/0x140 > [ 2.895762] vb2_streamon+0x29/0x50 > [ 2.895767] vb2_ioctl_streamon+0x42/0x50 > [ 2.895772] v4l_streamon+0x20/0x30 > [ 2.895776] __video_do_ioctl+0x1af/0x3c0 > [ 2.895781] video_usercopy+0x27e/0x7e0 > [ 2.895785] video_ioctl2+0x15/0x20 > [ 2.895789] v4l2_ioctl+0x49/0x50 > [ 2.895794] do_video_ioctl+0x93c/0x2360 > [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 > [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 > [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 > [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c > [ 2.895821] > [ 2.895821] other info that might help us debug this: > [ 2.895821] > [ 2.895826] Possible unsafe locking scenario: > [ 2.895826] > [ 2.895830] CPU0 CPU1 > [ 2.895833] ---- ---- > [ 2.895836] lock(&mdev->graph_mutex); > [ 2.895842] lock(&asd->mutex); > [ 2.895847] lock(&mdev->graph_mutex); > [ 2.895852] lock(&asd->mutex); > [ 2.895857] > [ 2.895857] *** DEADLOCK *** > [ 2.895857] > [ 2.895863] 3 locks held by earlyEvs/1839: > [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 > [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 > [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > [ 2.895896] > [ 2.895896] stack backtrace: > [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 > [ 2.895907] Call Trace: > [ 2.895915] dump_stack+0x70/0xa5 > [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 > [ 2.895927] __lock_acquire+0x1284/0x1340 > [ 2.895931] ? __lock_acquire+0x2b5/0x1340 > [ 2.895940] lock_acquire+0x95/0x1a0 > [ 2.895945] ? lock_acquire+0x95/0x1a0 > [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895961] __mutex_lock+0x80/0x9a0 > [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895971] ? crlmodule_get_format+0x43/0x50 > [ 2.895979] mutex_lock_nested+0x1b/0x20 > [ 2.895984] ? mutex_lock_nested+0x1b/0x20 > [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 > [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 > [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.896011] ? crlmodule_get_format+0x2a/0x50 > [ 2.896018] ? find_held_lock+0x35/0xa0 > [ 2.896023] ? crlmodule_get_format+0x43/0x50 > [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 > [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 > [ 2.896042] ? mutex_unlock+0x12/0x20 > [ 2.896046] ? crlmodule_get_format+0x43/0x50 > [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 > [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 > [ 2.896070] ? kernel_text_address+0xc4/0x100 > [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 > [ 2.896085] ? kernel_text_address+0xc4/0x100 > [ 2.896092] ? __lock_acquire+0x1106/0x1340 > [ 2.896096] ? __lock_acquire+0x1169/0x1340 > [ 2.896103] csi2_link_validate+0xc6/0x220 > [ 2.896110] ? __lock_is_held+0x5a/0xa0 > [ 2.896115] ? mark_held_locks+0x58/0x80 > [ 2.896122] ? __kmalloc+0x207/0x2e0 > [ 2.896127] ? __lock_is_held+0x5a/0xa0 > [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 > [ 2.896139] ? __kmalloc+0x2a3/0x2e0 > [ 2.896144] ? media_pipeline_start+0x28/0x50 > [ 2.896150] ? __media_entity_enum_init+0x33/0x70 > [ 2.896155] ? csi2_has_route+0x18/0x20 > [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 > [ 2.896166] __media_pipeline_start+0x15b/0x2f0 > [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 > [ 2.896179] media_pipeline_start+0x33/0x50 > [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 > [ 2.896191] ? __lock_acquire+0x132e/0x1340 > [ 2.896198] ? __lock_acquire+0x2b5/0x1340 > [ 2.896204] ? lock_acquire+0x95/0x1a0 > [ 2.896209] ? start_streaming+0x5c/0x3a0 > [ 2.896215] ? start_streaming+0x5c/0x3a0 > [ 2.896221] ? __mutex_lock+0x391/0x9a0 > [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 > [ 2.896233] ? find_held_lock+0x35/0xa0 > [ 2.896238] ? v4l_enable_media_source+0x57/0x70 > [ 2.896245] start_streaming+0x186/0x3a0 > [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 > [ 2.896257] vb2_start_streaming+0x6d/0x130 > [ 2.896262] ? vb2_start_streaming+0x6d/0x130 > [ 2.896267] vb2_core_streamon+0x108/0x140 > [ 2.896273] vb2_streamon+0x29/0x50 > [ 2.896278] vb2_ioctl_streamon+0x42/0x50 > [ 2.896284] v4l_streamon+0x20/0x30 > [ 2.896288] __video_do_ioctl+0x1af/0x3c0 > [ 2.896296] ? __might_fault+0x85/0x90 > [ 2.896302] video_usercopy+0x27e/0x7e0 > [ 2.896307] ? copy_overflow+0x20/0x20 > [ 2.896313] ? find_held_lock+0x35/0xa0 > [ 2.896319] ? __might_fault+0x3e/0x90 > [ 2.896325] video_ioctl2+0x15/0x20 > [ 2.896330] v4l2_ioctl+0x49/0x50 > [ 2.896335] do_video_ioctl+0x93c/0x2360 > [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 > [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 > [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 > [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 > [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 > [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c > [ 2.896377] RIP: 0023:0xf7e79b79 > [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 > [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 > [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c > [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 > [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > ---------------------------------------------------------------------- > -- > > > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Thursday, December 13, 2018 12:40 PM > > To: Zhang, Jun <jun.zhang@intel.com> > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, > > Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > > Ok, we will test it, thanks! > > > > But please also try the sysrq-y with the earlier patch after a hang! > > > > Thanx, Paul > > > > > -----Original Message----- > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > Sent: Thursday, December 13, 2018 10:43 > > > To: Zhang, Jun <jun.zhang@intel.com> > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > Sun, Yi J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > > Hello, Paul > > > > > > > > I think the next patch is better. > > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > > Please help review. > > > > I don't test it. If you agree, we will test it. > > > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > > and finds them equal. > > > > > > o At just this time something like rcu_start_this_gp() assigns a new > > > (larger) value to rdp->gp_seq_needed. > > > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > > old value. > > > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > > > Of course, there could be bugs. For example: > > > > > > o __note_gp_changes() might be called on a different CPU than that > > > corresponding to rdp. You can check this with something like: > > > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > > > o The same things could happen with rcu_start_this_gp(), and the > > > above WARN_ON_ONCE() would work there as well. > > > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > > you are doing CPU-hotplug operations. (It can run on a CPU other > > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > > > o Interrupts might not really be disabled. > > > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > > > So why not just test it anyway? If it makes the bug go away, I > > > will be surprised, but it would not be the first surprise for me. > > > ;-) > > > > > > Thanx, Paul > > > > > > > Thanks! > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > 0b760c1..c00f34e 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > > zero_cpu_stall_ticks(rdp); > > > > } > > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) > > > > + || > > > > + rdp->gpwrap) > > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > > WRITE_ONCE(rdp->gpwrap, false); > > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > Sent: Thursday, December 13, 2018 08:12 > > > > To: He, Bo <bo.he@intel.com> > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > > Please correct me if I have something wrong. > > > > > > > > That would be because I sent you the wrong patch, apologies! > > > > :-/ > > > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > <jie.a.bai@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > > > Strange. > > > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > > > ---------------------------------------------------------------- > > > > -- > > > > -- > > > > -- > > > > -- > > > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > > > Backported from v4.21/v5.0 > > > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > > for failing to start a grace period. This commit therefore adds a > > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > > must be set for this sysrq to be available. > > > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > 0b760c1369f7..e9392a9d6291 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -61,6 +61,7 @@ > > > > #include <linux/trace_events.h> #include <linux/suspend.h> > > > > #include <linux/ftrace.h> > > > > +#include <linux/sysrq.h> > > > > > > > > #include "tree.h" > > > > #include "rcu.h" > > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # > > > > rcu_nodes in use. */ > > > > /* panic() on RCU Stall sysctl. */ int > > > > sysctl_panic_on_rcu_stall __read_mostly; > > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > > > /* > > > > * The rcu_scheduler_active variable is initialized to the > > > > value @@ > > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > > +*/ static void sysrq_show_rcu(int key) { > > > > + show_rcu_gp_kthreads(); > > > > +} > > > > + > > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > > + .handler = sysrq_show_rcu, > > > > + .help_msg = "show-rcu(y)", > > > > + .action_msg = "Show RCU tree", > > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > > + > > > > +static int __init rcu_sysrq_init(void) { > > > > + if (sysrq_rcu) > > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > > + return 0; > > > > +} > > > > +early_initcall(rcu_sysrq_init); > > > > + > > > > /* > > > > * Send along grace-period-related data for rcutorture diagnostics. > > > > */ > > > > > > > > > > > [-- Attachment #2: 0001-rcu-detect-the-preempt_rcu-hang.patch --] [-- Type: application/octet-stream, Size: 3741 bytes --] From ee34709f4d26e65758b851985f0a030bf2fed904 Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: detect the preempt_rcu hang Change-Id: I2c059ffe7d8b3ef8ab5f2cb246dff24a729555f1 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 34 ++++++++++++++++++++++++++++------ kernel/rcu/update.c | 4 +++- 2 files changed, 31 insertions(+), 7 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1..df59507 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -61,6 +61,7 @@ #include <linux/trace_events.h> #include <linux/suspend.h> #include <linux/ftrace.h> +#include <linux/sched/clock.h> #include "tree.h" #include "rcu.h" @@ -637,11 +638,13 @@ void show_rcu_gp_kthreads(void) struct rcu_state *rsp; for_each_rcu_flavor(rsp) { - pr_info("%s: wait state: %d ->state: %#lx\n", - rsp->name, rsp->gp_state, rsp->gp_kthread->state); + pr_info("%s: wait state: %d ->state: %#lx gp_flags: %d rsp: gp_seq = %lu\n", + rsp->name, rsp->gp_state, rsp->gp_kthread->state, rsp->gp_flags, rsp->gp_seq); rcu_for_each_node_breadth_first(rsp, rnp) { - if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) + if (ULONG_CMP_GE(rsp->gp_seq, rnp->gp_seq_needed)) { + pr_info("\trsp->gp_seq %lu is ge rnp->gp_seq_needed %lu\n", rsp->gp_seq, rnp->gp_seq_needed); continue; + } pr_info("\trcu_node %d:%d ->gp_seq %lu ->gp_seq_needed %lu\n", rnp->grplo, rnp->grphi, rnp->gp_seq, rnp->gp_seq_needed); @@ -651,8 +654,11 @@ void show_rcu_gp_kthreads(void) rdp = per_cpu_ptr(rsp->rda, cpu); if (rdp->gpwrap || ULONG_CMP_GE(rsp->gp_seq, - rdp->gp_seq_needed)) + rdp->gp_seq_needed)) { + pr_info("\tcpu %d rdp->gpwrap = %d rsp->gp_seq %lu is ge rdp->gp_seq_needed %lu\n", + cpu, rdp->gpwrap, rsp->gp_seq, rdp->gp_seq_needed); continue; + } pr_info("\tcpu %d ->gp_seq_needed %lu\n", cpu, rdp->gp_seq_needed); } @@ -2153,8 +2159,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2163,8 +2174,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index 81db882..63f761a 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -364,8 +364,10 @@ void __wait_rcu_gp(bool checktiny, int n, call_rcu_func_t *crcu_array, break; if (j == i) { trace_printk("bobo: start wait for rcu gp\n"); - if(!wait_for_completion_timeout(&rs_array[i].completion, 3*HZ)) + if(!wait_for_completion_timeout(&rs_array[i].completion, 2*HZ)) { + show_rcu_gp_kthreads(); panic("hung_task: blocked tasks in rcu"); + } trace_printk("bobo: finish wait for rcu gp\n"); } -- 2.7.4 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-14 2:40 ` He, Bo @ 2018-12-14 5:10 ` Paul E. McKenney 2018-12-14 5:38 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-14 5:10 UTC (permalink / raw) To: He, Bo Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Fri, Dec 14, 2018 at 02:40:50AM +0000, He, Bo wrote: > another experiment we have done with the enclosed debug patch, and also have more rcu trace event enable but without CONFIG_RCU_BOOST config, we don't reproduce the issue after 90 Hours until now on 10 boards(the issue should reproduce on one night per previous experience). That certainly supports the hypothesis that a wakeup is either not being sent or is being lost. Your patch is great for debugging (thank you!), but the real solution of course needs to avoid the extra wakeups, especially on battery-powered systems. One suggested change below, to get rid of potential false positives. > the purposes are to capture the more rcu event trace close to the issue happen, because I check the __wait_rcu_gp is not always in running, so we think even it trigger the panic for 3s timeout, the issue is already happened before 3s. Agreed, it would be really good to have trace information from the cause. In the case you sent yesterday, it would be good to have trace information from 308.256 seconds prior to the sysrq-v, for example, by collecting the same event traces you did a few days ago. It would also be good to know whether the scheduler tick is providing interrupts, and if so, why rcu_check_gp_start_stall() isn't being invoked. ;-) If collecting this information with your setup is not feasible (for example, you might need a large trace buffer to capture five minutes of traces), please let me know and I can provide additional debug code. Or you could add "rcu_ftrace_dump(DUMP_ALL);" just before the "show_rcu_gp_kthreads();" in your patch below. > And Actually the rsp->gp_flags = 1, but RCU_GP_WAIT_GPS(1) ->state: 0x402, it means the kthread is not schedule for 300s but the RCU_GP_FLAG_INIT is set. What's your ideas? The most likely possibility is that my analysis below is confused and there really is some way that the code can set the RCU_GP_FLAG_INIT bit without later doing a wakeup. The trace data above could help unconfuse me. Thanx, Paul > --------------------------------------------------------------------------------------------------------------------------------- > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > - RCU_GP_FLAG_INIT); > + if (current->pid != rcu_preempt_pid) { > + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > + RCU_GP_FLAG_INIT); > + } else { wait_again: > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > + RCU_GP_FLAG_INIT, 2*HZ); > + > + if(!ret) { This would avoid complaining if RCU was legitimately idle for a long time: if(!ret && !READ_ONCE(rsp->gp_flags)) { rcu_ftrace_dump(DUMP_ALL); show_rcu_gp_kthreads(); panic("hung_task: blocked in rcu_gp_kthread init"); } else if (!ret) { goto wait_again; } > + show_rcu_gp_kthreads(); > + panic("hung_task: blocked in rcu_gp_kthread init"); > + } > + } > -------------------------------------------------------------------------------------- > -----Original Message----- > From: Paul E. McKenney <paulmck@linux.ibm.com> > Sent: Friday, December 14, 2018 10:15 AM > To: He, Bo <bo.he@intel.com> > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > Subject: Re: rcu_preempt caused oom > > On Fri, Dec 14, 2018 at 01:30:04AM +0000, He, Bo wrote: > > as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: > > Yes, you are correct, CONFIG_RCU_FAST_NO_HZ. OK, you do not have it set, which means several code paths can be ignored. Also CONFIG_HZ=1000, so > 300 second delay. > > Thanx, Paul > > > Here is the grep from .config: > > egrep "HZ|RCU" .config > > CONFIG_NO_HZ_COMMON=y > > # CONFIG_HZ_PERIODIC is not set > > CONFIG_NO_HZ_IDLE=y > > # CONFIG_NO_HZ_FULL is not set > > CONFIG_NO_HZ=y > > # RCU Subsystem > > CONFIG_PREEMPT_RCU=y > > # CONFIG_RCU_EXPERT is not set > > CONFIG_SRCU=y > > CONFIG_TREE_SRCU=y > > CONFIG_TASKS_RCU=y > > CONFIG_RCU_STALL_COMMON=y > > CONFIG_RCU_NEED_SEGCBLIST=y > > # CONFIG_HZ_100 is not set > > # CONFIG_HZ_250 is not set > > # CONFIG_HZ_300 is not set > > CONFIG_HZ_1000=y > > CONFIG_HZ=1000 > > # CONFIG_MACHZ_WDT is not set > > # RCU Debugging > > CONFIG_PROVE_RCU=y > > CONFIG_RCU_PERF_TEST=m > > CONFIG_RCU_TORTURE_TEST=m > > CONFIG_RCU_CPU_STALL_TIMEOUT=7 > > CONFIG_RCU_TRACE=y > > CONFIG_RCU_EQS_DEBUG=y > > > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Friday, December 14, 2018 2:12 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J > > <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > > > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > > > > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 > > > > This is quite helpful, thank you! > > > > The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. > > The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. > > > > The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. > > The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. > > > > But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: > > > > 1. Because rcu_check_gp_start_stall() is only ever invoked from > > RCU_SOFTIRQ, it is possible that softirqs are stalled for > > whatever reason. > > > > 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock > > interrupt handler, it is possible that the scheduler tick has > > somehow been disabled. Traces from earlier runs showed a great > > deal of RCU callbacks queued, which would have caused RCU to > > refuse to allow the scheduler tick to be disabled, even if the > > corresponding CPU was idle. > > > > 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given > > that you are building for a battery-powered device) and all of the > > CPU's callbacks are lazy. Except that your earlier traces showed > > lots of non-lazy callbacks. Besides, even if all callbacks were > > lazy, there would still be a scheduling-clock interrupt every > > six seconds, and there are quite a few six-second intervals > > in a two-minute watchdog timeout. > > > > But if we cannot find the problem quickly, I will likely ask > > you to try reproducing with CONFIG_FAST_NO_HZ=n. This could > > be thought of as bisecting the RCU code looking for the bug. > > > > The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? > > One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. > > > > Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. > > > > You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. > > > > Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. > > I did check this in current -rcu, but you are instead running v4.19, so I should also check there. > > > > The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. > > Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). > > > > The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: > > > > o rcu_accelerate_cbs_unlocked(), which does the following, thus > > properly awakening the rcu_preempt task when needed: > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > > > o rcu_advance_cbs(), which returns the value returned by > > rcu_accelerate_cbs(), thus pushing the problem off to its > > callers, which are called out below. > > > > o __note_gp_changes(), which also returns the value returned by > > rcu_accelerate_cbs(), thus pushing the problem off to its callers, > > which are called out below. > > > > o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period > > kthreads such as the rcu_preempt task. Therefore, this function > > never needs to awaken the rcu_preempt task, because the fact > > that this function is executing means that this task is already > > awake. (Also, as noted above, we can eliminate this code from > > consideration because this task is known to have been sleeping > > at the last time that the RCU_GP_FLAG_INIT bit was set.) > > > > o rcu_report_qs_rdp(), which does the following, thus properly > > awakening the rcu_preempt task when needed: > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > /* ^^^ Released rnp->lock */ > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > > > o rcu_prepare_for_idle(), which does the following, thus properly > > awakening the rcu_preempt task when needed: > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > > > Now for rcu_advance_cbs(): > > > > o __note_gp_changes(), which which also returns the value returned > > by rcu_advance_cbs(), thus pushing the problem off to its callers, > > which are called out below. > > > > o rcu_migrate_callbacks(), which does the following, thus properly > > awakening the rcu_preempt task when needed: > > > > needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || > > rcu_advance_cbs(rsp, rnp_root, my_rdp); > > rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); > > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != > > !rcu_segcblist_n_cbs(&my_rdp->cblist)); > > raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > > > Now for __note_gp_changes(): > > > > o note_gp_changes(), which does the following, thus properly > > awakening the rcu_preempt task when needed: > > > > needwake = __note_gp_changes(rsp, rnp, rdp); > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > if (needwake) > > rcu_gp_kthread_wake(rsp); > > > > o rcu_gp_init() which is only ever invoked by RCU grace-period > > kthreads such as the rcu_preempt task, which makes wakeups > > unnecessary, just as for rcu_gp_cleanup() above. > > > > o rcu_gp_cleanup(), ditto. > > > > So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. > > > > Thanx, Paul > > > > ---------------------------------------------------------------------- > > -- > > lockdep complaint: > > ---------------------------------------------------------------------- > > -- > > > > [ 2.895507] ====================================================== > > [ 2.895511] WARNING: possible circular locking dependency detected > > [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U > > [ 2.895521] ------------------------------------------------------ > > [ 2.895525] earlyEvs/1839 is trying to acquire lock: > > [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895546] > > [ 2.895546] but task is already holding lock: > > [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > [ 2.895561] > > [ 2.895561] which lock already depends on the new lock. > > [ 2.895561] > > [ 2.895566] > > [ 2.895566] the existing dependency chain (in reverse order) is: > > [ 2.895570] > > [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: > > [ 2.895583] __mutex_lock+0x80/0x9a0 > > [ 2.895588] mutex_lock_nested+0x1b/0x20 > > [ 2.895593] media_device_register_entity+0x92/0x1e0 > > [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 > > [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 > > [ 2.895608] isys_probe+0x6cb/0xed0 > > [ 2.895613] ipu_bus_probe+0xfd/0x2e0 > > [ 2.895620] really_probe+0x268/0x3d0 > > [ 2.895625] driver_probe_device+0x11a/0x130 > > [ 2.895630] __device_attach_driver+0x86/0x100 > > [ 2.895635] bus_for_each_drv+0x6e/0xb0 > > [ 2.895640] __device_attach+0xdf/0x160 > > [ 2.895645] device_initial_probe+0x13/0x20 > > [ 2.895650] bus_probe_device+0xa6/0xc0 > > [ 2.895655] deferred_probe_work_func+0x88/0xe0 > > [ 2.895661] process_one_work+0x220/0x5c0 > > [ 2.895665] worker_thread+0x1da/0x3b0 > > [ 2.895670] kthread+0x12c/0x150 > > [ 2.895675] ret_from_fork+0x3a/0x50 > > [ 2.895678] > > [ 2.895678] -> #0 (&asd->mutex){+.+.}: > > [ 2.895688] lock_acquire+0x95/0x1a0 > > [ 2.895693] __mutex_lock+0x80/0x9a0 > > [ 2.895698] mutex_lock_nested+0x1b/0x20 > > [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 > > [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 > > [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 > > [ 2.895728] csi2_link_validate+0xc6/0x220 > > [ 2.895733] __media_pipeline_start+0x15b/0x2f0 > > [ 2.895738] media_pipeline_start+0x33/0x50 > > [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > [ 2.895748] start_streaming+0x186/0x3a0 > > [ 2.895753] vb2_start_streaming+0x6d/0x130 > > [ 2.895758] vb2_core_streamon+0x108/0x140 > > [ 2.895762] vb2_streamon+0x29/0x50 > > [ 2.895767] vb2_ioctl_streamon+0x42/0x50 > > [ 2.895772] v4l_streamon+0x20/0x30 > > [ 2.895776] __video_do_ioctl+0x1af/0x3c0 > > [ 2.895781] video_usercopy+0x27e/0x7e0 > > [ 2.895785] video_ioctl2+0x15/0x20 > > [ 2.895789] v4l2_ioctl+0x49/0x50 > > [ 2.895794] do_video_ioctl+0x93c/0x2360 > > [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 > > [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 > > [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c > > [ 2.895821] > > [ 2.895821] other info that might help us debug this: > > [ 2.895821] > > [ 2.895826] Possible unsafe locking scenario: > > [ 2.895826] > > [ 2.895830] CPU0 CPU1 > > [ 2.895833] ---- ---- > > [ 2.895836] lock(&mdev->graph_mutex); > > [ 2.895842] lock(&asd->mutex); > > [ 2.895847] lock(&mdev->graph_mutex); > > [ 2.895852] lock(&asd->mutex); > > [ 2.895857] > > [ 2.895857] *** DEADLOCK *** > > [ 2.895857] > > [ 2.895863] 3 locks held by earlyEvs/1839: > > [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 > > [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 > > [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > [ 2.895896] > > [ 2.895896] stack backtrace: > > [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 > > [ 2.895907] Call Trace: > > [ 2.895915] dump_stack+0x70/0xa5 > > [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 > > [ 2.895927] __lock_acquire+0x1284/0x1340 > > [ 2.895931] ? __lock_acquire+0x2b5/0x1340 > > [ 2.895940] lock_acquire+0x95/0x1a0 > > [ 2.895945] ? lock_acquire+0x95/0x1a0 > > [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895961] __mutex_lock+0x80/0x9a0 > > [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895971] ? crlmodule_get_format+0x43/0x50 > > [ 2.895979] mutex_lock_nested+0x1b/0x20 > > [ 2.895984] ? mutex_lock_nested+0x1b/0x20 > > [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 > > [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 > > [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 > > [ 2.896011] ? crlmodule_get_format+0x2a/0x50 > > [ 2.896018] ? find_held_lock+0x35/0xa0 > > [ 2.896023] ? crlmodule_get_format+0x43/0x50 > > [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 > > [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 > > [ 2.896042] ? mutex_unlock+0x12/0x20 > > [ 2.896046] ? crlmodule_get_format+0x43/0x50 > > [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 > > [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 > > [ 2.896070] ? kernel_text_address+0xc4/0x100 > > [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 > > [ 2.896085] ? kernel_text_address+0xc4/0x100 > > [ 2.896092] ? __lock_acquire+0x1106/0x1340 > > [ 2.896096] ? __lock_acquire+0x1169/0x1340 > > [ 2.896103] csi2_link_validate+0xc6/0x220 > > [ 2.896110] ? __lock_is_held+0x5a/0xa0 > > [ 2.896115] ? mark_held_locks+0x58/0x80 > > [ 2.896122] ? __kmalloc+0x207/0x2e0 > > [ 2.896127] ? __lock_is_held+0x5a/0xa0 > > [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 > > [ 2.896139] ? __kmalloc+0x2a3/0x2e0 > > [ 2.896144] ? media_pipeline_start+0x28/0x50 > > [ 2.896150] ? __media_entity_enum_init+0x33/0x70 > > [ 2.896155] ? csi2_has_route+0x18/0x20 > > [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 > > [ 2.896166] __media_pipeline_start+0x15b/0x2f0 > > [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 > > [ 2.896179] media_pipeline_start+0x33/0x50 > > [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > [ 2.896191] ? __lock_acquire+0x132e/0x1340 > > [ 2.896198] ? __lock_acquire+0x2b5/0x1340 > > [ 2.896204] ? lock_acquire+0x95/0x1a0 > > [ 2.896209] ? start_streaming+0x5c/0x3a0 > > [ 2.896215] ? start_streaming+0x5c/0x3a0 > > [ 2.896221] ? __mutex_lock+0x391/0x9a0 > > [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 > > [ 2.896233] ? find_held_lock+0x35/0xa0 > > [ 2.896238] ? v4l_enable_media_source+0x57/0x70 > > [ 2.896245] start_streaming+0x186/0x3a0 > > [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 > > [ 2.896257] vb2_start_streaming+0x6d/0x130 > > [ 2.896262] ? vb2_start_streaming+0x6d/0x130 > > [ 2.896267] vb2_core_streamon+0x108/0x140 > > [ 2.896273] vb2_streamon+0x29/0x50 > > [ 2.896278] vb2_ioctl_streamon+0x42/0x50 > > [ 2.896284] v4l_streamon+0x20/0x30 > > [ 2.896288] __video_do_ioctl+0x1af/0x3c0 > > [ 2.896296] ? __might_fault+0x85/0x90 > > [ 2.896302] video_usercopy+0x27e/0x7e0 > > [ 2.896307] ? copy_overflow+0x20/0x20 > > [ 2.896313] ? find_held_lock+0x35/0xa0 > > [ 2.896319] ? __might_fault+0x3e/0x90 > > [ 2.896325] video_ioctl2+0x15/0x20 > > [ 2.896330] v4l2_ioctl+0x49/0x50 > > [ 2.896335] do_video_ioctl+0x93c/0x2360 > > [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 > > [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 > > [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 > > [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 > > [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c > > [ 2.896377] RIP: 0023:0xf7e79b79 > > [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > > [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 > > [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 > > [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c > > [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 > > [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > ---------------------------------------------------------------------- > > -- > > > > > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > > > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > > > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Thursday, December 13, 2018 12:40 PM > > > To: Zhang, Jun <jun.zhang@intel.com> > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, > > > Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > > > Ok, we will test it, thanks! > > > > > > But please also try the sysrq-y with the earlier patch after a hang! > > > > > > Thanx, Paul > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > Sent: Thursday, December 13, 2018 10:43 > > > > To: Zhang, Jun <jun.zhang@intel.com> > > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt > > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > > Sun, Yi J <yi.j.sun@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > > > Hello, Paul > > > > > > > > > > I think the next patch is better. > > > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > > > Please help review. > > > > > I don't test it. If you agree, we will test it. > > > > > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > > > and finds them equal. > > > > > > > > o At just this time something like rcu_start_this_gp() assigns a new > > > > (larger) value to rdp->gp_seq_needed. > > > > > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > > > old value. > > > > > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > > > > > Of course, there could be bugs. For example: > > > > > > > > o __note_gp_changes() might be called on a different CPU than that > > > > corresponding to rdp. You can check this with something like: > > > > > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > > > > > o The same things could happen with rcu_start_this_gp(), and the > > > > above WARN_ON_ONCE() would work there as well. > > > > > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > > > you are doing CPU-hotplug operations. (It can run on a CPU other > > > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > > > > > o Interrupts might not really be disabled. > > > > > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > > > > > So why not just test it anyway? If it makes the bug go away, I > > > > will be surprised, but it would not be the first surprise for me. > > > > ;-) > > > > > > > > Thanx, Paul > > > > > > > > > Thanks! > > > > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > 0b760c1..c00f34e 100644 > > > > > --- a/kernel/rcu/tree.c > > > > > +++ b/kernel/rcu/tree.c > > > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > > > zero_cpu_stall_ticks(rdp); > > > > > } > > > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) > > > > > + || > > > > > + rdp->gpwrap) > > > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > > > WRITE_ONCE(rdp->gpwrap, false); > > > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > > Sent: Thursday, December 13, 2018 08:12 > > > > > To: He, Bo <bo.he@intel.com> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > > > Please correct me if I have something wrong. > > > > > > > > > > That would be because I sent you the wrong patch, apologies! > > > > > :-/ > > > > > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > > > > > Thanx, Paul > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > > <jie.a.bai@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > > > > > Strange. > > > > > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > -- > > > > > -- > > > > > -- > > > > > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > > > > > Backported from v4.21/v5.0 > > > > > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > > > for failing to start a grace period. This commit therefore adds a > > > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > > > must be set for this sysrq to be available. > > > > > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > 0b760c1369f7..e9392a9d6291 100644 > > > > > --- a/kernel/rcu/tree.c > > > > > +++ b/kernel/rcu/tree.c > > > > > @@ -61,6 +61,7 @@ > > > > > #include <linux/trace_events.h> #include <linux/suspend.h> > > > > > #include <linux/ftrace.h> > > > > > +#include <linux/sysrq.h> > > > > > > > > > > #include "tree.h" > > > > > #include "rcu.h" > > > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # > > > > > rcu_nodes in use. */ > > > > > /* panic() on RCU Stall sysctl. */ int > > > > > sysctl_panic_on_rcu_stall __read_mostly; > > > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > > > > > /* > > > > > * The rcu_scheduler_active variable is initialized to the > > > > > value @@ > > > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > > > +*/ static void sysrq_show_rcu(int key) { > > > > > + show_rcu_gp_kthreads(); > > > > > +} > > > > > + > > > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > > > + .handler = sysrq_show_rcu, > > > > > + .help_msg = "show-rcu(y)", > > > > > + .action_msg = "Show RCU tree", > > > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > > > + > > > > > +static int __init rcu_sysrq_init(void) { > > > > > + if (sysrq_rcu) > > > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > > > + return 0; > > > > > +} > > > > > +early_initcall(rcu_sysrq_init); > > > > > + > > > > > /* > > > > > * Send along grace-period-related data for rcutorture diagnostics. > > > > > */ > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-14 5:10 ` Paul E. McKenney @ 2018-12-14 5:38 ` Paul E. McKenney 2018-12-17 3:15 ` He, Bo 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-14 5:38 UTC (permalink / raw) To: He, Bo Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J On Thu, Dec 13, 2018 at 09:10:12PM -0800, Paul E. McKenney wrote: > On Fri, Dec 14, 2018 at 02:40:50AM +0000, He, Bo wrote: > > another experiment we have done with the enclosed debug patch, and also have more rcu trace event enable but without CONFIG_RCU_BOOST config, we don't reproduce the issue after 90 Hours until now on 10 boards(the issue should reproduce on one night per previous experience). > > That certainly supports the hypothesis that a wakeup is either not > being sent or is being lost. Your patch is great for debugging (thank > you!), but the real solution of course needs to avoid the extra wakeups, > especially on battery-powered systems. > > One suggested change below, to get rid of potential false positives. > > > the purposes are to capture the more rcu event trace close to the issue happen, because I check the __wait_rcu_gp is not always in running, so we think even it trigger the panic for 3s timeout, the issue is already happened before 3s. > > Agreed, it would be really good to have trace information from the cause. > In the case you sent yesterday, it would be good to have trace information > from 308.256 seconds prior to the sysrq-v, for example, by collecting the > same event traces you did a few days ago. It would also be good to know > whether the scheduler tick is providing interrupts, and if so, why > rcu_check_gp_start_stall() isn't being invoked. ;-) > > If collecting this information with your setup is not feasible (for > example, you might need a large trace buffer to capture five minutes > of traces), please let me know and I can provide additional debug > code. Or you could add "rcu_ftrace_dump(DUMP_ALL);" just before the > "show_rcu_gp_kthreads();" in your patch below. > > > And Actually the rsp->gp_flags = 1, but RCU_GP_WAIT_GPS(1) ->state: 0x402, it means the kthread is not schedule for 300s but the RCU_GP_FLAG_INIT is set. What's your ideas? > > The most likely possibility is that my analysis below is confused and > there really is some way that the code can set the RCU_GP_FLAG_INIT > bit without later doing a wakeup. The trace data above could help > unconfuse me. > > Thanx, Paul > > > --------------------------------------------------------------------------------------------------------------------------------- > > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > - RCU_GP_FLAG_INIT); > > + if (current->pid != rcu_preempt_pid) { > > + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > + RCU_GP_FLAG_INIT); > > + } else { > > wait_again: > > > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > + RCU_GP_FLAG_INIT, 2*HZ); > > + > > + if(!ret) { > > This would avoid complaining if RCU was legitimately idle for a long time: Let's try this again. Unless I am confused (quite possible) your original would panic if RCU was idle for more than two seconds. What we instead want is to panic if we time out, but end up with RCU_GP_FLAG_INIT set. So something like this: if (ret == 1) { /* Timed out with RCU_GP_FLAG_INIT. */ rcu_ftrace_dump(DUMP_ALL); show_rcu_gp_kthreads(); panic("hung_task: blocked in rcu_gp_kthread init"); } else if (!ret) { /* Timed out w/out RCU_GP_FLAG_INIT. */ goto wait_again; } Thanx, Paul > > + show_rcu_gp_kthreads(); > > + panic("hung_task: blocked in rcu_gp_kthread init"); > > + } > > + } > > -------------------------------------------------------------------------------------- > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Friday, December 14, 2018 10:15 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, Dec 14, 2018 at 01:30:04AM +0000, He, Bo wrote: > > > as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: > > > > Yes, you are correct, CONFIG_RCU_FAST_NO_HZ. OK, you do not have it set, which means several code paths can be ignored. Also CONFIG_HZ=1000, so > > 300 second delay. > > > > Thanx, Paul > > > > > Here is the grep from .config: > > > egrep "HZ|RCU" .config > > > CONFIG_NO_HZ_COMMON=y > > > # CONFIG_HZ_PERIODIC is not set > > > CONFIG_NO_HZ_IDLE=y > > > # CONFIG_NO_HZ_FULL is not set > > > CONFIG_NO_HZ=y > > > # RCU Subsystem > > > CONFIG_PREEMPT_RCU=y > > > # CONFIG_RCU_EXPERT is not set > > > CONFIG_SRCU=y > > > CONFIG_TREE_SRCU=y > > > CONFIG_TASKS_RCU=y > > > CONFIG_RCU_STALL_COMMON=y > > > CONFIG_RCU_NEED_SEGCBLIST=y > > > # CONFIG_HZ_100 is not set > > > # CONFIG_HZ_250 is not set > > > # CONFIG_HZ_300 is not set > > > CONFIG_HZ_1000=y > > > CONFIG_HZ=1000 > > > # CONFIG_MACHZ_WDT is not set > > > # RCU Debugging > > > CONFIG_PROVE_RCU=y > > > CONFIG_RCU_PERF_TEST=m > > > CONFIG_RCU_TORTURE_TEST=m > > > CONFIG_RCU_CPU_STALL_TIMEOUT=7 > > > CONFIG_RCU_TRACE=y > > > CONFIG_RCU_EQS_DEBUG=y > > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Friday, December 14, 2018 2:12 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J > > > <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > > > > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > > > > > > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 > > > > > > This is quite helpful, thank you! > > > > > > The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. > > > The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. > > > > > > The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. > > > The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. > > > > > > But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: > > > > > > 1. Because rcu_check_gp_start_stall() is only ever invoked from > > > RCU_SOFTIRQ, it is possible that softirqs are stalled for > > > whatever reason. > > > > > > 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock > > > interrupt handler, it is possible that the scheduler tick has > > > somehow been disabled. Traces from earlier runs showed a great > > > deal of RCU callbacks queued, which would have caused RCU to > > > refuse to allow the scheduler tick to be disabled, even if the > > > corresponding CPU was idle. > > > > > > 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given > > > that you are building for a battery-powered device) and all of the > > > CPU's callbacks are lazy. Except that your earlier traces showed > > > lots of non-lazy callbacks. Besides, even if all callbacks were > > > lazy, there would still be a scheduling-clock interrupt every > > > six seconds, and there are quite a few six-second intervals > > > in a two-minute watchdog timeout. > > > > > > But if we cannot find the problem quickly, I will likely ask > > > you to try reproducing with CONFIG_FAST_NO_HZ=n. This could > > > be thought of as bisecting the RCU code looking for the bug. > > > > > > The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? > > > One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. > > > > > > Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. > > > > > > You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. > > > > > > Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. > > > I did check this in current -rcu, but you are instead running v4.19, so I should also check there. > > > > > > The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. > > > Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). > > > > > > The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: > > > > > > o rcu_accelerate_cbs_unlocked(), which does the following, thus > > > properly awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_advance_cbs(), which returns the value returned by > > > rcu_accelerate_cbs(), thus pushing the problem off to its > > > callers, which are called out below. > > > > > > o __note_gp_changes(), which also returns the value returned by > > > rcu_accelerate_cbs(), thus pushing the problem off to its callers, > > > which are called out below. > > > > > > o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period > > > kthreads such as the rcu_preempt task. Therefore, this function > > > never needs to awaken the rcu_preempt task, because the fact > > > that this function is executing means that this task is already > > > awake. (Also, as noted above, we can eliminate this code from > > > consideration because this task is known to have been sleeping > > > at the last time that the RCU_GP_FLAG_INIT bit was set.) > > > > > > o rcu_report_qs_rdp(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > > > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > > /* ^^^ Released rnp->lock */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_prepare_for_idle(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > Now for rcu_advance_cbs(): > > > > > > o __note_gp_changes(), which which also returns the value returned > > > by rcu_advance_cbs(), thus pushing the problem off to its callers, > > > which are called out below. > > > > > > o rcu_migrate_callbacks(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || > > > rcu_advance_cbs(rsp, rnp_root, my_rdp); > > > rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); > > > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != > > > !rcu_segcblist_n_cbs(&my_rdp->cblist)); > > > raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > Now for __note_gp_changes(): > > > > > > o note_gp_changes(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = __note_gp_changes(rsp, rnp, rdp); > > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_gp_init() which is only ever invoked by RCU grace-period > > > kthreads such as the rcu_preempt task, which makes wakeups > > > unnecessary, just as for rcu_gp_cleanup() above. > > > > > > o rcu_gp_cleanup(), ditto. > > > > > > So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. > > > > > > Thanx, Paul > > > > > > ---------------------------------------------------------------------- > > > -- > > > lockdep complaint: > > > ---------------------------------------------------------------------- > > > -- > > > > > > [ 2.895507] ====================================================== > > > [ 2.895511] WARNING: possible circular locking dependency detected > > > [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U > > > [ 2.895521] ------------------------------------------------------ > > > [ 2.895525] earlyEvs/1839 is trying to acquire lock: > > > [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895546] > > > [ 2.895546] but task is already holding lock: > > > [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > > [ 2.895561] > > > [ 2.895561] which lock already depends on the new lock. > > > [ 2.895561] > > > [ 2.895566] > > > [ 2.895566] the existing dependency chain (in reverse order) is: > > > [ 2.895570] > > > [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: > > > [ 2.895583] __mutex_lock+0x80/0x9a0 > > > [ 2.895588] mutex_lock_nested+0x1b/0x20 > > > [ 2.895593] media_device_register_entity+0x92/0x1e0 > > > [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 > > > [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 > > > [ 2.895608] isys_probe+0x6cb/0xed0 > > > [ 2.895613] ipu_bus_probe+0xfd/0x2e0 > > > [ 2.895620] really_probe+0x268/0x3d0 > > > [ 2.895625] driver_probe_device+0x11a/0x130 > > > [ 2.895630] __device_attach_driver+0x86/0x100 > > > [ 2.895635] bus_for_each_drv+0x6e/0xb0 > > > [ 2.895640] __device_attach+0xdf/0x160 > > > [ 2.895645] device_initial_probe+0x13/0x20 > > > [ 2.895650] bus_probe_device+0xa6/0xc0 > > > [ 2.895655] deferred_probe_work_func+0x88/0xe0 > > > [ 2.895661] process_one_work+0x220/0x5c0 > > > [ 2.895665] worker_thread+0x1da/0x3b0 > > > [ 2.895670] kthread+0x12c/0x150 > > > [ 2.895675] ret_from_fork+0x3a/0x50 > > > [ 2.895678] > > > [ 2.895678] -> #0 (&asd->mutex){+.+.}: > > > [ 2.895688] lock_acquire+0x95/0x1a0 > > > [ 2.895693] __mutex_lock+0x80/0x9a0 > > > [ 2.895698] mutex_lock_nested+0x1b/0x20 > > > [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 > > > [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.895728] csi2_link_validate+0xc6/0x220 > > > [ 2.895733] __media_pipeline_start+0x15b/0x2f0 > > > [ 2.895738] media_pipeline_start+0x33/0x50 > > > [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > > [ 2.895748] start_streaming+0x186/0x3a0 > > > [ 2.895753] vb2_start_streaming+0x6d/0x130 > > > [ 2.895758] vb2_core_streamon+0x108/0x140 > > > [ 2.895762] vb2_streamon+0x29/0x50 > > > [ 2.895767] vb2_ioctl_streamon+0x42/0x50 > > > [ 2.895772] v4l_streamon+0x20/0x30 > > > [ 2.895776] __video_do_ioctl+0x1af/0x3c0 > > > [ 2.895781] video_usercopy+0x27e/0x7e0 > > > [ 2.895785] video_ioctl2+0x15/0x20 > > > [ 2.895789] v4l2_ioctl+0x49/0x50 > > > [ 2.895794] do_video_ioctl+0x93c/0x2360 > > > [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 > > > [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > > [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 > > > [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c > > > [ 2.895821] > > > [ 2.895821] other info that might help us debug this: > > > [ 2.895821] > > > [ 2.895826] Possible unsafe locking scenario: > > > [ 2.895826] > > > [ 2.895830] CPU0 CPU1 > > > [ 2.895833] ---- ---- > > > [ 2.895836] lock(&mdev->graph_mutex); > > > [ 2.895842] lock(&asd->mutex); > > > [ 2.895847] lock(&mdev->graph_mutex); > > > [ 2.895852] lock(&asd->mutex); > > > [ 2.895857] > > > [ 2.895857] *** DEADLOCK *** > > > [ 2.895857] > > > [ 2.895863] 3 locks held by earlyEvs/1839: > > > [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 > > > [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 > > > [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > > [ 2.895896] > > > [ 2.895896] stack backtrace: > > > [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 > > > [ 2.895907] Call Trace: > > > [ 2.895915] dump_stack+0x70/0xa5 > > > [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 > > > [ 2.895927] __lock_acquire+0x1284/0x1340 > > > [ 2.895931] ? __lock_acquire+0x2b5/0x1340 > > > [ 2.895940] lock_acquire+0x95/0x1a0 > > > [ 2.895945] ? lock_acquire+0x95/0x1a0 > > > [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895961] __mutex_lock+0x80/0x9a0 > > > [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895971] ? crlmodule_get_format+0x43/0x50 > > > [ 2.895979] mutex_lock_nested+0x1b/0x20 > > > [ 2.895984] ? mutex_lock_nested+0x1b/0x20 > > > [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 > > > [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.896011] ? crlmodule_get_format+0x2a/0x50 > > > [ 2.896018] ? find_held_lock+0x35/0xa0 > > > [ 2.896023] ? crlmodule_get_format+0x43/0x50 > > > [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 > > > [ 2.896042] ? mutex_unlock+0x12/0x20 > > > [ 2.896046] ? crlmodule_get_format+0x43/0x50 > > > [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 > > > [ 2.896070] ? kernel_text_address+0xc4/0x100 > > > [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.896085] ? kernel_text_address+0xc4/0x100 > > > [ 2.896092] ? __lock_acquire+0x1106/0x1340 > > > [ 2.896096] ? __lock_acquire+0x1169/0x1340 > > > [ 2.896103] csi2_link_validate+0xc6/0x220 > > > [ 2.896110] ? __lock_is_held+0x5a/0xa0 > > > [ 2.896115] ? mark_held_locks+0x58/0x80 > > > [ 2.896122] ? __kmalloc+0x207/0x2e0 > > > [ 2.896127] ? __lock_is_held+0x5a/0xa0 > > > [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 > > > [ 2.896139] ? __kmalloc+0x2a3/0x2e0 > > > [ 2.896144] ? media_pipeline_start+0x28/0x50 > > > [ 2.896150] ? __media_entity_enum_init+0x33/0x70 > > > [ 2.896155] ? csi2_has_route+0x18/0x20 > > > [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 > > > [ 2.896166] __media_pipeline_start+0x15b/0x2f0 > > > [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 > > > [ 2.896179] media_pipeline_start+0x33/0x50 > > > [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > > [ 2.896191] ? __lock_acquire+0x132e/0x1340 > > > [ 2.896198] ? __lock_acquire+0x2b5/0x1340 > > > [ 2.896204] ? lock_acquire+0x95/0x1a0 > > > [ 2.896209] ? start_streaming+0x5c/0x3a0 > > > [ 2.896215] ? start_streaming+0x5c/0x3a0 > > > [ 2.896221] ? __mutex_lock+0x391/0x9a0 > > > [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 > > > [ 2.896233] ? find_held_lock+0x35/0xa0 > > > [ 2.896238] ? v4l_enable_media_source+0x57/0x70 > > > [ 2.896245] start_streaming+0x186/0x3a0 > > > [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 > > > [ 2.896257] vb2_start_streaming+0x6d/0x130 > > > [ 2.896262] ? vb2_start_streaming+0x6d/0x130 > > > [ 2.896267] vb2_core_streamon+0x108/0x140 > > > [ 2.896273] vb2_streamon+0x29/0x50 > > > [ 2.896278] vb2_ioctl_streamon+0x42/0x50 > > > [ 2.896284] v4l_streamon+0x20/0x30 > > > [ 2.896288] __video_do_ioctl+0x1af/0x3c0 > > > [ 2.896296] ? __might_fault+0x85/0x90 > > > [ 2.896302] video_usercopy+0x27e/0x7e0 > > > [ 2.896307] ? copy_overflow+0x20/0x20 > > > [ 2.896313] ? find_held_lock+0x35/0xa0 > > > [ 2.896319] ? __might_fault+0x3e/0x90 > > > [ 2.896325] video_ioctl2+0x15/0x20 > > > [ 2.896330] v4l2_ioctl+0x49/0x50 > > > [ 2.896335] do_video_ioctl+0x93c/0x2360 > > > [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 > > > [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > > [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 > > > [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 > > > [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 > > > [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c > > > [ 2.896377] RIP: 0023:0xf7e79b79 > > > [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > > > [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 > > > [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 > > > [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c > > > [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 > > > [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > > [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > > > > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > > > > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Thursday, December 13, 2018 12:40 PM > > > > To: Zhang, Jun <jun.zhang@intel.com> > > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt <rostedt@goodmis.org>; > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin > > > > <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, > > > > Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > > > > Ok, we will test it, thanks! > > > > > > > > But please also try the sysrq-y with the earlier patch after a hang! > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > > Sent: Thursday, December 13, 2018 10:43 > > > > > To: Zhang, Jun <jun.zhang@intel.com> > > > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt > > > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > > > Sun, Yi J <yi.j.sun@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > > > > Hello, Paul > > > > > > > > > > > > I think the next patch is better. > > > > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > > > > Please help review. > > > > > > I don't test it. If you agree, we will test it. > > > > > > > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > > > > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > > > > and finds them equal. > > > > > > > > > > o At just this time something like rcu_start_this_gp() assigns a new > > > > > (larger) value to rdp->gp_seq_needed. > > > > > > > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > > > > old value. > > > > > > > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > > > > > > > Of course, there could be bugs. For example: > > > > > > > > > > o __note_gp_changes() might be called on a different CPU than that > > > > > corresponding to rdp. You can check this with something like: > > > > > > > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > > > > > > > o The same things could happen with rcu_start_this_gp(), and the > > > > > above WARN_ON_ONCE() would work there as well. > > > > > > > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > > > > you are doing CPU-hotplug operations. (It can run on a CPU other > > > > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > > > > > > > o Interrupts might not really be disabled. > > > > > > > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > > > > > > > So why not just test it anyway? If it makes the bug go away, I > > > > > will be surprised, but it would not be the first surprise for me. > > > > > ;-) > > > > > > > > > > Thanx, Paul > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > > 0b760c1..c00f34e 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > > > > zero_cpu_stall_ticks(rdp); > > > > > > } > > > > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) > > > > > > + || > > > > > > + rdp->gpwrap) > > > > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > > > > WRITE_ONCE(rdp->gpwrap, false); > > > > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > > > Sent: Thursday, December 13, 2018 08:12 > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > > <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > > > > Please correct me if I have something wrong. > > > > > > > > > > > > That would be because I sent you the wrong patch, apologies! > > > > > > :-/ > > > > > > > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Zhang, > > > > > > > Jun <jun.zhang@intel.com>; Xiao, Jin <jin.xiao@intel.com>; > > > > > > > Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > > > <jie.a.bai@intel.com> > > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > > > > > > > Strange. > > > > > > > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > > > > > > > Backported from v4.21/v5.0 > > > > > > > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > > > > for failing to start a grace period. This commit therefore adds a > > > > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > > > > must be set for this sysrq to be available. > > > > > > > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > > 0b760c1369f7..e9392a9d6291 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -61,6 +61,7 @@ > > > > > > #include <linux/trace_events.h> #include <linux/suspend.h> > > > > > > #include <linux/ftrace.h> > > > > > > +#include <linux/sysrq.h> > > > > > > > > > > > > #include "tree.h" > > > > > > #include "rcu.h" > > > > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; int > > > > > > rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # > > > > > > rcu_nodes in use. */ > > > > > > /* panic() on RCU Stall sysctl. */ int > > > > > > sysctl_panic_on_rcu_stall __read_mostly; > > > > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static bool > > > > > > +sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > > > > > > > /* > > > > > > * The rcu_scheduler_active variable is initialized to the > > > > > > value @@ > > > > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > > > > +*/ static void sysrq_show_rcu(int key) { > > > > > > + show_rcu_gp_kthreads(); > > > > > > +} > > > > > > + > > > > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > > > > + .handler = sysrq_show_rcu, > > > > > > + .help_msg = "show-rcu(y)", > > > > > > + .action_msg = "Show RCU tree", > > > > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > > > > + > > > > > > +static int __init rcu_sysrq_init(void) { > > > > > > + if (sysrq_rcu) > > > > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > > > > + return 0; > > > > > > +} > > > > > > +early_initcall(rcu_sysrq_init); > > > > > > + > > > > > > /* > > > > > > * Send along grace-period-related data for rcutorture diagnostics. > > > > > > */ > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-14 5:38 ` Paul E. McKenney @ 2018-12-17 3:15 ` He, Bo 2018-12-17 4:26 ` Paul E. McKenney 0 siblings, 1 reply; 43+ messages in thread From: He, Bo @ 2018-12-17 3:15 UTC (permalink / raw) To: paulmck@linux.ibm.com Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J, Chang, Junxiao, Mei, Paul [-- Attachment #1: Type: text/plain, Size: 37805 bytes --] for double confirm the issue is not reproduce after 90 hours, we tried only add the enclosed patch on the easy reproduced build, the issue is not reproduced after 63 hours in the whole weekend on 16 boards. so current conclusion is the debug patch has extreme effect on the rcu issue. Compared with the swait_event_idle_timeout_exclusive will do 3 times to check the condition, while swait_event_idle_ exclusive will do 2 times check the condition. so today I will do another experiment, only change as below: - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT); + Can you get some clues from the experiment? -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Friday, December 14, 2018 1:39 PM To: He, Bo <bo.he@intel.com> Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> Subject: Re: rcu_preempt caused oom On Thu, Dec 13, 2018 at 09:10:12PM -0800, Paul E. McKenney wrote: > On Fri, Dec 14, 2018 at 02:40:50AM +0000, He, Bo wrote: > > another experiment we have done with the enclosed debug patch, and also have more rcu trace event enable but without CONFIG_RCU_BOOST config, we don't reproduce the issue after 90 Hours until now on 10 boards(the issue should reproduce on one night per previous experience). > > That certainly supports the hypothesis that a wakeup is either not > being sent or is being lost. Your patch is great for debugging (thank > you!), but the real solution of course needs to avoid the extra > wakeups, especially on battery-powered systems. > > One suggested change below, to get rid of potential false positives. > > > the purposes are to capture the more rcu event trace close to the issue happen, because I check the __wait_rcu_gp is not always in running, so we think even it trigger the panic for 3s timeout, the issue is already happened before 3s. > > Agreed, it would be really good to have trace information from the cause. > In the case you sent yesterday, it would be good to have trace > information from 308.256 seconds prior to the sysrq-v, for example, by > collecting the same event traces you did a few days ago. It would > also be good to know whether the scheduler tick is providing > interrupts, and if so, why > rcu_check_gp_start_stall() isn't being invoked. ;-) > > If collecting this information with your setup is not feasible (for > example, you might need a large trace buffer to capture five minutes > of traces), please let me know and I can provide additional debug > code. Or you could add "rcu_ftrace_dump(DUMP_ALL);" just before the > "show_rcu_gp_kthreads();" in your patch below. > > > And Actually the rsp->gp_flags = 1, but RCU_GP_WAIT_GPS(1) ->state: 0x402, it means the kthread is not schedule for 300s but the RCU_GP_FLAG_INIT is set. What's your ideas? > > The most likely possibility is that my analysis below is confused and > there really is some way that the code can set the RCU_GP_FLAG_INIT > bit without later doing a wakeup. The trace data above could help > unconfuse me. > > Thanx, Paul > > > --------------------------------------------------------------------------------------------------------------------------------- > > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > - RCU_GP_FLAG_INIT); > > + if (current->pid != rcu_preempt_pid) { > > + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > + RCU_GP_FLAG_INIT); > > + } else { > > wait_again: > > > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > > + RCU_GP_FLAG_INIT, 2*HZ); > > + > > + if(!ret) { > > This would avoid complaining if RCU was legitimately idle for a long time: Let's try this again. Unless I am confused (quite possible) your original would panic if RCU was idle for more than two seconds. What we instead want is to panic if we time out, but end up with RCU_GP_FLAG_INIT set. So something like this: if (ret == 1) { /* Timed out with RCU_GP_FLAG_INIT. */ rcu_ftrace_dump(DUMP_ALL); show_rcu_gp_kthreads(); panic("hung_task: blocked in rcu_gp_kthread init"); } else if (!ret) { /* Timed out w/out RCU_GP_FLAG_INIT. */ goto wait_again; } Thanx, Paul > > + show_rcu_gp_kthreads(); > > + panic("hung_task: blocked in rcu_gp_kthread init"); > > + } > > + } > > -------------------------------------------------------------------- > > ------------------ > > -----Original Message----- > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > Sent: Friday, December 14, 2018 10:15 AM > > To: He, Bo <bo.he@intel.com> > > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > Sun, Yi J <yi.j.sun@intel.com> > > Subject: Re: rcu_preempt caused oom > > > > On Fri, Dec 14, 2018 at 01:30:04AM +0000, He, Bo wrote: > > > as you mentioned CONFIG_FAST_NO_HZ, do you mean CONFIG_RCU_FAST_NO_HZ? I double checked there is no FAST_NO_HZ in .config: > > > > Yes, you are correct, CONFIG_RCU_FAST_NO_HZ. OK, you do not have it > > set, which means several code paths can be ignored. Also > > CONFIG_HZ=1000, so > > 300 second delay. > > > > Thanx, Paul > > > > > Here is the grep from .config: > > > egrep "HZ|RCU" .config > > > CONFIG_NO_HZ_COMMON=y > > > # CONFIG_HZ_PERIODIC is not set > > > CONFIG_NO_HZ_IDLE=y > > > # CONFIG_NO_HZ_FULL is not set > > > CONFIG_NO_HZ=y > > > # RCU Subsystem > > > CONFIG_PREEMPT_RCU=y > > > # CONFIG_RCU_EXPERT is not set > > > CONFIG_SRCU=y > > > CONFIG_TREE_SRCU=y > > > CONFIG_TASKS_RCU=y > > > CONFIG_RCU_STALL_COMMON=y > > > CONFIG_RCU_NEED_SEGCBLIST=y > > > # CONFIG_HZ_100 is not set > > > # CONFIG_HZ_250 is not set > > > # CONFIG_HZ_300 is not set > > > CONFIG_HZ_1000=y > > > CONFIG_HZ=1000 > > > # CONFIG_MACHZ_WDT is not set > > > # RCU Debugging > > > CONFIG_PROVE_RCU=y > > > CONFIG_RCU_PERF_TEST=m > > > CONFIG_RCU_TORTURE_TEST=m > > > CONFIG_RCU_CPU_STALL_TIMEOUT=7 > > > CONFIG_RCU_TRACE=y > > > CONFIG_RCU_EQS_DEBUG=y > > > > > > -----Original Message----- > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > Sent: Friday, December 14, 2018 2:12 AM > > > To: He, Bo <bo.he@intel.com> > > > Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > Sun, Yi J <yi.j.sun@intel.com> > > > Subject: Re: rcu_preempt caused oom > > > > > > On Thu, Dec 13, 2018 at 03:26:08PM +0000, He, Bo wrote: > > > > one of the board reproduce the issue with the show_rcu_gp_kthreads(), I also enclosed the logs as attachment. > > > > > > > > [17818.936032] rcu: rcu_preempt: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258 ->gp_wake_seq 21808189 ->gp_seq 21808192 ->gp_seq_needed 21808196 ->gp_flags 0x1 > > > > > > This is quite helpful, thank you! > > > > > > The "RCU lockdep checking is enabled" says that CONFIG_PROVE_RCU=y, which is good. The "RCU_GP_WAIT_GPS(1)" means that the rcu_preempt task is waiting for a new grace-period request. The "->state: 0x402" means that it is sleeping, neither running nor in the process of waking up. > > > The "delta ->gp_activity 308257 ->gp_req_activity 308256 ->gp_wake_time 308258" means that it has been more than 300,000 jiffies since the rcu_preempt task did anything or was requested to do anything. > > > > > > The "->gp_wake_seq 21808189 ->gp_seq 21808192" says that the last attempt to awaken the rcu_preempt task happened during the last grace period. > > > The "->gp_seq_needed 21808196 ->gp_flags 0x1" nevertheless says that someone requested a new grace period. So if the rcu_preempt task were to wake up, it would process the new grace period. Note again also the ->gp_req_activity 308256, which indicates that ->gp_flags was set more than 300,000 jiffies ago, just after the last recorded activity of the rcu_preempt task. > > > > > > But this is exactly the situation that rcu_check_gp_start_stall() is designed to warn about (and does warn about for me when I comment out the wakeup code). So why is rcu_check_gp_start_stall() not being called? Here are a couple of possibilities: > > > > > > 1. Because rcu_check_gp_start_stall() is only ever invoked from > > > RCU_SOFTIRQ, it is possible that softirqs are stalled for > > > whatever reason. > > > > > > 2. Because RCU_SOFTIRQ is invoked primarily from the scheduler-clock > > > interrupt handler, it is possible that the scheduler tick has > > > somehow been disabled. Traces from earlier runs showed a great > > > deal of RCU callbacks queued, which would have caused RCU to > > > refuse to allow the scheduler tick to be disabled, even if the > > > corresponding CPU was idle. > > > > > > 3. You have CONFIG_FAST_NO_HZ=y (which you probably do, given > > > that you are building for a battery-powered device) and all of the > > > CPU's callbacks are lazy. Except that your earlier traces showed > > > lots of non-lazy callbacks. Besides, even if all callbacks were > > > lazy, there would still be a scheduling-clock interrupt every > > > six seconds, and there are quite a few six-second intervals > > > in a two-minute watchdog timeout. > > > > > > But if we cannot find the problem quickly, I will likely ask > > > you to try reproducing with CONFIG_FAST_NO_HZ=n. This could > > > be thought of as bisecting the RCU code looking for the bug. > > > > > > The first two of these seem unlikely given that the watchdog timer was still firing. Still, I don't see how 300,000 jiffies elapsed with a grace period requested and not started otherwise. Could you please check? > > > One way to do so would be to enable ftrace on rcu_check_callbacks(), __rcu_process_callbacks(), and rcu_check_gp_start_stall(). It might be necessary to no-inline rcu_check_gp_start_stall(). You might have better ways to collect this information. > > > > > > Without this information, the only workaround patch I can give you will degrade battery lifetime, which might not be what you want. > > > > > > You do have a lockdep complaint early at boot. Although I don't immediately see how this self-deadlock would affect RCU, please do get it fixed. Sometimes the consequences of this sort of deadlock can propagate to unexepected places. > > > > > > Regardless of why rcu_check_gp_start_stall() failed to complain, it looks like this was set after the rcu_preempt task slept for the last time, and so there should have been a wakeup the last time that ->gp_flags was set. Perhaps there is some code path that drops the wakeup. > > > I did check this in current -rcu, but you are instead running v4.19, so I should also check there. > > > > > > The ->gp_flags has its RCU_GP_FLAG_INIT bit set in rcu_start_this_gp() and in rcu_gp_cleanup(). We can eliminate rcu_gp_cleanup() from consideration because only the rcu_preempt task will execute that code, and we know that this task was asleep at the last time this bit was set. > > > Now rcu_start_this_gp() returns a flag indicating whether or not a wakeup is needed, and the caller must do the wakeup once it is safe to do so, that is, after the various rcu_node locks have been released (doing a wakeup while holding any of those locks results in deadlock). > > > > > > The following functions invoke rcu_start_this_gp: rcu_accelerate_cbs() and rcu_nocb_wait_gp(). We can eliminate rcu_nocb_wait_gp() because you are building with CONFIG_RCU_NOCB_CPU=n. Then rcu_accelerate_cbs() is invoked from: > > > > > > o rcu_accelerate_cbs_unlocked(), which does the following, thus > > > properly awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_advance_cbs(), which returns the value returned by > > > rcu_accelerate_cbs(), thus pushing the problem off to its > > > callers, which are called out below. > > > > > > o __note_gp_changes(), which also returns the value returned by > > > rcu_accelerate_cbs(), thus pushing the problem off to its callers, > > > which are called out below. > > > > > > o rcu_gp_cleanup(), which is only ever invoked by RCU grace-period > > > kthreads such as the rcu_preempt task. Therefore, this function > > > never needs to awaken the rcu_preempt task, because the fact > > > that this function is executing means that this task is already > > > awake. (Also, as noted above, we can eliminate this code from > > > consideration because this task is known to have been sleeping > > > at the last time that the RCU_GP_FLAG_INIT bit was set.) > > > > > > o rcu_report_qs_rdp(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > > > > rcu_report_qs_rnp(mask, rsp, rnp, rnp->gp_seq, flags); > > > /* ^^^ Released rnp->lock */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_prepare_for_idle(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_accelerate_cbs(rsp, rnp, rdp); > > > raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > Now for rcu_advance_cbs(): > > > > > > o __note_gp_changes(), which which also returns the value returned > > > by rcu_advance_cbs(), thus pushing the problem off to its callers, > > > which are called out below. > > > > > > o rcu_migrate_callbacks(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = rcu_advance_cbs(rsp, rnp_root, rdp) || > > > rcu_advance_cbs(rsp, rnp_root, my_rdp); > > > rcu_segcblist_merge(&my_rdp->cblist, &rdp->cblist); > > > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != > > > !rcu_segcblist_n_cbs(&my_rdp->cblist)); > > > raw_spin_unlock_irqrestore_rcu_node(rnp_root, flags); > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > Now for __note_gp_changes(): > > > > > > o note_gp_changes(), which does the following, thus properly > > > awakening the rcu_preempt task when needed: > > > > > > needwake = __note_gp_changes(rsp, rnp, rdp); > > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > > if (needwake) > > > rcu_gp_kthread_wake(rsp); > > > > > > o rcu_gp_init() which is only ever invoked by RCU grace-period > > > kthreads such as the rcu_preempt task, which makes wakeups > > > unnecessary, just as for rcu_gp_cleanup() above. > > > > > > o rcu_gp_cleanup(), ditto. > > > > > > So I am not seeing how I am losing a wakeup, but please do feel free to double-check my analysis. One way to do that is using event tracing. > > > > > > Thanx, Paul > > > > > > ------------------------------------------------------------------ > > > ---- > > > -- > > > lockdep complaint: > > > ------------------------------------------------------------------ > > > ---- > > > -- > > > > > > [ 2.895507] ====================================================== > > > [ 2.895511] WARNING: possible circular locking dependency detected > > > [ 2.895517] 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 Tainted: G U > > > [ 2.895521] ------------------------------------------------------ > > > [ 2.895525] earlyEvs/1839 is trying to acquire lock: > > > [ 2.895530] 00000000ff344115 (&asd->mutex){+.+.}, at: ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895546] > > > [ 2.895546] but task is already holding lock: > > > [ 2.895550] 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > > [ 2.895561] > > > [ 2.895561] which lock already depends on the new lock. > > > [ 2.895561] > > > [ 2.895566] > > > [ 2.895566] the existing dependency chain (in reverse order) is: > > > [ 2.895570] > > > [ 2.895570] -> #1 (&mdev->graph_mutex){+.+.}: > > > [ 2.895583] __mutex_lock+0x80/0x9a0 > > > [ 2.895588] mutex_lock_nested+0x1b/0x20 > > > [ 2.895593] media_device_register_entity+0x92/0x1e0 > > > [ 2.895598] v4l2_device_register_subdev+0xc2/0x1b0 > > > [ 2.895604] ipu_isys_csi2_init+0x22c/0x520 > > > [ 2.895608] isys_probe+0x6cb/0xed0 > > > [ 2.895613] ipu_bus_probe+0xfd/0x2e0 > > > [ 2.895620] really_probe+0x268/0x3d0 > > > [ 2.895625] driver_probe_device+0x11a/0x130 > > > [ 2.895630] __device_attach_driver+0x86/0x100 > > > [ 2.895635] bus_for_each_drv+0x6e/0xb0 > > > [ 2.895640] __device_attach+0xdf/0x160 > > > [ 2.895645] device_initial_probe+0x13/0x20 > > > [ 2.895650] bus_probe_device+0xa6/0xc0 > > > [ 2.895655] deferred_probe_work_func+0x88/0xe0 > > > [ 2.895661] process_one_work+0x220/0x5c0 > > > [ 2.895665] worker_thread+0x1da/0x3b0 > > > [ 2.895670] kthread+0x12c/0x150 > > > [ 2.895675] ret_from_fork+0x3a/0x50 > > > [ 2.895678] > > > [ 2.895678] -> #0 (&asd->mutex){+.+.}: > > > [ 2.895688] lock_acquire+0x95/0x1a0 > > > [ 2.895693] __mutex_lock+0x80/0x9a0 > > > [ 2.895698] mutex_lock_nested+0x1b/0x20 > > > [ 2.895703] ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895708] ipu_isys_csi2_get_fmt+0x14/0x30 > > > [ 2.895713] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.895718] v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.895723] v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.895728] csi2_link_validate+0xc6/0x220 > > > [ 2.895733] __media_pipeline_start+0x15b/0x2f0 > > > [ 2.895738] media_pipeline_start+0x33/0x50 > > > [ 2.895743] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > > [ 2.895748] start_streaming+0x186/0x3a0 > > > [ 2.895753] vb2_start_streaming+0x6d/0x130 > > > [ 2.895758] vb2_core_streamon+0x108/0x140 > > > [ 2.895762] vb2_streamon+0x29/0x50 > > > [ 2.895767] vb2_ioctl_streamon+0x42/0x50 > > > [ 2.895772] v4l_streamon+0x20/0x30 > > > [ 2.895776] __video_do_ioctl+0x1af/0x3c0 > > > [ 2.895781] video_usercopy+0x27e/0x7e0 > > > [ 2.895785] video_ioctl2+0x15/0x20 > > > [ 2.895789] v4l2_ioctl+0x49/0x50 > > > [ 2.895794] do_video_ioctl+0x93c/0x2360 > > > [ 2.895799] v4l2_compat_ioctl32+0x93/0xe0 > > > [ 2.895806] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > > [ 2.895813] do_fast_syscall_32+0x9a/0x2d6 > > > [ 2.895818] entry_SYSENTER_compat+0x6d/0x7c > > > [ 2.895821] > > > [ 2.895821] other info that might help us debug this: > > > [ 2.895821] > > > [ 2.895826] Possible unsafe locking scenario: > > > [ 2.895826] > > > [ 2.895830] CPU0 CPU1 > > > [ 2.895833] ---- ---- > > > [ 2.895836] lock(&mdev->graph_mutex); > > > [ 2.895842] lock(&asd->mutex); > > > [ 2.895847] lock(&mdev->graph_mutex); > > > [ 2.895852] lock(&asd->mutex); > > > [ 2.895857] > > > [ 2.895857] *** DEADLOCK *** > > > [ 2.895857] > > > [ 2.895863] 3 locks held by earlyEvs/1839: > > > [ 2.895866] #0: 00000000ed860090 (&av->mutex){+.+.}, at: __video_do_ioctl+0xbf/0x3c0 > > > [ 2.895876] #1: 000000000cb253e7 (&isys->stream_mutex){+.+.}, at: start_streaming+0x5c/0x3a0 > > > [ 2.895886] #2: 0000000069562e72 (&mdev->graph_mutex){+.+.}, at: media_pipeline_start+0x28/0x50 > > > [ 2.895896] > > > [ 2.895896] stack backtrace: > > > [ 2.895903] CPU: 0 PID: 1839 Comm: earlyEvs Tainted: G U 4.19.5-quilt-2e5dc0ac-g4d59bbd0fd1a #1 > > > [ 2.895907] Call Trace: > > > [ 2.895915] dump_stack+0x70/0xa5 > > > [ 2.895921] print_circular_bug.isra.35+0x1d8/0x1e6 > > > [ 2.895927] __lock_acquire+0x1284/0x1340 > > > [ 2.895931] ? __lock_acquire+0x2b5/0x1340 > > > [ 2.895940] lock_acquire+0x95/0x1a0 > > > [ 2.895945] ? lock_acquire+0x95/0x1a0 > > > [ 2.895950] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895956] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895961] __mutex_lock+0x80/0x9a0 > > > [ 2.895966] ? ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895971] ? crlmodule_get_format+0x43/0x50 > > > [ 2.895979] mutex_lock_nested+0x1b/0x20 > > > [ 2.895984] ? mutex_lock_nested+0x1b/0x20 > > > [ 2.895989] ipu_isys_subdev_get_ffmt+0x32/0x90 > > > [ 2.895995] ipu_isys_csi2_get_fmt+0x14/0x30 > > > [ 2.896001] v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.896006] v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.896011] ? crlmodule_get_format+0x2a/0x50 > > > [ 2.896018] ? find_held_lock+0x35/0xa0 > > > [ 2.896023] ? crlmodule_get_format+0x43/0x50 > > > [ 2.896030] v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.896035] ? __mutex_unlock_slowpath+0x58/0x2f0 > > > [ 2.896042] ? mutex_unlock+0x12/0x20 > > > [ 2.896046] ? crlmodule_get_format+0x43/0x50 > > > [ 2.896052] ? v4l2_subdev_link_validate_get_format.isra.6+0x52/0x80 > > > [ 2.896057] ? v4l2_subdev_link_validate_one+0x67/0x120 > > > [ 2.896065] ? __is_insn_slot_addr+0xad/0x120 > > > [ 2.896070] ? kernel_text_address+0xc4/0x100 > > > [ 2.896078] ? v4l2_subdev_link_validate+0x246/0x490 > > > [ 2.896085] ? kernel_text_address+0xc4/0x100 > > > [ 2.896092] ? __lock_acquire+0x1106/0x1340 > > > [ 2.896096] ? __lock_acquire+0x1169/0x1340 > > > [ 2.896103] csi2_link_validate+0xc6/0x220 > > > [ 2.896110] ? __lock_is_held+0x5a/0xa0 > > > [ 2.896115] ? mark_held_locks+0x58/0x80 > > > [ 2.896122] ? __kmalloc+0x207/0x2e0 > > > [ 2.896127] ? __lock_is_held+0x5a/0xa0 > > > [ 2.896134] ? rcu_read_lock_sched_held+0x81/0x90 > > > [ 2.896139] ? __kmalloc+0x2a3/0x2e0 > > > [ 2.896144] ? media_pipeline_start+0x28/0x50 > > > [ 2.896150] ? __media_entity_enum_init+0x33/0x70 > > > [ 2.896155] ? csi2_has_route+0x18/0x20 > > > [ 2.896160] ? media_graph_walk_next.part.9+0xac/0x290 > > > [ 2.896166] __media_pipeline_start+0x15b/0x2f0 > > > [ 2.896173] ? rcu_read_lock_sched_held+0x81/0x90 > > > [ 2.896179] media_pipeline_start+0x33/0x50 > > > [ 2.896186] ipu_isys_video_prepare_streaming+0x1e0/0x610 > > > [ 2.896191] ? __lock_acquire+0x132e/0x1340 > > > [ 2.896198] ? __lock_acquire+0x2b5/0x1340 > > > [ 2.896204] ? lock_acquire+0x95/0x1a0 > > > [ 2.896209] ? start_streaming+0x5c/0x3a0 > > > [ 2.896215] ? start_streaming+0x5c/0x3a0 > > > [ 2.896221] ? __mutex_lock+0x391/0x9a0 > > > [ 2.896226] ? v4l_enable_media_source+0x2d/0x70 > > > [ 2.896233] ? find_held_lock+0x35/0xa0 > > > [ 2.896238] ? v4l_enable_media_source+0x57/0x70 > > > [ 2.896245] start_streaming+0x186/0x3a0 > > > [ 2.896250] ? __mutex_unlock_slowpath+0x58/0x2f0 > > > [ 2.896257] vb2_start_streaming+0x6d/0x130 > > > [ 2.896262] ? vb2_start_streaming+0x6d/0x130 > > > [ 2.896267] vb2_core_streamon+0x108/0x140 > > > [ 2.896273] vb2_streamon+0x29/0x50 > > > [ 2.896278] vb2_ioctl_streamon+0x42/0x50 > > > [ 2.896284] v4l_streamon+0x20/0x30 > > > [ 2.896288] __video_do_ioctl+0x1af/0x3c0 > > > [ 2.896296] ? __might_fault+0x85/0x90 > > > [ 2.896302] video_usercopy+0x27e/0x7e0 > > > [ 2.896307] ? copy_overflow+0x20/0x20 > > > [ 2.896313] ? find_held_lock+0x35/0xa0 > > > [ 2.896319] ? __might_fault+0x3e/0x90 > > > [ 2.896325] video_ioctl2+0x15/0x20 > > > [ 2.896330] v4l2_ioctl+0x49/0x50 > > > [ 2.896335] do_video_ioctl+0x93c/0x2360 > > > [ 2.896343] v4l2_compat_ioctl32+0x93/0xe0 > > > [ 2.896349] __ia32_compat_sys_ioctl+0x73a/0x1c90 > > > [ 2.896354] ? lockdep_hardirqs_on+0xef/0x180 > > > [ 2.896359] ? do_fast_syscall_32+0x3b/0x2d6 > > > [ 2.896364] do_fast_syscall_32+0x9a/0x2d6 > > > [ 2.896370] entry_SYSENTER_compat+0x6d/0x7c > > > [ 2.896377] RIP: 0023:0xf7e79b79 > > > [ 2.896382] Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > > > [ 2.896387] RSP: 002b:00000000f76816bc EFLAGS: 00000292 ORIG_RAX: 0000000000000036 > > > [ 2.896393] RAX: ffffffffffffffda RBX: 000000000000000e RCX: 0000000040045612 > > > [ 2.896396] RDX: 00000000f768172c RSI: 00000000f7d42d9c RDI: 00000000f768172c > > > [ 2.896400] RBP: 00000000f7681708 R08: 0000000000000000 R09: 0000000000000000 > > > [ 2.896404] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > > [ 2.896408] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > > > ------------------------------------------------------------------ > > > ---- > > > -- > > > > > > > [17818.936039] rcu: rcu_node 0:3 ->gp_seq 21808192 ->gp_seq_needed 21808196 > > > > [17818.936048] rcu: rcu_sched: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 101730 ->gp_req_activity 101732 ->gp_wake_time 101730 ->gp_wake_seq 1357 - >gp_seq 1360 ->gp_seq_needed 1360 ->gp_flags 0x0 > > > > [17818.936056] rcu: rcu_bh: wait state: RCU_GP_WAIT_GPS(1) ->state: 0x402 delta ->gp_activity 4312486108 ->gp_req_activity 4312486108 ->gp_wake_time 4312486108 - >gp_wake_seq 0 ->gp_seq -1200 ->gp_seq_needed -1200 ->gp_flags 0x0 > > > > > > > > -----Original Message----- > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > Sent: Thursday, December 13, 2018 12:40 PM > > > > To: Zhang, Jun <jun.zhang@intel.com> > > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt > > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > On Thu, Dec 13, 2018 at 03:28:46AM +0000, Zhang, Jun wrote: > > > > > Ok, we will test it, thanks! > > > > > > > > But please also try the sysrq-y with the earlier patch after a hang! > > > > > > > > Thanx, Paul > > > > > > > > > -----Original Message----- > > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > > Sent: Thursday, December 13, 2018 10:43 > > > > > To: Zhang, Jun <jun.zhang@intel.com> > > > > > Cc: He, Bo <bo.he@intel.com>; Steven Rostedt > > > > > <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; > > > > > josh@joshtriplett.org; mathieu.desnoyers@efficios.com; > > > > > jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, > > > > > Yanmin <yanmin.zhang@intel.com>; Bai, Jie A > > > > > <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com> > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > On Thu, Dec 13, 2018 at 02:11:35AM +0000, Zhang, Jun wrote: > > > > > > Hello, Paul > > > > > > > > > > > > I think the next patch is better. > > > > > > Because ULONG_CMP_GE could cause double write, which has risk that write back old value. > > > > > > Please help review. > > > > > > I don't test it. If you agree, we will test it. > > > > > > > > > > Just to make sure that I understand, you are worried about something like the following, correct? > > > > > > > > > > o __note_gp_changes() compares rnp->gp_seq_needed and rdp->gp_seq_needed > > > > > and finds them equal. > > > > > > > > > > o At just this time something like rcu_start_this_gp() assigns a new > > > > > (larger) value to rdp->gp_seq_needed. > > > > > > > > > > o Then __note_gp_changes() overwrites rdp->gp_seq_needed with the > > > > > old value. > > > > > > > > > > This cannot happen because __note_gp_changes() runs with interrupts disabled on the CPU corresponding to the rcu_data structure referenced by the rdp pointer. So there is no way for rcu_start_this_gp() to be invoked on the same CPU during this "if" statement. > > > > > > > > > > Of course, there could be bugs. For example: > > > > > > > > > > o __note_gp_changes() might be called on a different CPU than that > > > > > corresponding to rdp. You can check this with something like: > > > > > > > > > > WARN_ON_ONCE(rdp->cpu != smp_processor_id()); > > > > > > > > > > o The same things could happen with rcu_start_this_gp(), and the > > > > > above WARN_ON_ONCE() would work there as well. > > > > > > > > > > o rcutree_prepare_cpu() is a special case, but is irrelevant unless > > > > > you are doing CPU-hotplug operations. (It can run on a CPU other > > > > > than rdp->cpu, but only at times when rdp->cpu is offline.) > > > > > > > > > > o Interrupts might not really be disabled. > > > > > > > > > > That said, your patch could reduce overhead slightly, given that the two values will be equal much of the time. So it might be worth testing just for that reason. > > > > > > > > > > So why not just test it anyway? If it makes the bug go away, > > > > > I will be surprised, but it would not be the first surprise for me. > > > > > ;-) > > > > > > > > > > Thanx, Paul > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > > 0b760c1..c00f34e 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -1849,7 +1849,7 @@ static bool __note_gp_changes(struct rcu_state *rsp, struct rcu_node *rnp, > > > > > > zero_cpu_stall_ticks(rdp); > > > > > > } > > > > > > rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ > > > > > > - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) > > > > > > + if (ULONG_CMP_LT(rdp->gp_seq_needed, > > > > > > + rnp->gp_seq_needed) > > > > > > + || > > > > > > + rdp->gpwrap) > > > > > > rdp->gp_seq_needed = rnp->gp_seq_needed; > > > > > > WRITE_ONCE(rdp->gpwrap, false); > > > > > > rcu_gpnum_ovf(rnp, rdp); > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Paul E. McKenney [mailto:paulmck@linux.ibm.com] > > > > > > Sent: Thursday, December 13, 2018 08:12 > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; > > > > > > Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > > > > > <jin.xiao@intel.com>; Zhang, Yanmin > > > > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; > > > > > > Sun, Yi J <yi.j.sun@intel.com> > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > On Wed, Dec 12, 2018 at 11:13:22PM +0000, He, Bo wrote: > > > > > > > I don't see the rcutree.sysrq_rcu parameter in v4.19 kernel, I also checked the latest kernel and the latest tag v4.20-rc6, not see the sysrq_rcu. > > > > > > > Please correct me if I have something wrong. > > > > > > > > > > > > That would be because I sent you the wrong patch, apologies! > > > > > > :-/ > > > > > > > > > > > > Please instead see the one below, which does add sysrq_rcu. > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > Sent: Thursday, December 13, 2018 5:03 AM > > > > > > > To: He, Bo <bo.he@intel.com> > > > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>; > > > > > > > linux-kernel@vger.kernel.org; josh@joshtriplett.org; > > > > > > > mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; > > > > > > > Zhang, Jun <jun.zhang@intel.com>; Xiao, Jin > > > > > > > <jin.xiao@intel.com>; Zhang, Yanmin > > > > > > > <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com> > > > > > > > Subject: Re: rcu_preempt caused oom > > > > > > > > > > > > > > On Wed, Dec 12, 2018 at 07:42:24AM -0800, Paul E. McKenney wrote: > > > > > > > > On Wed, Dec 12, 2018 at 01:21:33PM +0000, He, Bo wrote: > > > > > > > > > we reproduce on two boards, but I still not see the show_rcu_gp_kthreads() dump logs, it seems the patch can't catch the scenario. > > > > > > > > > I double confirmed the CONFIG_PROVE_RCU=y is enabled in the config as it's extracted from the /proc/config.gz. > > > > > > > > > > > > > > > > Strange. > > > > > > > > > > > > > > > > Are the systems responsive to sysrq keys once failure occurs? > > > > > > > > If so, I will provide you a sysrq-R or some such to dump out the RCU state. > > > > > > > > > > > > > > Or, as it turns out, sysrq-y if booting with rcutree.sysrq_rcu=1 using the patch below. Only lightly tested. > > > > > > > > > > > > ------------------------------------------------------------ > > > > > > ---- > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > > > > > > > commit 04b6245c8458e8725f4169e62912c1fadfdf8141 > > > > > > Author: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > Date: Wed Dec 12 16:10:09 2018 -0800 > > > > > > > > > > > > rcu: Add sysrq rcu_node-dump capability > > > > > > > > > > > > Backported from v4.21/v5.0 > > > > > > > > > > > > Life is hard if RCU manages to get stuck without triggering RCU CPU > > > > > > stall warnings or triggering the rcu_check_gp_start_stall() checks > > > > > > for failing to start a grace period. This commit therefore adds a > > > > > > boot-time-selectable sysrq key (commandeering "y") that allows manually > > > > > > dumping Tree RCU state. The new rcutree.sysrq_rcu kernel boot parameter > > > > > > must be set for this sysrq to be available. > > > > > > > > > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> > > > > > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index > > > > > > 0b760c1369f7..e9392a9d6291 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -61,6 +61,7 @@ > > > > > > #include <linux/trace_events.h> #include <linux/suspend.h> > > > > > > #include <linux/ftrace.h> > > > > > > +#include <linux/sysrq.h> > > > > > > > > > > > > #include "tree.h" > > > > > > #include "rcu.h" > > > > > > @@ -128,6 +129,9 @@ int num_rcu_lvl[] = NUM_RCU_LVL_INIT; > > > > > > int rcu_num_nodes __read_mostly = NUM_RCU_NODES; /* Total # > > > > > > rcu_nodes in use. */ > > > > > > /* panic() on RCU Stall sysctl. */ int > > > > > > sysctl_panic_on_rcu_stall __read_mostly; > > > > > > +/* Commandeer a sysrq key to dump RCU's tree. */ static > > > > > > +bool sysrq_rcu; module_param(sysrq_rcu, bool, 0444); > > > > > > > > > > > > /* > > > > > > * The rcu_scheduler_active variable is initialized to the > > > > > > value @@ > > > > > > -662,6 +666,27 @@ void show_rcu_gp_kthreads(void) } > > > > > > EXPORT_SYMBOL_GPL(show_rcu_gp_kthreads); > > > > > > > > > > > > +/* Dump grace-period-request information due to commandeered sysrq. > > > > > > +*/ static void sysrq_show_rcu(int key) { > > > > > > + show_rcu_gp_kthreads(); > > > > > > +} > > > > > > + > > > > > > +static struct sysrq_key_op sysrq_rcudump_op = { > > > > > > + .handler = sysrq_show_rcu, > > > > > > + .help_msg = "show-rcu(y)", > > > > > > + .action_msg = "Show RCU tree", > > > > > > + .enable_mask = SYSRQ_ENABLE_DUMP, }; > > > > > > + > > > > > > +static int __init rcu_sysrq_init(void) { > > > > > > + if (sysrq_rcu) > > > > > > + return register_sysrq_key('y', &sysrq_rcudump_op); > > > > > > + return 0; > > > > > > +} > > > > > > +early_initcall(rcu_sysrq_init); > > > > > > + > > > > > > /* > > > > > > * Send along grace-period-related data for rcutorture diagnostics. > > > > > > */ > > > > > > > > > > > > > > > > > > > > > > > > > [-- Attachment #2: 0001-rcu-detect-the-preempt_rcu-hang-for-triage-jing-s-bo.patch --] [-- Type: application/octet-stream, Size: 1692 bytes --] From e8b583aa685b3b4f304f72398a80461bba09389c Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: detect the preempt_rcu hang for triage jing's board Change-Id: I2ffceec2ae4847867753609e45c99afc66956003 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 78c0cf2..d6de363 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2192,8 +2192,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2202,8 +2207,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) -- 2.7.4 [-- Attachment #3: 0002-rcu-v2-detect-the-preempt_rcu-hang-for-triage-jing-s.patch --] [-- Type: application/octet-stream, Size: 1069 bytes --] From 57f50b53ca5c8a5f6503f0ac058e306dbdcecb21 Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: v2: detect the preempt_rcu hang for triage jing's board Change-Id: I7b413b4fb40b16e5f33737b15689dacaf6d4f33e Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1..23669c1 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2163,8 +2163,9 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT); + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) -- 2.7.4 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-17 3:15 ` He, Bo @ 2018-12-17 4:26 ` Paul E. McKenney [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A1A634@SHSMSX104.ccr.corp.intel.com> 0 siblings, 1 reply; 43+ messages in thread From: Paul E. McKenney @ 2018-12-17 4:26 UTC (permalink / raw) To: He, Bo Cc: Zhang, Jun, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J, Chang, Junxiao, Mei, Paul On Mon, Dec 17, 2018 at 03:15:42AM +0000, He, Bo wrote: > for double confirm the issue is not reproduce after 90 hours, we tried only add the enclosed patch on the easy reproduced build, the issue is not reproduced after 63 hours in the whole weekend on 16 boards. > so current conclusion is the debug patch has extreme effect on the rcu issue. This is not a surprise. (Please see the end of this email for a replacement patch that won't suppress the bug.) To see why this is not a surprise, let's take a closer look at your patch, in light of the comment header for wait_event_idle_timeout_exclusive(): * Returns: * 0 if the @condition evaluated to %false after the @timeout elapsed, * 1 if the @condition evaluated to %true after the @timeout elapsed, * or the remaining jiffies (at least 1) if the @condition evaluated * to %true before the @timeout elapsed. The situation we are seeing is that the RCU_GP_FLAG_INIT is set, but the rcu_preempt task does not wake up. This would correspond to the second case above, that is, a return value of 1. Looking now at your patch, with comments interspersed below: ------------------------------------------------------------------------ From e8b583aa685b3b4f304f72398a80461bba09389c Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: detect the preempt_rcu hang for triage jing's board Change-Id: I2ffceec2ae4847867753609e45c99afc66956003 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 78c0cf2..d6de363 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2192,8 +2192,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2202,8 +2207,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { We get here if ret==0. Therefore, the above "if" statement needs to instead be "if (ret == 1) {". In addition, in order to get event traces dumped, we also need: rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) -- 2.7.4 ------------------------------------------------------------------------ So, again, please change the "if(!ret) {" to "if (ret == 1) {", and please add "rcu_ftrace_dump(DUMP_ALL);" right after this "if" statement, as shown above. With that change, I bet that you will again see failures. > Compared with the swait_event_idle_timeout_exclusive will do 3 times to check the condition, while swait_event_idle_ exclusive will do 2 times check the condition. > > so today I will do another experiment, only change as below: > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > - RCU_GP_FLAG_INIT); > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT); > + > > Can you get some clues from the experiment? Again, please instead make the changes that I called out above, with the replacement for your patch 0001 shown below. Thanx, Paul PS. I have been testing for quite some time, but am still unable to reproduce this. So we must depend on you to reproduce it. ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..86152af1a580 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2153,8 +2153,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2163,8 +2168,20 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if (ret == 1) { + rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) ^ permalink raw reply related [flat|nested] 43+ messages in thread
[parent not found: <CD6925E8781EFD4D8E11882D20FC406D52A1A634@SHSMSX104.ccr.corp.intel.com>]
* RE: rcu_preempt caused oom [not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A1A634@SHSMSX104.ccr.corp.intel.com> @ 2018-12-18 2:46 ` Zhang, Jun 2018-12-18 3:12 ` He, Bo 2018-12-18 5:34 ` Paul E. McKenney 0 siblings, 2 replies; 43+ messages in thread From: Zhang, Jun @ 2018-12-18 2:46 UTC (permalink / raw) To: He, Bo, paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J, Chang, Junxiao, Mei, Paul Hello, paul In softirq context, and current is rcu_preempt-10, rcu_gp_kthread_wake don't wakeup rcu_preempt. Maybe next patch could fix it. Please help review. diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1..98f5b40 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1697,7 +1697,7 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { - if (current == rsp->gp_kthread || + if (((current == rsp->gp_kthread) && !in_softirq()) || !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; [44932.311439, 0][ rcu_preempt] rcu_preempt-10 [001] .n.. 44929.401037: rcu_grace_period: rcu_preempt 19063548 reqwait ...... [44932.311517, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402234: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startleaf [44932.311536, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402237: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startedroot -----Original Message----- From: He, Bo Sent: Tuesday, December 18, 2018 07:16 To: paulmck@linux.ibm.com Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com>; Chang, Junxiao <junxiao.chang@intel.com>; Mei, Paul <paul.mei@intel.com> Subject: RE: rcu_preempt caused oom Thanks for your comments, the issue could be panic with the change if (ret == 1). Here enclosed are the logs. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Monday, December 17, 2018 12:26 PM To: He, Bo <bo.he@intel.com> Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com>; Chang, Junxiao <junxiao.chang@intel.com>; Mei, Paul <paul.mei@intel.com> Subject: Re: rcu_preempt caused oom On Mon, Dec 17, 2018 at 03:15:42AM +0000, He, Bo wrote: > for double confirm the issue is not reproduce after 90 hours, we tried only add the enclosed patch on the easy reproduced build, the issue is not reproduced after 63 hours in the whole weekend on 16 boards. > so current conclusion is the debug patch has extreme effect on the rcu issue. This is not a surprise. (Please see the end of this email for a replacement patch that won't suppress the bug.) To see why this is not a surprise, let's take a closer look at your patch, in light of the comment header for wait_event_idle_timeout_exclusive(): * Returns: * 0 if the @condition evaluated to %false after the @timeout elapsed, * 1 if the @condition evaluated to %true after the @timeout elapsed, * or the remaining jiffies (at least 1) if the @condition evaluated * to %true before the @timeout elapsed. The situation we are seeing is that the RCU_GP_FLAG_INIT is set, but the rcu_preempt task does not wake up. This would correspond to the second case above, that is, a return value of 1. Looking now at your patch, with comments interspersed below: ------------------------------------------------------------------------ From e8b583aa685b3b4f304f72398a80461bba09389c Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: detect the preempt_rcu hang for triage jing's board Change-Id: I2ffceec2ae4847867753609e45c99afc66956003 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 78c0cf2..d6de363 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2192,8 +2192,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2202,8 +2207,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { We get here if ret==0. Therefore, the above "if" statement needs to instead be "if (ret == 1) {". In addition, in order to get event traces dumped, we also need: rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) -- 2.7.4 ------------------------------------------------------------------------ So, again, please change the "if(!ret) {" to "if (ret == 1) {", and please add "rcu_ftrace_dump(DUMP_ALL);" right after this "if" statement, as shown above. With that change, I bet that you will again see failures. > Compared with the swait_event_idle_timeout_exclusive will do 3 times to check the condition, while swait_event_idle_ exclusive will do 2 times check the condition. > > so today I will do another experiment, only change as below: > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > - RCU_GP_FLAG_INIT); > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT); > + > > Can you get some clues from the experiment? Again, please instead make the changes that I called out above, with the replacement for your patch 0001 shown below. Thanx, Paul PS. I have been testing for quite some time, but am still unable to reproduce this. So we must depend on you to reproduce it. ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..86152af1a580 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2153,8 +2153,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2163,8 +2168,20 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if (ret == 1) { + rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) ^ permalink raw reply related [flat|nested] 43+ messages in thread
* RE: rcu_preempt caused oom 2018-12-18 2:46 ` Zhang, Jun @ 2018-12-18 3:12 ` He, Bo 2018-12-18 5:34 ` Paul E. McKenney 1 sibling, 0 replies; 43+ messages in thread From: He, Bo @ 2018-12-18 3:12 UTC (permalink / raw) To: Zhang, Jun, paulmck@linux.ibm.com Cc: Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J, Chang, Junxiao, Mei, Paul check with jun: the scenario is more like: @@@rcu_start_this_gp@@@ start after ___swait_event before schedule rcu_gp_kthread--> swait_event_idle_exclusive--> __swait_event_idle--> ___swait_event--------->schedule @@@ rcu_gp_kthread_wake skip wakeup in rcu_gp_kthread then rcu_gp_kthread will sleep and can't wake up. Jun's patch can workaround it, what's your ideas? -----Original Message----- From: Zhang, Jun Sent: Tuesday, December 18, 2018 10:47 AM To: He, Bo <bo.he@intel.com>; paulmck@linux.ibm.com Cc: Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com>; Chang, Junxiao <junxiao.chang@intel.com>; Mei, Paul <paul.mei@intel.com> Subject: RE: rcu_preempt caused oom Hello, paul In softirq context, and current is rcu_preempt-10, rcu_gp_kthread_wake don't wakeup rcu_preempt. Maybe next patch could fix it. Please help review. diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1..98f5b40 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1697,7 +1697,7 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { - if (current == rsp->gp_kthread || + if (((current == rsp->gp_kthread) && !in_softirq()) || !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; [44932.311439, 0][ rcu_preempt] rcu_preempt-10 [001] .n.. 44929.401037: rcu_grace_period: rcu_preempt 19063548 reqwait ...... [44932.311517, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402234: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startleaf [44932.311536, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402237: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startedroot -----Original Message----- From: He, Bo Sent: Tuesday, December 18, 2018 07:16 To: paulmck@linux.ibm.com Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com>; Chang, Junxiao <junxiao.chang@intel.com>; Mei, Paul <paul.mei@intel.com> Subject: RE: rcu_preempt caused oom Thanks for your comments, the issue could be panic with the change if (ret == 1). Here enclosed are the logs. -----Original Message----- From: Paul E. McKenney <paulmck@linux.ibm.com> Sent: Monday, December 17, 2018 12:26 PM To: He, Bo <bo.he@intel.com> Cc: Zhang, Jun <jun.zhang@intel.com>; Steven Rostedt <rostedt@goodmis.org>; linux-kernel@vger.kernel.org; josh@joshtriplett.org; mathieu.desnoyers@efficios.com; jiangshanlai@gmail.com; Xiao, Jin <jin.xiao@intel.com>; Zhang, Yanmin <yanmin.zhang@intel.com>; Bai, Jie A <jie.a.bai@intel.com>; Sun, Yi J <yi.j.sun@intel.com>; Chang, Junxiao <junxiao.chang@intel.com>; Mei, Paul <paul.mei@intel.com> Subject: Re: rcu_preempt caused oom On Mon, Dec 17, 2018 at 03:15:42AM +0000, He, Bo wrote: > for double confirm the issue is not reproduce after 90 hours, we tried only add the enclosed patch on the easy reproduced build, the issue is not reproduced after 63 hours in the whole weekend on 16 boards. > so current conclusion is the debug patch has extreme effect on the rcu issue. This is not a surprise. (Please see the end of this email for a replacement patch that won't suppress the bug.) To see why this is not a surprise, let's take a closer look at your patch, in light of the comment header for wait_event_idle_timeout_exclusive(): * Returns: * 0 if the @condition evaluated to %false after the @timeout elapsed, * 1 if the @condition evaluated to %true after the @timeout elapsed, * or the remaining jiffies (at least 1) if the @condition evaluated * to %true before the @timeout elapsed. The situation we are seeing is that the RCU_GP_FLAG_INIT is set, but the rcu_preempt task does not wake up. This would correspond to the second case above, that is, a return value of 1. Looking now at your patch, with comments interspersed below: ------------------------------------------------------------------------ From e8b583aa685b3b4f304f72398a80461bba09389c Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he@intel.com> Date: Sun, 9 Dec 2018 18:11:33 +0800 Subject: [PATCH] rcu: detect the preempt_rcu hang for triage jing's board Change-Id: I2ffceec2ae4847867753609e45c99afc66956003 Tracked-On: Signed-off-by: he, bo <bo.he@intel.com> --- kernel/rcu/tree.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 78c0cf2..d6de363 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2192,8 +2192,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2202,8 +2207,19 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if(!ret) { We get here if ret==0. Therefore, the above "if" statement needs to instead be "if (ret == 1) {". In addition, in order to get event traces dumped, we also need: rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) -- 2.7.4 ------------------------------------------------------------------------ So, again, please change the "if(!ret) {" to "if (ret == 1) {", and please add "rcu_ftrace_dump(DUMP_ALL);" right after this "if" statement, as shown above. With that change, I bet that you will again see failures. > Compared with the swait_event_idle_timeout_exclusive will do 3 times to check the condition, while swait_event_idle_ exclusive will do 2 times check the condition. > > so today I will do another experiment, only change as below: > - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > - RCU_GP_FLAG_INIT); > + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & > + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT); > + > > Can you get some clues from the experiment? Again, please instead make the changes that I called out above, with the replacement for your patch 0001 shown below. Thanx, Paul PS. I have been testing for quite some time, but am still unable to reproduce this. So we must depend on you to reproduce it. ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0b760c1369f7..86152af1a580 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2153,8 +2153,13 @@ static int __noreturn rcu_gp_kthread(void *arg) int ret; struct rcu_state *rsp = arg; struct rcu_node *rnp = rcu_get_root(rsp); + pid_t rcu_preempt_pid; rcu_bind_gp_kthread(); + if(!strcmp(rsp->name, "rcu_preempt")) { + rcu_preempt_pid = rsp->gp_kthread->pid; + } + for (;;) { /* Handle grace-period start. */ @@ -2163,8 +2168,20 @@ static int __noreturn rcu_gp_kthread(void *arg) READ_ONCE(rsp->gp_seq), TPS("reqwait")); rsp->gp_state = RCU_GP_WAIT_GPS; - swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & - RCU_GP_FLAG_INIT); + if (current->pid != rcu_preempt_pid) { + swait_event_idle_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT); + } else { + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) & + RCU_GP_FLAG_INIT, 2*HZ); + + if (ret == 1) { + rcu_ftrace_dump(DUMP_ALL); + show_rcu_gp_kthreads(); + panic("hung_task: blocked in rcu_gp_kthread init"); + } + } + rsp->gp_state = RCU_GP_DONE_GPS; /* Locking provides needed memory barrier. */ if (rcu_gp_init(rsp)) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: rcu_preempt caused oom 2018-12-18 2:46 ` Zhang, Jun 2018-12-18 3:12 ` He, Bo @ 2018-12-18 5:34 ` Paul E. McKenney 1 sibling, 0 replies; 43+ messages in thread From: Paul E. McKenney @ 2018-12-18 5:34 UTC (permalink / raw) To: Zhang, Jun Cc: He, Bo, Steven Rostedt, linux-kernel@vger.kernel.org, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Xiao, Jin, Zhang, Yanmin, Bai, Jie A, Sun, Yi J, Chang, Junxiao, Mei, Paul On Tue, Dec 18, 2018 at 02:46:43AM +0000, Zhang, Jun wrote: > Hello, paul > > In softirq context, and current is rcu_preempt-10, rcu_gp_kthread_wake don't wakeup rcu_preempt. > Maybe next patch could fix it. Please help review. > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 0b760c1..98f5b40 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -1697,7 +1697,7 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > */ > static void rcu_gp_kthread_wake(struct rcu_state *rsp) > { > - if (current == rsp->gp_kthread || > + if (((current == rsp->gp_kthread) && !in_softirq()) || Close, but not quite. Please see below. > !READ_ONCE(rsp->gp_flags) || > !rsp->gp_kthread) > return; > > [44932.311439, 0][ rcu_preempt] rcu_preempt-10 [001] .n.. 44929.401037: rcu_grace_period: rcu_preempt 19063548 reqwait > ...... > [44932.311517, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402234: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startleaf > [44932.311536, 0][ rcu_preempt] rcu_preempt-10 [001] d.s2 44929.402237: rcu_future_grace_period: rcu_preempt 19063548 19063552 0 0 3 Startedroot Good catch! If the rcu_preempt kthread had just entered the function swait_event_idle_exclusive(), which had just called __swait_event_idle() which had just called ___swait_event(), which had just gotten done checking the "condition", then yes, the rcu_preempt kthread could sleep forever. This is a very narrow race window, but that matches your experience with its not happening often -- and my experience with it not happening at all. However, for this to happen, the wakeup must happen within a softirq handler that executes upon return from an interrupt that interrupted ___swait_event() just after the "if (condition)". For this, we don't want in_softirq() but rather in_serving_softirq(), as shown in the patch below. The patch you have above could result in spurious wakeups, as it is checking for bottom halves being disabled, not just executing within a softirq handler. Which might be better than not having enough wakeups, but let's please try for just the right number. ;-) So could you please instead test the patch below? And if it works, could I please have your Signed-off-by so that I can queue it? My patch is quite clearly derived from yours, after all! And you should get credit for finding the problem and arriving at an approximate fix, after all. Thanx, Paul ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index e9392a9d6291..b9205b40b621 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1722,7 +1722,7 @@ static bool rcu_future_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) */ static void rcu_gp_kthread_wake(struct rcu_state *rsp) { - if (current == rsp->gp_kthread || + if ((current == rsp->gp_kthread && !in_serving_softirq()) || !READ_ONCE(rsp->gp_flags) || !rsp->gp_kthread) return; ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [tip:core/rcu] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() 2018-12-13 2:11 ` Zhang, Jun 2018-12-13 2:42 ` Paul E. McKenney @ 2019-02-13 8:31 ` tip-bot for Zhang, Jun 1 sibling, 0 replies; 43+ messages in thread From: tip-bot for Zhang, Jun @ 2019-02-13 8:31 UTC (permalink / raw) To: linux-tip-commits; +Cc: tglx, jun.zhang, hpa, linux-kernel, mingo, paulmck Commit-ID: 13dc7d0c7a2ed438f0ec8e9fb365a1256d87cf87 Gitweb: https://git.kernel.org/tip/13dc7d0c7a2ed438f0ec8e9fb365a1256d87cf87 Author: Zhang, Jun <jun.zhang@intel.com> AuthorDate: Wed, 19 Dec 2018 10:37:34 -0800 Committer: Paul E. McKenney <paulmck@linux.ibm.com> CommitDate: Fri, 25 Jan 2019 15:30:00 -0800 rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() Currently, __note_gp_changes() checks to see if the rcu_node structure's ->gp_seq_needed is greater than or equal to that of the rcu_data structure, and if so, updates the rcu_data structure's ->gp_seq_needed field. This results in a useless store in the case where the two fields are equal. This commit therefore carries out this store only in the case where the rcu_node structure's ->gp_seq_needed is strictly greater than that of the rcu_data structure. Signed-off-by: "Zhang, Jun" <jun.zhang@intel.com> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> Link: https://lkml.kernel.org/r/88DC34334CA3444C85D647DBFA962C2735AD5F77@SHSMSX104.ccr.corp.intel.com --- kernel/rcu/tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 21775eebb8f0..9d0e2ac9356e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1758,7 +1758,7 @@ static bool __note_gp_changes(struct rcu_node *rnp, struct rcu_data *rdp) zero_cpu_stall_ticks(rdp); } rdp->gp_seq = rnp->gp_seq; /* Remember new grace-period state. */ - if (ULONG_CMP_GE(rnp->gp_seq_needed, rdp->gp_seq_needed) || rdp->gpwrap) + if (ULONG_CMP_LT(rdp->gp_seq_needed, rnp->gp_seq_needed) || rdp->gpwrap) rdp->gp_seq_needed = rnp->gp_seq_needed; WRITE_ONCE(rdp->gpwrap, false); rcu_gpnum_ovf(rnp, rdp); ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [tip:core/rcu] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt 2018-11-29 8:49 rcu_preempt caused oom He, Bo 2018-11-29 13:06 ` Paul E. McKenney @ 2019-02-13 8:30 ` tip-bot for Zhang, Jun 1 sibling, 0 replies; 43+ messages in thread From: tip-bot for Zhang, Jun @ 2019-02-13 8:30 UTC (permalink / raw) To: linux-tip-commits Cc: linux-kernel, mingo, bo.he, hpa, tglx, jun.zhang, jin.xiao, paulmck, jie.a.bai Commit-ID: 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Gitweb: https://git.kernel.org/tip/1d1f898df6586c5ea9aeaf349f13089c6fa37903 Author: Zhang, Jun <jun.zhang@intel.com> AuthorDate: Tue, 18 Dec 2018 06:55:01 -0800 Committer: Paul E. McKenney <paulmck@linux.ibm.com> CommitDate: Fri, 25 Jan 2019 15:29:59 -0800 rcu: Do RCU GP kthread self-wakeup from softirq and interrupt The rcu_gp_kthread_wake() function is invoked when it might be necessary to wake the RCU grace-period kthread. Because self-wakeups are normally a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from this kthread, it naturally refuses to do the wakeup. Unfortunately, natural though it might be, this heuristic fails when rcu_gp_kthread_wake() is invoked from an interrupt or softirq handler that interrupted the grace-period kthread just after the final check of the wait-event condition but just before the schedule() call. In this case, a wakeup is required, even though the call to rcu_gp_kthread_wake() is within the RCU grace-period kthread's context. Failing to provide this wakeup can result in grace periods failing to start, which in turn results in out-of-memory conditions. This race window is quite narrow, but it actually did happen during real testing. It would of course need to be fixed even if it was strictly theoretical in nature. This patch does not Cc stable because it does not apply cleanly to earlier kernel versions. Fixes: 48a7639ce80c ("rcu: Make callers awaken grace-period kthread") Reported-by: "He, Bo" <bo.he@intel.com> Co-developed-by: "Zhang, Jun" <jun.zhang@intel.com> Co-developed-by: "He, Bo" <bo.he@intel.com> Co-developed-by: "xiao, jin" <jin.xiao@intel.com> Co-developed-by: Bai, Jie A <jie.a.bai@intel.com> Signed-off: "Zhang, Jun" <jun.zhang@intel.com> Signed-off: "He, Bo" <bo.he@intel.com> Signed-off: "xiao, jin" <jin.xiao@intel.com> Signed-off: Bai, Jie A <jie.a.bai@intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang@intel.com> [ paulmck: Switch from !in_softirq() to "!in_interrupt() && !in_serving_softirq() to avoid redundant wakeups and to also handle the interrupt-handler scenario as well as the softirq-handler scenario that actually occurred in testing. ] Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com> Link: https://lkml.kernel.org/r/CD6925E8781EFD4D8E11882D20FC406D52A11F61@SHSMSX104.ccr.corp.intel.com --- kernel/rcu/tree.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9ceb93f848cd..21775eebb8f0 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1593,15 +1593,23 @@ static bool rcu_future_gp_cleanup(struct rcu_node *rnp) } /* - * Awaken the grace-period kthread. Don't do a self-awaken, and don't - * bother awakening when there is nothing for the grace-period kthread - * to do (as in several CPUs raced to awaken, and we lost), and finally - * don't try to awaken a kthread that has not yet been created. If - * all those checks are passed, track some debug information and awaken. + * Awaken the grace-period kthread. Don't do a self-awaken (unless in + * an interrupt or softirq handler), and don't bother awakening when there + * is nothing for the grace-period kthread to do (as in several CPUs raced + * to awaken, and we lost), and finally don't try to awaken a kthread that + * has not yet been created. If all those checks are passed, track some + * debug information and awaken. + * + * So why do the self-wakeup when in an interrupt or softirq handler + * in the grace-period kthread's context? Because the kthread might have + * been interrupted just as it was going to sleep, and just after the final + * pre-sleep check of the awaken condition. In this case, a wakeup really + * is required, and is therefore supplied. */ static void rcu_gp_kthread_wake(void) { - if (current == rcu_state.gp_kthread || + if ((current == rcu_state.gp_kthread && + !in_interrupt() && !in_serving_softirq()) || !READ_ONCE(rcu_state.gp_flags) || !rcu_state.gp_kthread) return; ^ permalink raw reply related [flat|nested] 43+ messages in thread
end of thread, other threads:[~2019-02-13 8:31 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-29 8:49 rcu_preempt caused oom He, Bo
2018-11-29 13:06 ` Paul E. McKenney
2018-11-29 14:27 ` Paul E. McKenney
2018-11-30 8:03 ` He, Bo
2018-11-30 14:43 ` Paul E. McKenney
2018-11-30 15:16 ` Steven Rostedt
2018-11-30 15:18 ` He, Bo
2018-11-30 16:49 ` Paul E. McKenney
2018-12-03 7:44 ` He, Bo
2018-12-03 13:56 ` Paul E. McKenney
2018-12-04 7:50 ` He, Bo
2018-12-04 19:49 ` Paul E. McKenney
2018-12-05 8:42 ` He, Bo
2018-12-05 17:44 ` Paul E. McKenney
[not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A16C46@SHSMSX104.ccr.corp.intel.com>
2018-12-06 17:38 ` Paul E. McKenney
[not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A180C5@SHSMSX104.ccr.corp.intel.com>
2018-12-07 14:11 ` Paul E. McKenney
2018-12-09 19:56 ` Paul E. McKenney
2018-12-10 6:56 ` He, Bo
2018-12-11 0:38 ` Paul E. McKenney
2018-12-11 4:46 ` Paul E. McKenney
2018-12-11 5:29 ` He, Bo
2018-12-12 1:37 ` He, Bo
2018-12-12 2:24 ` Paul E. McKenney
[not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A192C3@SHSMSX104.ccr.corp.intel.com>
2018-12-12 15:42 ` Paul E. McKenney
2018-12-12 21:03 ` Paul E. McKenney
2018-12-12 23:13 ` He, Bo
2018-12-13 0:12 ` Paul E. McKenney
2018-12-13 2:11 ` Zhang, Jun
2018-12-13 2:42 ` Paul E. McKenney
[not found] ` <88DC34334CA3444C85D647DBFA962C2735AD5F9E@SHSMSX104.ccr.corp.intel.com>
2018-12-13 4:40 ` Paul E. McKenney
[not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A197EC@SHSMSX104.ccr.corp.intel.com>
2018-12-13 18:11 ` Paul E. McKenney
2018-12-14 1:30 ` He, Bo
2018-12-14 2:15 ` Paul E. McKenney
2018-12-14 2:40 ` He, Bo
2018-12-14 5:10 ` Paul E. McKenney
2018-12-14 5:38 ` Paul E. McKenney
2018-12-17 3:15 ` He, Bo
2018-12-17 4:26 ` Paul E. McKenney
[not found] ` <CD6925E8781EFD4D8E11882D20FC406D52A1A634@SHSMSX104.ccr.corp.intel.com>
2018-12-18 2:46 ` Zhang, Jun
2018-12-18 3:12 ` He, Bo
2018-12-18 5:34 ` Paul E. McKenney
2019-02-13 8:31 ` [tip:core/rcu] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes() tip-bot for Zhang, Jun
2019-02-13 8:30 ` [tip:core/rcu] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt tip-bot for Zhang, Jun
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.