* localed stuck in recent 3.18 git in copy_net_ns? @ 2014-10-20 20:15 Kevin Fenzi 2014-10-20 20:43 ` Dave Jones 0 siblings, 1 reply; 63+ messages in thread From: Kevin Fenzi @ 2014-10-20 20:15 UTC (permalink / raw) To: netdev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2849 bytes --] Greetings. I'm seeing suspend/resume failures with recent 3.18 git kernels. Full dmesg at: http://paste.fedoraproject.org/143615/83287914/ The possibly interesting parts: [ 78.373144] PM: Syncing filesystems ... done. [ 78.411180] PM: Preparing system for mem sleep [ 78.411995] Freezing user space processes ... [ 98.429955] Freezing of tasks failed after 20.001 seconds (1 tasks refusing to freeze, wq_busy=0): [ 98.429971] (-localed) D ffff88025f214c80 0 1866 1 0x00000084 [ 98.429975] ffff88024e777df8 0000000000000086 ffff88009b4444b0 0000000000014c80 [ 98.429978] ffff88024e777fd8 0000000000014c80 ffff880250ffb110 ffff88009b4444b0 [ 98.429981] 0000000000000000 ffffffff81cec1a0 ffffffff81cec1a4 ffff88009b4444b0 [ 98.429983] Call Trace: [ 98.429991] [<ffffffff8175d619>] schedule_preempt_disabled+0x29/0x70 [ 98.429994] [<ffffffff8175f433>] __mutex_lock_slowpath+0xb3/0x120 [ 98.429997] [<ffffffff8175f4c3>] mutex_lock+0x23/0x40 [ 98.430001] [<ffffffff8163e325>] copy_net_ns+0x75/0x140 [ 98.430005] [<ffffffff810b8c2d>] create_new_namespaces+0xfd/0x1a0 [ 98.430008] [<ffffffff810b8e5a>] unshare_nsproxy_namespaces+0x5a/0xc0 [ 98.430012] [<ffffffff81098813>] SyS_unshare+0x193/0x340 [ 98.430015] [<ffffffff817617a9>] system_call_fastpath+0x12/0x17 [ 98.430032] Restarting tasks ... done. [ 98.480361] PM: Syncing filesystems ... done. [ 98.571645] PM: Preparing system for freeze sleep [ 98.571779] Freezing user space processes ... [ 118.592086] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): [ 118.592102] (-localed) D ffff88025f214c80 0 1866 1 0x00000084 [ 118.592106] ffff88024e777df8 0000000000000086 ffff88009b4444b0 0000000000014c80 [ 118.592109] ffff88024e777fd8 0000000000014c80 ffff880250ffb110 ffff88009b4444b0 [ 118.592111] 0000000000000000 ffffffff81cec1a0 ffffffff81cec1a4 ffff88009b4444b0 [ 118.592114] Call Trace: [ 118.592121] [<ffffffff8175d619>] schedule_preempt_disabled+0x29/0x70 [ 118.592125] [<ffffffff8175f433>] __mutex_lock_slowpath+0xb3/0x120 [ 118.592127] [<ffffffff8175f4c3>] mutex_lock+0x23/0x40 [ 118.592132] [<ffffffff8163e325>] copy_net_ns+0x75/0x140 [ 118.592136] [<ffffffff810b8c2d>] create_new_namespaces+0xfd/0x1a0 [ 118.592139] [<ffffffff810b8e5a>] unshare_nsproxy_namespaces+0x5a/0xc0 [ 118.592143] [<ffffffff81098813>] SyS_unshare+0x193/0x340 [ 118.592146] [<ffffffff817617a9>] system_call_fastpath+0x12/0x17 [ 118.592163] Restarting tasks ... done. root 6 0.0 0.0 0 0 ? D 13:49 0:00 [kworker/u16:0] root 1876 0.0 0.0 41460 5784 ? Ds 13:49 0:00 (-localed) I'll try and bisect this, but perhaps it rings bells already for folks. kevin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-20 20:15 localed stuck in recent 3.18 git in copy_net_ns? Kevin Fenzi @ 2014-10-20 20:43 ` Dave Jones 2014-10-20 20:53 ` Kevin Fenzi 0 siblings, 1 reply; 63+ messages in thread From: Dave Jones @ 2014-10-20 20:43 UTC (permalink / raw) To: Kevin Fenzi; +Cc: netdev, linux-kernel On Mon, Oct 20, 2014 at 02:15:15PM -0600, Kevin Fenzi wrote: > I'm seeing suspend/resume failures with recent 3.18 git kernels. > > Full dmesg at: http://paste.fedoraproject.org/143615/83287914/ > > The possibly interesting parts: > > [ 78.373144] PM: Syncing filesystems ... done. > [ 78.411180] PM: Preparing system for mem sleep > [ 78.411995] Freezing user space processes ... > [ 98.429955] Freezing of tasks failed after 20.001 seconds (1 tasks refusing to freeze, wq_busy=0): > [ 98.429971] (-localed) D ffff88025f214c80 0 1866 1 0x00000084 > [ 98.429975] ffff88024e777df8 0000000000000086 ffff88009b4444b0 0000000000014c80 > [ 98.429978] ffff88024e777fd8 0000000000014c80 ffff880250ffb110 ffff88009b4444b0 > [ 98.429981] 0000000000000000 ffffffff81cec1a0 ffffffff81cec1a4 ffff88009b4444b0 > [ 98.429983] Call Trace: > [ 98.429991] [<ffffffff8175d619>] schedule_preempt_disabled+0x29/0x70 > [ 98.429994] [<ffffffff8175f433>] __mutex_lock_slowpath+0xb3/0x120 > [ 98.429997] [<ffffffff8175f4c3>] mutex_lock+0x23/0x40 > [ 98.430001] [<ffffffff8163e325>] copy_net_ns+0x75/0x140 > [ 98.430005] [<ffffffff810b8c2d>] create_new_namespaces+0xfd/0x1a0 > [ 98.430008] [<ffffffff810b8e5a>] unshare_nsproxy_namespaces+0x5a/0xc0 > [ 98.430012] [<ffffffff81098813>] SyS_unshare+0x193/0x340 > [ 98.430015] [<ffffffff817617a9>] system_call_fastpath+0x12/0x17 I've seen similar soft lockup traces from the sys_unshare path when running my fuzz tester. It seems that if you create enough network namespaces, it can take a huge amount of time for them to be iterated. (Running trinity with '-c unshare' you can see the slow down happen. In some cases, it takes so long that the watchdog process kills it -- though the SIGKILL won't get delivered until the unshare() completes) Any idea what this machine had been doing prior to this that may have involved creating lots of namespaces ? Dave ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-20 20:43 ` Dave Jones @ 2014-10-20 20:53 ` Kevin Fenzi 2014-10-21 21:12 ` Kevin Fenzi 0 siblings, 1 reply; 63+ messages in thread From: Kevin Fenzi @ 2014-10-20 20:53 UTC (permalink / raw) To: Dave Jones; +Cc: netdev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 752 bytes --] On Mon, 20 Oct 2014 16:43:26 -0400 Dave Jones <davej@redhat.com> wrote: > I've seen similar soft lockup traces from the sys_unshare path when > running my fuzz tester. It seems that if you create enough network > namespaces, it can take a huge amount of time for them to be iterated. > (Running trinity with '-c unshare' you can see the slow down happen. > In some cases, it takes so long that the watchdog process kills it -- > though the SIGKILL won't get delivered until the unshare() completes) > > Any idea what this machine had been doing prior to this that may have > involved creating lots of namespaces ? That was right after boot. ;) This is my main rawhide running laptop. A 'ip netns list' shows nothing. kevin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-20 20:53 ` Kevin Fenzi @ 2014-10-21 21:12 ` Kevin Fenzi 2014-10-22 17:12 ` Josh Boyer 0 siblings, 1 reply; 63+ messages in thread From: Kevin Fenzi @ 2014-10-21 21:12 UTC (permalink / raw) To: netdev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2006 bytes --] On Mon, 20 Oct 2014 14:53:59 -0600 Kevin Fenzi <kevin@scrye.com> wrote: > On Mon, 20 Oct 2014 16:43:26 -0400 > Dave Jones <davej@redhat.com> wrote: > > > I've seen similar soft lockup traces from the sys_unshare path when > > running my fuzz tester. It seems that if you create enough network > > namespaces, it can take a huge amount of time for them to be > > iterated. (Running trinity with '-c unshare' you can see the slow > > down happen. In some cases, it takes so long that the watchdog > > process kills it -- though the SIGKILL won't get delivered until > > the unshare() completes) > > > > Any idea what this machine had been doing prior to this that may > > have involved creating lots of namespaces ? > > That was right after boot. ;) > > This is my main rawhide running laptop. > > A 'ip netns list' shows nothing. Some more information: The problem started between: v3.17-7872-g5ff0b9e1a1da and v3.17-8307-gf1d0d14120a8 (I can try and do a bisect, but have to head out on a trip tomorrow) In all the kernels with the problem, there is a kworker process in D. sysrq-t says: Showing all locks held in the system: Oct 21 15:06:31 voldemort.scrye.com kernel: 4 locks held by kworker/u16:0/6: Oct 21 15:06:31 voldemort.scrye.com kernel: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850 Oct 21 15:06:31 voldemort.scrye.com kernel: #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850 Oct 21 15:06:31 voldemort.scrye.com kernel: #2: (net_mutex){+.+.+.}, at: [<ffffffff817069fc>] cleanup_net+0x8c/0x1f0 Oct 21 15:06:31 voldemort.scrye.com kernel: #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a395>] _rcu_barrier+0x35/0x200 On first running any of the systemd units that use PrivateNetwork, then run ok, but they are also set to timeout after a minute. On sucessive runs they hang in D also. kevin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-21 21:12 ` Kevin Fenzi @ 2014-10-22 17:12 ` Josh Boyer 2014-10-22 17:37 ` Cong Wang 0 siblings, 1 reply; 63+ messages in thread From: Josh Boyer @ 2014-10-22 17:12 UTC (permalink / raw) To: Kevin Fenzi; +Cc: netdev, Linux-Kernel@Vger. Kernel. Org On Tue, Oct 21, 2014 at 5:12 PM, Kevin Fenzi <kevin@scrye.com> wrote: > On Mon, 20 Oct 2014 14:53:59 -0600 > Kevin Fenzi <kevin@scrye.com> wrote: > >> On Mon, 20 Oct 2014 16:43:26 -0400 >> Dave Jones <davej@redhat.com> wrote: >> >> > I've seen similar soft lockup traces from the sys_unshare path when >> > running my fuzz tester. It seems that if you create enough network >> > namespaces, it can take a huge amount of time for them to be >> > iterated. (Running trinity with '-c unshare' you can see the slow >> > down happen. In some cases, it takes so long that the watchdog >> > process kills it -- though the SIGKILL won't get delivered until >> > the unshare() completes) >> > >> > Any idea what this machine had been doing prior to this that may >> > have involved creating lots of namespaces ? >> >> That was right after boot. ;) >> >> This is my main rawhide running laptop. >> >> A 'ip netns list' shows nothing. > > Some more information: > > The problem started between: > > v3.17-7872-g5ff0b9e1a1da and v3.17-8307-gf1d0d14120a8 > > (I can try and do a bisect, but have to head out on a trip tomorrow) > > In all the kernels with the problem, there is a kworker process in D. > > sysrq-t says: > Showing all locks held in the system: > Oct 21 15:06:31 voldemort.scrye.com kernel: 4 locks held by kworker/u16:0/6: > Oct 21 15:06:31 voldemort.scrye.com kernel: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850 > Oct 21 15:06:31 voldemort.scrye.com kernel: #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccbff>] process_one_work+0x17f/0x850 > Oct 21 15:06:31 voldemort.scrye.com kernel: #2: (net_mutex){+.+.+.}, at: [<ffffffff817069fc>] cleanup_net+0x8c/0x1f0 > Oct 21 15:06:31 voldemort.scrye.com kernel: #3: > (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a395>] > _rcu_barrier+0x35/0x200 > > On first running any of the systemd units that use PrivateNetwork, then > run ok, but they are also set to timeout after a minute. On sucessive > runs they hang in D also. Someone else is seeing this when they try and modprobe ppp_generic: [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 [ 240.599744] Workqueue: netns cleanup_net [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 00000000001d5f00 [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 ffff8802202db480 [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 ffffffff81ee2690 [ 240.600386] Call Trace: [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 [ 240.603224] 4 locks held by kworker/u16:5/100: [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] cleanup_net+0x8c/0x1f0 [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 00000000001d5f00 [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 ffff8800cb4f1a40 [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 ffff8800cb4f1a40 [ 240.605228] Call Trace: [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 [ 240.606773] 1 lock held by modprobe/1387: [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 00000000001d5f00 [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 ffff88020fbab480 [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 ffff88020fbab480 [ 240.608138] Call Trace: [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 [ 240.609677] 1 lock held by modprobe/1466: [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 Looks like contention on net_mutex or something, but I honestly have no idea yet. I can't recreate it myself at the moment or I would bisect. Has nobody else run into this with the pre-3.18 kernels? Fedora isn't carrying any patches in this area. josh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:12 ` Josh Boyer @ 2014-10-22 17:37 ` Cong Wang 2014-10-22 17:49 ` Josh Boyer ` (2 more replies) 0 siblings, 3 replies; 63+ messages in thread From: Cong Wang @ 2014-10-22 17:37 UTC (permalink / raw) To: Josh Boyer Cc: Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, Paul McKenney, Eric W. Biederman (Adding Paul and Eric in Cc) I am not aware of any change in net/core/dev.c related here, so I guess it's a bug in rcu_barrier(). Thanks. On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > > Someone else is seeing this when they try and modprobe ppp_generic: > > [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. > [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 > [ 240.599744] Workqueue: netns cleanup_net > [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 > 00000000001d5f00 > [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 > ffff8802202db480 > [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 > ffffffff81ee2690 > [ 240.600386] Call Trace: > [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 > [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 > [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 > [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 > [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 > [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 > [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 > [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 > [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 > [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 > [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 > [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 > [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 > [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 > [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 > [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 > [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 > [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 > [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 > [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 > [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 > [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 > [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > [ 240.603224] 4 locks held by kworker/u16:5/100: > [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] > process_one_work+0x17f/0x850 > [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: > [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 > [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] > cleanup_net+0x8c/0x1f0 > [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: > [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 > [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. > [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 > [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 > 00000000001d5f00 > [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 > ffff8800cb4f1a40 > [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 > ffff8800cb4f1a40 > [ 240.605228] Call Trace: > [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 > [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 > [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] > [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > [ 240.606773] 1 lock held by modprobe/1387: > [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] > register_pernet_subsys+0x1f/0x50 > [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. > [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 > [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 > 00000000001d5f00 > [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 > ffff88020fbab480 > [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 > ffff88020fbab480 > [ 240.608138] Call Trace: > [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 > [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 > [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] > [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > [ 240.609677] 1 lock held by modprobe/1466: > [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] > register_pernet_device+0x1d/0x70 > > Looks like contention on net_mutex or something, but I honestly have > no idea yet. I can't recreate it myself at the moment or I would > bisect. > > Has nobody else run into this with the pre-3.18 kernels? Fedora isn't > carrying any patches in this area. > > josh > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:37 ` Cong Wang @ 2014-10-22 17:49 ` Josh Boyer 2014-10-22 17:53 ` Eric W. Biederman 2014-10-22 17:59 ` Paul E. McKenney 2 siblings, 0 replies; 63+ messages in thread From: Josh Boyer @ 2014-10-22 17:49 UTC (permalink / raw) To: Cong Wang Cc: Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, Paul McKenney, Eric W. Biederman On Wed, Oct 22, 2014 at 1:37 PM, Cong Wang <cwang@twopensource.com> wrote: > (Adding Paul and Eric in Cc) > > I am not aware of any change in net/core/dev.c related here, > so I guess it's a bug in rcu_barrier(). Possibly. The person that reported the issue below said it showed up between Linux v3.17-7872-g5ff0b9e1a1da and Linux v3.17-8307-gf1d0d14120a8 for them. Which is a slightly older window than the on that Kevin reported. I haven't had a chance to dig through the commits yet. josh > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> >> Someone else is seeing this when they try and modprobe ppp_generic: >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 >> [ 240.599744] Workqueue: netns cleanup_net >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 >> 00000000001d5f00 >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 >> ffff8802202db480 >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 >> ffffffff81ee2690 >> [ 240.600386] Call Trace: >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> [ 240.603224] 4 locks held by kworker/u16:5/100: >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] >> process_one_work+0x17f/0x850 >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] >> cleanup_net+0x8c/0x1f0 >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 >> 00000000001d5f00 >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 >> ffff8800cb4f1a40 >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 >> ffff8800cb4f1a40 >> [ 240.605228] Call Trace: >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> [ 240.606773] 1 lock held by modprobe/1387: >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] >> register_pernet_subsys+0x1f/0x50 >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 >> 00000000001d5f00 >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 >> ffff88020fbab480 >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 >> ffff88020fbab480 >> [ 240.608138] Call Trace: >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> [ 240.609677] 1 lock held by modprobe/1466: >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] >> register_pernet_device+0x1d/0x70 >> >> Looks like contention on net_mutex or something, but I honestly have >> no idea yet. I can't recreate it myself at the moment or I would >> bisect. >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't >> carrying any patches in this area. >> >> josh >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:37 ` Cong Wang 2014-10-22 17:49 ` Josh Boyer @ 2014-10-22 17:53 ` Eric W. Biederman 2014-10-22 18:11 ` Paul E. McKenney 2014-10-22 17:59 ` Paul E. McKenney 2 siblings, 1 reply; 63+ messages in thread From: Eric W. Biederman @ 2014-10-22 17:53 UTC (permalink / raw) To: Cong Wang Cc: Josh Boyer, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, Paul McKenney Cong Wang <cwang@twopensource.com> writes: > (Adding Paul and Eric in Cc) > > > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> >> Someone else is seeing this when they try and modprobe ppp_generic: >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 >> [ 240.599744] Workqueue: netns cleanup_net >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 >> 00000000001d5f00 >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 >> ffff8802202db480 >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 >> ffffffff81ee2690 >> [ 240.600386] Call Trace: >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> [ 240.603224] 4 locks held by kworker/u16:5/100: >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] >> process_one_work+0x17f/0x850 >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] >> cleanup_net+0x8c/0x1f0 >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 >> 00000000001d5f00 >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 >> ffff8800cb4f1a40 >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 >> ffff8800cb4f1a40 >> [ 240.605228] Call Trace: >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> [ 240.606773] 1 lock held by modprobe/1387: >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] >> register_pernet_subsys+0x1f/0x50 >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 >> 00000000001d5f00 >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 >> ffff88020fbab480 >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 >> ffff88020fbab480 >> [ 240.608138] Call Trace: >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> [ 240.609677] 1 lock held by modprobe/1466: >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] >> register_pernet_device+0x1d/0x70 >> >> Looks like contention on net_mutex or something, but I honestly have >> no idea yet. I can't recreate it myself at the moment or I would >> bisect. >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't >> carrying any patches in this area. > I am not aware of any change in net/core/dev.c related here, > so I guess it's a bug in rcu_barrier(). >From the limited trace data I see in this email I have to agree. It looks like for some reason rcu_barrier is taking forever while the rtnl_lock is held in cleanup_net. Because the rtnl_lock is held modprobe of the ppp driver is getting stuck. Is it possible we have an AB BA deadlock between the rtnl_lock and rcu. With something the module loading code assumes? Eric ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:53 ` Eric W. Biederman @ 2014-10-22 18:11 ` Paul E. McKenney 2014-10-22 18:25 ` Eric W. Biederman 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-22 18:11 UTC (permalink / raw) To: Eric W. Biederman Cc: Cong Wang, Josh Boyer, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote: > Cong Wang <cwang@twopensource.com> writes: > > > (Adding Paul and Eric in Cc) > > > > > > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > >> > >> Someone else is seeing this when they try and modprobe ppp_generic: > >> > >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. > >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> disables this message. > >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 > >> [ 240.599744] Workqueue: netns cleanup_net > >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 > >> 00000000001d5f00 > >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 > >> ffff8802202db480 > >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 > >> ffffffff81ee2690 > >> [ 240.600386] Call Trace: > >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 > >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 > >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 > >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 > >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 > >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 > >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 > >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 > >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 > >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 > >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 > >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 > >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 > >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 > >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 > >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 > >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 > >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 > >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 > >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 > >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 > >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 > >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> [ 240.603224] 4 locks held by kworker/u16:5/100: > >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] > >> process_one_work+0x17f/0x850 > >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: > >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 > >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] > >> cleanup_net+0x8c/0x1f0 > >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: > >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 > >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. > >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> disables this message. > >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 > >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 > >> 00000000001d5f00 > >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 > >> ffff8800cb4f1a40 > >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 > >> ffff8800cb4f1a40 > >> [ 240.605228] Call Trace: > >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 > >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 > >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] > >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> [ 240.606773] 1 lock held by modprobe/1387: > >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] > >> register_pernet_subsys+0x1f/0x50 > >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. > >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> disables this message. > >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 > >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 > >> 00000000001d5f00 > >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 > >> ffff88020fbab480 > >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 > >> ffff88020fbab480 > >> [ 240.608138] Call Trace: > >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 > >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 > >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] > >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> [ 240.609677] 1 lock held by modprobe/1466: > >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] > >> register_pernet_device+0x1d/0x70 > >> > >> Looks like contention on net_mutex or something, but I honestly have > >> no idea yet. I can't recreate it myself at the moment or I would > >> bisect. > >> > >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't > >> carrying any patches in this area. > > > I am not aware of any change in net/core/dev.c related here, > > so I guess it's a bug in rcu_barrier(). > > >From the limited trace data I see in this email I have to agree. > > It looks like for some reason rcu_barrier is taking forever > while the rtnl_lock is held in cleanup_net. Because the > rtnl_lock is held modprobe of the ppp driver is getting stuck. > > Is it possible we have an AB BA deadlock between the rtnl_lock > and rcu. With something the module loading code assumes? I am not aware of RCU ever acquiring rtnl_lock, not directly, anyway. Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 18:11 ` Paul E. McKenney @ 2014-10-22 18:25 ` Eric W. Biederman 2014-10-22 18:55 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Eric W. Biederman @ 2014-10-22 18:25 UTC (permalink / raw) To: paulmck Cc: Cong Wang, Josh Boyer, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes: > On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote: >> Cong Wang <cwang@twopensource.com> writes: >> >> > (Adding Paul and Eric in Cc) >> > >> > >> > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> >> >> >> Someone else is seeing this when they try and modprobe ppp_generic: >> >> >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. >> >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> disables this message. >> >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 >> >> [ 240.599744] Workqueue: netns cleanup_net >> >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 >> >> 00000000001d5f00 >> >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 >> >> ffff8802202db480 >> >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 >> >> ffffffff81ee2690 >> >> [ 240.600386] Call Trace: >> >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 >> >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 >> >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 >> >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 >> >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 >> >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 >> >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 >> >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 >> >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 >> >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 >> >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 >> >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 >> >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 >> >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 >> >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 >> >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 >> >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 >> >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 >> >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 >> >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 >> >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 >> >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 >> >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 >> >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> >> [ 240.603224] 4 locks held by kworker/u16:5/100: >> >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] >> >> process_one_work+0x17f/0x850 >> >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: >> >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 >> >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] >> >> cleanup_net+0x8c/0x1f0 >> >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: >> >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 >> >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. >> >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> disables this message. >> >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 >> >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 >> >> 00000000001d5f00 >> >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 >> >> ffff8800cb4f1a40 >> >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 >> >> ffff8800cb4f1a40 >> >> [ 240.605228] Call Trace: >> >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 >> >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 >> >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] >> >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> >> [ 240.606773] 1 lock held by modprobe/1387: >> >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] >> >> register_pernet_subsys+0x1f/0x50 >> >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. >> >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> disables this message. >> >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 >> >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 >> >> 00000000001d5f00 >> >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 >> >> ffff88020fbab480 >> >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 >> >> ffff88020fbab480 >> >> [ 240.608138] Call Trace: >> >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 >> >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 >> >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] >> >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> >> [ 240.609677] 1 lock held by modprobe/1466: >> >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] >> >> register_pernet_device+0x1d/0x70 >> >> >> >> Looks like contention on net_mutex or something, but I honestly have >> >> no idea yet. I can't recreate it myself at the moment or I would >> >> bisect. >> >> >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't >> >> carrying any patches in this area. >> >> > I am not aware of any change in net/core/dev.c related here, >> > so I guess it's a bug in rcu_barrier(). >> >> >From the limited trace data I see in this email I have to agree. >> >> It looks like for some reason rcu_barrier is taking forever >> while the rtnl_lock is held in cleanup_net. Because the >> rtnl_lock is held modprobe of the ppp driver is getting stuck. >> >> Is it possible we have an AB BA deadlock between the rtnl_lock >> and rcu. With something the module loading code assumes? > > I am not aware of RCU ever acquiring rtnl_lock, not directly, anyway. Does the module loading code do something strange with rcu? Perhaps blocking an rcu grace period until the module loading completes? If the module loading somehow blocks an rcu grace period that would create an AB deadlock because loading the ppp module grabs the rtnl_lock. And elsewhere we have the rtnl_lock waiting for an rcu grace period. I would think trying and failing to get the rtnl_lock would sleep and thus let any rcu grace period happen but shrug. It looks like something is holding up the rcu grace period, and causing this. Although it is possible that something is causing cleanup_net to run slowly and we are just seeing that slowness show up in rcu_barrier as that is one of the slower bits. With a single trace I can't definitely same that the rcu barrier is getting stuck but it certainly looks that way. Eric ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 18:25 ` Eric W. Biederman @ 2014-10-22 18:55 ` Paul E. McKenney 2014-10-22 19:33 ` Josh Boyer 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-22 18:55 UTC (permalink / raw) To: Eric W. Biederman Cc: Cong Wang, Josh Boyer, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Wed, Oct 22, 2014 at 01:25:37PM -0500, Eric W. Biederman wrote: > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes: > > > On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote: > >> Cong Wang <cwang@twopensource.com> writes: > >> > >> > (Adding Paul and Eric in Cc) > >> > > >> > > >> > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > >> >> > >> >> Someone else is seeing this when they try and modprobe ppp_generic: > >> >> > >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. > >> >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> disables this message. > >> >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 > >> >> [ 240.599744] Workqueue: netns cleanup_net > >> >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 > >> >> 00000000001d5f00 > >> >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 > >> >> ffff8802202db480 > >> >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 > >> >> ffffffff81ee2690 > >> >> [ 240.600386] Call Trace: > >> >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 > >> >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 > >> >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 > >> >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 > >> >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 > >> >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 > >> >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 > >> >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 > >> >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 > >> >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 > >> >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 > >> >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 > >> >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 > >> >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 > >> >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 > >> >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 > >> >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 > >> >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 > >> >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 > >> >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 > >> >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 > >> >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > >> >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 > >> >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> >> [ 240.603224] 4 locks held by kworker/u16:5/100: > >> >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] > >> >> process_one_work+0x17f/0x850 > >> >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: > >> >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 > >> >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] > >> >> cleanup_net+0x8c/0x1f0 > >> >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: > >> >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 > >> >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. > >> >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> disables this message. > >> >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 > >> >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 > >> >> 00000000001d5f00 > >> >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 > >> >> ffff8800cb4f1a40 > >> >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 > >> >> ffff8800cb4f1a40 > >> >> [ 240.605228] Call Trace: > >> >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 > >> >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 > >> >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] > >> >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> >> [ 240.606773] 1 lock held by modprobe/1387: > >> >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] > >> >> register_pernet_subsys+0x1f/0x50 > >> >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. > >> >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> disables this message. > >> >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 > >> >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 > >> >> 00000000001d5f00 > >> >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 > >> >> ffff88020fbab480 > >> >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 > >> >> ffff88020fbab480 > >> >> [ 240.608138] Call Trace: > >> >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 > >> >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 > >> >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] > >> >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> >> [ 240.609677] 1 lock held by modprobe/1466: > >> >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] > >> >> register_pernet_device+0x1d/0x70 > >> >> > >> >> Looks like contention on net_mutex or something, but I honestly have > >> >> no idea yet. I can't recreate it myself at the moment or I would > >> >> bisect. > >> >> > >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't > >> >> carrying any patches in this area. > >> > >> > I am not aware of any change in net/core/dev.c related here, > >> > so I guess it's a bug in rcu_barrier(). > >> > >> >From the limited trace data I see in this email I have to agree. > >> > >> It looks like for some reason rcu_barrier is taking forever > >> while the rtnl_lock is held in cleanup_net. Because the > >> rtnl_lock is held modprobe of the ppp driver is getting stuck. > >> > >> Is it possible we have an AB BA deadlock between the rtnl_lock > >> and rcu. With something the module loading code assumes? > > > > I am not aware of RCU ever acquiring rtnl_lock, not directly, anyway. > > Does the module loading code do something strange with rcu? Perhaps > blocking an rcu grace period until the module loading completes? > > If the module loading somehow blocks an rcu grace period that would > create an AB deadlock because loading the ppp module grabs the > rtnl_lock. And elsewhere we have the rtnl_lock waiting for an rcu grace > period. > > I would think trying and failing to get the rtnl_lock would sleep and > thus let any rcu grace period happen but shrug. > > It looks like something is holding up the rcu grace period, and causing > this. Although it is possible that something is causing cleanup_net > to run slowly and we are just seeing that slowness show up in > rcu_barrier as that is one of the slower bits. With a single trace I > can't definitely same that the rcu barrier is getting stuck but it > certainly looks that way. Don't get me wrong -- the fact that this kthread appears to have blocked within rcu_barrier() for 120 seconds means that something is most definitely wrong here. I am surprised that there are no RCU CPU stall warnings, but perhaps the blockage is in the callback execution rather than grace-period completion. Or something is preventing this kthread from starting up after the wake-up callback executes. Or... Is this thing reproducible? Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 18:55 ` Paul E. McKenney @ 2014-10-22 19:33 ` Josh Boyer 2014-10-22 22:40 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Josh Boyer @ 2014-10-22 19:33 UTC (permalink / raw) To: Paul McKenney Cc: Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, yaneti On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Oct 22, 2014 at 01:25:37PM -0500, Eric W. Biederman wrote: >> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes: >> >> > On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote: >> >> Cong Wang <cwang@twopensource.com> writes: >> >> >> >> > (Adding Paul and Eric in Cc) >> >> > >> >> > >> >> > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> >> >> >> >> >> Someone else is seeing this when they try and modprobe ppp_generic: >> >> >> >> >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. >> >> >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> >> disables this message. >> >> >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 >> >> >> [ 240.599744] Workqueue: netns cleanup_net >> >> >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 >> >> >> 00000000001d5f00 >> >> >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 >> >> >> ffff8802202db480 >> >> >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 >> >> >> ffffffff81ee2690 >> >> >> [ 240.600386] Call Trace: >> >> >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 >> >> >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 >> >> >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 >> >> >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 >> >> >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 >> >> >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 >> >> >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 >> >> >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 >> >> >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 >> >> >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 >> >> >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 >> >> >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 >> >> >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 >> >> >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 >> >> >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 >> >> >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 >> >> >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 >> >> >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 >> >> >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 >> >> >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 >> >> >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 >> >> >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 >> >> >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> >> >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 >> >> >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> >> >> [ 240.603224] 4 locks held by kworker/u16:5/100: >> >> >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] >> >> >> process_one_work+0x17f/0x850 >> >> >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: >> >> >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 >> >> >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] >> >> >> cleanup_net+0x8c/0x1f0 >> >> >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: >> >> >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 >> >> >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. >> >> >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> >> disables this message. >> >> >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 >> >> >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 >> >> >> 00000000001d5f00 >> >> >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 >> >> >> ffff8800cb4f1a40 >> >> >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 >> >> >> ffff8800cb4f1a40 >> >> >> [ 240.605228] Call Trace: >> >> >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> >> >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> >> >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> >> >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> >> >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 >> >> >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 >> >> >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] >> >> >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> >> >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> >> >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> >> >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> >> >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> >> >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> >> >> [ 240.606773] 1 lock held by modprobe/1387: >> >> >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] >> >> >> register_pernet_subsys+0x1f/0x50 >> >> >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. >> >> >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> >> >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> >> >> disables this message. >> >> >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 >> >> >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 >> >> >> 00000000001d5f00 >> >> >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 >> >> >> ffff88020fbab480 >> >> >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 >> >> >> ffff88020fbab480 >> >> >> [ 240.608138] Call Trace: >> >> >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> >> >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> >> >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> >> >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> >> >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 >> >> >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 >> >> >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] >> >> >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> >> >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> >> >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> >> >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> >> >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> >> >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> >> >> [ 240.609677] 1 lock held by modprobe/1466: >> >> >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] >> >> >> register_pernet_device+0x1d/0x70 >> >> >> >> >> >> Looks like contention on net_mutex or something, but I honestly have >> >> >> no idea yet. I can't recreate it myself at the moment or I would >> >> >> bisect. >> >> >> >> >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't >> >> >> carrying any patches in this area. >> >> >> >> > I am not aware of any change in net/core/dev.c related here, >> >> > so I guess it's a bug in rcu_barrier(). >> >> >> >> >From the limited trace data I see in this email I have to agree. >> >> >> >> It looks like for some reason rcu_barrier is taking forever >> >> while the rtnl_lock is held in cleanup_net. Because the >> >> rtnl_lock is held modprobe of the ppp driver is getting stuck. >> >> >> >> Is it possible we have an AB BA deadlock between the rtnl_lock >> >> and rcu. With something the module loading code assumes? >> > >> > I am not aware of RCU ever acquiring rtnl_lock, not directly, anyway. >> >> Does the module loading code do something strange with rcu? Perhaps >> blocking an rcu grace period until the module loading completes? >> >> If the module loading somehow blocks an rcu grace period that would >> create an AB deadlock because loading the ppp module grabs the >> rtnl_lock. And elsewhere we have the rtnl_lock waiting for an rcu grace >> period. >> >> I would think trying and failing to get the rtnl_lock would sleep and >> thus let any rcu grace period happen but shrug. >> >> It looks like something is holding up the rcu grace period, and causing >> this. Although it is possible that something is causing cleanup_net >> to run slowly and we are just seeing that slowness show up in >> rcu_barrier as that is one of the slower bits. With a single trace I >> can't definitely same that the rcu barrier is getting stuck but it >> certainly looks that way. > > Don't get me wrong -- the fact that this kthread appears to have > blocked within rcu_barrier() for 120 seconds means that something is > most definitely wrong here. I am surprised that there are no RCU CPU > stall warnings, but perhaps the blockage is in the callback execution > rather than grace-period completion. Or something is preventing this > kthread from starting up after the wake-up callback executes. Or... > > Is this thing reproducible? I've added Yanko on CC, who reported the backtrace above and can recreate it reliably. Apparently reverting the RCU merge commit (d6dd50e) and rebuilding the latest after that does not show the issue. I'll let Yanko explain more and answer any questions you have. josh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 19:33 ` Josh Boyer @ 2014-10-22 22:40 ` Yanko Kaneti 2014-10-22 23:24 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-22 22:40 UTC (permalink / raw) To: Josh Boyer Cc: Paul McKenney, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Oct 22, 2014 at 01:25:37PM -0500, Eric W. Biederman wrote: > >> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes: > >> > >> > On Wed, Oct 22, 2014 at 12:53:24PM -0500, Eric W. Biederman wrote: > >> >> Cong Wang <cwang@twopensource.com> writes: > >> >> > >> >> > (Adding Paul and Eric in Cc) > >> >> > > >> >> > > >> >> > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > >> >> >> > >> >> >> Someone else is seeing this when they try and modprobe ppp_generic: > >> >> >> > >> >> >> [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. > >> >> >> [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> >> [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> >> disables this message. > >> >> >> [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 > >> >> >> [ 240.599744] Workqueue: netns cleanup_net > >> >> >> [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 > >> >> >> 00000000001d5f00 > >> >> >> [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 > >> >> >> ffff8802202db480 > >> >> >> [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 > >> >> >> ffffffff81ee2690 > >> >> >> [ 240.600386] Call Trace: > >> >> >> [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 > >> >> >> [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 > >> >> >> [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 > >> >> >> [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 > >> >> >> [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 > >> >> >> [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 > >> >> >> [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 > >> >> >> [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 > >> >> >> [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 > >> >> >> [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 > >> >> >> [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 > >> >> >> [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 > >> >> >> [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 > >> >> >> [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 > >> >> >> [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 > >> >> >> [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 > >> >> >> [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 > >> >> >> [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 > >> >> >> [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 > >> >> >> [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 > >> >> >> [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 > >> >> >> [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > >> >> >> [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> >> >> [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 > >> >> >> [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > >> >> >> [ 240.603224] 4 locks held by kworker/u16:5/100: > >> >> >> [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] > >> >> >> process_one_work+0x17f/0x850 > >> >> >> [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: > >> >> >> [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 > >> >> >> [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] > >> >> >> cleanup_net+0x8c/0x1f0 > >> >> >> [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: > >> >> >> [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 > >> >> >> [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. > >> >> >> [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> >> [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> >> disables this message. > >> >> >> [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 > >> >> >> [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 > >> >> >> 00000000001d5f00 > >> >> >> [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 > >> >> >> ffff8800cb4f1a40 > >> >> >> [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 > >> >> >> ffff8800cb4f1a40 > >> >> >> [ 240.605228] Call Trace: > >> >> >> [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> >> >> [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> >> >> [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> >> >> [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > >> >> >> [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 > >> >> >> [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 > >> >> >> [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] > >> >> >> [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> >> >> [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> >> >> [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> >> >> [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> >> >> [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> >> >> [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> >> >> [ 240.606773] 1 lock held by modprobe/1387: > >> >> >> [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] > >> >> >> register_pernet_subsys+0x1f/0x50 > >> >> >> [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. > >> >> >> [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > >> >> >> [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > >> >> >> disables this message. > >> >> >> [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 > >> >> >> [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 > >> >> >> 00000000001d5f00 > >> >> >> [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 > >> >> >> ffff88020fbab480 > >> >> >> [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 > >> >> >> ffff88020fbab480 > >> >> >> [ 240.608138] Call Trace: > >> >> >> [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > >> >> >> [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > >> >> >> [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> >> >> [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > >> >> >> [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 > >> >> >> [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 > >> >> >> [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] > >> >> >> [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> >> >> [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > >> >> >> [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > >> >> >> [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > >> >> >> [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > >> >> >> [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > >> >> >> [ 240.609677] 1 lock held by modprobe/1466: > >> >> >> [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] > >> >> >> register_pernet_device+0x1d/0x70 > >> >> >> > >> >> >> Looks like contention on net_mutex or something, but I honestly have > >> >> >> no idea yet. I can't recreate it myself at the moment or I would > >> >> >> bisect. > >> >> >> > >> >> >> Has nobody else run into this with the pre-3.18 kernels? Fedora isn't > >> >> >> carrying any patches in this area. > >> >> > >> >> > I am not aware of any change in net/core/dev.c related here, > >> >> > so I guess it's a bug in rcu_barrier(). > >> >> > >> >> >From the limited trace data I see in this email I have to agree. > >> >> > >> >> It looks like for some reason rcu_barrier is taking forever > >> >> while the rtnl_lock is held in cleanup_net. Because the > >> >> rtnl_lock is held modprobe of the ppp driver is getting stuck. > >> >> > >> >> Is it possible we have an AB BA deadlock between the rtnl_lock > >> >> and rcu. With something the module loading code assumes? > >> > > >> > I am not aware of RCU ever acquiring rtnl_lock, not directly, anyway. > >> > >> Does the module loading code do something strange with rcu? Perhaps > >> blocking an rcu grace period until the module loading completes? > >> > >> If the module loading somehow blocks an rcu grace period that would > >> create an AB deadlock because loading the ppp module grabs the > >> rtnl_lock. And elsewhere we have the rtnl_lock waiting for an rcu grace > >> period. > >> > >> I would think trying and failing to get the rtnl_lock would sleep and > >> thus let any rcu grace period happen but shrug. > >> > >> It looks like something is holding up the rcu grace period, and causing > >> this. Although it is possible that something is causing cleanup_net > >> to run slowly and we are just seeing that slowness show up in > >> rcu_barrier as that is one of the slower bits. With a single trace I > >> can't definitely same that the rcu barrier is getting stuck but it > >> certainly looks that way. > > > > Don't get me wrong -- the fact that this kthread appears to have > > blocked within rcu_barrier() for 120 seconds means that something is > > most definitely wrong here. I am surprised that there are no RCU CPU > > stall warnings, but perhaps the blockage is in the callback execution > > rather than grace-period completion. Or something is preventing this > > kthread from starting up after the wake-up callback executes. Or... > > > > Is this thing reproducible? > > I've added Yanko on CC, who reported the backtrace above and can > recreate it reliably. Apparently reverting the RCU merge commit > (d6dd50e) and rebuilding the latest after that does not show the > issue. I'll let Yanko explain more and answer any questions you have. - It is reproducible - I've done another build here to double check and its definitely the rcu merge that's causing it. Don't think I'll be able to dig deeper, but I can do testing if needed. --Yanko ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 22:40 ` Yanko Kaneti @ 2014-10-22 23:24 ` Paul E. McKenney 2014-10-23 6:09 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-22 23:24 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > <paulmck@linux.vnet.ibm.com> wrote: [ . . . ] > > > Don't get me wrong -- the fact that this kthread appears to have > > > blocked within rcu_barrier() for 120 seconds means that something is > > > most definitely wrong here. I am surprised that there are no RCU CPU > > > stall warnings, but perhaps the blockage is in the callback execution > > > rather than grace-period completion. Or something is preventing this > > > kthread from starting up after the wake-up callback executes. Or... > > > > > > Is this thing reproducible? > > > > I've added Yanko on CC, who reported the backtrace above and can > > recreate it reliably. Apparently reverting the RCU merge commit > > (d6dd50e) and rebuilding the latest after that does not show the > > issue. I'll let Yanko explain more and answer any questions you have. > > - It is reproducible > - I've done another build here to double check and its definitely the rcu merge > that's causing it. > > Don't think I'll be able to dig deeper, but I can do testing if needed. Please! Does the following patch help? Thanx, Paul ------------------------------------------------------------------------ rcu: More on deadlock between CPU hotplug and expedited grace periods Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and expedited grace periods) was incomplete. Although it did eliminate deadlocks involving synchronize_sched_expedited()'s acquisition of cpu_hotplug.lock via get_online_cpus(), it did nothing about the similar deadlock involving acquisition of this same lock via put_online_cpus(). This deadlock became apparent with testing involving hibernation. This commit therefore changes put_online_cpus() acquisition of this lock to be conditional, and increments a new cpu_hotplug.puts_pending field in case of acquisition failure. Then cpu_hotplug_begin() checks for this new field being non-zero, and applies any changes to cpu_hotplug.refcount. Reported-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Jiri Kosina <jkosina@suse.cz> diff --git a/kernel/cpu.c b/kernel/cpu.c index 356450f09c1f..90a3d017b90c 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -64,6 +64,8 @@ static struct { * an ongoing cpu hotplug operation. */ int refcount; + /* And allows lockless put_online_cpus(). */ + atomic_t puts_pending; #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; @@ -113,7 +115,11 @@ void put_online_cpus(void) { if (cpu_hotplug.active_writer == current) return; - mutex_lock(&cpu_hotplug.lock); + if (!mutex_trylock(&cpu_hotplug.lock)) { + atomic_inc(&cpu_hotplug.puts_pending); + cpuhp_lock_release(); + return; + } if (WARN_ON(!cpu_hotplug.refcount)) cpu_hotplug.refcount++; /* try to fix things up */ @@ -155,6 +161,12 @@ void cpu_hotplug_begin(void) cpuhp_lock_acquire(); for (;;) { mutex_lock(&cpu_hotplug.lock); + if (atomic_read(&cpu_hotplug.puts_pending)) { + int delta; + + delta = atomic_xchg(&cpu_hotplug.puts_pending, 0); + cpu_hotplug.refcount -= delta; + } if (likely(!cpu_hotplug.refcount)) break; __set_current_state(TASK_UNINTERRUPTIBLE); ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 23:24 ` Paul E. McKenney @ 2014-10-23 6:09 ` Yanko Kaneti 2014-10-23 12:27 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-23 6:09 UTC (permalink / raw) To: paulmck Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > <paulmck@linux.vnet.ibm.com> wrote: > > [ . . . ] > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > have > > > > blocked within rcu_barrier() for 120 seconds means that > > > > something is > > > > most definitely wrong here. I am surprised that there are no > > > > RCU CPU > > > > stall warnings, but perhaps the blockage is in the callback > > > > execution > > > > rather than grace-period completion. Or something is > > > > preventing this > > > > kthread from starting up after the wake-up callback executes. > > > > Or... > > > > > > > > Is this thing reproducible? > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > recreate it reliably. Apparently reverting the RCU merge commit > > > (d6dd50e) and rebuilding the latest after that does not show the > > > issue. I'll let Yanko explain more and answer any questions you > > > have. > > > > - It is reproducible > > - I've done another build here to double check and its definitely > > the rcu merge > > that's causing it. > > > > Don't think I'll be able to dig deeper, but I can do testing if > > needed. > > Please! Does the following patch help? Nope, doesn't seem to make a difference to the modprobe ppp_generic test INFO: task kworker/u16:6:101 blocked for more than 120 seconds. Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:6 D ffff88022067cec0 11680 101 2 0x00000000 Workqueue: netns cleanup_net ffff8802206939e8 0000000000000096 ffff88022067cec0 00000000001d5f00 ffff880220693fd8 00000000001d5f00 ffff880223263480 ffff88022067cec0 ffffffff82c51d60 7fffffffffffffff ffffffff81ee2698 ffffffff81ee2690 Call Trace: [<ffffffff8185e289>] schedule+0x29/0x70 [<ffffffff818634ac>] schedule_timeout+0x26c/0x410 [<ffffffff81028c4a>] ? native_sched_clock+0x2a/0xa0 [<ffffffff81107afc>] ? mark_held_locks+0x7c/0xb0 [<ffffffff81864530>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff81107c8d>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffff8185fcbc>] wait_for_completion+0x10c/0x150 [<ffffffff810e5430>] ? wake_up_state+0x20/0x20 [<ffffffff8112a799>] _rcu_barrier+0x159/0x200 [<ffffffff8112a895>] rcu_barrier+0x15/0x20 [<ffffffff81718f0f>] netdev_run_todo+0x6f/0x310 [<ffffffff8170dad5>] ? rollback_registered_many+0x265/0x2e0 [<ffffffff81725f7e>] rtnl_unlock+0xe/0x10 [<ffffffff8170f936>] default_device_exit_batch+0x156/0x180 [<ffffffff810fd8f0>] ? abort_exclusive_wait+0xb0/0xb0 [<ffffffff817079e3>] ops_exit_list.isra.1+0x53/0x60 [<ffffffff81708590>] cleanup_net+0x100/0x1f0 [<ffffffff810ccff8>] process_one_work+0x218/0x850 [<ffffffff810ccf5f>] ? process_one_work+0x17f/0x850 [<ffffffff810cd717>] ? worker_thread+0xe7/0x4a0 [<ffffffff810cd69b>] worker_thread+0x6b/0x4a0 [<ffffffff810cd630>] ? process_one_work+0x850/0x850 [<ffffffff810d39eb>] kthread+0x10b/0x130 [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 [<ffffffff810d38e0>] ? kthread_create_on_node+0x250/0x250 [<ffffffff8186527c>] ret_from_fork+0x7c/0xb0 [<ffffffff810d38e0>] ? kthread_create_on_node+0x250/0x250 4 locks held by kworker/u16:6/101: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf5f>] process_one_work+0x17f/0x850 #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccf5f>] process_one_work+0x17f/0x850 #2: (net_mutex){+.+.+.}, at: [<ffffffff8170851c>] cleanup_net+0x8c/0x1f0 #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a675>] _rcu_barrier+0x35/0x200 INFO: task modprobe:1139 blocked for more than 120 seconds. Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D ffff880213ac1a40 13112 1139 1138 0x00000080 ffff880036ab3be8 0000000000000096 ffff880213ac1a40 00000000001d5f00 ffff880036ab3fd8 00000000001d5f00 ffff880223264ec0 ffff880213ac1a40 ffff880213ac1a40 ffffffff81f8fb48 0000000000000246 ffff880213ac1a40 Call Trace: [<ffffffff8185e831>] schedule_preempt_disabled+0x31/0x80 [<ffffffff81860083>] mutex_lock_nested+0x183/0x440 [<ffffffff817083af>] ? register_pernet_subsys+0x1f/0x50 [<ffffffff817083af>] ? register_pernet_subsys+0x1f/0x50 [<ffffffffa06f3000>] ? 0xffffffffa06f3000 [<ffffffff817083af>] register_pernet_subsys+0x1f/0x50 [<ffffffffa06f3048>] br_init+0x48/0xd3 [bridge] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [<ffffffff81153c52>] load_module+0x20c2/0x2870 [<ffffffff8114ec30>] ? store_uevent+0x70/0x70 [<ffffffff8110ac76>] ? lock_release_non_nested+0x3c6/0x3d0 [<ffffffff811544e7>] SyS_init_module+0xe7/0x140 [<ffffffff81865329>] system_call_fastpath+0x12/0x17 1 lock held by modprobe/1139: #0: (net_mutex){+.+.+.}, at: [<ffffffff817083af>] register_pernet_subsys+0x1f/0x50 INFO: task modprobe:1209 blocked for more than 120 seconds. Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D ffff8800c5324ec0 13368 1209 1151 0x00000080 ffff88020d14bbe8 0000000000000096 ffff8800c5324ec0 00000000001d5f00 ffff88020d14bfd8 00000000001d5f00 ffff880223280000 ffff8800c5324ec0 ffff8800c5324ec0 ffffffff81f8fb48 0000000000000246 ffff8800c5324ec0 Call Trace: [<ffffffff8185e831>] schedule_preempt_disabled+0x31/0x80 [<ffffffff81860083>] mutex_lock_nested+0x183/0x440 [<ffffffff817083fd>] ? register_pernet_device+0x1d/0x70 [<ffffffff817083fd>] ? register_pernet_device+0x1d/0x70 [<ffffffffa070f000>] ? 0xffffffffa070f000 [<ffffffff817083fd>] register_pernet_device+0x1d/0x70 [<ffffffffa070f020>] ppp_init+0x20/0x1000 [ppp_generic] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [<ffffffff81153c52>] load_module+0x20c2/0x2870 [<ffffffff8114ec30>] ? store_uevent+0x70/0x70 [<ffffffff8110ac76>] ? lock_release_non_nested+0x3c6/0x3d0 [<ffffffff811544e7>] SyS_init_module+0xe7/0x140 [<ffffffff81865329>] system_call_fastpath+0x12/0x17 1 lock held by modprobe/1209: #0: (net_mutex){+.+.+.}, at: [<ffffffff817083fd>] register_pernet_device+0x1d/0x70 > Thanx, Paul > > --------------------------------------------------------------------- > --- > > rcu: More on deadlock between CPU hotplug and expedited grace periods > > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and > expedited grace periods) was incomplete. Although it did eliminate > deadlocks involving synchronize_sched_expedited()'s acquisition of > cpu_hotplug.lock via get_online_cpus(), it did nothing about the > similar > deadlock involving acquisition of this same lock via > put_online_cpus(). > This deadlock became apparent with testing involving hibernation. > > This commit therefore changes put_online_cpus() acquisition of this > lock > to be conditional, and increments a new cpu_hotplug.puts_pending > field > in case of acquisition failure. Then cpu_hotplug_begin() checks for > this > new field being non-zero, and applies any changes to > cpu_hotplug.refcount. > > Reported-by: Jiri Kosina <jkosina@suse.cz> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Tested-by: Jiri Kosina <jkosina@suse.cz> > > diff --git a/kernel/cpu.c b/kernel/cpu.c > index 356450f09c1f..90a3d017b90c 100644 > --- a/kernel/cpu.c > +++ b/kernel/cpu.c > @@ -64,6 +64,8 @@ static struct { > * an ongoing cpu hotplug operation. > */ > int refcount; > + /* And allows lockless put_online_cpus(). */ > + atomic_t puts_pending; > > #ifdef CONFIG_DEBUG_LOCK_ALLOC > struct lockdep_map dep_map; > @@ -113,7 +115,11 @@ void put_online_cpus(void) > { > if (cpu_hotplug.active_writer == current) > return; > - mutex_lock(&cpu_hotplug.lock); > + if (!mutex_trylock(&cpu_hotplug.lock)) { > + atomic_inc(&cpu_hotplug.puts_pending); > + cpuhp_lock_release(); > + return; > + } > > if (WARN_ON(!cpu_hotplug.refcount)) > cpu_hotplug.refcount++; /* try to fix things up */ > @@ -155,6 +161,12 @@ void cpu_hotplug_begin(void) > cpuhp_lock_acquire(); > for (;;) { > mutex_lock(&cpu_hotplug.lock); > + if (atomic_read(&cpu_hotplug.puts_pending)) { > + int delta; > + > + delta = atomic_xchg(&cpu_hotplug.puts_pending, 0); > + cpu_hotplug.refcount -= delta; > + } > if (likely(!cpu_hotplug.refcount)) > break; > __set_current_state(TASK_UNINTERRUPTIBLE); > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 6:09 ` Yanko Kaneti @ 2014-10-23 12:27 ` Paul E. McKenney 2014-10-23 15:33 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-23 12:27 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > [ . . . ] > > > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > > have > > > > > blocked within rcu_barrier() for 120 seconds means that > > > > > something is > > > > > most definitely wrong here. I am surprised that there are no > > > > > RCU CPU > > > > > stall warnings, but perhaps the blockage is in the callback > > > > > execution > > > > > rather than grace-period completion. Or something is > > > > > preventing this > > > > > kthread from starting up after the wake-up callback executes. > > > > > Or... > > > > > > > > > > Is this thing reproducible? > > > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > > recreate it reliably. Apparently reverting the RCU merge commit > > > > (d6dd50e) and rebuilding the latest after that does not show the > > > > issue. I'll let Yanko explain more and answer any questions you > > > > have. > > > > > > - It is reproducible > > > - I've done another build here to double check and its definitely > > > the rcu merge > > > that's causing it. > > > > > > Don't think I'll be able to dig deeper, but I can do testing if > > > needed. > > > > Please! Does the following patch help? > > Nope, doesn't seem to make a difference to the modprobe ppp_generic > test Well, I was hoping. I will take a closer look at the RCU merge commit and see what suggests itself. I am likely to ask you to revert specific commits, if that works for you. Thanx, Paul > INFO: task kworker/u16:6:101 blocked for more than 120 seconds. > Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > kworker/u16:6 D ffff88022067cec0 11680 101 2 0x00000000 > Workqueue: netns cleanup_net > ffff8802206939e8 0000000000000096 ffff88022067cec0 00000000001d5f00 > ffff880220693fd8 00000000001d5f00 ffff880223263480 ffff88022067cec0 > ffffffff82c51d60 7fffffffffffffff ffffffff81ee2698 ffffffff81ee2690 > Call Trace: > [<ffffffff8185e289>] schedule+0x29/0x70 > [<ffffffff818634ac>] schedule_timeout+0x26c/0x410 > [<ffffffff81028c4a>] ? native_sched_clock+0x2a/0xa0 > [<ffffffff81107afc>] ? mark_held_locks+0x7c/0xb0 > [<ffffffff81864530>] ? _raw_spin_unlock_irq+0x30/0x50 > [<ffffffff81107c8d>] ? trace_hardirqs_on_caller+0x15d/0x200 > [<ffffffff8185fcbc>] wait_for_completion+0x10c/0x150 > [<ffffffff810e5430>] ? wake_up_state+0x20/0x20 > [<ffffffff8112a799>] _rcu_barrier+0x159/0x200 > [<ffffffff8112a895>] rcu_barrier+0x15/0x20 > [<ffffffff81718f0f>] netdev_run_todo+0x6f/0x310 > [<ffffffff8170dad5>] ? rollback_registered_many+0x265/0x2e0 > [<ffffffff81725f7e>] rtnl_unlock+0xe/0x10 > [<ffffffff8170f936>] default_device_exit_batch+0x156/0x180 > [<ffffffff810fd8f0>] ? abort_exclusive_wait+0xb0/0xb0 > [<ffffffff817079e3>] ops_exit_list.isra.1+0x53/0x60 > [<ffffffff81708590>] cleanup_net+0x100/0x1f0 > [<ffffffff810ccff8>] process_one_work+0x218/0x850 > [<ffffffff810ccf5f>] ? process_one_work+0x17f/0x850 > [<ffffffff810cd717>] ? worker_thread+0xe7/0x4a0 > [<ffffffff810cd69b>] worker_thread+0x6b/0x4a0 > [<ffffffff810cd630>] ? process_one_work+0x850/0x850 > [<ffffffff810d39eb>] kthread+0x10b/0x130 > [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > [<ffffffff810d38e0>] ? kthread_create_on_node+0x250/0x250 > [<ffffffff8186527c>] ret_from_fork+0x7c/0xb0 > [<ffffffff810d38e0>] ? kthread_create_on_node+0x250/0x250 > 4 locks held by kworker/u16:6/101: > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf5f>] process_one_work+0x17f/0x850 > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810ccf5f>] process_one_work+0x17f/0x850 > #2: (net_mutex){+.+.+.}, at: [<ffffffff8170851c>] cleanup_net+0x8c/0x1f0 > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a675>] _rcu_barrier+0x35/0x200 > INFO: task modprobe:1139 blocked for more than 120 seconds. > Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > modprobe D ffff880213ac1a40 13112 1139 1138 0x00000080 > ffff880036ab3be8 0000000000000096 ffff880213ac1a40 00000000001d5f00 > ffff880036ab3fd8 00000000001d5f00 ffff880223264ec0 ffff880213ac1a40 > ffff880213ac1a40 ffffffff81f8fb48 0000000000000246 ffff880213ac1a40 > Call Trace: > [<ffffffff8185e831>] schedule_preempt_disabled+0x31/0x80 > [<ffffffff81860083>] mutex_lock_nested+0x183/0x440 > [<ffffffff817083af>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffff817083af>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffffa06f3000>] ? 0xffffffffa06f3000 > [<ffffffff817083af>] register_pernet_subsys+0x1f/0x50 > [<ffffffffa06f3048>] br_init+0x48/0xd3 [bridge] > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [<ffffffff81153c52>] load_module+0x20c2/0x2870 > [<ffffffff8114ec30>] ? store_uevent+0x70/0x70 > [<ffffffff8110ac76>] ? lock_release_non_nested+0x3c6/0x3d0 > [<ffffffff811544e7>] SyS_init_module+0xe7/0x140 > [<ffffffff81865329>] system_call_fastpath+0x12/0x17 > 1 lock held by modprobe/1139: > #0: (net_mutex){+.+.+.}, at: [<ffffffff817083af>] > register_pernet_subsys+0x1f/0x50 > INFO: task modprobe:1209 blocked for more than 120 seconds. > Not tainted 3.18.0-0.rc1.git2.3.fc22.x86_64 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > modprobe D ffff8800c5324ec0 13368 1209 1151 0x00000080 > ffff88020d14bbe8 0000000000000096 ffff8800c5324ec0 00000000001d5f00 > ffff88020d14bfd8 00000000001d5f00 ffff880223280000 ffff8800c5324ec0 > ffff8800c5324ec0 ffffffff81f8fb48 0000000000000246 ffff8800c5324ec0 > Call Trace: > [<ffffffff8185e831>] schedule_preempt_disabled+0x31/0x80 > [<ffffffff81860083>] mutex_lock_nested+0x183/0x440 > [<ffffffff817083fd>] ? register_pernet_device+0x1d/0x70 > [<ffffffff817083fd>] ? register_pernet_device+0x1d/0x70 > [<ffffffffa070f000>] ? 0xffffffffa070f000 > [<ffffffff817083fd>] register_pernet_device+0x1d/0x70 > [<ffffffffa070f020>] ppp_init+0x20/0x1000 [ppp_generic] > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [<ffffffff81153c52>] load_module+0x20c2/0x2870 > [<ffffffff8114ec30>] ? store_uevent+0x70/0x70 > [<ffffffff8110ac76>] ? lock_release_non_nested+0x3c6/0x3d0 > [<ffffffff811544e7>] SyS_init_module+0xe7/0x140 > [<ffffffff81865329>] system_call_fastpath+0x12/0x17 > 1 lock held by modprobe/1209: > #0: (net_mutex){+.+.+.}, at: [<ffffffff817083fd>] register_pernet_device+0x1d/0x70 > > > > Thanx, Paul > > > > --------------------------------------------------------------------- > > --- > > > > rcu: More on deadlock between CPU hotplug and expedited grace periods > > > > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and > > expedited grace periods) was incomplete. Although it did eliminate > > deadlocks involving synchronize_sched_expedited()'s acquisition of > > cpu_hotplug.lock via get_online_cpus(), it did nothing about the > > similar > > deadlock involving acquisition of this same lock via > > put_online_cpus(). > > This deadlock became apparent with testing involving hibernation. > > > > This commit therefore changes put_online_cpus() acquisition of this > > lock > > to be conditional, and increments a new cpu_hotplug.puts_pending > > field > > in case of acquisition failure. Then cpu_hotplug_begin() checks for > > this > > new field being non-zero, and applies any changes to > > cpu_hotplug.refcount. > > > > Reported-by: Jiri Kosina <jkosina@suse.cz> > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Tested-by: Jiri Kosina <jkosina@suse.cz> > > > > diff --git a/kernel/cpu.c b/kernel/cpu.c > > index 356450f09c1f..90a3d017b90c 100644 > > --- a/kernel/cpu.c > > +++ b/kernel/cpu.c > > @@ -64,6 +64,8 @@ static struct { > > * an ongoing cpu hotplug operation. > > */ > > int refcount; > > + /* And allows lockless put_online_cpus(). */ > > + atomic_t puts_pending; > > > > #ifdef CONFIG_DEBUG_LOCK_ALLOC > > struct lockdep_map dep_map; > > @@ -113,7 +115,11 @@ void put_online_cpus(void) > > { > > if (cpu_hotplug.active_writer == current) > > return; > > - mutex_lock(&cpu_hotplug.lock); > > + if (!mutex_trylock(&cpu_hotplug.lock)) { > > + atomic_inc(&cpu_hotplug.puts_pending); > > + cpuhp_lock_release(); > > + return; > > + } > > > > if (WARN_ON(!cpu_hotplug.refcount)) > > cpu_hotplug.refcount++; /* try to fix things up */ > > @@ -155,6 +161,12 @@ void cpu_hotplug_begin(void) > > cpuhp_lock_acquire(); > > for (;;) { > > mutex_lock(&cpu_hotplug.lock); > > + if (atomic_read(&cpu_hotplug.puts_pending)) { > > + int delta; > > + > > + delta = atomic_xchg(&cpu_hotplug.puts_pending, 0); > > + cpu_hotplug.refcount -= delta; > > + } > > if (likely(!cpu_hotplug.refcount)) > > break; > > __set_current_state(TASK_UNINTERRUPTIBLE); > > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 12:27 ` Paul E. McKenney @ 2014-10-23 15:33 ` Paul E. McKenney [not found] ` <CA+5PVA4H6EAf6cBc4a_8W8x4Mgppjc5GsskKaCRry2jq+LP+FA@mail.gmail.com> 2014-10-23 19:51 ` Yanko Kaneti 0 siblings, 2 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-23 15:33 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > [ . . . ] > > > > > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > > > have > > > > > > blocked within rcu_barrier() for 120 seconds means that > > > > > > something is > > > > > > most definitely wrong here. I am surprised that there are no > > > > > > RCU CPU > > > > > > stall warnings, but perhaps the blockage is in the callback > > > > > > execution > > > > > > rather than grace-period completion. Or something is > > > > > > preventing this > > > > > > kthread from starting up after the wake-up callback executes. > > > > > > Or... > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > > > recreate it reliably. Apparently reverting the RCU merge commit > > > > > (d6dd50e) and rebuilding the latest after that does not show the > > > > > issue. I'll let Yanko explain more and answer any questions you > > > > > have. > > > > > > > > - It is reproducible > > > > - I've done another build here to double check and its definitely > > > > the rcu merge > > > > that's causing it. > > > > > > > > Don't think I'll be able to dig deeper, but I can do testing if > > > > needed. > > > > > > Please! Does the following patch help? > > > > Nope, doesn't seem to make a difference to the modprobe ppp_generic > > test > > Well, I was hoping. I will take a closer look at the RCU merge commit > and see what suggests itself. I am likely to ask you to revert specific > commits, if that works for you. Well, rather than reverting commits, could you please try testing the following commits? 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks after spawning) 73a860cd58a1 (rcu: Replace flush_signals() with WARN_ON(signal_pending())) c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) For whatever it is worth, I am guessing this one. a53dd6a65668 (rcutorture: Add RCU-tasks tests to default rcutorture list) If any of the above fail, this one should also fail. Also, could you please send along your .config? Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
[parent not found: <CA+5PVA4H6EAf6cBc4a_8W8x4Mgppjc5GsskKaCRry2jq+LP+FA@mail.gmail.com>]
* Re: localed stuck in recent 3.18 git in copy_net_ns? [not found] ` <CA+5PVA4H6EAf6cBc4a_8W8x4Mgppjc5GsskKaCRry2jq+LP+FA@mail.gmail.com> @ 2014-10-23 16:28 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-23 16:28 UTC (permalink / raw) To: Josh Boyer Cc: Linux-Kernel@Vger. Kernel. Org, Kevin Fenzi, Eric W. Biederman, Yanko Kaneti, netdev, Cong Wang On Thu, Oct 23, 2014 at 12:11:26PM -0400, Josh Boyer wrote: > On Oct 23, 2014 11:37 AM, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> > wrote: > > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > > > > > have > > > > > > > > blocked within rcu_barrier() for 120 seconds means that > > > > > > > > something is > > > > > > > > most definitely wrong here. I am surprised that there are no > > > > > > > > RCU CPU > > > > > > > > stall warnings, but perhaps the blockage is in the callback > > > > > > > > execution > > > > > > > > rather than grace-period completion. Or something is > > > > > > > > preventing this > > > > > > > > kthread from starting up after the wake-up callback executes. > > > > > > > > Or... > > > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > > > > > recreate it reliably. Apparently reverting the RCU merge commit > > > > > > > (d6dd50e) and rebuilding the latest after that does not show the > > > > > > > issue. I'll let Yanko explain more and answer any questions you > > > > > > > have. > > > > > > > > > > > > - It is reproducible > > > > > > - I've done another build here to double check and its definitely > > > > > > the rcu merge > > > > > > that's causing it. > > > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do testing if > > > > > > needed. > > > > > > > > > > Please! Does the following patch help? > > > > > > > > Nope, doesn't seem to make a difference to the modprobe ppp_generic > > > > test > > > > > > Well, I was hoping. I will take a closer look at the RCU merge commit > > > and see what suggests itself. I am likely to ask you to revert specific > > > commits, if that works for you. > > > > Well, rather than reverting commits, could you please try testing the > > following commits? > > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks > after spawning) > > > > 73a860cd58a1 (rcu: Replace flush_signals() with WARN_ON(signal_pending())) > > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > > > For whatever it is worth, I am guessing this one. > > > > a53dd6a65668 (rcutorture: Add RCU-tasks tests to default rcutorture list) > > > > If any of the above fail, this one should also fail. > > > > Also, could you please send along your .config? > > Which tree are those in? They are all in Linus's tree. They are topic branches of the RCU merge commit (d6dd50e), and the test results will hopefully give me more of a clue where to look. As would the .config file. ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 15:33 ` Paul E. McKenney [not found] ` <CA+5PVA4H6EAf6cBc4a_8W8x4Mgppjc5GsskKaCRry2jq+LP+FA@mail.gmail.com> @ 2014-10-23 19:51 ` Yanko Kaneti 2014-10-23 20:05 ` Paul E. McKenney 1 sibling, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-23 19:51 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org [-- Attachment #1: Type: text/plain, Size: 2944 bytes --] On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > [ . . . ] > > > > > > > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > > > > have > > > > > > > blocked within rcu_barrier() for 120 seconds means that > > > > > > > something is > > > > > > > most definitely wrong here. I am surprised that there are no > > > > > > > RCU CPU > > > > > > > stall warnings, but perhaps the blockage is in the callback > > > > > > > execution > > > > > > > rather than grace-period completion. Or something is > > > > > > > preventing this > > > > > > > kthread from starting up after the wake-up callback executes. > > > > > > > Or... > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > > > > recreate it reliably. Apparently reverting the RCU merge commit > > > > > > (d6dd50e) and rebuilding the latest after that does not show the > > > > > > issue. I'll let Yanko explain more and answer any questions you > > > > > > have. > > > > > > > > > > - It is reproducible > > > > > - I've done another build here to double check and its definitely > > > > > the rcu merge > > > > > that's causing it. > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do testing if > > > > > needed. > > > > > > > > Please! Does the following patch help? > > > > > > Nope, doesn't seem to make a difference to the modprobe ppp_generic > > > test > > > > Well, I was hoping. I will take a closer look at the RCU merge commit > > and see what suggests itself. I am likely to ask you to revert specific > > commits, if that works for you. > > Well, rather than reverting commits, could you please try testing the > following commits? > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks after spawning) > > 73a860cd58a1 (rcu: Replace flush_signals() with WARN_ON(signal_pending())) > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > For whatever it is worth, I am guessing this one. Indeed, c847f14217d5 it is. Much to my embarrasment I just noticed that in addition to the rcu merge, triggering the bug "requires" my specific Fedora rawhide network setup. Booting in single mode and modprobe ppp_generic is fine. The bug appears when starting with my regular fedora network setup, which in my case includes 3 ethernet adapters and a libvirt birdge+nat setup. Hope that helps. I am attaching the config. [-- Attachment #2: 3.18.0-rc0.config --] [-- Type: text/plain, Size: 151087 bytes --] # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.17.0-rc2 Kernel Configuration # 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_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y 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_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_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set 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=y # 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 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=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_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y 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_BUILD=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 is not set CONFIG_NO_HZ_FULL=y # CONFIG_NO_HZ_FULL_ALL is not set # CONFIG_NO_HZ_FULL_SYSIDLE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_NOCB_CPU=y # CONFIG_RCU_NOCB_CPU_NONE is not set # CONFIG_RCU_NOCB_CPU_ZERO is not set CONFIG_RCU_NOCB_CPU_ALL=y CONFIG_BUILD_BIN2C=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_ARCH_USES_NUMA_PROT_NONE=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # 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_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_EXPERT is not set CONFIG_UID16=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_PCI_QUIRKS=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_SLUB_CPU_PARTIAL=y CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m CONFIG_OPROFILE_EVENT_MULTIPLEX=y CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y CONFIG_KPROBES=y CONFIG_JUMP_LABEL=y CONFIG_OPTPROBES=y CONFIG_KPROBES_ON_FTRACE=y CONFIG_UPROBES=y # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=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_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=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_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_ALIGNED_STRUCT_PAGE=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_CC_STACKPROTECTOR=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set # CONFIG_CC_STACKPROTECTOR_REGULAR is not set CONFIG_CC_STACKPROTECTOR_STRONG=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_SOFT_DIRTY=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=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 is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set CONFIG_MODULE_SIG_SHA256=y # CONFIG_MODULE_SIG_SHA384 is not set # CONFIG_MODULE_SIG_SHA512 is not set CONFIG_MODULE_SIG_HASH="sha256" CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLK_DEV_THROTTLING=y # CONFIG_BLK_CMDLINE_PARSER is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_AIX_PARTITION=y CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # CONFIG_CMDLINE_PARTITION is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_PADATA=y CONFIG_ASN1=y CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_ARCH_USE_QUEUE_RWLOCK=y CONFIG_QUEUE_RWLOCK=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_SMP=y CONFIG_X86_X2APIC=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y # CONFIG_X86_NUMACHIP is not set # CONFIG_X86_VSMP is not set CONFIG_X86_UV=y # CONFIG_X86_GOLDFISH is not set CONFIG_X86_INTEL_LPSS=y CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_HYPERVISOR_GUEST=y CONFIG_PARAVIRT=y # CONFIG_PARAVIRT_DEBUG is not set # CONFIG_PARAVIRT_SPINLOCKS is not set CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=500 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y # CONFIG_XEN_PVH is not set CONFIG_KVM_GUEST=y # CONFIG_KVM_DEBUG_FS is not set CONFIG_PARAVIRT_TIME_ACCOUNTING=y CONFIG_PARAVIRT_CLOCK=y CONFIG_NO_BOOTMEM=y # CONFIG_MEMTEST is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=6 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y 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 is not set # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y # CONFIG_MAXSMP is not set CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MCE_INJECT=m CONFIG_X86_THERMAL_VECTOR=y CONFIG_X86_16BIT=y CONFIG_X86_ESPFIX64=y CONFIG_I8K=m CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_MICROCODE_INTEL_EARLY=y CONFIG_MICROCODE_AMD_EARLY=y CONFIG_MICROCODE_EARLY=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=9 CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y # CONFIG_ARCH_MEMORY_PROBE is not set CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_HAVE_MEMBLOCK_NODE_MAP=y CONFIG_ARCH_DISCARD_MEMBLOCK=y CONFIG_MEMORY_ISOLATION=y # CONFIG_MOVABLE_NODE is not set # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y # CONFIG_MEMORY_HOTREMOVE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y CONFIG_BALLOON_COMPACTION=y CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=m CONFIG_TRANSPARENT_HUGEPAGE=y # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y CONFIG_CLEANCACHE=y CONFIG_FRONTSWAP=y # CONFIG_CMA is not set CONFIG_ZSWAP=y CONFIG_ZPOOL=y # CONFIG_ZBUD is not set CONFIG_ZSMALLOC=y # CONFIG_PGTABLE_MAPPING is not set CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y # CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 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_EFI=y CONFIG_EFI_STUB=y # CONFIG_EFI_MIXED 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=y CONFIG_KEXEC_VERIFY_SIG=y CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y CONFIG_CRASH_DUMP=y CONFIG_KEXEC_JUMP=y 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_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_USE_PERCPU_NUMA_NODE_ID=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y # CONFIG_PM_AUTOSLEEP is not set # CONFIG_PM_WAKELOCKS is not set CONFIG_PM_RUNTIME=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 is not set CONFIG_ACPI=y CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y CONFIG_ACPI_SLEEP=y # CONFIG_ACPI_PROCFS_POWER is not set CONFIG_ACPI_EC_DEBUGFS=m CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_IPMI=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_PCI_SLOT=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_HOTPLUG_MEMORY=y CONFIG_ACPI_SBS=m CONFIG_ACPI_HED=y CONFIG_ACPI_CUSTOM_METHOD=m CONFIG_ACPI_BGRT=y # CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set CONFIG_HAVE_ACPI_APEI=y CONFIG_HAVE_ACPI_APEI_NMI=y CONFIG_ACPI_APEI=y CONFIG_ACPI_APEI_GHES=y CONFIG_ACPI_APEI_PCIEAER=y CONFIG_ACPI_APEI_MEMORY_FAILURE=y # CONFIG_ACPI_APEI_EINJ is not set # CONFIG_ACPI_APEI_ERST_DEBUG is not set # CONFIG_ACPI_EXTLOG is not set CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 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_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # x86 CPU frequency scaling drivers # CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ_CPB=y CONFIG_X86_POWERNOW_K8=m CONFIG_X86_AMD_FREQ_SENSITIVITY=m # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_P4_CLOCKMOD=m # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m # # CPU Idle # CONFIG_CPU_IDLE=y # CONFIG_CPU_IDLE_GOV_LADDER is not set CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set CONFIG_INTEL_IDLE=y # # Memory power savings # CONFIG_I7300_IDLE_IOAT_CHANNEL=y CONFIG_I7300_IDLE=m # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_XEN=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_REALLOC_ENABLE_AUTO is not set CONFIG_PCI_STUB=y CONFIG_XEN_PCIDEV_FRONTEND=m CONFIG_HT_IRQ=y CONFIG_PCI_ATS=y CONFIG_PCI_IOV=y CONFIG_PCI_PRI=y CONFIG_PCI_PASID=y CONFIG_PCI_IOAPIC=y CONFIG_PCI_LABEL=y # # PCI host controller drivers # CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m CONFIG_PCCARD_NONSTATIC=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=m # CONFIG_RAPIDIO is not set # CONFIG_X86_SYSFB is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_BINFMT_SCRIPT=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=m CONFIG_COREDUMP=y CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set # CONFIG_X86_X32 is not set CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_KEYS_COMPAT=y CONFIG_X86_DEV_DMA_OPS=y CONFIG_IOSF_MBI=m CONFIG_PMC_ATOM=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_DIAG=m CONFIG_UNIX=y CONFIG_UNIX_DIAG=m CONFIG_XFRM=y CONFIG_XFRM_ALGO=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_STATISTICS=y CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_FIB_TRIE_STATS=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_CLASSID=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE_DEMUX=m CONFIG_NET_IP_TUNNEL=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_MROUTE_MULTIPLE_TABLES=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_SYN_COOKIES=y CONFIG_NET_IPVTI=m CONFIG_NET_UDP_TUNNEL=m CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_INET_UDP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m 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=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=y CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_VTI=m CONFIG_IPV6_SIT=m CONFIG_IPV6_SIT_6RD=y CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m # CONFIG_IPV6_GRE is not set CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_IPV6_MROUTE=y CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y CONFIG_IPV6_PIMSM_V2=y CONFIG_NETLABEL=y CONFIG_NETWORK_SECMARK=y CONFIG_NET_PTP_CLASSIFY=y CONFIG_NETWORK_PHY_TIMESTAMPING=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_ACCT=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_LOG_COMMON=m CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_ZONES=y CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set CONFIG_NF_CONNTRACK_TIMESTAMP=y CONFIG_NF_CONNTRACK_LABELS=y CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_BROADCAST=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_SNMP=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m # CONFIG_NF_CT_NETLINK_TIMEOUT is not set CONFIG_NF_CT_NETLINK_HELPER=m CONFIG_NETFILTER_NETLINK_QUEUE_CT=y CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_SIP=m CONFIG_NF_NAT_TFTP=m CONFIG_NETFILTER_SYNPROXY=m CONFIG_NF_TABLES=m CONFIG_NF_TABLES_INET=m CONFIG_NFT_EXTHDR=m CONFIG_NFT_META=m CONFIG_NFT_CT=m CONFIG_NFT_RBTREE=m CONFIG_NFT_HASH=m CONFIG_NFT_COUNTER=m CONFIG_NFT_LOG=m CONFIG_NFT_LIMIT=m CONFIG_NFT_NAT=m CONFIG_NFT_QUEUE=m CONFIG_NFT_REJECT=m CONFIG_NFT_REJECT_INET=m CONFIG_NFT_COMPAT=m CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=m CONFIG_NETFILTER_XT_CONNMARK=m CONFIG_NETFILTER_XT_SET=m # # Xtables targets # CONFIG_NETFILTER_XT_TARGET_AUDIT=m CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_CT=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m CONFIG_NETFILTER_XT_TARGET_HMARK=m CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m CONFIG_NETFILTER_XT_TARGET_LED=m CONFIG_NETFILTER_XT_TARGET_LOG=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NETMAP=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_REDIRECT=m CONFIG_NETFILTER_XT_TARGET_TEE=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m # # Xtables matches # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m CONFIG_NETFILTER_XT_MATCH_BPF=m CONFIG_NETFILTER_XT_MATCH_CGROUP=m CONFIG_NETFILTER_XT_MATCH_CLUSTER=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLABEL=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_CPU=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ECN=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPCOMP=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_IPVS=m CONFIG_NETFILTER_XT_MATCH_L2TP=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_NFACCT=m CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_IP_SET=m CONFIG_IP_SET_MAX=256 CONFIG_IP_SET_BITMAP_IP=m CONFIG_IP_SET_BITMAP_IPMAC=m CONFIG_IP_SET_BITMAP_PORT=m CONFIG_IP_SET_HASH_IP=m CONFIG_IP_SET_HASH_IPMARK=m CONFIG_IP_SET_HASH_IPPORT=m CONFIG_IP_SET_HASH_IPPORTIP=m CONFIG_IP_SET_HASH_IPPORTNET=m CONFIG_IP_SET_HASH_NETPORTNET=m CONFIG_IP_SET_HASH_NET=m CONFIG_IP_SET_HASH_NETNET=m CONFIG_IP_SET_HASH_NETPORT=m CONFIG_IP_SET_HASH_NETIFACE=m CONFIG_IP_SET_LIST_SET=m CONFIG_IP_VS=m CONFIG_IP_VS_IPV6=y # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_PROTO_SCTP=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS SH scheduler # CONFIG_IP_VS_SH_TAB_BITS=8 # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IP_VS_NFCT=y CONFIG_IP_VS_PE_SIP=m # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_NF_LOG_ARP=m CONFIG_NF_LOG_IPV4=m CONFIG_NF_TABLES_IPV4=m CONFIG_NFT_CHAIN_ROUTE_IPV4=m CONFIG_NFT_CHAIN_NAT_IPV4=m CONFIG_NFT_REJECT_IPV4=m CONFIG_NF_TABLES_ARP=m CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_RPFILTER=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_SYNPROXY=m CONFIG_NF_NAT_IPV4=m CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_SECURITY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_NF_TABLES_IPV6=m CONFIG_NFT_CHAIN_ROUTE_IPV6=m CONFIG_NFT_CHAIN_NAT_IPV6=m CONFIG_NFT_REJECT_IPV6=m CONFIG_NF_LOG_IPV6=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RPFILTER=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_TARGET_SYNPROXY=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_SECURITY=m CONFIG_NF_NAT_IPV6=m CONFIG_IP6_NF_TARGET_MASQUERADE=m # CONFIG_IP6_NF_TARGET_NPT is not set CONFIG_NF_TABLES_BRIDGE=m CONFIG_NFT_BRIDGE_META=m CONFIG_NFT_BRIDGE_REJECT=m CONFIG_NF_LOG_BRIDGE=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m # # DCCP CCIDs Configuration # # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=y # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_TFRC_LIB=y # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set # CONFIG_NET_DCCPPROBE is not set CONFIG_IP_SCTP=m CONFIG_NET_SCTPPROBE=m # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1=y # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set CONFIG_SCTP_COOKIE_HMAC_MD5=y CONFIG_SCTP_COOKIE_HMAC_SHA1=y CONFIG_RDS=m CONFIG_RDS_RDMA=m CONFIG_RDS_TCP=m # CONFIG_RDS_DEBUG is not set CONFIG_TIPC=m CONFIG_TIPC_PORTS=8192 # CONFIG_TIPC_MEDIA_IB is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m # CONFIG_ATM_MPOA is not set CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_L2TP=m CONFIG_L2TP_DEBUGFS=m CONFIG_L2TP_V3=y CONFIG_L2TP_IP=m CONFIG_L2TP_ETH=m CONFIG_STP=m CONFIG_GARP=m CONFIG_MRP=m CONFIG_BRIDGE=m CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_HAVE_NET_DSA=y CONFIG_NET_DSA=m CONFIG_NET_DSA_TAG_DSA=y CONFIG_NET_DSA_TAG_EDSA=y CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y CONFIG_VLAN_8021Q_MVRP=y # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=m CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_PHONET is not set CONFIG_6LOWPAN=m CONFIG_IEEE802154=m CONFIG_IEEE802154_6LOWPAN=m CONFIG_MAC802154=m CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_MULTIQ=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFB=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DRR=m CONFIG_NET_SCH_MQPRIO=m CONFIG_NET_SCH_CHOKE=m CONFIG_NET_SCH_QFQ=m CONFIG_NET_SCH_CODEL=m CONFIG_NET_SCH_FQ_CODEL=y CONFIG_NET_SCH_FQ=m CONFIG_NET_SCH_HHF=m CONFIG_NET_SCH_PIE=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_SCH_PLUG=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_CLS_CGROUP=y CONFIG_NET_CLS_BPF=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_EMATCH_IPSET=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_ACT_SKBEDIT=m CONFIG_NET_ACT_CSUM=m CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y CONFIG_DCB=y CONFIG_DNS_RESOLVER=m CONFIG_BATMAN_ADV=m CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_NC=y CONFIG_BATMAN_ADV_MCAST=y # CONFIG_BATMAN_ADV_DEBUG is not set CONFIG_OPENVSWITCH=m CONFIG_OPENVSWITCH_GRE=y CONFIG_OPENVSWITCH_VXLAN=y CONFIG_VSOCKETS=m CONFIG_VMWARE_VMCI_VSOCKETS=m CONFIG_NETLINK_MMAP=y CONFIG_NETLINK_DIAG=m CONFIG_NET_MPLS_GSO=m # CONFIG_HSR is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y CONFIG_CGROUP_NET_PRIO=y CONFIG_CGROUP_NET_CLASSID=y CONFIG_NET_RX_BUSY_POLL=y CONFIG_BQL=y CONFIG_BPF_JIT=y CONFIG_NET_FLOW_LIMIT=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NET_TCPPROBE is not set CONFIG_NET_DROP_MONITOR=y CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m # # AX.25 network device drivers # CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_YAM=m # CONFIG_CAN is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_KINGSUN_DONGLE=m CONFIG_KSDAZZLE_DONGLE=m CONFIG_KS959_DONGLE=m # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_MCS_FIR=m CONFIG_BT=m CONFIG_BT_6LOWPAN=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_CMTP=m CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_ATH3K=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIUART_3WIRE=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MRVL=m CONFIG_BT_MRVL_SDIO=m CONFIG_BT_ATH3K=m # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m # CONFIG_NL80211_TESTMODE is not set # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set # CONFIG_CFG80211_REG_DEBUG is not set CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_DEBUGFS=y # CONFIG_CFG80211_INTERNAL_REGDB is not set CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=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_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y # CONFIG_MAC80211_MESSAGE_TRACING is not set # CONFIG_MAC80211_DEBUG_MENU is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y CONFIG_RFKILL_GPIO=m CONFIG_NET_9P=m CONFIG_NET_9P_VIRTIO=m CONFIG_NET_9P_RDMA=m # CONFIG_NET_9P_DEBUG is not set # CONFIG_CAIF is not set CONFIG_CEPH_LIB=m # CONFIG_CEPH_LIB_PRETTYDEBUG is not set # CONFIG_CEPH_LIB_USE_DNS_RESOLVER is not set CONFIG_NFC=m CONFIG_NFC_DIGITAL=m CONFIG_NFC_NCI=m # CONFIG_NFC_NCI_SPI is not set CONFIG_NFC_HCI=m CONFIG_NFC_SHDLC=y # # Near Field Communication (NFC) devices # CONFIG_NFC_PN533=m # CONFIG_NFC_TRF7970A is not set CONFIG_NFC_MEI_PHY=m CONFIG_NFC_SIM=m CONFIG_NFC_PORT100=m CONFIG_NFC_PN544=m CONFIG_NFC_PN544_I2C=m CONFIG_NFC_PN544_MEI=m CONFIG_NFC_MICROREAD=m CONFIG_NFC_MICROREAD_I2C=m CONFIG_NFC_MICROREAD_MEI=m CONFIG_NFC_MRVL=m CONFIG_NFC_MRVL_USB=m CONFIG_NFC_ST21NFCA=m CONFIG_NFC_ST21NFCA_I2C=m # CONFIG_NFC_ST21NFCB is not set CONFIG_HAVE_BPF_JIT=y # # Device Drivers # # # Generic Driver Options # # CONFIG_UEVENT_HELPER is not set CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_DEVRES=y CONFIG_SYS_HYPERVISOR=y # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=m CONFIG_DMA_SHARED_BUFFER=y # CONFIG_FENCE_TRACE is not set # # Bus devices # CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=m # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_BLKDEVS=m CONFIG_MTD_BLOCK=m # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set # CONFIG_SM_FTL is not set # CONFIG_MTD_OOPS is not set # CONFIG_MTD_SWAP is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_DATAFLASH is not set # CONFIG_MTD_SST25L is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOCG3 is not set # CONFIG_MTD_NAND is not set # CONFIG_MTD_ONENAND is not set # # LPDDR & LPDDR2 PCM memory drivers # # CONFIG_MTD_LPDDR is not set # CONFIG_MTD_SPI_NOR is not set CONFIG_MTD_UBI=m CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_LIMIT=20 # CONFIG_MTD_UBI_FASTMAP is not set # CONFIG_MTD_UBI_GLUEBI is not set # CONFIG_MTD_UBI_BLOCK is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_NULL_BLK=m CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m CONFIG_ZRAM=m # CONFIG_ZRAM_LZ4_COMPRESS is not set # CONFIG_ZRAM_DEBUG is not set CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_DRBD=m # CONFIG_DRBD_FAULT_INJECTION is not set CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_NVME=m CONFIG_BLK_DEV_SKD=m CONFIG_BLK_DEV_OSD=m CONFIG_BLK_DEV_SX8=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_XEN_BLKDEV_FRONTEND=m CONFIG_XEN_BLKDEV_BACKEND=m CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_RBD=m # CONFIG_BLK_DEV_RSXX is not set # # Misc devices # CONFIG_SENSORS_LIS3LV02D=m # 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=m CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m # CONFIG_ICS932S401 is not set CONFIG_ENCLOSURE_SERVICES=m CONFIG_SGI_XP=m CONFIG_HP_ILO=m CONFIG_SGI_GRU=m # CONFIG_SGI_GRU_DEBUG is not set CONFIG_APDS9802ALS=m CONFIG_ISL29003=m CONFIG_ISL29020=m CONFIG_SENSORS_TSL2550=m # CONFIG_SENSORS_BH1780 is not set CONFIG_SENSORS_BH1770=m CONFIG_SENSORS_APDS990X=m # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set # CONFIG_TI_DAC7512 is not set CONFIG_VMWARE_BALLOON=m # CONFIG_BMP085_I2C is not set # CONFIG_BMP085_SPI is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_LATTICE_ECP3_CONFIG is not set # CONFIG_SRAM is not set # CONFIG_C2PORT is not set # # EEPROM support # CONFIG_EEPROM_AT24=m # CONFIG_EEPROM_AT25 is not set CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m # CONFIG_EEPROM_93XX46 is not set CONFIG_CB710_CORE=m # CONFIG_CB710_DEBUG is not set CONFIG_CB710_DEBUG_ASSUMPTIONS=y # # Texas Instruments shared transport line discipline # # CONFIG_TI_ST is not set CONFIG_SENSORS_LIS3_I2C=m # # Altera FPGA firmware download module # CONFIG_ALTERA_STAPL=m CONFIG_INTEL_MEI=m CONFIG_INTEL_MEI_ME=m CONFIG_INTEL_MEI_TXE=m CONFIG_VMWARE_VMCI=m # # Intel MIC Bus Driver # CONFIG_INTEL_MIC_BUS=m # # Intel MIC Host Driver # CONFIG_INTEL_MIC_HOST=m # # Intel MIC Card Driver # CONFIG_INTEL_MIC_CARD=m # CONFIG_GENWQE is not set # CONFIG_ECHO is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SRP_ATTRS=m CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_ISCSI_BOOT_SYSFS=m CONFIG_SCSI_CXGB3_ISCSI=m CONFIG_SCSI_CXGB4_ISCSI=m CONFIG_SCSI_BNX2_ISCSI=m CONFIG_SCSI_BNX2X_FCOE=m CONFIG_BE2ISCSI=m CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_HPSA=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_3W_SAS=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC94XX is not set CONFIG_SCSI_MVSAS=m # CONFIG_SCSI_MVSAS_DEBUG is not set CONFIG_SCSI_MVSAS_TASKLET=y CONFIG_SCSI_MVUMI=m # CONFIG_SCSI_DPT_I2O is not set CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_ARCMSR=m CONFIG_SCSI_ESAS2R=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_MPT2SAS=m CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS_LOGGING=y CONFIG_SCSI_MPT3SAS=m CONFIG_SCSI_MPT3SAS_MAX_SGE=128 CONFIG_SCSI_MPT3SAS_LOGGING=y CONFIG_SCSI_UFSHCD=m CONFIG_SCSI_UFSHCD_PCI=m # CONFIG_SCSI_UFSHCD_PLATFORM is not set CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m CONFIG_SCSI_FLASHPOINT=y CONFIG_VMWARE_PVSCSI=m CONFIG_HYPERV_STORAGE=m CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_FCOE=m CONFIG_FCOE_FNIC=m CONFIG_SCSI_DMX3191D=m # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set CONFIG_SCSI_GDTH=m CONFIG_SCSI_ISCI=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=m CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m CONFIG_TCM_QLA2XXX=m CONFIG_SCSI_QLA_ISCSI=m CONFIG_SCSI_LPFC=m # CONFIG_SCSI_LPFC_DEBUG_FS is not set CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_DEBUG=m CONFIG_SCSI_PMCRAID=m CONFIG_SCSI_PM8001=m CONFIG_SCSI_BFA_FC=m CONFIG_SCSI_VIRTIO=m CONFIG_SCSI_CHELSIO_FCOE=m # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set CONFIG_SCSI_DH=y CONFIG_SCSI_DH_RDAC=m CONFIG_SCSI_DH_HP_SW=m CONFIG_SCSI_DH_EMC=m CONFIG_SCSI_DH_ALUA=m CONFIG_SCSI_OSD_INITIATOR=m CONFIG_SCSI_OSD_ULD=m CONFIG_SCSI_OSD_DPRINT_SENSE=1 # CONFIG_SCSI_OSD_DEBUG is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y # CONFIG_SATA_ZPODD is not set CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=m CONFIG_SATA_INIC162X=m CONFIG_SATA_ACARD_AHCI=m CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SX4=m CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # CONFIG_ATA_PIIX=y CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_ATP867X=m CONFIG_PATA_CMD64X=m CONFIG_PATA_CYPRESS=m CONFIG_PATA_EFAR=m CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m # CONFIG_PATA_HPT3X3_DMA is not set CONFIG_PATA_IT8213=m CONFIG_PATA_IT821X=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NINJA32=m CONFIG_PATA_NS87415=m CONFIG_PATA_OLDPIIX=m CONFIG_PATA_OPTIDMA=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_PDC_OLD=m # CONFIG_PATA_RADISYS is not set CONFIG_PATA_RDC=m CONFIG_PATA_SCH=m CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_TOSHIBA=m CONFIG_PATA_TRIFLEX=m CONFIG_PATA_VIA=m CONFIG_PATA_WINBOND=m # # PIO-only SFF controllers # CONFIG_PATA_CMD640_PCI=m CONFIG_PATA_MPIIX=m CONFIG_PATA_NS87410=m CONFIG_PATA_OPTI=m CONFIG_PATA_PCMCIA=m # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # CONFIG_PATA_ACPI=m CONFIG_ATA_GENERIC=m # CONFIG_PATA_LEGACY is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m 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_DEBUG=y CONFIG_DM_BUFIO=y CONFIG_DM_BIO_PRISON=m CONFIG_DM_PERSISTENT_DATA=m # CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=y CONFIG_DM_THIN_PROVISIONING=m CONFIG_DM_CACHE=m CONFIG_DM_CACHE_MQ=m CONFIG_DM_CACHE_CLEANER=m # CONFIG_DM_ERA is not set CONFIG_DM_MIRROR=y CONFIG_DM_LOG_USERSPACE=m CONFIG_DM_RAID=m CONFIG_DM_ZERO=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_QL=m CONFIG_DM_MULTIPATH_ST=m CONFIG_DM_DELAY=m CONFIG_DM_UEVENT=y CONFIG_DM_FLAKEY=m CONFIG_DM_VERITY=m CONFIG_DM_SWITCH=m CONFIG_TARGET_CORE=m CONFIG_TCM_IBLOCK=m CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m CONFIG_LOOPBACK_TARGET=m CONFIG_TCM_FC=m CONFIG_ISCSI_TARGET=m CONFIG_SBP_TARGET=m CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m CONFIG_FUSION_LOGGING=y # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m CONFIG_FIREWIRE_NET=m CONFIG_FIREWIRE_NOSY=m # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y CONFIG_NETDEVICES=y CONFIG_MII=m CONFIG_NET_CORE=y CONFIG_BONDING=m CONFIG_DUMMY=m CONFIG_EQUALIZER=m CONFIG_NET_FC=y CONFIG_IFB=m CONFIG_NET_TEAM=m CONFIG_NET_TEAM_MODE_BROADCAST=m CONFIG_NET_TEAM_MODE_ROUNDROBIN=m CONFIG_NET_TEAM_MODE_RANDOM=m CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m CONFIG_NET_TEAM_MODE_LOADBALANCE=m CONFIG_MACVLAN=m CONFIG_MACVTAP=m CONFIG_VXLAN=m CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_NTB_NETDEV=m CONFIG_TUN=m CONFIG_VETH=m CONFIG_VIRTIO_NET=m CONFIG_NLMON=m CONFIG_SUNGEM_PHY=m # CONFIG_ARCNET is not set CONFIG_ATM_DRIVERS=y # CONFIG_ATM_DUMMY is not set CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m # CONFIG_ATM_ZATM is not set CONFIG_ATM_NICSTAR=m # CONFIG_ATM_NICSTAR_USE_SUNI is not set # CONFIG_ATM_NICSTAR_USE_IDT77105 is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E is not set CONFIG_ATM_HE=m # CONFIG_ATM_HE_USE_SUNI is not set CONFIG_ATM_SOLOS=m # # CAIF transport drivers # CONFIG_VHOST_NET=m CONFIG_VHOST_SCSI=m CONFIG_VHOST_RING=m CONFIG_VHOST=m # # Distributed Switch Architecture drivers # CONFIG_NET_DSA_MV88E6XXX=m CONFIG_NET_DSA_MV88E6060=m CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y CONFIG_NET_DSA_MV88E6131=m CONFIG_NET_DSA_MV88E6123_61_65=m CONFIG_ETHERNET=y CONFIG_MDIO=m CONFIG_NET_VENDOR_3COM=y CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_3C589=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_VENDOR_ADAPTEC=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_NET_VENDOR_ALTEON=y CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_ALTERA_TSE=m CONFIG_NET_VENDOR_AMD=y CONFIG_AMD8111_ETH=m CONFIG_PCNET32=m CONFIG_PCMCIA_NMCLAN=m # CONFIG_NET_XGENE is not set CONFIG_NET_VENDOR_ARC=y CONFIG_NET_VENDOR_ATHEROS=y CONFIG_ATL2=m CONFIG_ATL1=m CONFIG_ATL1E=m CONFIG_ATL1C=m CONFIG_ALX=m CONFIG_NET_VENDOR_BROADCOM=y CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_BNX2=m CONFIG_CNIC=m CONFIG_TIGON3=m CONFIG_BNX2X=m CONFIG_BNX2X_SRIOV=y CONFIG_NET_VENDOR_BROCADE=y CONFIG_BNA=m # CONFIG_NET_CALXEDA_XGMAC is not set CONFIG_NET_VENDOR_CHELSIO=y CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T3=m CONFIG_CHELSIO_T4=m # CONFIG_CHELSIO_T4_DCB is not set CONFIG_CHELSIO_T4VF=m CONFIG_NET_VENDOR_CISCO=y CONFIG_ENIC=m # CONFIG_CX_ECAT is not set CONFIG_DNET=m CONFIG_NET_VENDOR_DEC=y CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_DE2104X_DSL=0 CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_ULI526X=m CONFIG_PCMCIA_XIRCOM=m CONFIG_NET_VENDOR_DLINK=y CONFIG_DL2K=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_NET_VENDOR_EMULEX=y CONFIG_BE2NET=m CONFIG_BE2NET_VXLAN=y CONFIG_NET_VENDOR_EXAR=y CONFIG_S2IO=m CONFIG_VXGE=m # CONFIG_VXGE_DEBUG_TRACE_ALL is not set # CONFIG_NET_VENDOR_FUJITSU is not set # CONFIG_NET_VENDOR_HP is not set CONFIG_NET_VENDOR_INTEL=y CONFIG_E100=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IGB=m CONFIG_IGB_HWMON=y CONFIG_IGB_DCA=y CONFIG_IGBVF=m CONFIG_IXGB=m CONFIG_IXGBE=m CONFIG_IXGBE_HWMON=y CONFIG_IXGBE_DCA=y CONFIG_IXGBE_DCB=y CONFIG_IXGBEVF=m CONFIG_I40E=m # CONFIG_I40E_VXLAN is not set # CONFIG_I40E_DCB is not set # CONFIG_I40EVF is not set # CONFIG_NET_VENDOR_I825XX is not set CONFIG_IP1000=m CONFIG_JME=m CONFIG_NET_VENDOR_MARVELL=y CONFIG_MVMDIO=m CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set CONFIG_SKGE_GENESIS=y CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_NET_VENDOR_MELLANOX=y CONFIG_MLX4_EN=m CONFIG_MLX4_EN_DCB=y # CONFIG_MLX4_EN_VXLAN is not set CONFIG_MLX4_CORE=m CONFIG_MLX4_DEBUG=y CONFIG_MLX5_CORE=m CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8842 is not set # CONFIG_KS8851 is not set # CONFIG_KS8851_MLL is not set CONFIG_KSZ884X_PCI=m CONFIG_NET_VENDOR_MICROCHIP=y # CONFIG_ENC28J60 is not set CONFIG_NET_VENDOR_MYRI=y CONFIG_MYRI10GE=m CONFIG_MYRI10GE_DCA=y CONFIG_FEALNX=m CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NATSEMI=m CONFIG_NS83820=m CONFIG_NET_VENDOR_8390=y CONFIG_PCMCIA_AXNET=m CONFIG_NE2K_PCI=m CONFIG_PCMCIA_PCNET=m CONFIG_NET_VENDOR_NVIDIA=y CONFIG_FORCEDETH=m CONFIG_NET_VENDOR_OKI=y CONFIG_ETHOC=m CONFIG_NET_PACKET_ENGINE=y CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_NET_VENDOR_QLOGIC=y CONFIG_QLA3XXX=m CONFIG_QLCNIC=m CONFIG_QLCNIC_SRIOV=y CONFIG_QLCNIC_DCB=y CONFIG_QLCNIC_VXLAN=y CONFIG_QLCNIC_HWMON=y CONFIG_QLGE=m CONFIG_NETXEN_NIC=m CONFIG_NET_VENDOR_REALTEK=y CONFIG_ATP=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_R8169=m # CONFIG_SH_ETH is not set CONFIG_NET_VENDOR_RDC=y CONFIG_R6040=m # CONFIG_NET_VENDOR_SAMSUNG is not set # CONFIG_NET_VENDOR_SEEQ is not set CONFIG_NET_VENDOR_SILAN=y CONFIG_SC92031=m CONFIG_NET_VENDOR_SIS=y CONFIG_SIS900=m CONFIG_SIS190=m CONFIG_SFC=m CONFIG_SFC_MTD=y CONFIG_SFC_MCDI_MON=y CONFIG_SFC_SRIOV=y CONFIG_NET_VENDOR_SMSC=y CONFIG_PCMCIA_SMC91C92=m CONFIG_EPIC100=m CONFIG_SMSC911X=m # CONFIG_SMSC911X_ARCH_HOOKS is not set CONFIG_SMSC9420=m CONFIG_NET_VENDOR_STMICRO=y CONFIG_STMMAC_ETH=m # CONFIG_STMMAC_PLATFORM is not set # CONFIG_STMMAC_PCI is not set # CONFIG_STMMAC_DEBUG_FS is not set # CONFIG_STMMAC_DA is not set CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NIU=m CONFIG_NET_VENDOR_TEHUTI=y CONFIG_TEHUTI=m CONFIG_NET_VENDOR_TI=y CONFIG_TLAN=m CONFIG_NET_VENDOR_VIA=y CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_VELOCITY=m CONFIG_NET_VENDOR_WIZNET=y CONFIG_WIZNET_W5100=m CONFIG_WIZNET_W5300=m # CONFIG_WIZNET_BUS_DIRECT is not set # CONFIG_WIZNET_BUS_INDIRECT is not set CONFIG_WIZNET_BUS_ANY=y CONFIG_NET_VENDOR_XIRCOM=y CONFIG_PCMCIA_XIRC2PS=m # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_AT803X_PHY=m CONFIG_AMD_PHY=m CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_BCM7XXX_PHY=m CONFIG_BCM87XX_PHY=m CONFIG_ICPLUS_PHY=m CONFIG_REALTEK_PHY=m CONFIG_NATIONAL_PHY=m CONFIG_STE10XP=m CONFIG_LSI_ET1011C_PHY=m CONFIG_MICREL_PHY=m CONFIG_FIXED_PHY=y CONFIG_MDIO_BITBANG=m # CONFIG_MDIO_GPIO is not set # CONFIG_MICREL_KS8995MA is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_FILTER=y CONFIG_PPP_MPPE=m CONFIG_PPP_MULTILINK=y CONFIG_PPPOATM=m CONFIG_PPPOE=m CONFIG_PPTP=m CONFIG_PPPOL2TP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_SLIP=m CONFIG_SLHC=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set CONFIG_USB_NET_DRIVERS=y CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_RTL8152=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_AX88179_178A=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_CDC_EEM=m CONFIG_USB_NET_CDC_NCM=m CONFIG_USB_NET_HUAWEI_CDC_NCM=m CONFIG_USB_NET_CDC_MBIM=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_SR9700=m # CONFIG_USB_NET_SR9800 is not set CONFIG_USB_NET_SMSC75XX=m CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_NET_CX82310_ETH=m CONFIG_USB_NET_KALMIA=m CONFIG_USB_NET_QMI_WWAN=m CONFIG_USB_HSO=m CONFIG_USB_NET_INT51X1=m CONFIG_USB_IPHETH=m CONFIG_USB_SIERRA_NET=m CONFIG_USB_VL600=m CONFIG_WLAN=y # CONFIG_PCMCIA_RAYCS is not set # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_AIRO is not set # CONFIG_ATMEL is not set CONFIG_AT76C50X_USB=m # CONFIG_AIRO_CS is not set # CONFIG_PCMCIA_WL3501 is not set # CONFIG_PRISM54 is not set # CONFIG_USB_ZD1201 is not set CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_RTL8187_LEDS=y # CONFIG_ADM8211 is not set CONFIG_MAC80211_HWSIM=m CONFIG_MWL8K=m CONFIG_ATH_COMMON=m CONFIG_ATH_CARDS=m # CONFIG_ATH_DEBUG is not set CONFIG_ATH5K=m CONFIG_ATH5K_DEBUG=y # CONFIG_ATH5K_TRACER is not set CONFIG_ATH5K_PCI=y CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K=m CONFIG_ATH9K_PCI=y CONFIG_ATH9K_AHB=y CONFIG_ATH9K_DEBUGFS=y # CONFIG_ATH9K_STATION_STATISTICS is not set # CONFIG_ATH9K_WOW is not set CONFIG_ATH9K_RFKILL=y CONFIG_ATH9K_HTC=m # CONFIG_ATH9K_HTC_DEBUGFS is not set CONFIG_CARL9170=m CONFIG_CARL9170_LEDS=y # CONFIG_CARL9170_DEBUGFS is not set CONFIG_CARL9170_WPC=y # CONFIG_CARL9170_HWRNG is not set CONFIG_ATH6KL=m CONFIG_ATH6KL_SDIO=m CONFIG_ATH6KL_USB=m CONFIG_ATH6KL_DEBUG=y # CONFIG_ATH6KL_TRACING is not set CONFIG_AR5523=m CONFIG_WIL6210=m CONFIG_WIL6210_ISR_COR=y # CONFIG_WIL6210_TRACING is not set CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m # CONFIG_ATH10K_DEBUG is not set CONFIG_ATH10K_DEBUGFS=y # CONFIG_ATH10K_TRACING is not set CONFIG_WCN36XX=m # CONFIG_WCN36XX_DEBUGFS is not set CONFIG_B43=m CONFIG_B43_BCMA=y CONFIG_B43_SSB=y CONFIG_B43_BUSES_BCMA_AND_SSB=y # CONFIG_B43_BUSES_BCMA is not set # CONFIG_B43_BUSES_SSB is not set CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_BCMA_PIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_G=y CONFIG_B43_PHY_N=y CONFIG_B43_PHY_LP=y CONFIG_B43_PHY_HT=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y # CONFIG_B43LEGACY_DEBUG is not set CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set CONFIG_BRCMUTIL=m CONFIG_BRCMSMAC=m CONFIG_BRCMFMAC=m CONFIG_BRCMFMAC_SDIO=y CONFIG_BRCMFMAC_USB=y CONFIG_BRCMFMAC_PCIE=y # CONFIG_BRCM_TRACING is not set # CONFIG_BRCMDBG is not set # CONFIG_HOSTAP is not set CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set CONFIG_LIBIPW=m # CONFIG_LIBIPW_DEBUG is not set CONFIG_IWLWIFI=m CONFIG_IWLWIFI_LEDS=y CONFIG_IWLDVM=m CONFIG_IWLMVM=m CONFIG_IWLWIFI_OPMODE_MODULAR=y # CONFIG_IWLWIFI_BCAST_FILTERING is not set # # Debugging Options # CONFIG_IWLWIFI_DEBUG=y CONFIG_IWLWIFI_DEBUGFS=y # CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE is not set # CONFIG_IWLWIFI_DEVICE_TRACING is not set CONFIG_IWLEGACY=m CONFIG_IWL4965=m CONFIG_IWL3945=m # # iwl3945 / iwl4965 Debugging Options # CONFIG_IWLEGACY_DEBUG=y CONFIG_IWLEGACY_DEBUGFS=y CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_CS=m CONFIG_LIBERTAS_SDIO=m # CONFIG_LIBERTAS_SPI is not set # CONFIG_LIBERTAS_DEBUG is not set CONFIG_LIBERTAS_MESH=y CONFIG_HERMES=m CONFIG_HERMES_PRISM=y CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=m # CONFIG_TMD_HERMES is not set CONFIG_NORTEL_HERMES=m CONFIG_PCI_HERMES=m CONFIG_PCMCIA_HERMES=m # CONFIG_PCMCIA_SPECTRUM is not set CONFIG_ORINOCO_USB=m CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m # CONFIG_P54_SPI is not set CONFIG_P54_LEDS=y CONFIG_RT2X00=m CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m CONFIG_RT2800PCI=m CONFIG_RT2800PCI_RT33XX=y CONFIG_RT2800PCI_RT35XX=y CONFIG_RT2800PCI_RT53XX=y CONFIG_RT2800PCI_RT3290=y CONFIG_RT2500USB=m CONFIG_RT73USB=m CONFIG_RT2800USB=m CONFIG_RT2800USB_RT33XX=y CONFIG_RT2800USB_RT35XX=y CONFIG_RT2800USB_RT3573=y CONFIG_RT2800USB_RT53XX=y CONFIG_RT2800USB_RT55XX=y CONFIG_RT2800USB_UNKNOWN=y CONFIG_RT2800_LIB=m CONFIG_RT2800_LIB_MMIO=m CONFIG_RT2X00_LIB_MMIO=m CONFIG_RT2X00_LIB_PCI=m CONFIG_RT2X00_LIB_USB=m CONFIG_RT2X00_LIB=m CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y CONFIG_RT2X00_LIB_DEBUGFS=y # CONFIG_RT2X00_DEBUG is not set CONFIG_RTL_CARDS=m CONFIG_RTL8192CE=m CONFIG_RTL8192SE=m CONFIG_RTL8192DE=m CONFIG_RTL8723AE=m CONFIG_RTL8723BE=m CONFIG_RTL8188EE=m CONFIG_RTL8192CU=m CONFIG_RTLWIFI=m CONFIG_RTLWIFI_PCI=m CONFIG_RTLWIFI_USB=m # CONFIG_RTLWIFI_DEBUG is not set CONFIG_RTL8192C_COMMON=m CONFIG_RTL8723_COMMON=m CONFIG_RTLBTCOEXIST=m # CONFIG_WL_TI is not set CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set CONFIG_MWIFIEX=m CONFIG_MWIFIEX_SDIO=m CONFIG_MWIFIEX_PCIE=m CONFIG_MWIFIEX_USB=m CONFIG_CW1200=m CONFIG_CW1200_WLAN_SDIO=m # CONFIG_CW1200_WLAN_SPI is not set CONFIG_RSI_91X=m CONFIG_RSI_DEBUGFS=y CONFIG_RSI_SDIO=m CONFIG_RSI_USB=m # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set CONFIG_IEEE802154_DRIVERS=m CONFIG_IEEE802154_FAKEHARD=m CONFIG_IEEE802154_FAKELB=m # CONFIG_IEEE802154_AT86RF230 is not set # CONFIG_IEEE802154_MRF24J40 is not set # CONFIG_IEEE802154_CC2520 is not set CONFIG_XEN_NETDEV_FRONTEND=m CONFIG_XEN_NETDEV_BACKEND=m CONFIG_VMXNET3=m CONFIG_HYPERV_NET=m CONFIG_ISDN=y CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y # # ISDN feature submodules # CONFIG_ISDN_DIVERSION=m # # ISDN4Linux hardware drivers # # # Passive cards # CONFIG_ISDN_DRV_HISAX=m # # D-channel protocol features # CONFIG_HISAX_EURO=y CONFIG_DE_AOC=y CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 # # HiSax supported cards # CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set # # HiSax PCMCIA card service modules # CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_TELES_CS=m # # HiSax sub driver modules # CONFIG_HISAX_ST5481=m # CONFIG_HISAX_HFCUSB is not set CONFIG_HISAX_HFC4S8S=m CONFIG_HISAX_FRITZ_PCIPNP=m # # Active cards # CONFIG_ISDN_CAPI=m # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPIDRV=m # CONFIG_ISDN_CAPI_CAPIDRV_VERBOSE is not set # # CAPI hardware drivers # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m CONFIG_CAPI_EICON=y CONFIG_ISDN_DIVAS=m CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_ISDN_DIVAS_DIVACAPI=m CONFIG_ISDN_DIVAS_USERIDI=m CONFIG_ISDN_DIVAS_MAINT=m CONFIG_ISDN_DRV_GIGASET=m CONFIG_GIGASET_CAPI=y # CONFIG_GIGASET_I4L is not set # CONFIG_GIGASET_DUMMYLL is not set CONFIG_GIGASET_BASE=m CONFIG_GIGASET_M105=m CONFIG_GIGASET_M101=m # CONFIG_GIGASET_DEBUG is not set CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y CONFIG_MISDN=m CONFIG_MISDN_DSP=m CONFIG_MISDN_L1OIP=m # # mISDN hardware drivers # CONFIG_MISDN_HFCPCI=m CONFIG_MISDN_HFCMULTI=m CONFIG_MISDN_HFCUSB=m CONFIG_MISDN_AVMFRITZ=m CONFIG_MISDN_SPEEDFAX=m CONFIG_MISDN_INFINEON=m CONFIG_MISDN_W6692=m CONFIG_MISDN_NETJET=m CONFIG_MISDN_IPAC=m CONFIG_MISDN_ISAR=m CONFIG_ISDN_HDLC=m # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_SPARSEKMAP=m # 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=m CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_GPIO is not set # 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_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_CYPRESS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y CONFIG_MOUSE_PS2_ELANTECH=y CONFIG_MOUSE_PS2_SENTELIC=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m CONFIG_MOUSE_BCM5974=m CONFIG_MOUSE_CYAPA=m CONFIG_MOUSE_VSXXXAA=m # CONFIG_MOUSE_GPIO is not set CONFIG_MOUSE_SYNAPTICS_I2C=m CONFIG_MOUSE_SYNAPTICS_USB=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDJOY=m CONFIG_JOYSTICK_ZHENHUA=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m # CONFIG_JOYSTICK_AS5011 is not set CONFIG_JOYSTICK_JOYDUMP=m CONFIG_JOYSTICK_XPAD=m CONFIG_JOYSTICK_XPAD_FF=y CONFIG_JOYSTICK_XPAD_LEDS=y CONFIG_JOYSTICK_WALKERA0701=m CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_HANWANG=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_SERIAL_WACOM4=m CONFIG_INPUT_TOUCHSCREEN=y # CONFIG_TOUCHSCREEN_ADS7846 is not set # CONFIG_TOUCHSCREEN_AD7877 is not set # CONFIG_TOUCHSCREEN_AD7879 is not set CONFIG_TOUCHSCREEN_ATMEL_MXT=m CONFIG_TOUCHSCREEN_AUO_PIXCIR=m # CONFIG_TOUCHSCREEN_BU21013 is not set # CONFIG_TOUCHSCREEN_CY8CTMG110 is not set # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set # CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set CONFIG_TOUCHSCREEN_DYNAPRO=m # CONFIG_TOUCHSCREEN_HAMPSHIRE is not set CONFIG_TOUCHSCREEN_EETI=m CONFIG_TOUCHSCREEN_FUJITSU=m CONFIG_TOUCHSCREEN_ILI210X=m CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_WACOM_W8001=m CONFIG_TOUCHSCREEN_WACOM_I2C=m # CONFIG_TOUCHSCREEN_MAX11801 is not set CONFIG_TOUCHSCREEN_MCS5000=m CONFIG_TOUCHSCREEN_MMS114=m CONFIG_TOUCHSCREEN_MTOUCH=m CONFIG_TOUCHSCREEN_INEXIO=m CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_EDT_FT5X06=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_PIXCIR=m # CONFIG_TOUCHSCREEN_WM97XX is not set CONFIG_TOUCHSCREEN_USB_COMPOSITE=m CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y CONFIG_TOUCHSCREEN_USB_JASTEC=y CONFIG_TOUCHSCREEN_USB_ELO=y CONFIG_TOUCHSCREEN_USB_E2I=y CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y CONFIG_TOUCHSCREEN_USB_NEXIO=y CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y CONFIG_TOUCHSCREEN_TOUCHIT213=m CONFIG_TOUCHSCREEN_TSC_SERIO=m # CONFIG_TOUCHSCREEN_TSC2005 is not set CONFIG_TOUCHSCREEN_TSC2007=m CONFIG_TOUCHSCREEN_ST1232=m # CONFIG_TOUCHSCREEN_SUR40 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set CONFIG_TOUCHSCREEN_ZFORCE=m CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_MMA8450=m CONFIG_INPUT_MPU3050=m CONFIG_INPUT_APANEL=m CONFIG_INPUT_GP2A=m # CONFIG_INPUT_GPIO_BEEPER is not set # CONFIG_INPUT_GPIO_TILT_POLLED is not set CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m CONFIG_INPUT_KXTJ9=m # CONFIG_INPUT_KXTJ9_POLLED_MODE is not set CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m CONFIG_INPUT_CM109=m CONFIG_INPUT_UINPUT=m # CONFIG_INPUT_PCF8574 is not set CONFIG_INPUT_GPIO_ROTARY_ENCODER=m # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_IMS_PCU is not set CONFIG_INPUT_CMA3000=m CONFIG_INPUT_CMA3000_I2C=m CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y CONFIG_INPUT_IDEAPAD_SLIDEBAR=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_SERIO_ALTERA_PS2=m # CONFIG_SERIO_PS2MULT is not set CONFIG_SERIO_ARC_PS2=m CONFIG_HYPERV_KEYBOARD=m CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_FM801=m # # 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_DEVPTS_MULTIPLE_INSTANCES=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_NONSTANDARD=y CONFIG_ROCKETPORT=m CONFIG_CYCLADES=m # CONFIG_CYZ_INTR is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_NOZOMI=m # CONFIG_ISI is not set CONFIG_N_HDLC=m CONFIG_N_GSM=m # CONFIG_TRACE_SINK is not set # CONFIG_DEVKMEM is not set # # Serial drivers # CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_CS=m 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 is not set CONFIG_SERIAL_8250_RSA=y # CONFIG_SERIAL_8250_DW is not set # # Non-8250 serial port support # # CONFIG_SERIAL_KGDB_NMI is not set # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX310X is not set # CONFIG_SERIAL_MFD_HSU is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y CONFIG_SERIAL_JSM=m # 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=m CONFIG_SERIAL_ARC_NR_PORTS=1 # CONFIG_SERIAL_RP2 is not set # CONFIG_SERIAL_FSL_LPUART is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_HVC_XEN_FRONTEND=y CONFIG_VIRTIO_CONSOLE=m CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m # CONFIG_IPMI_SI_PROBE_DEFAULTS is not set CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_HW_RANDOM_TPM=m CONFIG_NVRAM=y CONFIG_R3964=m # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_IPWIRELESS=m CONFIG_MWAVE=m CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=8192 CONFIG_HPET=y # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=m CONFIG_UV_MMTIMER=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m # CONFIG_TCG_TIS_I2C_ATMEL is not set # CONFIG_TCG_TIS_I2C_INFINEON is not set # CONFIG_TCG_TIS_I2C_NUVOTON is not set CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TCG_ST33_I2C is not set # CONFIG_TCG_XEN is not set CONFIG_TELCLOCK=m CONFIG_DEVPORT=y # # I2C support # CONFIG_I2C=y CONFIG_ACPI_I2C_OPREGION=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_MUX=m # # Multiplexer I2C Chip support # # CONFIG_I2C_MUX_GPIO is not set # CONFIG_I2C_MUX_PCA9541 is not set # CONFIG_I2C_MUX_PCA954x is not set # CONFIG_I2C_MUX_PINCTRL is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCA=m # # 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=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_ISCH=m CONFIG_I2C_ISMT=m CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_NFORCE2_S4985=m # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set CONFIG_I2C_SIS96X=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # # ACPI drivers # CONFIG_I2C_SCMI=m # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_CBUS_GPIO is not set CONFIG_I2C_DESIGNWARE_CORE=m CONFIG_I2C_DESIGNWARE_PLATFORM=m CONFIG_I2C_DESIGNWARE_PCI=m # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set CONFIG_I2C_PCA_PLATFORM=m # CONFIG_I2C_PXA_PCI is not set CONFIG_I2C_SIMTEC=m # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # CONFIG_I2C_DIOLAN_U2C=m CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m # CONFIG_I2C_ROBOTFUZZ_OSIF is not set # CONFIG_I2C_TAOS_EVM is not set CONFIG_I2C_TINY_USB=m CONFIG_I2C_VIPERBOARD=m # # Other I2C/SMBus bus drivers # CONFIG_I2C_STUB=m # 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 # # SPI Master Controller Drivers # # CONFIG_SPI_ALTERA is not set # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_BUTTERFLY is not set # CONFIG_SPI_GPIO is not set # CONFIG_SPI_LM70_LLP is not set # CONFIG_SPI_OC_TINY is not set # CONFIG_SPI_PXA2XX is not set # CONFIG_SPI_PXA2XX_PCI is not set # CONFIG_SPI_SC18IS602 is not set # CONFIG_SPI_XCOMM is not set # CONFIG_SPI_XILINX is not set # CONFIG_SPI_DESIGNWARE is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # CONFIG_SPMI is not set # CONFIG_HSI is not set # # PPS support # CONFIG_PPS=m # CONFIG_PPS_DEBUG is not set # # PPS clients support # # CONFIG_PPS_CLIENT_KTIMER is not set CONFIG_PPS_CLIENT_LDISC=m CONFIG_PPS_CLIENT_PARPORT=m CONFIG_PPS_CLIENT_GPIO=m # # PPS generators support # # # PTP clock support # CONFIG_PTP_1588_CLOCK=m CONFIG_DP83640_PHY=m CONFIG_PINCTRL=y # # Pin controllers # # CONFIG_DEBUG_PINCTRL is not set CONFIG_PINCTRL_BAYTRAIL=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y CONFIG_GPIO_DEVRES=y CONFIG_GPIO_ACPI=y CONFIG_GPIOLIB_IRQCHIP=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y # # Memory mapped GPIO drivers: # # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_IT8761E is not set # CONFIG_GPIO_F7188X is not set # CONFIG_GPIO_SCH311X is not set # CONFIG_GPIO_SCH is not set CONFIG_GPIO_ICH=m # CONFIG_GPIO_VX855 is not set # CONFIG_GPIO_LYNXPOINT is not set # # I2C GPIO expanders: # # 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_SX150X is not set # CONFIG_GPIO_ADP5588 is not set # # PCI GPIO expanders: # # CONFIG_GPIO_AMD8111 is not set # CONFIG_GPIO_INTEL_MID is not set # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders: # # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MC33880 is not set # # AC97 GPIO expanders: # # # LPC GPIO expanders: # # # MODULbus GPIO expanders: # # # USB GPIO expanders: # CONFIG_GPIO_VIPERBOARD=m CONFIG_W1=m CONFIG_W1_CON=y # # 1-wire Bus Masters # # CONFIG_W1_MASTER_MATROX is not set CONFIG_W1_MASTER_DS2490=m CONFIG_W1_MASTER_DS2482=m CONFIG_W1_MASTER_DS1WM=m # CONFIG_W1_MASTER_GPIO is not set # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2408=m # CONFIG_W1_SLAVE_DS2408_READBACK is not set CONFIG_W1_SLAVE_DS2413=m CONFIG_W1_SLAVE_DS2406=m CONFIG_W1_SLAVE_DS2423=m CONFIG_W1_SLAVE_DS2431=m CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y CONFIG_W1_SLAVE_DS2760=m CONFIG_W1_SLAVE_DS2780=m CONFIG_W1_SLAVE_DS2781=m CONFIG_W1_SLAVE_DS28E04=m CONFIG_W1_SLAVE_BQ27000=m CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_GENERIC_ADC_BATTERY is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2760 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_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_ISP1704 is not set # CONFIG_CHARGER_MAX8903 is not set # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_BQ2415X is not set # CONFIG_CHARGER_BQ24190 is not set # CONFIG_CHARGER_BQ24735 is not set CONFIG_CHARGER_SMB347=m CONFIG_POWER_RESET=y # CONFIG_POWER_AVS is not set CONFIG_HWMON=y CONFIG_HWMON_VID=m # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m # CONFIG_SENSORS_AD7314 is not set CONFIG_SENSORS_AD7414=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ADT7X10=m # CONFIG_SENSORS_ADT7310 is not set CONFIG_SENSORS_ADT7410=m CONFIG_SENSORS_ADT7411=m CONFIG_SENSORS_ADT7462=m CONFIG_SENSORS_ADT7470=m CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_ASC7621=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_K10TEMP=m CONFIG_SENSORS_FAM15H_POWER=m CONFIG_SENSORS_APPLESMC=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS620=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_F71882FG=m CONFIG_SENSORS_F75375S=m CONFIG_SENSORS_FSCHMD=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_G760A=m CONFIG_SENSORS_G762=m # CONFIG_SENSORS_GPIO_FAN is not set # CONFIG_SENSORS_HIH6130 is not set CONFIG_SENSORS_IBMAEM=m CONFIG_SENSORS_IBMPEX=m # CONFIG_SENSORS_IIO_HWMON is not set CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IT87=m # CONFIG_SENSORS_JC42 is not set CONFIG_SENSORS_POWR1220=m CONFIG_SENSORS_LINEAGE=m CONFIG_SENSORS_LTC2945=m CONFIG_SENSORS_LTC4151=m CONFIG_SENSORS_LTC4215=m CONFIG_SENSORS_LTC4222=m CONFIG_SENSORS_LTC4245=m CONFIG_SENSORS_LTC4260=m CONFIG_SENSORS_LTC4261=m # CONFIG_SENSORS_MAX1111 is not set CONFIG_SENSORS_MAX16065=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX1668=m CONFIG_SENSORS_MAX197=m CONFIG_SENSORS_MAX6639=m CONFIG_SENSORS_MAX6642=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_MAX6697=m # CONFIG_SENSORS_HTU21 is not set CONFIG_SENSORS_MCP3021=m # CONFIG_SENSORS_ADCXX is not set CONFIG_SENSORS_LM63=m # CONFIG_SENSORS_LM70 is not set CONFIG_SENSORS_LM73=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_LM95234=m CONFIG_SENSORS_LM95241=m CONFIG_SENSORS_LM95245=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_NTC_THERMISTOR=m CONFIG_SENSORS_NCT6683=m CONFIG_SENSORS_NCT6775=m CONFIG_SENSORS_PCF8591=m CONFIG_PMBUS=m CONFIG_SENSORS_PMBUS=m CONFIG_SENSORS_ADM1275=m CONFIG_SENSORS_LM25066=m CONFIG_SENSORS_LTC2978=m CONFIG_SENSORS_MAX16064=m CONFIG_SENSORS_MAX34440=m CONFIG_SENSORS_MAX8688=m CONFIG_SENSORS_TPS40422=m CONFIG_SENSORS_UCD9000=m CONFIG_SENSORS_UCD9200=m CONFIG_SENSORS_ZL6100=m CONFIG_SENSORS_SHT15=m CONFIG_SENSORS_SHT21=m CONFIG_SENSORS_SHTC1=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_EMC1403=m # CONFIG_SENSORS_EMC2103 is not set CONFIG_SENSORS_EMC6W201=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_SCH56XX_COMMON=m CONFIG_SENSORS_SCH5627=m CONFIG_SENSORS_SCH5636=m # CONFIG_SENSORS_SMM665 is not set CONFIG_SENSORS_ADC128D818=m CONFIG_SENSORS_ADS1015=m CONFIG_SENSORS_ADS7828=m # CONFIG_SENSORS_ADS7871 is not set CONFIG_SENSORS_AMC6821=m CONFIG_SENSORS_INA209=m CONFIG_SENSORS_INA2XX=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP102=m CONFIG_SENSORS_TMP103=m CONFIG_SENSORS_TMP401=m CONFIG_SENSORS_TMP421=m CONFIG_SENSORS_VIA_CPUTEMP=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83795=m # CONFIG_SENSORS_W83795_FANCTRL is not set CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m # # ACPI drivers # CONFIG_SENSORS_ACPI_POWER=m CONFIG_SENSORS_ATK0110=m CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=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_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_USER_SPACE=y # CONFIG_THERMAL_EMULATION is not set # CONFIG_INTEL_POWERCLAMP is not set CONFIG_X86_PKG_TEMP_THERMAL=m CONFIG_ACPI_INT3403_THERMAL=m CONFIG_INTEL_SOC_DTS_THERMAL=m # # Texas Instruments thermal drivers # CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_XILINX_WATCHDOG is not set # CONFIG_DW_WATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_F71808E_WDT=m CONFIG_SP5100_TCO=m CONFIG_SBC_FITPC2_WATCHDOG=m # CONFIG_EUROTECH_WDT is not set CONFIG_IB700_WDT=m CONFIG_IBMASR=m # CONFIG_WAFER_WDT is not set CONFIG_I6300ESB_WDT=m CONFIG_IE6XX_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y CONFIG_IT8712F_WDT=m CONFIG_IT87_WDT=m CONFIG_HP_WATCHDOG=m CONFIG_HPWDT_NMI_DECODING=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set CONFIG_NV_TCO=m # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_SMSC_SCH311X_WDT=m # CONFIG_SMSC37B787_WDT is not set CONFIG_VIA_WDT=m CONFIG_W83627HF_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set # CONFIG_MEN_A21_WDT is not set CONFIG_XEN_WDT=m # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y CONFIG_SSB_PCMCIAHOST=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_SSB_DRIVER_GPIO=y CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # CONFIG_BCMA=m CONFIG_BCMA_BLOCKIO=y CONFIG_BCMA_HOST_PCI_POSSIBLE=y CONFIG_BCMA_HOST_PCI=y # CONFIG_BCMA_HOST_SOC is not set CONFIG_BCMA_DRIVER_GMAC_CMN=y CONFIG_BCMA_DRIVER_GPIO=y # CONFIG_BCMA_DEBUG is not set # # Multifunction device drivers # CONFIG_MFD_CORE=m # 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_AXP20X is not set # CONFIG_MFD_CROS_EC 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_DA9063 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_LPC_ICH=m CONFIG_LPC_SCH=m # CONFIG_INTEL_SOC_PMIC is not set # 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_MAX77686 is not set # CONFIG_MFD_MAX77693 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_EZX_PCAP is not set CONFIG_MFD_VIPERBOARD=m # CONFIG_MFD_RETU is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_UCB1400_CORE is not set # CONFIG_MFD_RDC321X is not set CONFIG_MFD_RTSX_PCI=m CONFIG_MFD_RTSX_USB=m # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set CONFIG_MFD_SM501=m CONFIG_MFD_SM501_GPIO=y # 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_PALMAS is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TPS65218 is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912 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=m # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set CONFIG_MFD_VX855=m # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_ARIZONA_SPI is not set # 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 is not set CONFIG_MEDIA_SUPPORT=m # # Multimedia core support # CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_ANALOG_TV_SUPPORT=y CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y CONFIG_MEDIA_RADIO_SUPPORT=y # CONFIG_MEDIA_SDR_SUPPORT is not set CONFIG_MEDIA_RC_SUPPORT=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_V4L2=m # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_TUNER=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_DMA_CONTIG=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_VIDEOBUF2_DMA_SG=m CONFIG_VIDEOBUF2_DVB=m CONFIG_DVB_CORE=m CONFIG_DVB_NET=y CONFIG_TTPCI_EEPROM=m CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_DYNAMIC_MINORS=y # # Media drivers # CONFIG_RC_CORE=m CONFIG_RC_MAP=m CONFIG_RC_DECODERS=y CONFIG_LIRC=m CONFIG_IR_LIRC_CODEC=m CONFIG_IR_NEC_DECODER=m CONFIG_IR_RC5_DECODER=m CONFIG_IR_RC6_DECODER=m CONFIG_IR_JVC_DECODER=m CONFIG_IR_SONY_DECODER=m CONFIG_IR_SANYO_DECODER=m CONFIG_IR_SHARP_DECODER=m CONFIG_IR_MCE_KBD_DECODER=m CONFIG_IR_XMP_DECODER=m CONFIG_RC_DEVICES=y CONFIG_RC_ATI_REMOTE=m CONFIG_IR_ENE=m CONFIG_IR_IMON=m CONFIG_IR_MCEUSB=m CONFIG_IR_ITE_CIR=m CONFIG_IR_FINTEK=m CONFIG_IR_NUVOTON=m CONFIG_IR_REDRAT3=m CONFIG_IR_STREAMZAP=m CONFIG_IR_WINBOND_CIR=m CONFIG_IR_IGUANA=m CONFIG_IR_TTUSBIR=m # CONFIG_IR_IMG is not set CONFIG_RC_LOOPBACK=m CONFIG_IR_GPIO_CIR=m CONFIG_MEDIA_USB_SUPPORT=y # # Webcam devices # CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_BENQ=m CONFIG_USB_GSPCA_CONEX=m CONFIG_USB_GSPCA_CPIA1=m CONFIG_USB_GSPCA_DTCS033=m CONFIG_USB_GSPCA_ETOMS=m CONFIG_USB_GSPCA_FINEPIX=m CONFIG_USB_GSPCA_JEILINJ=m CONFIG_USB_GSPCA_JL2005BCD=m CONFIG_USB_GSPCA_KINECT=m CONFIG_USB_GSPCA_KONICA=m CONFIG_USB_GSPCA_MARS=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_NW80X=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_OV534_9=m CONFIG_USB_GSPCA_PAC207=m CONFIG_USB_GSPCA_PAC7302=m CONFIG_USB_GSPCA_PAC7311=m CONFIG_USB_GSPCA_SE401=m CONFIG_USB_GSPCA_SN9C2028=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SPCA1528=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_SQ930X=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_STK1135=m CONFIG_USB_GSPCA_STV0680=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m CONFIG_USB_GSPCA_TOPRO=m CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m CONFIG_USB_GSPCA_VICAM=m CONFIG_USB_GSPCA_XIRLINK_CIT=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_VIDEO_CPIA2=m CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_VIDEO_USBTV=m # # Analog TV USB devices # CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_TLG2300=m CONFIG_VIDEO_USBVISION=m CONFIG_VIDEO_STK1160_COMMON=m CONFIG_VIDEO_STK1160_AC97=y CONFIG_VIDEO_STK1160=m # CONFIG_VIDEO_GO7007 is not set # # Analog/digital TV USB devices # CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_AU0828_V4L2=y # CONFIG_VIDEO_AU0828_RC is not set CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_RC=y CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m CONFIG_VIDEO_TM6000=m CONFIG_VIDEO_TM6000_ALSA=m CONFIG_VIDEO_TM6000_DVB=m # # Digital TV USB devices # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m CONFIG_DVB_USB_PCTV452E=m CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_USB_AZ6027=m CONFIG_DVB_USB_TECHNISAT_USB2=m CONFIG_DVB_USB_V2=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_USB_AF9035=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_AZ6007=m CONFIG_DVB_USB_CE6230=m CONFIG_DVB_USB_EC168=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_LME2510=m CONFIG_DVB_USB_MXL111SF=m CONFIG_DVB_USB_RTL28XXU=m CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_SMS_USB_DRV=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set # # Webcam, TV (analog/digital) USB devices # CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_V4L2=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_EM28XX_RC=m CONFIG_MEDIA_PCI_SUPPORT=y # # Media capture support # CONFIG_VIDEO_MEYE=m # # Media capture/analog TV support # CONFIG_VIDEO_IVTV=m # CONFIG_VIDEO_IVTV_ALSA is not set CONFIG_VIDEO_FB_IVTV=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_ZR36060=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_SOLO6X10=m # # Media capture/analog/hybrid TV support # CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CX18_ALSA=m CONFIG_VIDEO_CX23885=m CONFIG_MEDIA_ALTERA_CI=m # CONFIG_VIDEO_CX25821 is not set CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_ENABLE_VP3054=y CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_BT848=m CONFIG_DVB_BT8XX=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_RC=y CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_SAA7164=m # # Media digital TV PCI Adapters # CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m # CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set CONFIG_DVB_PLUTO2=m CONFIG_DVB_DM1105=m CONFIG_DVB_PT1=m CONFIG_MANTIS_CORE=m CONFIG_DVB_MANTIS=m CONFIG_DVB_HOPPER=m CONFIG_DVB_NGENE=m CONFIG_DVB_DDBRIDGE=m # CONFIG_V4L_PLATFORM_DRIVERS is not set CONFIG_V4L_MEM2MEM_DRIVERS=y # CONFIG_VIDEO_MEM2MEM_DEINTERLACE is not set # CONFIG_VIDEO_SH_VEU is not set # CONFIG_VIDEO_RENESAS_VSP1 is not set # CONFIG_V4L_TEST_DRIVERS is not set # # Supported MMC/SDIO adapters # CONFIG_SMS_SDIO_DRV=m # CONFIG_MEDIA_PARPORT_SUPPORT is not set CONFIG_RADIO_ADAPTERS=y CONFIG_RADIO_TEA575X=m CONFIG_RADIO_SI470X=y CONFIG_USB_SI470X=m CONFIG_I2C_SI470X=m CONFIG_RADIO_SI4713=m # CONFIG_USB_SI4713 is not set # CONFIG_PLATFORM_SI4713 is not set # CONFIG_I2C_SI4713 is not set CONFIG_USB_MR800=m CONFIG_USB_DSBR=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_SHARK=m CONFIG_RADIO_SHARK2=m CONFIG_USB_KEENE=m # CONFIG_USB_RAREMONO is not set CONFIG_USB_MA901=m CONFIG_RADIO_TEA5764=m CONFIG_RADIO_SAA7706H=m # CONFIG_RADIO_TEF6862 is not set CONFIG_RADIO_WL1273=m # # Texas Instruments WL128x FM driver (ST based) # # CONFIG_RADIO_WL128X is not set # # Supported FireWire (IEEE 1394) Adapters # CONFIG_DVB_FIREDTV=m CONFIG_DVB_FIREDTV_INPUT=y CONFIG_MEDIA_COMMON_OPTIONS=y # # common driver options # CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_TVEEPROM=m CONFIG_CYPRESS_FIRMWARE=m CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_SMS_SIANO_MDTV=m CONFIG_SMS_SIANO_RC=y # CONFIG_SMS_SIANO_DEBUGFS is not set # # Media ancillary drivers (tuners, sensors, i2c, frontends) # CONFIG_MEDIA_SUBDRV_AUTOSELECT=y CONFIG_MEDIA_ATTACH=y CONFIG_VIDEO_IR_I2C=m # # Audio decoders, processors and mixers # CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_TDA9840=m CONFIG_VIDEO_TEA6415C=m CONFIG_VIDEO_TEA6420=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m # # RDS decoders # CONFIG_VIDEO_SAA6588=m # # Video decoders # CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m CONFIG_VIDEO_BT866=m CONFIG_VIDEO_KS0127=m CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_VPX3220=m # # Video and audio decoders # CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_CX25840=m # # Video encoders # CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7185=m CONFIG_VIDEO_ADV7170=m CONFIG_VIDEO_ADV7175=m # # Camera sensor devices # CONFIG_VIDEO_MT9V011=m # # Flash devices # # # Video improvement chips # CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m # # Audio/Video compression chips # CONFIG_VIDEO_SAA6752HS=m # # Miscellaneous helper chips # CONFIG_VIDEO_M52790=m # # Sensors used on soc_camera driver # CONFIG_MEDIA_TUNER=m CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2063=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_XC4000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_MEDIA_TUNER_MC44S803=m CONFIG_MEDIA_TUNER_MAX2165=m CONFIG_MEDIA_TUNER_TDA18218=m CONFIG_MEDIA_TUNER_FC0011=m CONFIG_MEDIA_TUNER_FC0012=m CONFIG_MEDIA_TUNER_FC0013=m CONFIG_MEDIA_TUNER_TDA18212=m CONFIG_MEDIA_TUNER_E4000=m CONFIG_MEDIA_TUNER_FC2580=m CONFIG_MEDIA_TUNER_M88TS2022=m CONFIG_MEDIA_TUNER_TUA9001=m CONFIG_MEDIA_TUNER_SI2157=m CONFIG_MEDIA_TUNER_IT913X=m CONFIG_MEDIA_TUNER_R820T=m # # Multistandard (satellite) frontends # CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_STV090x=m CONFIG_DVB_STV6110x=m CONFIG_DVB_M88DS3103=m # # Multistandard (cable + terrestrial) frontends # CONFIG_DVB_DRXK=m CONFIG_DVB_TDA18271C2DD=m CONFIG_DVB_SI2165=m # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_ZL10036=m CONFIG_DVB_ZL10039=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TUNER_CX24113=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_CX24117=m CONFIG_DVB_SI21XX=m CONFIG_DVB_TS2020=m CONFIG_DVB_DS3000=m CONFIG_DVB_MB86A16=m CONFIG_DVB_TDA10071=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_DRXD=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m CONFIG_DVB_AF9013=m CONFIG_DVB_EC100=m CONFIG_DVB_STV0367=m CONFIG_DVB_CXD2820R=m CONFIG_DVB_RTL2830=m CONFIG_DVB_RTL2832=m CONFIG_DVB_SI2168=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_LG2160=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_AU8522_DTV=m CONFIG_DVB_AU8522_V4L=m CONFIG_DVB_S5H1411=m # # ISDB-T (terrestrial) frontends # CONFIG_DVB_S921=m CONFIG_DVB_DIB8000=m CONFIG_DVB_MB86A20S=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m CONFIG_DVB_TUNER_DIB0090=m # # SEC control devices for DVB-S # CONFIG_DVB_DRX39XYJ=m CONFIG_DVB_LNBP21=m CONFIG_DVB_LNBP22=m CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m CONFIG_DVB_ISL6423=m CONFIG_DVB_A8293=m CONFIG_DVB_LGS8GXX=m CONFIG_DVB_ATBM8830=m CONFIG_DVB_TDA665x=m CONFIG_DVB_IX2505V=m CONFIG_DVB_M88RS2000=m CONFIG_DVB_AF9033=m # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_AGP_SIS=y CONFIG_AGP_VIA=y CONFIG_INTEL_GTT=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y # # Direct Rendering Manager # CONFIG_DRM=m CONFIG_DRM_USB=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_LOAD_EDID_FIRMWARE=y CONFIG_DRM_TTM=m # # I2C encoder or helper chips # CONFIG_DRM_I2C_CH7006=m CONFIG_DRM_I2C_SIL164=m CONFIG_DRM_I2C_NXP_TDA998X=m CONFIG_DRM_PTN3460=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_UMS is not set CONFIG_DRM_NOUVEAU=m CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 CONFIG_DRM_NOUVEAU_BACKLIGHT=y # CONFIG_DRM_I810 is not set CONFIG_DRM_I915=m CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=m # CONFIG_DRM_SAVAGE is not set CONFIG_DRM_VMWGFX=m CONFIG_DRM_VMWGFX_FBCON=y CONFIG_DRM_GMA500=m # CONFIG_DRM_GMA600 is not set CONFIG_DRM_GMA3600=y CONFIG_DRM_UDL=m CONFIG_DRM_AST=m CONFIG_DRM_MGAG200=m CONFIG_DRM_CIRRUS_QEMU=m CONFIG_DRM_QXL=m CONFIG_DRM_BOCHS=m # # Frame buffer Devices # CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set 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_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y # CONFIG_FB_MODE_HELPERS is not set 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=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y CONFIG_FB_EFI=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_SM501 is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set CONFIG_FB_VIRTUAL=m CONFIG_XEN_FBDEV_FRONTEND=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_AUO_K190X is not set CONFIG_FB_HYPERV=m # CONFIG_FB_SIMPLE 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_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_BACKLIGHT_APPLE=m # CONFIG_BACKLIGHT_SAHARA is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # CONFIG_BACKLIGHT_LM3639 is not set # CONFIG_BACKLIGHT_GPIO is not set # CONFIG_BACKLIGHT_LV5207LP is not set # CONFIG_BACKLIGHT_BD6107 is not set CONFIG_VGASTATE=m CONFIG_HDMI=y # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_MAX_CARDS=32 # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y # CONFIG_SND_DEBUG_VERBOSE is not set CONFIG_SND_PCM_XRUN_DEBUG=y CONFIG_SND_VMASTER=y CONFIG_SND_KCTL_JACK=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_OPL3_LIB_SEQ=m # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set CONFIG_SND_EMU10K1_SEQ=m CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_ALOOP=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_SB_COMMON=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m CONFIG_SND_ALS300=m CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ASIHPI=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CTXFI=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_INDIGOIOX=m CONFIG_SND_INDIGODJX=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_ES1968_INPUT=y CONFIG_SND_ES1968_RADIO=y CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_LOLA=m CONFIG_SND_LX6464ES=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MAESTRO3_INPUT=y CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m # # HD-Audio # CONFIG_SND_HDA=m CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_DSP_LOADER=y CONFIG_SND_HDA_PREALLOC_SIZE=4096 CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_INPUT_BEEP_MODE=0 CONFIG_SND_HDA_INPUT_JACK=y CONFIG_SND_HDA_PATCH_LOADER=y CONFIG_SND_HDA_CODEC_REALTEK=m CONFIG_SND_HDA_CODEC_ANALOG=m CONFIG_SND_HDA_CODEC_SIGMATEL=m CONFIG_SND_HDA_CODEC_VIA=m CONFIG_SND_HDA_CODEC_HDMI=m CONFIG_SND_HDA_I915=y CONFIG_SND_HDA_CODEC_CIRRUS=m CONFIG_SND_HDA_CODEC_CONEXANT=m CONFIG_SND_HDA_CODEC_CA0110=m CONFIG_SND_HDA_CODEC_CA0132=m CONFIG_SND_HDA_CODEC_CA0132_DSP=y CONFIG_SND_HDA_CODEC_CMEDIA=m CONFIG_SND_HDA_CODEC_SI3054=m CONFIG_SND_HDA_GENERIC=m CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_SPI=y CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_UA101=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SND_USB_6FIRE=m CONFIG_SND_USB_HIFACE=m # CONFIG_SND_BCD2000 is not set CONFIG_SND_FIREWIRE=y CONFIG_SND_FIREWIRE_LIB=m CONFIG_SND_DICE=m CONFIG_SND_FIREWIRE_SPEAKERS=m CONFIG_SND_ISIGHT=m CONFIG_SND_SCS1X=m # CONFIG_SND_FIREWORKS is not set # CONFIG_SND_BEBOB is not set # CONFIG_SND_PCMCIA is not set # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m # # HID support # CONFIG_HID=y CONFIG_HID_BATTERY_STRENGTH=y CONFIG_HIDRAW=y CONFIG_UHID=m CONFIG_HID_GENERIC=y # # Special HID drivers # CONFIG_HID_A4TECH=y CONFIG_HID_ACRUX=m CONFIG_HID_ACRUX_FF=y CONFIG_HID_APPLE=y CONFIG_HID_APPLEIR=m CONFIG_HID_AUREAL=m CONFIG_HID_BELKIN=y CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y CONFIG_HID_PRODIKEYS=m # CONFIG_HID_CP2112 is not set CONFIG_HID_CYPRESS=y CONFIG_HID_DRAGONRISE=m CONFIG_DRAGONRISE_FF=y CONFIG_HID_EMS_FF=m CONFIG_HID_ELECOM=m CONFIG_HID_ELO=m CONFIG_HID_EZKEY=y CONFIG_HID_HOLTEK=m CONFIG_HOLTEK_FF=y CONFIG_HID_GT683R=m CONFIG_HID_HUION=m CONFIG_HID_KEYTOUCH=m CONFIG_HID_KYE=m CONFIG_HID_UCLOGIC=m CONFIG_HID_WALTOP=m CONFIG_HID_GYRATION=m CONFIG_HID_ICADE=m CONFIG_HID_TWINHAN=m CONFIG_HID_KENSINGTON=y CONFIG_HID_LCPOWER=m CONFIG_HID_LENOVO=m CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=m CONFIG_LOGITECH_FF=y CONFIG_LOGIRUMBLEPAD2_FF=y CONFIG_LOGIG940_FF=y CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=y CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=m CONFIG_HID_NTRIG=y CONFIG_HID_ORTEK=m CONFIG_HID_PANTHERLORD=m CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=m CONFIG_HID_PICOLCD=m CONFIG_HID_PICOLCD_FB=y CONFIG_HID_PICOLCD_BACKLIGHT=y CONFIG_HID_PICOLCD_LCD=y CONFIG_HID_PICOLCD_LEDS=y CONFIG_HID_PICOLCD_CIR=y CONFIG_HID_PRIMAX=m CONFIG_HID_ROCCAT=m CONFIG_HID_SAITEK=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_SONY_FF=y CONFIG_HID_SPEEDLINK=m CONFIG_HID_STEELSERIES=m CONFIG_HID_SUNPLUS=m CONFIG_HID_RMI=m CONFIG_HID_GREENASIA=m CONFIG_GREENASIA_FF=y CONFIG_HID_HYPERV_MOUSE=m CONFIG_HID_SMARTJOYPLUS=m CONFIG_SMARTJOYPLUS_FF=y CONFIG_HID_TIVO=m CONFIG_HID_TOPSEED=m CONFIG_HID_THINGM=m CONFIG_HID_THRUSTMASTER=m CONFIG_THRUSTMASTER_FF=y CONFIG_HID_WACOM=m CONFIG_HID_WIIMOTE=m CONFIG_HID_XINMO=m CONFIG_HID_ZEROPLUS=m CONFIG_ZEROPLUS_FF=y CONFIG_HID_ZYDACRON=m CONFIG_HID_SENSOR_HUB=m # # USB HID support # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # I2C HID support # CONFIG_I2C_HID=m 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_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # CONFIG_USB_OTG_FSM is not set CONFIG_USB_MON=y CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m # CONFIG_USB_WUSB_CBAF_DEBUG is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_PCI=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_ISP1362_HCD=m CONFIG_USB_FUSBH200_HCD=m # CONFIG_USB_FOTG210_HCD is not set # CONFIG_USB_MAX3421_HCD is not set CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PCI=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m CONFIG_USB_SL811_HCD_ISO=y # CONFIG_USB_SL811_CS is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set CONFIG_USB_HWA_HCD=m # CONFIG_USB_HCD_BCMA is not set # CONFIG_USB_HCD_SSB is not set # CONFIG_USB_HCD_TEST_MODE is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m CONFIG_USB_TMC=m # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_REALTEK=m CONFIG_REALTEK_AUTOPM=y CONFIG_USB_STORAGE_DATAFAB=m CONFIG_USB_STORAGE_FREECOM=m CONFIG_USB_STORAGE_ISD200=m CONFIG_USB_STORAGE_USBAT=m CONFIG_USB_STORAGE_SDDR09=m CONFIG_USB_STORAGE_SDDR55=m CONFIG_USB_STORAGE_JUMPSHOT=m CONFIG_USB_STORAGE_ALAUDA=m CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m CONFIG_USB_STORAGE_ENE_UB6250=m CONFIG_USB_UAS=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # CONFIG_USB_MUSB_HDRC is not set # CONFIG_USB_DWC3 is not set # CONFIG_USB_DWC2 is not set # CONFIG_USB_CHIPIDEA is not set # # USB port drivers # CONFIG_USB_USS720=m CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_SIMPLE=m CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP210X=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_F81232 is not set CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m # CONFIG_USB_SERIAL_METRO is not set CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7715_PARPORT=y CONFIG_USB_SERIAL_MOS7840=m # CONFIG_USB_SERIAL_MXUPORT is not set CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_QCAUX=m CONFIG_USB_SERIAL_QUALCOMM=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_SYMBOL=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_WWAN=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_OPTICON=m CONFIG_USB_SERIAL_XSENS_MT=m # CONFIG_USB_SERIAL_WISHBONE is not set # CONFIG_USB_SERIAL_ZTE is not set CONFIG_USB_SERIAL_SSU100=m CONFIG_USB_SERIAL_QT2=m CONFIG_USB_SERIAL_DEBUG=m # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_SEVSEG=m # CONFIG_USB_RIO500 is not set CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m CONFIG_USB_TRANCEVIBRATOR=m CONFIG_USB_IOWARRIOR=m # CONFIG_USB_TEST is not set # CONFIG_USB_EHSET_TEST_FIXTURE is not set CONFIG_USB_ISIGHTFW=m CONFIG_USB_YUREX=m CONFIG_USB_EZUSB_FX2=m CONFIG_USB_HSIC_USB3503=m # CONFIG_USB_LINK_LAYER_TEST is not set CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # # USB Physical Layer drivers # CONFIG_USB_PHY=y CONFIG_NOP_USB_XCEIV=m # CONFIG_SAMSUNG_USB2PHY is not set # CONFIG_SAMSUNG_USB3PHY is not set # CONFIG_USB_GPIO_VBUS is not set # CONFIG_USB_ISP1301 is not set # CONFIG_USB_GADGET is not set CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_I1480U=m CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_CLKGATE is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_MMC_RICOH_MMC=y CONFIG_MMC_SDHCI_ACPI=m CONFIG_MMC_SDHCI_PLTFM=m # CONFIG_MMC_SDHCI_PXAV3 is not set # CONFIG_MMC_SDHCI_PXAV2 is not set CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m # CONFIG_MMC_SPI is not set CONFIG_MMC_SDRICOH_CS=m CONFIG_MMC_CB710=m CONFIG_MMC_VIA_SDMMC=m CONFIG_MMC_VUB300=m CONFIG_MMC_USHC=m # CONFIG_MMC_USDHI6ROL0 is not set CONFIG_MMC_REALTEK_PCI=m CONFIG_MMC_REALTEK_USB=m CONFIG_MEMSTICK=m # CONFIG_MEMSTICK_DEBUG is not set # # MemoryStick drivers # # CONFIG_MEMSTICK_UNSAFE_RESUME is not set CONFIG_MSPRO_BLOCK=m # CONFIG_MS_BLOCK is not set # # MemoryStick Host Controller Drivers # CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_MEMSTICK_R592=m CONFIG_MEMSTICK_REALTEK_PCI=m CONFIG_MEMSTICK_REALTEK_USB=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # CONFIG_LEDS_LM3530=m # CONFIG_LEDS_LM3642 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_GPIO is not set CONFIG_LEDS_LP3944=m CONFIG_LEDS_LP55XX_COMMON=m CONFIG_LEDS_LP5521=m CONFIG_LEDS_LP5523=m CONFIG_LEDS_LP5562=m # CONFIG_LEDS_LP8501 is not set CONFIG_LEDS_CLEVO_MAIL=m # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_PCA963X is not set # CONFIG_LEDS_DAC124S085 is not set # CONFIG_LEDS_BD2802 is not set CONFIG_LEDS_INTEL_SS4200=m CONFIG_LEDS_LT3593=m CONFIG_LEDS_DELL_NETBOOKS=m # CONFIG_LEDS_TCA6507 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=m # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_ONESHOT=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_BACKLIGHT=m # CONFIG_LEDS_TRIGGER_CPU is not set CONFIG_LEDS_TRIGGER_GPIO=m CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # # iptables trigger is under Netfilter config (LED target) # CONFIG_LEDS_TRIGGER_TRANSIENT=m CONFIG_LEDS_TRIGGER_CAMERA=m CONFIG_ACCESSIBILITY=y CONFIG_A11Y_BRAILLE_CONSOLE=y CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_IPATH=m CONFIG_INFINIBAND_QIB=m CONFIG_INFINIBAND_QIB_DCA=y CONFIG_INFINIBAND_AMSO1100=m # CONFIG_INFINIBAND_AMSO1100_DEBUG is not set CONFIG_INFINIBAND_CXGB3=m # CONFIG_INFINIBAND_CXGB3_DEBUG is not set CONFIG_INFINIBAND_CXGB4=m CONFIG_MLX4_INFINIBAND=m CONFIG_MLX5_INFINIBAND=m CONFIG_INFINIBAND_NES=m # CONFIG_INFINIBAND_NES_DEBUG is not set # CONFIG_INFINIBAND_OCRDMA is not set # CONFIG_INFINIBAND_USNIC is not set CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y CONFIG_INFINIBAND_SRP=m CONFIG_INFINIBAND_SRPT=m CONFIG_INFINIBAND_ISER=m CONFIG_INFINIBAND_ISERT=m CONFIG_EDAC=y CONFIG_EDAC_LEGACY_SYSFS=y # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_DECODE_MCE=m CONFIG_EDAC_MCE_INJ=m CONFIG_EDAC_MM_EDAC=m CONFIG_EDAC_AMD64=m # CONFIG_EDAC_AMD64_ERROR_INJECTION is not set CONFIG_EDAC_E752X=m CONFIG_EDAC_I82975X=m CONFIG_EDAC_I3000=m CONFIG_EDAC_I3200=m CONFIG_EDAC_IE31200=m CONFIG_EDAC_X38=m CONFIG_EDAC_I5400=m CONFIG_EDAC_I7CORE=m CONFIG_EDAC_I5000=m CONFIG_EDAC_I5100=m CONFIG_EDAC_I7300=m CONFIG_EDAC_SBRIDGE=m CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y # CONFIG_RTC_SYSTOHC is not set CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # 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_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_DS3232=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_ISL12022=m # CONFIG_RTC_DRV_ISL12057 is not set CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF2127=m CONFIG_RTC_DRV_PCF8523=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF85063=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y CONFIG_RTC_DRV_BQ32K=m # CONFIG_RTC_DRV_S35390A is not set CONFIG_RTC_DRV_FM3130=m CONFIG_RTC_DRV_RX8581=m CONFIG_RTC_DRV_RX8025=m CONFIG_RTC_DRV_EM3027=m CONFIG_RTC_DRV_RV3029C2=m # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T93 is not set # CONFIG_RTC_DRV_M41T94 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_MAX6902 is not set # CONFIG_RTC_DRV_R9701 is not set # CONFIG_RTC_DRV_RS5C348 is not set # CONFIG_RTC_DRV_DS3234 is not set # CONFIG_RTC_DRV_PCF2123 is not set # CONFIG_RTC_DRV_RX4581 is not set # CONFIG_RTC_DRV_MCP795 is not set # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_DS2404=m # CONFIG_RTC_DRV_EFI is not set CONFIG_RTC_DRV_STK17TA8=m # CONFIG_RTC_DRV_M48T86 is not set CONFIG_RTC_DRV_M48T35=m CONFIG_RTC_DRV_M48T59=m CONFIG_RTC_DRV_MSM6242=m CONFIG_RTC_DRV_BQ4802=m CONFIG_RTC_DRV_RP5C01=m CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # # CONFIG_RTC_DRV_XGENE 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_INTEL_MIC_X100_DMA=m # CONFIG_INTEL_MID_DMAC is not set CONFIG_INTEL_IOATDMA=m CONFIG_DW_DMAC_CORE=m CONFIG_DW_DMAC=m CONFIG_DW_DMAC_PCI=m CONFIG_DMA_ENGINE=y CONFIG_DMA_ACPI=y # # DMA Clients # CONFIG_ASYNC_TX_DMA=y # CONFIG_DMATEST is not set CONFIG_DMA_ENGINE_RAID=y CONFIG_DCA=m CONFIG_AUXDISPLAY=y CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=m CONFIG_CFAG12864B_RATE=20 CONFIG_UIO=m CONFIG_UIO_CIF=m # CONFIG_UIO_PDRV_GENIRQ is not set # CONFIG_UIO_DMEM_GENIRQ is not set CONFIG_UIO_AEC=m CONFIG_UIO_SERCOS3=m CONFIG_UIO_PCI_GENERIC=m # CONFIG_UIO_NETX is not set # CONFIG_UIO_MF624 is not set CONFIG_VFIO_IOMMU_TYPE1=m CONFIG_VFIO=m CONFIG_VFIO_PCI=m CONFIG_VFIO_PCI_VGA=y # CONFIG_VIRT_DRIVERS is not set CONFIG_VIRTIO=m # # Virtio drivers # CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_VIRTIO_MMIO=m # CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set # # Microsoft Hyper-V guest support # CONFIG_HYPERV=m CONFIG_HYPERV_UTILS=m CONFIG_HYPERV_BALLOON=m # # Xen driver support # CONFIG_XEN_BALLOON=y CONFIG_XEN_SELFBALLOONING=y # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=m CONFIG_XEN_BACKEND=y CONFIG_XENFS=m CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=m CONFIG_XEN_GRANT_DEV_ALLOC=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_TMEM=m CONFIG_XEN_PCIDEV_BACKEND=m CONFIG_XEN_PRIVCMD=m CONFIG_XEN_ACPI_PROCESSOR=m # CONFIG_XEN_MCE_LOG is not set CONFIG_XEN_HAVE_PVMMU=y CONFIG_XEN_EFI=y CONFIG_STAGING=y # CONFIG_ET131X is not set # CONFIG_SLICOSS is not set # CONFIG_USBIP_CORE is not set # CONFIG_PRISM2_USB is not set # CONFIG_COMEDI is not set # CONFIG_PANEL is not set # CONFIG_RTL8192U is not set CONFIG_RTLLIB=m CONFIG_RTLLIB_CRYPTO_CCMP=m CONFIG_RTLLIB_CRYPTO_TKIP=m CONFIG_RTLLIB_CRYPTO_WEP=m CONFIG_RTL8192E=m CONFIG_R8712U=m # CONFIG_R8188EU is not set # CONFIG_R8192EE is not set CONFIG_R8723AU=m # CONFIG_8723AU_AP_MODE is not set # CONFIG_8723AU_BT_COEXIST is not set # CONFIG_R8821AE is not set # CONFIG_RTS5208 is not set # CONFIG_LINE6_USB is not set # CONFIG_VT6655 is not set # CONFIG_VT6656 is not set # # IIO staging drivers # # # Accelerometers # # CONFIG_ADIS16201 is not set # CONFIG_ADIS16203 is not set # CONFIG_ADIS16204 is not set # CONFIG_ADIS16209 is not set # CONFIG_ADIS16220 is not set # CONFIG_ADIS16240 is not set # CONFIG_LIS3L02DQ is not set # CONFIG_SCA3000 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_AD5930 is not set # CONFIG_AD9832 is not set # CONFIG_AD9834 is not set # CONFIG_AD9850 is not set # CONFIG_AD9852 is not set # CONFIG_AD9910 is not set # CONFIG_AD9951 is not set # # Digital gyroscope sensors # # CONFIG_ADIS16060 is not set # # Network Analyzer, Impedance Converters # # CONFIG_AD5933 is not set # # Light sensors # # CONFIG_SENSORS_ISL29018 is not set # CONFIG_SENSORS_ISL29028 is not set # CONFIG_TSL2583 is not set # CONFIG_TSL2x7x is not set # # Magnetometer sensors # # CONFIG_SENSORS_HMC5843_I2C is not set # CONFIG_SENSORS_HMC5843_SPI is not set # # Active energy metering IC # # CONFIG_ADE7753 is not set # CONFIG_ADE7754 is not set # CONFIG_ADE7758 is not set # CONFIG_ADE7759 is not set # CONFIG_ADE7854 is not set # # Resolver to digital converters # # CONFIG_AD2S90 is not set # CONFIG_AD2S1200 is not set # CONFIG_AD2S1210 is not set # # Triggers - standalone # # CONFIG_IIO_PERIODIC_RTC_TRIGGER is not set # CONFIG_IIO_SIMPLE_DUMMY is not set # CONFIG_FB_XGI is not set # CONFIG_BCM_WIMAX is not set # CONFIG_FT1000 is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set CONFIG_STAGING_MEDIA=y # CONFIG_DVB_AS102 is not set # CONFIG_I2C_BCM2048 is not set # CONFIG_DVB_CXD2099 is not set # CONFIG_VIDEO_DT3155 is not set # CONFIG_VIDEO_TCM825X is not set CONFIG_LIRC_STAGING=y CONFIG_LIRC_BT829=m CONFIG_LIRC_IGORPLUGUSB=m CONFIG_LIRC_IMON=m CONFIG_LIRC_PARALLEL=m CONFIG_LIRC_SASEM=m CONFIG_LIRC_SERIAL=m CONFIG_LIRC_SERIAL_TRANSMITTER=y CONFIG_LIRC_SIR=m CONFIG_LIRC_ZILOG=m # # Android # # CONFIG_ANDROID is not set # CONFIG_USB_WPAN_HCD is not set # CONFIG_WIMAX_GDM72XX is not set # CONFIG_LTE_GDM724X is not set # CONFIG_FIREWIRE_SERIAL is not set # CONFIG_LUSTRE_FS is not set # CONFIG_XILLYBUS is not set # CONFIG_DGNC is not set # CONFIG_DGAP is not set # CONFIG_GS_FPGABOOT is not set # CONFIG_CRYPTO_SKEIN is not set # CONFIG_CRYPTO_THREEFISH is not set # CONFIG_UNISYSSPAR is not set CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACER_WMI=m CONFIG_ACERHDF=m CONFIG_ALIENWARE_WMI=m CONFIG_ASUS_LAPTOP=m CONFIG_DELL_LAPTOP=m CONFIG_DELL_WMI=m CONFIG_DELL_WMI_AIO=m CONFIG_DELL_SMO8800=m CONFIG_FUJITSU_LAPTOP=m # CONFIG_FUJITSU_LAPTOP_DEBUG is not set CONFIG_FUJITSU_TABLET=m CONFIG_AMILO_RFKILL=m CONFIG_HP_ACCEL=m CONFIG_HP_WIRELESS=m CONFIG_HP_WMI=m CONFIG_MSI_LAPTOP=m CONFIG_PANASONIC_LAPTOP=m CONFIG_COMPAL_LAPTOP=m CONFIG_SONY_LAPTOP=m CONFIG_SONYPI_COMPAT=y CONFIG_IDEAPAD_LAPTOP=m CONFIG_THINKPAD_ACPI=m CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y # CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set # CONFIG_THINKPAD_ACPI_DEBUG is not set # CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_SENSORS_HDAPS=m # CONFIG_INTEL_MENLOW is not set CONFIG_EEEPC_LAPTOP=m CONFIG_ASUS_WMI=m CONFIG_ASUS_NB_WMI=m CONFIG_EEEPC_WMI=m CONFIG_ACPI_WMI=m CONFIG_MSI_WMI=m CONFIG_TOPSTAR_LAPTOP=m CONFIG_ACPI_TOSHIBA=m CONFIG_TOSHIBA_BT_RFKILL=m CONFIG_TOSHIBA_HAPS=m CONFIG_ACPI_CMPC=m CONFIG_INTEL_IPS=m # CONFIG_IBM_RTL is not set CONFIG_SAMSUNG_LAPTOP=m CONFIG_MXM_WMI=m CONFIG_INTEL_OAKTRAIL=m CONFIG_SAMSUNG_Q10=m CONFIG_APPLE_GMUX=m CONFIG_INTEL_RST=m CONFIG_INTEL_SMARTCONNECT=y CONFIG_PVPANIC=m CONFIG_CHROME_PLATFORMS=y CONFIG_CHROMEOS_LAPTOP=m CONFIG_CHROMEOS_PSTORE=m # # SOC (System On Chip) specific Drivers # CONFIG_CLKDEV_LOOKUP=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_COMMON_CLK=y # # Common Clock Framework # # CONFIG_COMMON_CLK_SI5351 is not set # # Hardware Spinlock drivers # # # Clock Source drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y # CONFIG_SH_TIMER_CMT is not set # CONFIG_SH_TIMER_MTU2 is not set # CONFIG_SH_TIMER_TMU is not set # CONFIG_EM_TIMER_STI is not set # CONFIG_MAILBOX is not set CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y CONFIG_AMD_IOMMU_V2=m CONFIG_DMAR_TABLE=y CONFIG_INTEL_IOMMU=y # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set CONFIG_INTEL_IOMMU_FLOPPY_WA=y CONFIG_IRQ_REMAP=y # # Remoteproc drivers # # CONFIG_STE_MODEM_RPROC is not set # # Rpmsg drivers # CONFIG_PM_DEVFREQ=y # # DEVFREQ Governors # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m # CONFIG_DEVFREQ_GOV_PERFORMANCE is not set # CONFIG_DEVFREQ_GOV_POWERSAVE is not set # CONFIG_DEVFREQ_GOV_USERSPACE is not set # # DEVFREQ Drivers # # CONFIG_EXTCON is not set # CONFIG_MEMORY is not set CONFIG_IIO=m CONFIG_IIO_BUFFER=y CONFIG_IIO_BUFFER_CB=y CONFIG_IIO_KFIFO_BUF=m CONFIG_IIO_TRIGGERED_BUFFER=m CONFIG_IIO_TRIGGER=y CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 # # Accelerometers # # CONFIG_BMA180 is not set CONFIG_HID_SENSOR_ACCEL_3D=m CONFIG_IIO_ST_ACCEL_3AXIS=m CONFIG_IIO_ST_ACCEL_I2C_3AXIS=m CONFIG_IIO_ST_ACCEL_SPI_3AXIS=m # CONFIG_KXSD9 is not set # CONFIG_MMA8452 is not set # CONFIG_KXCJK1013 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_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_MAX1027 is not set # CONFIG_MAX1363 is not set # CONFIG_MCP320X is not set # CONFIG_MCP3422 is not set # CONFIG_NAU7802 is not set # CONFIG_TI_ADC081C is not set # CONFIG_VIPERBOARD_ADC is not set # # Amplifiers # # CONFIG_AD8366 is not set # # Hid Sensor IIO Common # CONFIG_HID_SENSOR_IIO_COMMON=m CONFIG_HID_SENSOR_IIO_TRIGGER=m CONFIG_IIO_ST_SENSORS_I2C=m CONFIG_IIO_ST_SENSORS_SPI=m CONFIG_IIO_ST_SENSORS_CORE=m # # 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_AD5504 is not set # CONFIG_AD5624R_SPI is not set # CONFIG_AD5686 is not set # CONFIG_AD5755 is not set # CONFIG_AD5764 is not set # CONFIG_AD5791 is not set # CONFIG_AD7303 is not set # CONFIG_MAX517 is not set # CONFIG_MCP4725 is not set # CONFIG_MCP4922 is not set # # 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_HID_SENSOR_GYRO_3D=m CONFIG_IIO_ST_GYRO_3AXIS=m CONFIG_IIO_ST_GYRO_I2C_3AXIS=m CONFIG_IIO_ST_GYRO_SPI_3AXIS=m # CONFIG_ITG3200 is not set # # Humidity sensors # # CONFIG_DHT11 is not set # CONFIG_SI7005 is not set # # Inertial measurement units # # CONFIG_ADIS16400 is not set # CONFIG_ADIS16480 is not set # CONFIG_INV_MPU6050_IIO is not set # # Light sensors # # CONFIG_ADJD_S311 is not set # CONFIG_APDS9300 is not set # CONFIG_CM32181 is not set # CONFIG_CM36651 is not set # CONFIG_GP2AP020A00F is not set # CONFIG_ISL29125 is not set CONFIG_HID_SENSOR_ALS=m # CONFIG_HID_SENSOR_PROX is not set # CONFIG_LTR501 is not set # CONFIG_TCS3414 is not set # CONFIG_TCS3472 is not set # CONFIG_SENSORS_TSL2563 is not set # CONFIG_TSL4531 is not set # CONFIG_VCNL4000 is not set # # Magnetometer sensors # # CONFIG_AK8975 is not set # CONFIG_AK09911 is not set # CONFIG_MAG3110 is not set CONFIG_HID_SENSOR_MAGNETOMETER_3D=m CONFIG_IIO_ST_MAGN_3AXIS=m CONFIG_IIO_ST_MAGN_I2C_3AXIS=m CONFIG_IIO_ST_MAGN_SPI_3AXIS=m # # Inclinometer sensors # CONFIG_HID_SENSOR_INCLINOMETER_3D=m CONFIG_HID_SENSOR_DEVICE_ROTATION=m # # Triggers - standalone # CONFIG_IIO_INTERRUPT_TRIGGER=m # CONFIG_IIO_SYSFS_TRIGGER is not set # # Pressure sensors # # CONFIG_HID_SENSOR_PRESS is not set # CONFIG_MPL115 is not set # CONFIG_MPL3115 is not set # CONFIG_IIO_ST_PRESS is not set # CONFIG_T5403 is not set # # Lightning sensors # # CONFIG_AS3935 is not set # # Temperature sensors # # CONFIG_MLX90614 is not set # CONFIG_TMP006 is not set CONFIG_NTB=m # CONFIG_VME_BUS is not set # CONFIG_PWM is not set # CONFIG_IPACK_BUS is not set CONFIG_RESET_CONTROLLER=y CONFIG_FMC=m CONFIG_FMC_FAKEDEV=m CONFIG_FMC_TRIVIAL=m CONFIG_FMC_WRITE_EEPROM=m CONFIG_FMC_CHARDEV=m # # PHY Subsystem # CONFIG_GENERIC_PHY=y # CONFIG_BCM_KONA_USB2_PHY is not set # CONFIG_PHY_ST_SPEAR1310_MIPHY is not set # CONFIG_PHY_ST_SPEAR1340_MIPHY is not set # CONFIG_POWERCAP is not set # CONFIG_MCB is not set CONFIG_RAS=y CONFIG_THUNDERBOLT=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y # CONFIG_DELL_RBU is not set CONFIG_DCDBAS=m CONFIG_DMIID=y CONFIG_DMI_SYSFS=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m # CONFIG_GOOGLE_FIRMWARE is not set # # EFI (Extensible Firmware Interface) Support # CONFIG_EFI_VARS=y CONFIG_EFI_VARS_PSTORE=y CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y CONFIG_EFI_RUNTIME_MAP=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_UEFI_CPER=y # # File systems # CONFIG_DCACHE_WORD_ACCESS=y # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT23=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set CONFIG_JBD2=y # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_XFS_WARN is not set # CONFIG_XFS_DEBUG is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_DLM=y CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m # CONFIG_OCFS2_FS_STATS is not set # CONFIG_OCFS2_DEBUG_MASKLOG is not set # CONFIG_OCFS2_DEBUG_FS is not set CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set # CONFIG_BTRFS_DEBUG is not set # CONFIG_BTRFS_ASSERT is not set CONFIG_NILFS2_FS=m CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y 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=y CONFIG_FUSE_FS=m CONFIG_CUSE=m # # Caches # CONFIG_FSCACHE=m CONFIG_FSCACHE_STATS=y # CONFIG_FSCACHE_HISTOGRAM is not set # CONFIG_FSCACHE_DEBUG is not set CONFIG_FSCACHE_OBJECT_LIST=y CONFIG_CACHEFILES=m # CONFIG_CACHEFILES_DEBUG is not set # CONFIG_CACHEFILES_HISTOGRAM is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=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_CONFIGFS_FS=y CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set CONFIG_AFFS_FS=m CONFIG_ECRYPT_FS=m # CONFIG_ECRYPT_FS_MESSAGING is not set CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m # CONFIG_HFSPLUS_FS_POSIX_ACL is not set CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_UBIFS_FS=m # CONFIG_UBIFS_FS_ADVANCED_COMPR is not set CONFIG_UBIFS_FS_LZO=y CONFIG_UBIFS_FS_ZLIB=y # CONFIG_LOGFS is not set CONFIG_CRAMFS=m CONFIG_SQUASHFS=m CONFIG_SQUASHFS_FILE_CACHE=y # CONFIG_SQUASHFS_FILE_DIRECT is not set CONFIG_SQUASHFS_DECOMP_SINGLE=y # CONFIG_SQUASHFS_DECOMP_MULTI is not set # CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_VXFS_FS is not set CONFIG_MINIX_FS=m # 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=m CONFIG_ROMFS_BACKED_BY_BLOCK=y # CONFIG_ROMFS_BACKED_BY_MTD is not set # CONFIG_ROMFS_BACKED_BY_BOTH is not set CONFIG_ROMFS_ON_BLOCK=y CONFIG_PSTORE=y # CONFIG_PSTORE_CONSOLE is not set # CONFIG_PSTORE_FTRACE is not set CONFIG_PSTORE_RAM=m CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set # CONFIG_EXOFS_FS is not set # CONFIG_F2FS_FS is not set CONFIG_EFIVAR_FS=y CONFIG_ORE=m CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m # CONFIG_NFS_V2 is not set CONFIG_NFS_V3=m CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=m CONFIG_NFS_SWAP=y CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_PNFS_FILE_LAYOUT=m CONFIG_PNFS_BLOCK=m CONFIG_PNFS_OBJLAYOUT=m CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org" # CONFIG_NFS_V4_1_MIGRATION is not set CONFIG_NFS_V4_SECURITY_LABEL=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y CONFIG_NFS_DEBUG=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_V4_SECURITY_LABEL=y # CONFIG_NFSD_FAULT_INJECTION is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BACKCHANNEL=y CONFIG_SUNRPC_SWAP=y CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SUNRPC_DEBUG=y CONFIG_SUNRPC_XPRT_RDMA_CLIENT=m # CONFIG_SUNRPC_XPRT_RDMA_SERVER is not set CONFIG_CEPH_FS=m CONFIG_CEPH_FSCACHE=y CONFIG_CEPH_FS_POSIX_ACL=y CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y CONFIG_CIFS_ACL=y CONFIG_CIFS_DEBUG=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_DFS_UPCALL=y CONFIG_CIFS_SMB2=y CONFIG_CIFS_FSCACHE=y CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m # CONFIG_AFS_FS is not set CONFIG_9P_FS=m CONFIG_9P_FSCACHE=y CONFIG_9P_FS_POSIX_ACL=y CONFIG_9P_FS_SECURITY=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_MAC_ROMAN=m CONFIG_NLS_MAC_CELTIC=m CONFIG_NLS_MAC_CENTEURO=m CONFIG_NLS_MAC_CROATIAN=m CONFIG_NLS_MAC_CYRILLIC=m CONFIG_NLS_MAC_GAELIC=m CONFIG_NLS_MAC_GREEK=m CONFIG_NLS_MAC_ICELAND=m CONFIG_NLS_MAC_INUIT=m CONFIG_NLS_MAC_ROMANIAN=m CONFIG_NLS_MAC_TURKISH=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # # printk and dmesg options # CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 CONFIG_BOOT_PRINTK_DELAY=y 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_ENABLE_WARN_DEPRECATED is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_STRIP_ASM_SYMS=y # CONFIG_READABLE_ASM is not set CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y CONFIG_HEADERS_CHECK=y # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x0 CONFIG_DEBUG_KERNEL=y # # Memory Debugging # # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_HAVE_DEBUG_KMEMLEAK=y # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_DEBUG_VM=y # CONFIG_DEBUG_VM_VMACACHE is not set # CONFIG_DEBUG_VM_RB is not set # 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_KMEMCHECK=y CONFIG_DEBUG_SHIRQ=y # # Debug Lockups and Hangs # CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 CONFIG_PANIC_TIMEOUT=0 CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set CONFIG_TIMER_STATS=y # # Lock Debugging (spinlocks, mutexes, etc...) # # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_LOCK_TORTURE_TEST is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_LIST=y # CONFIG_DEBUG_PI_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set # # RCU Debugging # CONFIG_SPARSE_RCU_POINTER=y # CONFIG_TORTURE_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_CPU_STALL_INFO is not set # CONFIG_RCU_TRACE is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y # CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=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_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_TRACER_SNAPSHOT=y # CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_UPROBE_EVENT=y CONFIG_PROBE_EVENTS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_MMIOTRACE is not set # CONFIG_TRACEPOINT_BENCHMARK is not set CONFIG_RING_BUFFER_BENCHMARK=m # CONFIG_RING_BUFFER_STARTUP_TEST is not set # # Runtime Testing # # CONFIG_LKDTM is not set # CONFIG_TEST_LIST_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=y CONFIG_ASYNC_RAID6_TEST=m # CONFIG_TEST_STRING_HELPERS is not set CONFIG_TEST_KSTRTOX=y # CONFIG_TEST_RHASHTABLE is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_BUILD_DOCSRC is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_TEST_MODULE is not set # CONFIG_TEST_USER_COPY is not set # CONFIG_TEST_BPF is not set # CONFIG_TEST_FIRMWARE is not set # CONFIG_TEST_UDELAY is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set CONFIG_KGDB_LOW_LEVEL_TRAP=y CONFIG_KGDB_KDB=y CONFIG_KDB_KEYBOARD=y CONFIG_KDB_CONTINUE_CATASTROPHIC=0 CONFIG_STRICT_DEVMEM=y # CONFIG_X86_VERBOSE_BOOTUP is not set CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y # CONFIG_X86_PTDUMP is not set CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_NX_TEST=m CONFIG_DOUBLEFAULT=y # CONFIG_DEBUG_TLBFLUSH is not set # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y CONFIG_X86_DECODER_SELFTEST=y 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_NMI_SELFTEST is not set # CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set # # Security options # CONFIG_KEYS=y CONFIG_PERSISTENT_KEYRINGS=y CONFIG_BIG_KEYS=y CONFIG_TRUSTED_KEYS=m CONFIG_ENCRYPTED_KEYS=m CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y # CONFIG_SECURITY_PATH is not set CONFIG_INTEL_TXT=y CONFIG_LSM_MMAP_MIN_ADDR=65536 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_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_SECURITY_YAMA is not set # CONFIG_IMA is not set # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_FIPS=y 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_PCOMP=m CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=m # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_ABLK_HELPER=y CONFIG_CRYPTO_GLUE_HELPER_X86=y # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=y # # Block modes # CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=y CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=y # # Hash modes # CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m # # Digest # CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_CRC32=m CONFIG_CRYPTO_CRC32_PCLMUL=m CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=m CONFIG_CRYPTO_SHA256_SSSE3=m CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=y CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m CONFIG_CRYPTO_CAST_COMMON=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST5_AVX_X86_64=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_DES3_EDE_X86_64=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m CONFIG_CRYPTO_SERPENT_AVX_X86_64=m CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m CONFIG_CRYPTO_LZO=y CONFIG_CRYPTO_LZ4=m CONFIG_CRYPTO_LZ4HC=m # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m # CONFIG_CRYPTO_DRBG_MENU is not set CONFIG_CRYPTO_USER_API=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_CRYPTO_USER_API_SKCIPHER=y CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_CCP_CRYPTO=m CONFIG_CRYPTO_DEV_QAT=m CONFIG_CRYPTO_DEV_QAT_DH895xCC=m CONFIG_ASYMMETRIC_KEY_TYPE=y CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y CONFIG_PUBLIC_KEY_ALGO_RSA=y CONFIG_X509_CERTIFICATE_PARSER=y CONFIG_PKCS7_MESSAGE_PARSER=y # CONFIG_PKCS7_TEST_KEY is not set CONFIG_SIGNED_PE_FILE_VERIFICATION=y CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQFD=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM_VFIO=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_MMU_AUDIT=y CONFIG_KVM_DEVICE_ASSIGNMENT=y CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m CONFIG_BITREVERSE=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_GENERIC_IO=y CONFIG_PERCPU_RWSEM=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_CRC_CCITT=m CONFIG_CRC16=y CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=m 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_CRC7 is not set CONFIG_LIBCRC32C=m CONFIG_CRC8=m # CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set # 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=m CONFIG_LZ4HC_COMPRESS=m CONFIG_LZ4_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y 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=m CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_BTREE=y CONFIG_INTERVAL_TREE=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y CONFIG_HAS_DMA=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_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_LRU_CACHE=m CONFIG_AVERAGE=y CONFIG_CLZ_TAB=y CONFIG_CORDIC=m # CONFIG_DDR is not set CONFIG_MPILIB=y CONFIG_OID_REGISTRY=y CONFIG_UCS2_STRING=y CONFIG_FONT_SUPPORT=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_ARCH_HAS_SG_CHAIN=y ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 19:51 ` Yanko Kaneti @ 2014-10-23 20:05 ` Paul E. McKenney 2014-10-23 21:45 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-23 20:05 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti wrote: > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > Don't get me wrong -- the fact that this kthread appears to > > > > > > > > have > > > > > > > > blocked within rcu_barrier() for 120 seconds means that > > > > > > > > something is > > > > > > > > most definitely wrong here. I am surprised that there are no > > > > > > > > RCU CPU > > > > > > > > stall warnings, but perhaps the blockage is in the callback > > > > > > > > execution > > > > > > > > rather than grace-period completion. Or something is > > > > > > > > preventing this > > > > > > > > kthread from starting up after the wake-up callback executes. > > > > > > > > Or... > > > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace above and can > > > > > > > recreate it reliably. Apparently reverting the RCU merge commit > > > > > > > (d6dd50e) and rebuilding the latest after that does not show the > > > > > > > issue. I'll let Yanko explain more and answer any questions you > > > > > > > have. > > > > > > > > > > > > - It is reproducible > > > > > > - I've done another build here to double check and its definitely > > > > > > the rcu merge > > > > > > that's causing it. > > > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do testing if > > > > > > needed. > > > > > > > > > > Please! Does the following patch help? > > > > > > > > Nope, doesn't seem to make a difference to the modprobe ppp_generic > > > > test > > > > > > Well, I was hoping. I will take a closer look at the RCU merge commit > > > and see what suggests itself. I am likely to ask you to revert specific > > > commits, if that works for you. > > > > Well, rather than reverting commits, could you please try testing the > > following commits? > > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks after spawning) > > > > 73a860cd58a1 (rcu: Replace flush_signals() with WARN_ON(signal_pending())) > > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > > > For whatever it is worth, I am guessing this one. > > Indeed, c847f14217d5 it is. > > Much to my embarrasment I just noticed that in addition to the > rcu merge, triggering the bug "requires" my specific Fedora rawhide network > setup. Booting in single mode and modprobe ppp_generic is fine. The bug > appears when starting with my regular fedora network setup, which in my case > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > Hope that helps. > > I am attaching the config. It does help a lot, thank you!!! The following patch is a bit of a shot in the dark, and assumes that commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled idle code) introduced the problem. Does this patch fix things up? Thanx, Paul ------------------------------------------------------------------------ rcu: Kick rcuo kthreads after their CPU goes offline If a no-CBs CPU were to post an RCU callback with interrupts disabled after it entered the idle loop for the last time, there might be no deferred wakeup for the corresponding rcuo kthreads. This commit therefore adds a set of calls to do_nocb_deferred_wakeup() after the CPU has gone completely offline. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 84b41b3c6ebd..4f3d25a58786 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3493,8 +3493,10 @@ static int rcu_cpu_notify(struct notifier_block *self, case CPU_DEAD_FROZEN: case CPU_UP_CANCELED: case CPU_UP_CANCELED_FROZEN: - for_each_rcu_flavor(rsp) + for_each_rcu_flavor(rsp) { rcu_cleanup_dead_cpu(cpu, rsp); + do_nocb_deferred_wakeup(this_cpu_ptr(rsp->rda)); + } break; default: break; ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 20:05 ` Paul E. McKenney @ 2014-10-23 21:45 ` Yanko Kaneti 2014-10-23 22:04 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-23 21:45 UTC (permalink / raw) To: paulmck Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti > > > > > > wrote: > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > Don't get me wrong -- the fact that this kthread > > > > > > > > > appears to > > > > > > > > > have > > > > > > > > > blocked within rcu_barrier() for 120 seconds means > > > > > > > > > that > > > > > > > > > something is > > > > > > > > > most definitely wrong here. I am surprised that > > > > > > > > > there are no > > > > > > > > > RCU CPU > > > > > > > > > stall warnings, but perhaps the blockage is in the > > > > > > > > > callback > > > > > > > > > execution > > > > > > > > > rather than grace-period completion. Or something is > > > > > > > > > preventing this > > > > > > > > > kthread from starting up after the wake-up callback > > > > > > > > > executes. > > > > > > > > > Or... > > > > > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace > > > > > > > > above and can > > > > > > > > recreate it reliably. Apparently reverting the RCU > > > > > > > > merge commit > > > > > > > > (d6dd50e) and rebuilding the latest after that does > > > > > > > > not show the > > > > > > > > issue. I'll let Yanko explain more and answer any > > > > > > > > questions you > > > > > > > > have. > > > > > > > > > > > > > > - It is reproducible > > > > > > > - I've done another build here to double check and its > > > > > > > definitely > > > > > > > the rcu merge > > > > > > > that's causing it. > > > > > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do > > > > > > > testing if > > > > > > > needed. > > > > > > > > > > > > Please! Does the following patch help? > > > > > > > > > > Nope, doesn't seem to make a difference to the modprobe > > > > > ppp_generic > > > > > test > > > > > > > > Well, I was hoping. I will take a closer look at the RCU > > > > merge commit > > > > and see what suggests itself. I am likely to ask you to > > > > revert specific > > > > commits, if that works for you. > > > > > > Well, rather than reverting commits, could you please try > > > testing the > > > following commits? > > > > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending > > > callbacks after spawning) > > > > > > 73a860cd58a1 (rcu: Replace flush_signals() with > > > WARN_ON(signal_pending())) > > > > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > > > > > For whatever it is worth, I am guessing this one. > > > > Indeed, c847f14217d5 it is. > > > > Much to my embarrasment I just noticed that in addition to the > > rcu merge, triggering the bug "requires" my specific Fedora > > rawhide network > > setup. Booting in single mode and modprobe ppp_generic is fine. > > The bug > > appears when starting with my regular fedora network setup, which > > in my case > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > > > Hope that helps. > > > > I am attaching the config. > > It does help a lot, thank you!!! > > The following patch is a bit of a shot in the dark, and assumes that > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > idle > code) introduced the problem. Does this patch fix things up? Unfortunately not, This is linus-tip + patch INFO: task kworker/u16:6:96 blocked for more than 120 seconds. Not tainted 3.18.0-rc1+ #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 Workqueue: netns cleanup_net ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 Call Trace: [<ffffffff8185b8e9>] schedule+0x29/0x70 [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 [<ffffffff8112a315>] rcu_barrier+0x15/0x20 [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 [<ffffffff810cca98>] process_one_work+0x218/0x850 [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 [<ffffffff810d348b>] kthread+0x10b/0x130 [<ffffffff81028c69>] ? sched_clock+0x9/0x10 [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 4 locks held by kworker/u16:6/96: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 INFO: task modprobe:1045 blocked for more than 120 seconds. Not tainted 3.18.0-rc1+ #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D ffff880218343480 12920 1045 1044 0x00000080 ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 Call Trace: [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 [<ffffffffa0673000>] ? 0xffffffffa0673000 [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [<ffffffff81153052>] load_module+0x20c2/0x2870 [<ffffffff8114e030>] ? store_uevent+0x70/0x70 [<ffffffff81278717>] ? kernel_read+0x57/0x90 [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 [<ffffffff81862969>] system_call_fastpath+0x12/0x17 1 lock held by modprobe/1045: #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > Thanx, Paul > > --------------------------------------------------------------------- > --- > > rcu: Kick rcuo kthreads after their CPU goes offline > > If a no-CBs CPU were to post an RCU callback with interrupts disabled > after it entered the idle loop for the last time, there might be no > deferred wakeup for the corresponding rcuo kthreads. This commit > therefore adds a set of calls to do_nocb_deferred_wakeup() after the > CPU has gone completely offline. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 84b41b3c6ebd..4f3d25a58786 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -3493,8 +3493,10 @@ static int rcu_cpu_notify(struct > notifier_block *self, > case CPU_DEAD_FROZEN: > case CPU_UP_CANCELED: > case CPU_UP_CANCELED_FROZEN: > - for_each_rcu_flavor(rsp) > + for_each_rcu_flavor(rsp) { > rcu_cleanup_dead_cpu(cpu, rsp); > + do_nocb_deferred_wakeup(this_cpu_ptr(rsp->rda)); > + } > break; > default: > break; > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 21:45 ` Yanko Kaneti @ 2014-10-23 22:04 ` Paul E. McKenney 2014-10-24 4:48 ` Jay Vosburgh 2014-10-24 9:08 ` Yanko Kaneti 0 siblings, 2 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-23 22:04 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti > > > > > > > wrote: > > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > Don't get me wrong -- the fact that this kthread > > > > > > > > > > appears to > > > > > > > > > > have > > > > > > > > > > blocked within rcu_barrier() for 120 seconds means > > > > > > > > > > that > > > > > > > > > > something is > > > > > > > > > > most definitely wrong here. I am surprised that > > > > > > > > > > there are no > > > > > > > > > > RCU CPU > > > > > > > > > > stall warnings, but perhaps the blockage is in the > > > > > > > > > > callback > > > > > > > > > > execution > > > > > > > > > > rather than grace-period completion. Or something is > > > > > > > > > > preventing this > > > > > > > > > > kthread from starting up after the wake-up callback > > > > > > > > > > executes. > > > > > > > > > > Or... > > > > > > > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace > > > > > > > > > above and can > > > > > > > > > recreate it reliably. Apparently reverting the RCU > > > > > > > > > merge commit > > > > > > > > > (d6dd50e) and rebuilding the latest after that does > > > > > > > > > not show the > > > > > > > > > issue. I'll let Yanko explain more and answer any > > > > > > > > > questions you > > > > > > > > > have. > > > > > > > > > > > > > > > > - It is reproducible > > > > > > > > - I've done another build here to double check and its > > > > > > > > definitely > > > > > > > > the rcu merge > > > > > > > > that's causing it. > > > > > > > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do > > > > > > > > testing if > > > > > > > > needed. > > > > > > > > > > > > > > Please! Does the following patch help? > > > > > > > > > > > > Nope, doesn't seem to make a difference to the modprobe > > > > > > ppp_generic > > > > > > test > > > > > > > > > > Well, I was hoping. I will take a closer look at the RCU > > > > > merge commit > > > > > and see what suggests itself. I am likely to ask you to > > > > > revert specific > > > > > commits, if that works for you. > > > > > > > > Well, rather than reverting commits, could you please try > > > > testing the > > > > following commits? > > > > > > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending > > > > callbacks after spawning) > > > > > > > > 73a860cd58a1 (rcu: Replace flush_signals() with > > > > WARN_ON(signal_pending())) > > > > > > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > > > > > > > For whatever it is worth, I am guessing this one. > > > > > > Indeed, c847f14217d5 it is. > > > > > > Much to my embarrasment I just noticed that in addition to the > > > rcu merge, triggering the bug "requires" my specific Fedora > > > rawhide network > > > setup. Booting in single mode and modprobe ppp_generic is fine. > > > The bug > > > appears when starting with my regular fedora network setup, which > > > in my case > > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > > > > > Hope that helps. > > > > > > I am attaching the config. > > > > It does help a lot, thank you!!! > > > > The following patch is a bit of a shot in the dark, and assumes that > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > > idle > > code) introduced the problem. Does this patch fix things up? > > Unfortunately not, This is linus-tip + patch OK. Can't have everything, I guess. > INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > Not tainted 3.18.0-rc1+ #4 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 > Workqueue: netns cleanup_net > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 > Call Trace: > [<ffffffff8185b8e9>] schedule+0x29/0x70 > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 > [<ffffffff8112a315>] rcu_barrier+0x15/0x20 > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 > [<ffffffff810cca98>] process_one_work+0x218/0x850 > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 > [<ffffffff810d348b>] kthread+0x10b/0x130 > [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > 4 locks held by kworker/u16:6/96: > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 > INFO: task modprobe:1045 blocked for more than 120 seconds. > Not tainted 3.18.0-rc1+ #4 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > modprobe D ffff880218343480 12920 1045 1044 0x00000080 > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 > Call Trace: > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffffa0673000>] ? 0xffffffffa0673000 > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [<ffffffff81153052>] load_module+0x20c2/0x2870 > [<ffffffff8114e030>] ? store_uevent+0x70/0x70 > [<ffffffff81278717>] ? kernel_read+0x57/0x90 > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 > [<ffffffff81862969>] system_call_fastpath+0x12/0x17 > 1 lock held by modprobe/1045: > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 Presumably the kworker/u16:6 completed, then modprobe hung? If not, I have some very hard questions about why net_mutex can be held by two tasks concurrently, given that it does not appear to be a reader-writer lock... Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled idle code) would fail. Is that the case? If not, could you please bisect the commits between 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending callbacks after spawning) and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 22:04 ` Paul E. McKenney @ 2014-10-24 4:48 ` Jay Vosburgh 2014-10-24 14:50 ` Paul E. McKenney 2014-10-24 9:08 ` Yanko Kaneti 1 sibling, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 4:48 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: >> >> On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: >> > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: >> > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: >> > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: >> > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: >> > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: >> > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti >> > > > > > > wrote: >> > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: >> > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney >> > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: >> > > > > > > >> > > > > > > [ . . . ] >> > > > > > > >> > > > > > > > > > Don't get me wrong -- the fact that this kthread >> > > > > > > > > > appears to >> > > > > > > > > > have >> > > > > > > > > > blocked within rcu_barrier() for 120 seconds means >> > > > > > > > > > that >> > > > > > > > > > something is >> > > > > > > > > > most definitely wrong here. I am surprised that >> > > > > > > > > > there are no >> > > > > > > > > > RCU CPU >> > > > > > > > > > stall warnings, but perhaps the blockage is in the >> > > > > > > > > > callback >> > > > > > > > > > execution >> > > > > > > > > > rather than grace-period completion. Or something is >> > > > > > > > > > preventing this >> > > > > > > > > > kthread from starting up after the wake-up callback >> > > > > > > > > > executes. >> > > > > > > > > > Or... >> > > > > > > > > > >> > > > > > > > > > Is this thing reproducible? >> > > > > > > > > >> > > > > > > > > I've added Yanko on CC, who reported the backtrace >> > > > > > > > > above and can >> > > > > > > > > recreate it reliably. Apparently reverting the RCU >> > > > > > > > > merge commit >> > > > > > > > > (d6dd50e) and rebuilding the latest after that does >> > > > > > > > > not show the >> > > > > > > > > issue. I'll let Yanko explain more and answer any >> > > > > > > > > questions you >> > > > > > > > > have. >> > > > > > > > >> > > > > > > > - It is reproducible >> > > > > > > > - I've done another build here to double check and its >> > > > > > > > definitely >> > > > > > > > the rcu merge >> > > > > > > > that's causing it. >> > > > > > > > >> > > > > > > > Don't think I'll be able to dig deeper, but I can do >> > > > > > > > testing if >> > > > > > > > needed. >> > > > > > > >> > > > > > > Please! Does the following patch help? >> > > > > > >> > > > > > Nope, doesn't seem to make a difference to the modprobe >> > > > > > ppp_generic >> > > > > > test >> > > > > >> > > > > Well, I was hoping. I will take a closer look at the RCU >> > > > > merge commit >> > > > > and see what suggests itself. I am likely to ask you to >> > > > > revert specific >> > > > > commits, if that works for you. >> > > > >> > > > Well, rather than reverting commits, could you please try >> > > > testing the >> > > > following commits? >> > > > >> > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending >> > > > callbacks after spawning) >> > > > >> > > > 73a860cd58a1 (rcu: Replace flush_signals() with >> > > > WARN_ON(signal_pending())) >> > > > >> > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) >> > > > >> > > > For whatever it is worth, I am guessing this one. >> > > >> > > Indeed, c847f14217d5 it is. >> > > >> > > Much to my embarrasment I just noticed that in addition to the >> > > rcu merge, triggering the bug "requires" my specific Fedora >> > > rawhide network >> > > setup. Booting in single mode and modprobe ppp_generic is fine. >> > > The bug >> > > appears when starting with my regular fedora network setup, which >> > > in my case >> > > includes 3 ethernet adapters and a libvirt birdge+nat setup. >> > > >> > > Hope that helps. >> > > >> > > I am attaching the config. >> > >> > It does help a lot, thank you!!! >> > >> > The following patch is a bit of a shot in the dark, and assumes that >> > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled >> > idle >> > code) introduced the problem. Does this patch fix things up? >> >> Unfortunately not, This is linus-tip + patch > >OK. Can't have everything, I guess. > >> INFO: task kworker/u16:6:96 blocked for more than 120 seconds. >> Not tainted 3.18.0-rc1+ #4 >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 >> Workqueue: netns cleanup_net >> ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 >> ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 >> ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 >> Call Trace: >> [<ffffffff8185b8e9>] schedule+0x29/0x70 >> [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 >> [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 >> [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 >> [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 >> [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 >> [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 >> [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 >> [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 >> [<ffffffff8112a315>] rcu_barrier+0x15/0x20 >> [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 >> [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 >> [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 >> [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 >> [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 >> [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 >> [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 >> [<ffffffff810cca98>] process_one_work+0x218/0x850 >> [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 >> [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 >> [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 >> [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 >> [<ffffffff810d348b>] kthread+0x10b/0x130 >> [<ffffffff81028c69>] ? sched_clock+0x9/0x10 >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 >> [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 >> 4 locks held by kworker/u16:6/96: >> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 >> #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 >> #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 >> #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 >> INFO: task modprobe:1045 blocked for more than 120 seconds. >> Not tainted 3.18.0-rc1+ #4 >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. >> modprobe D ffff880218343480 12920 1045 1044 0x00000080 >> ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 >> ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 >> ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 >> Call Trace: >> [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 >> [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 >> [<ffffffffa0673000>] ? 0xffffffffa0673000 >> [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 >> [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] >> [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> [<ffffffff81153052>] load_module+0x20c2/0x2870 >> [<ffffffff8114e030>] ? store_uevent+0x70/0x70 >> [<ffffffff81278717>] ? kernel_read+0x57/0x90 >> [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 >> [<ffffffff81862969>] system_call_fastpath+0x12/0x17 >> 1 lock held by modprobe/1045: >> #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > >Presumably the kworker/u16:6 completed, then modprobe hung? > >If not, I have some very hard questions about why net_mutex can be >held by two tasks concurrently, given that it does not appear to be a >reader-writer lock... > >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle >NOCB callbacks from irq-disabled idle code) would fail. Is that the case? >If not, could you please bisect the commits between 11ed7f934cb8 (rcu: >Make nocb leader kthreads process pending callbacks after spawning) >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? Just a note to add that I am also reliably inducing what appears to be this issue on a current -net tree, when configuring openvswitch via script. I am available to test patches or bisect tomorrow (Friday) US time if needed. The stack is as follows: [ 1320.492020] INFO: task ovs-vswitchd:1303 blocked for more than 120 seconds. [ 1320.498965] Not tainted 3.17.0-testola+ #1 [ 1320.503570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1320.511374] ovs-vswitchd D ffff88013fc14600 0 1303 1302 0x00000004 [ 1320.511378] ffff8801388d77d8 0000000000000002 ffff880031144b00 ffff8801388d7fd8 [ 1320.511382] 0000000000014600 0000000000014600 ffff8800b092e400 ffff880031144b00 [ 1320.511385] ffff8800b1126000 ffffffff81c58ad0 ffffffff81c58ad8 7fffffffffffffff [ 1320.511389] Call Trace: [ 1320.511396] [<ffffffff81739db9>] schedule+0x29/0x70 [ 1320.511399] [<ffffffff8173cd8c>] schedule_timeout+0x1dc/0x260 [ 1320.511404] [<ffffffff8109698d>] ? check_preempt_curr+0x8d/0xa0 [ 1320.511407] [<ffffffff810969bd>] ? ttwu_do_wakeup+0x1d/0xd0 [ 1320.511410] [<ffffffff8173aab6>] wait_for_completion+0xa6/0x160 [ 1320.511413] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 [ 1320.511417] [<ffffffff810cdb57>] _rcu_barrier+0x157/0x200 [ 1320.511419] [<ffffffff810cdc55>] rcu_barrier+0x15/0x20 [ 1320.511423] [<ffffffff8163a780>] netdev_run_todo+0x60/0x300 [ 1320.511427] [<ffffffff8164515e>] rtnl_unlock+0xe/0x10 [ 1320.511435] [<ffffffffa01aecc5>] internal_dev_destroy+0x55/0x80 [openvswitch] [ 1320.511440] [<ffffffffa01ae622>] ovs_vport_del+0x32/0x40 [openvswitch] [ 1320.511444] [<ffffffffa01a7dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] [ 1320.511448] [<ffffffffa01a7ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] [ 1320.511452] [<ffffffff816675b5>] genl_family_rcv_msg+0x1a5/0x3c0 [ 1320.511455] [<ffffffff816677d0>] ? genl_family_rcv_msg+0x3c0/0x3c0 [ 1320.511458] [<ffffffff81667861>] genl_rcv_msg+0x91/0xd0 [ 1320.511461] [<ffffffff816658d1>] netlink_rcv_skb+0xc1/0xe0 [ 1320.511463] [<ffffffff81665dfc>] genl_rcv+0x2c/0x40 [ 1320.511466] [<ffffffff81664e66>] netlink_unicast+0xf6/0x200 [ 1320.511468] [<ffffffff8166528d>] netlink_sendmsg+0x31d/0x780 [ 1320.511472] [<ffffffff81662274>] ? netlink_rcv_wake+0x44/0x60 [ 1320.511475] [<ffffffff816632e3>] ? netlink_recvmsg+0x1d3/0x3e0 [ 1320.511479] [<ffffffff8161c463>] sock_sendmsg+0x93/0xd0 [ 1320.511484] [<ffffffff81332d00>] ? apparmor_file_alloc_security+0x20/0x40 [ 1320.511487] [<ffffffff8162a697>] ? verify_iovec+0x47/0xd0 [ 1320.511491] [<ffffffff8161cc79>] ___sys_sendmsg+0x399/0x3b0 [ 1320.511495] [<ffffffff81254e02>] ? kernfs_seq_stop_active+0x32/0x40 [ 1320.511499] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 1320.511502] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 1320.511505] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 [ 1320.511509] [<ffffffff81122d5c>] ? acct_account_cputime+0x1c/0x20 [ 1320.511512] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 [ 1320.511516] [<ffffffff811fc135>] ? __fget_light+0x25/0x70 [ 1320.511519] [<ffffffff8161d372>] __sys_sendmsg+0x42/0x80 [ 1320.511521] [<ffffffff8161d3c2>] SyS_sendmsg+0x12/0x20 [ 1320.511525] [<ffffffff8173e6a4>] tracesys_phase2+0xd8/0xdd -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 4:48 ` Jay Vosburgh @ 2014-10-24 14:50 ` Paul E. McKenney 2014-10-24 18:20 ` Jay Vosburgh 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 14:50 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > >> > >> On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > >> > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > >> > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > >> > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > >> > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > >> > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > >> > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti > >> > > > > > > wrote: > >> > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > >> > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > >> > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > >> > > > > > > > >> > > > > > > [ . . . ] > >> > > > > > > > >> > > > > > > > > > Don't get me wrong -- the fact that this kthread > >> > > > > > > > > > appears to > >> > > > > > > > > > have > >> > > > > > > > > > blocked within rcu_barrier() for 120 seconds means > >> > > > > > > > > > that > >> > > > > > > > > > something is > >> > > > > > > > > > most definitely wrong here. I am surprised that > >> > > > > > > > > > there are no > >> > > > > > > > > > RCU CPU > >> > > > > > > > > > stall warnings, but perhaps the blockage is in the > >> > > > > > > > > > callback > >> > > > > > > > > > execution > >> > > > > > > > > > rather than grace-period completion. Or something is > >> > > > > > > > > > preventing this > >> > > > > > > > > > kthread from starting up after the wake-up callback > >> > > > > > > > > > executes. > >> > > > > > > > > > Or... > >> > > > > > > > > > > >> > > > > > > > > > Is this thing reproducible? > >> > > > > > > > > > >> > > > > > > > > I've added Yanko on CC, who reported the backtrace > >> > > > > > > > > above and can > >> > > > > > > > > recreate it reliably. Apparently reverting the RCU > >> > > > > > > > > merge commit > >> > > > > > > > > (d6dd50e) and rebuilding the latest after that does > >> > > > > > > > > not show the > >> > > > > > > > > issue. I'll let Yanko explain more and answer any > >> > > > > > > > > questions you > >> > > > > > > > > have. > >> > > > > > > > > >> > > > > > > > - It is reproducible > >> > > > > > > > - I've done another build here to double check and its > >> > > > > > > > definitely > >> > > > > > > > the rcu merge > >> > > > > > > > that's causing it. > >> > > > > > > > > >> > > > > > > > Don't think I'll be able to dig deeper, but I can do > >> > > > > > > > testing if > >> > > > > > > > needed. > >> > > > > > > > >> > > > > > > Please! Does the following patch help? > >> > > > > > > >> > > > > > Nope, doesn't seem to make a difference to the modprobe > >> > > > > > ppp_generic > >> > > > > > test > >> > > > > > >> > > > > Well, I was hoping. I will take a closer look at the RCU > >> > > > > merge commit > >> > > > > and see what suggests itself. I am likely to ask you to > >> > > > > revert specific > >> > > > > commits, if that works for you. > >> > > > > >> > > > Well, rather than reverting commits, could you please try > >> > > > testing the > >> > > > following commits? > >> > > > > >> > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending > >> > > > callbacks after spawning) > >> > > > > >> > > > 73a860cd58a1 (rcu: Replace flush_signals() with > >> > > > WARN_ON(signal_pending())) > >> > > > > >> > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > >> > > > > >> > > > For whatever it is worth, I am guessing this one. > >> > > > >> > > Indeed, c847f14217d5 it is. > >> > > > >> > > Much to my embarrasment I just noticed that in addition to the > >> > > rcu merge, triggering the bug "requires" my specific Fedora > >> > > rawhide network > >> > > setup. Booting in single mode and modprobe ppp_generic is fine. > >> > > The bug > >> > > appears when starting with my regular fedora network setup, which > >> > > in my case > >> > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > >> > > > >> > > Hope that helps. > >> > > > >> > > I am attaching the config. > >> > > >> > It does help a lot, thank you!!! > >> > > >> > The following patch is a bit of a shot in the dark, and assumes that > >> > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > >> > idle > >> > code) introduced the problem. Does this patch fix things up? > >> > >> Unfortunately not, This is linus-tip + patch > > > >OK. Can't have everything, I guess. > > > >> INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > >> Not tainted 3.18.0-rc1+ #4 > >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > >> kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 > >> Workqueue: netns cleanup_net > >> ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 > >> ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 > >> ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 > >> Call Trace: > >> [<ffffffff8185b8e9>] schedule+0x29/0x70 > >> [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 > >> [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > >> [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 > >> [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 > >> [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 > >> [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 > >> [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 > >> [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 > >> [<ffffffff8112a315>] rcu_barrier+0x15/0x20 > >> [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 > >> [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 > >> [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 > >> [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 > >> [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 > >> [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 > >> [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 > >> [<ffffffff810cca98>] process_one_work+0x218/0x850 > >> [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 > >> [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 > >> [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 > >> [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 > >> [<ffffffff810d348b>] kthread+0x10b/0x130 > >> [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > >> [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 > >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > >> 4 locks held by kworker/u16:6/96: > >> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > >> #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > >> #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 > >> #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 > >> INFO: task modprobe:1045 blocked for more than 120 seconds. > >> Not tainted 3.18.0-rc1+ #4 > >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > >> modprobe D ffff880218343480 12920 1045 1044 0x00000080 > >> ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 > >> ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 > >> ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 > >> Call Trace: > >> [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 > >> [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 > >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > >> [<ffffffffa0673000>] ? 0xffffffffa0673000 > >> [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > >> [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] > >> [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > >> [<ffffffff81153052>] load_module+0x20c2/0x2870 > >> [<ffffffff8114e030>] ? store_uevent+0x70/0x70 > >> [<ffffffff81278717>] ? kernel_read+0x57/0x90 > >> [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 > >> [<ffffffff81862969>] system_call_fastpath+0x12/0x17 > >> 1 lock held by modprobe/1045: > >> #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > > >Presumably the kworker/u16:6 completed, then modprobe hung? > > > >If not, I have some very hard questions about why net_mutex can be > >held by two tasks concurrently, given that it does not appear to be a > >reader-writer lock... > > > >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in > >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle > >NOCB callbacks from irq-disabled idle code) would fail. Is that the case? > >If not, could you please bisect the commits between 11ed7f934cb8 (rcu: > >Make nocb leader kthreads process pending callbacks after spawning) > >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? > > Just a note to add that I am also reliably inducing what appears > to be this issue on a current -net tree, when configuring openvswitch > via script. I am available to test patches or bisect tomorrow (Friday) > US time if needed. Thank you, Jay! Could you please check to see if reverting this commit fixes things for you? 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs Reverting is not a long-term fix, as this commit is itself a bug fix, but would be good to check to see if you are seeing the same thing that Yanko is. ;-) Thanx, Paul > The stack is as follows: > > [ 1320.492020] INFO: task ovs-vswitchd:1303 blocked for more than 120 seconds. > [ 1320.498965] Not tainted 3.17.0-testola+ #1 > [ 1320.503570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 1320.511374] ovs-vswitchd D ffff88013fc14600 0 1303 1302 0x00000004 > [ 1320.511378] ffff8801388d77d8 0000000000000002 ffff880031144b00 ffff8801388d7fd8 > [ 1320.511382] 0000000000014600 0000000000014600 ffff8800b092e400 ffff880031144b00 > [ 1320.511385] ffff8800b1126000 ffffffff81c58ad0 ffffffff81c58ad8 7fffffffffffffff > [ 1320.511389] Call Trace: > [ 1320.511396] [<ffffffff81739db9>] schedule+0x29/0x70 > [ 1320.511399] [<ffffffff8173cd8c>] schedule_timeout+0x1dc/0x260 > [ 1320.511404] [<ffffffff8109698d>] ? check_preempt_curr+0x8d/0xa0 > [ 1320.511407] [<ffffffff810969bd>] ? ttwu_do_wakeup+0x1d/0xd0 > [ 1320.511410] [<ffffffff8173aab6>] wait_for_completion+0xa6/0x160 > [ 1320.511413] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 > [ 1320.511417] [<ffffffff810cdb57>] _rcu_barrier+0x157/0x200 > [ 1320.511419] [<ffffffff810cdc55>] rcu_barrier+0x15/0x20 > [ 1320.511423] [<ffffffff8163a780>] netdev_run_todo+0x60/0x300 > [ 1320.511427] [<ffffffff8164515e>] rtnl_unlock+0xe/0x10 > [ 1320.511435] [<ffffffffa01aecc5>] internal_dev_destroy+0x55/0x80 [openvswitch] > [ 1320.511440] [<ffffffffa01ae622>] ovs_vport_del+0x32/0x40 [openvswitch] > [ 1320.511444] [<ffffffffa01a7dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] > [ 1320.511448] [<ffffffffa01a7ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] > [ 1320.511452] [<ffffffff816675b5>] genl_family_rcv_msg+0x1a5/0x3c0 > [ 1320.511455] [<ffffffff816677d0>] ? genl_family_rcv_msg+0x3c0/0x3c0 > [ 1320.511458] [<ffffffff81667861>] genl_rcv_msg+0x91/0xd0 > [ 1320.511461] [<ffffffff816658d1>] netlink_rcv_skb+0xc1/0xe0 > [ 1320.511463] [<ffffffff81665dfc>] genl_rcv+0x2c/0x40 > [ 1320.511466] [<ffffffff81664e66>] netlink_unicast+0xf6/0x200 > [ 1320.511468] [<ffffffff8166528d>] netlink_sendmsg+0x31d/0x780 > [ 1320.511472] [<ffffffff81662274>] ? netlink_rcv_wake+0x44/0x60 > [ 1320.511475] [<ffffffff816632e3>] ? netlink_recvmsg+0x1d3/0x3e0 > [ 1320.511479] [<ffffffff8161c463>] sock_sendmsg+0x93/0xd0 > [ 1320.511484] [<ffffffff81332d00>] ? apparmor_file_alloc_security+0x20/0x40 > [ 1320.511487] [<ffffffff8162a697>] ? verify_iovec+0x47/0xd0 > [ 1320.511491] [<ffffffff8161cc79>] ___sys_sendmsg+0x399/0x3b0 > [ 1320.511495] [<ffffffff81254e02>] ? kernfs_seq_stop_active+0x32/0x40 > [ 1320.511499] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 1320.511502] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 1320.511505] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 > [ 1320.511509] [<ffffffff81122d5c>] ? acct_account_cputime+0x1c/0x20 > [ 1320.511512] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 > [ 1320.511516] [<ffffffff811fc135>] ? __fget_light+0x25/0x70 > [ 1320.511519] [<ffffffff8161d372>] __sys_sendmsg+0x42/0x80 > [ 1320.511521] [<ffffffff8161d3c2>] SyS_sendmsg+0x12/0x20 > [ 1320.511525] [<ffffffff8173e6a4>] tracesys_phase2+0xd8/0xdd > > -J > > --- > -Jay Vosburgh, jay.vosburgh@canonical.com > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 14:50 ` Paul E. McKenney @ 2014-10-24 18:20 ` Jay Vosburgh 2014-10-24 18:33 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 18:20 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote: >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: [...] >> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in >> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle >> >NOCB callbacks from irq-disabled idle code) would fail. Is that the case? >> >If not, could you please bisect the commits between 11ed7f934cb8 (rcu: >> >Make nocb leader kthreads process pending callbacks after spawning) >> >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? >> >> Just a note to add that I am also reliably inducing what appears >> to be this issue on a current -net tree, when configuring openvswitch >> via script. I am available to test patches or bisect tomorrow (Friday) >> US time if needed. > >Thank you, Jay! Could you please check to see if reverting this commit >fixes things for you? > >35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > >Reverting is not a long-term fix, as this commit is itself a bug fix, >but would be good to check to see if you are seeing the same thing that >Yanko is. ;-) Just to confirm what Yanko found, reverting this commit makes the problem go away for me. -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 18:20 ` Jay Vosburgh @ 2014-10-24 18:33 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 18:33 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Fri, Oct 24, 2014 at 11:20:11AM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote: > >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > [...] > >> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in > >> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle > >> >NOCB callbacks from irq-disabled idle code) would fail. Is that the case? > >> >If not, could you please bisect the commits between 11ed7f934cb8 (rcu: > >> >Make nocb leader kthreads process pending callbacks after spawning) > >> >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? > >> > >> Just a note to add that I am also reliably inducing what appears > >> to be this issue on a current -net tree, when configuring openvswitch > >> via script. I am available to test patches or bisect tomorrow (Friday) > >> US time if needed. > > > >Thank you, Jay! Could you please check to see if reverting this commit > >fixes things for you? > > > >35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > >Reverting is not a long-term fix, as this commit is itself a bug fix, > >but would be good to check to see if you are seeing the same thing that > >Yanko is. ;-) > > Just to confirm what Yanko found, reverting this commit makes > the problem go away for me. Thank you! I take it that the patches that don't help Yanko also don't help you? Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-23 22:04 ` Paul E. McKenney 2014-10-24 4:48 ` Jay Vosburgh @ 2014-10-24 9:08 ` Yanko Kaneti 2014-10-24 15:40 ` Paul E. McKenney 1 sibling, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-24 9:08 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote: > > > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote: > > > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote: > > > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote: > > > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti > > > > > > > > wrote: > > > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote: > > > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney > > > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > > > Don't get me wrong -- the fact that this kthread > > > > > > > > > > > appears to > > > > > > > > > > > have > > > > > > > > > > > blocked within rcu_barrier() for 120 seconds means > > > > > > > > > > > that > > > > > > > > > > > something is > > > > > > > > > > > most definitely wrong here. I am surprised that > > > > > > > > > > > there are no > > > > > > > > > > > RCU CPU > > > > > > > > > > > stall warnings, but perhaps the blockage is in the > > > > > > > > > > > callback > > > > > > > > > > > execution > > > > > > > > > > > rather than grace-period completion. Or something is > > > > > > > > > > > preventing this > > > > > > > > > > > kthread from starting up after the wake-up callback > > > > > > > > > > > executes. > > > > > > > > > > > Or... > > > > > > > > > > > > > > > > > > > > > > Is this thing reproducible? > > > > > > > > > > > > > > > > > > > > I've added Yanko on CC, who reported the backtrace > > > > > > > > > > above and can > > > > > > > > > > recreate it reliably. Apparently reverting the RCU > > > > > > > > > > merge commit > > > > > > > > > > (d6dd50e) and rebuilding the latest after that does > > > > > > > > > > not show the > > > > > > > > > > issue. I'll let Yanko explain more and answer any > > > > > > > > > > questions you > > > > > > > > > > have. > > > > > > > > > > > > > > > > > > - It is reproducible > > > > > > > > > - I've done another build here to double check and its > > > > > > > > > definitely > > > > > > > > > the rcu merge > > > > > > > > > that's causing it. > > > > > > > > > > > > > > > > > > Don't think I'll be able to dig deeper, but I can do > > > > > > > > > testing if > > > > > > > > > needed. > > > > > > > > > > > > > > > > Please! Does the following patch help? > > > > > > > > > > > > > > Nope, doesn't seem to make a difference to the modprobe > > > > > > > ppp_generic > > > > > > > test > > > > > > > > > > > > Well, I was hoping. I will take a closer look at the RCU > > > > > > merge commit > > > > > > and see what suggests itself. I am likely to ask you to > > > > > > revert specific > > > > > > commits, if that works for you. > > > > > > > > > > Well, rather than reverting commits, could you please try > > > > > testing the > > > > > following commits? > > > > > > > > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending > > > > > callbacks after spawning) > > > > > > > > > > 73a860cd58a1 (rcu: Replace flush_signals() with > > > > > WARN_ON(signal_pending())) > > > > > > > > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait()) > > > > > > > > > > For whatever it is worth, I am guessing this one. > > > > > > > > Indeed, c847f14217d5 it is. > > > > > > > > Much to my embarrasment I just noticed that in addition to the > > > > rcu merge, triggering the bug "requires" my specific Fedora > > > > rawhide network > > > > setup. Booting in single mode and modprobe ppp_generic is fine. > > > > The bug > > > > appears when starting with my regular fedora network setup, which > > > > in my case > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > > > > > > > Hope that helps. > > > > > > > > I am attaching the config. > > > > > > It does help a lot, thank you!!! > > > > > > The following patch is a bit of a shot in the dark, and assumes that > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > > > idle > > > code) introduced the problem. Does this patch fix things up? > > > > Unfortunately not, This is linus-tip + patch > > OK. Can't have everything, I guess. > > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > > Not tainted 3.18.0-rc1+ #4 > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 > > Workqueue: netns cleanup_net > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 > > Call Trace: > > [<ffffffff8185b8e9>] schedule+0x29/0x70 > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20 > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 > > [<ffffffff810cca98>] process_one_work+0x218/0x850 > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 > > [<ffffffff810d348b>] kthread+0x10b/0x130 > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > 4 locks held by kworker/u16:6/96: > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 > > INFO: task modprobe:1045 blocked for more than 120 seconds. > > Not tainted 3.18.0-rc1+ #4 > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > modprobe D ffff880218343480 12920 1045 1044 0x00000080 > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 > > Call Trace: > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > [<ffffffffa0673000>] ? 0xffffffffa0673000 > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > > [<ffffffff81153052>] load_module+0x20c2/0x2870 > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70 > > [<ffffffff81278717>] ? kernel_read+0x57/0x90 > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17 > > 1 lock held by modprobe/1045: > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > Presumably the kworker/u16:6 completed, then modprobe hung? > > If not, I have some very hard questions about why net_mutex can be > held by two tasks concurrently, given that it does not appear to be a > reader-writer lock... > > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle > NOCB callbacks from irq-disabled idle code) would fail. Is that the case? > If not, could you please bisect the commits between 11ed7f934cb8 (rcu: > Make nocb leader kthreads process pending callbacks after spawning) > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? Ok, unless I've messsed up something major, bisecting points to: 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs Makes any sense ? Another thing I noticed is that in failure mode the libvirtd bridge actually doesn't show up. So maybe ppp is just the first thing to try that bumps up into whatever libvirtd is failing to do to setup those. Truly hope this is not something with random timing dependency.... --Yanko ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 9:08 ` Yanko Kaneti @ 2014-10-24 15:40 ` Paul E. McKenney 2014-10-24 16:29 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 15:40 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: [ . . . ] > > > > > Indeed, c847f14217d5 it is. > > > > > > > > > > Much to my embarrasment I just noticed that in addition to the > > > > > rcu merge, triggering the bug "requires" my specific Fedora > > > > > rawhide network > > > > > setup. Booting in single mode and modprobe ppp_generic is fine. > > > > > The bug > > > > > appears when starting with my regular fedora network setup, which > > > > > in my case > > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > > > > > > > > > Hope that helps. > > > > > > > > > > I am attaching the config. > > > > > > > > It does help a lot, thank you!!! > > > > > > > > The following patch is a bit of a shot in the dark, and assumes that > > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > > > > idle > > > > code) introduced the problem. Does this patch fix things up? > > > > > > Unfortunately not, This is linus-tip + patch > > > > OK. Can't have everything, I guess. > > > > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > > > Not tainted 3.18.0-rc1+ #4 > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 > > > Workqueue: netns cleanup_net > > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 > > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 > > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 > > > Call Trace: > > > [<ffffffff8185b8e9>] schedule+0x29/0x70 > > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 > > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 > > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 > > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 > > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 > > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 > > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 > > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20 > > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 > > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 > > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 > > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 > > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 > > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 > > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 > > > [<ffffffff810cca98>] process_one_work+0x218/0x850 > > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 > > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 > > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 > > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 > > > [<ffffffff810d348b>] kthread+0x10b/0x130 > > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > > 4 locks held by kworker/u16:6/96: > > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 > > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 > > > INFO: task modprobe:1045 blocked for more than 120 seconds. > > > Not tainted 3.18.0-rc1+ #4 > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > modprobe D ffff880218343480 12920 1045 1044 0x00000080 > > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 > > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 > > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 > > > Call Trace: > > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 > > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > > [<ffffffffa0673000>] ? 0xffffffffa0673000 > > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] > > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > > > [<ffffffff81153052>] load_module+0x20c2/0x2870 > > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70 > > > [<ffffffff81278717>] ? kernel_read+0x57/0x90 > > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 > > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17 > > > 1 lock held by modprobe/1045: > > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > > > Presumably the kworker/u16:6 completed, then modprobe hung? > > > > If not, I have some very hard questions about why net_mutex can be > > held by two tasks concurrently, given that it does not appear to be a > > reader-writer lock... > > > > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in > > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle > > NOCB callbacks from irq-disabled idle code) would fail. Is that the case? > > If not, could you please bisect the commits between 11ed7f934cb8 (rcu: > > Make nocb leader kthreads process pending callbacks after spawning) > > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? > > Ok, unless I've messsed up something major, bisecting points to: > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > Makes any sense ? Good question. ;-) Are any of your online CPUs missing rcuo kthreads? There should be kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > Another thing I noticed is that in failure mode the libvirtd bridge actually > doesn't show up. So maybe ppp is just the first thing to try that bumps up > into whatever libvirtd is failing to do to setup those. > > Truly hope this is not something with random timing dependency.... Me too. ;-) Thanx, Paul > --Yanko > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 15:40 ` Paul E. McKenney @ 2014-10-24 16:29 ` Yanko Kaneti 2014-10-24 16:54 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-24 16:29 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > [ . . . ] > > > > > > > Indeed, c847f14217d5 it is. > > > > > > > > > > > > Much to my embarrasment I just noticed that in addition to the > > > > > > rcu merge, triggering the bug "requires" my specific Fedora > > > > > > rawhide network > > > > > > setup. Booting in single mode and modprobe ppp_generic is fine. > > > > > > The bug > > > > > > appears when starting with my regular fedora network setup, which > > > > > > in my case > > > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup. > > > > > > > > > > > > Hope that helps. > > > > > > > > > > > > I am attaching the config. > > > > > > > > > > It does help a lot, thank you!!! > > > > > > > > > > The following patch is a bit of a shot in the dark, and assumes that > > > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled > > > > > idle > > > > > code) introduced the problem. Does this patch fix things up? > > > > > > > > Unfortunately not, This is linus-tip + patch > > > > > > OK. Can't have everything, I guess. > > > > > > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > > > > Not tainted 3.18.0-rc1+ #4 > > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000 > > > > Workqueue: netns cleanup_net > > > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00 > > > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0 > > > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650 > > > > Call Trace: > > > > [<ffffffff8185b8e9>] schedule+0x29/0x70 > > > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410 > > > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > > > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0 > > > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50 > > > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200 > > > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150 > > > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20 > > > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200 > > > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20 > > > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310 > > > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0 > > > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10 > > > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180 > > > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0 > > > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60 > > > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0 > > > > [<ffffffff810cca98>] process_one_work+0x218/0x850 > > > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850 > > > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0 > > > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0 > > > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850 > > > > [<ffffffff810d348b>] kthread+0x10b/0x130 > > > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0 > > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250 > > > > 4 locks held by kworker/u16:6/96: > > > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850 > > > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0 > > > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200 > > > > INFO: task modprobe:1045 blocked for more than 120 seconds. > > > > Not tainted 3.18.0-rc1+ #4 > > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > > modprobe D ffff880218343480 12920 1045 1044 0x00000080 > > > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00 > > > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480 > > > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480 > > > > Call Trace: > > > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80 > > > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440 > > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50 > > > > [<ffffffffa0673000>] ? 0xffffffffa0673000 > > > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge] > > > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > > > > [<ffffffff81153052>] load_module+0x20c2/0x2870 > > > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70 > > > > [<ffffffff81278717>] ? kernel_read+0x57/0x90 > > > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0 > > > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17 > > > > 1 lock held by modprobe/1045: > > > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50 > > > > > > Presumably the kworker/u16:6 completed, then modprobe hung? > > > > > > If not, I have some very hard questions about why net_mutex can be > > > held by two tasks concurrently, given that it does not appear to be a > > > reader-writer lock... > > > > > > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in > > > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle > > > NOCB callbacks from irq-disabled idle code) would fail. Is that the case? > > > If not, could you please bisect the commits between 11ed7f934cb8 (rcu: > > > Make nocb leader kthreads process pending callbacks after spawning) > > > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())? > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > Makes any sense ? > > Good question. ;-) > > Are any of your online CPUs missing rcuo kthreads? There should be > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 and the modprobe ppp_generic testcase reliably works, libvirt also manages to setup its bridge. Just with linux-tip , the rcuos are 6 but the failure is as reliable as before. Awating instructions: :) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 16:29 ` Yanko Kaneti @ 2014-10-24 16:54 ` Paul E. McKenney 2014-10-24 17:09 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 16:54 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: [ . . . ] > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > Makes any sense ? > > > > Good question. ;-) > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > and the modprobe ppp_generic testcase reliably works, libvirt also manages > to setup its bridge. > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > before. Thank you, very interesting. Which 6 of the rcuos are present? > Awating instructions: :) Well, I thought I understood the problem until you found that only 6 of the expected 8 rcuos are present with linux-tip without the revert. ;-) I am putting together a patch for the part of the problem that I think I understand, of course, but it would help a lot to know which two of the rcuos are missing. ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 16:54 ` Paul E. McKenney @ 2014-10-24 17:09 ` Yanko Kaneti 2014-10-24 17:20 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-24 17:09 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > [ . . . ] > > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > > > Makes any sense ? > > > > > > Good question. ;-) > > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > to setup its bridge. > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > before. > Thank you, very interesting. Which 6 of the rcuos are present? Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this Phenom II. > > Awating instructions: :) > > Well, I thought I understood the problem until you found that only 6 of > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > I am putting together a patch for the part of the problem that I think > I understand, of course, but it would help a lot to know which two of > the rcuos are missing. ;-) > Ready to test --Yanko ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 17:09 ` Yanko Kaneti @ 2014-10-24 17:20 ` Paul E. McKenney 2014-10-24 17:35 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 17:20 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > > [ . . . ] > > > > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > > > > > Makes any sense ? > > > > > > > > Good question. ;-) > > > > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > > to setup its bridge. > > > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > > before. > > > Thank you, very interesting. Which 6 of the rcuos are present? > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > Phenom II. Ah, you get 8 without the patch because it creates them for potential CPUs as well as real ones. OK, got it. > > > Awating instructions: :) > > > > Well, I thought I understood the problem until you found that only 6 of > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > > > I am putting together a patch for the part of the problem that I think > > I understand, of course, but it would help a lot to know which two of > > the rcuos are missing. ;-) > > Ready to test Well, if you are feeling aggressive, give the following patch a spin. I am doing sanity tests on it in the meantime. Thanx, Paul ------------------------------------------------------------------------ diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 29fb23f33c18..927c17b081c7 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) rdp->nocb_leader = rdp_spawn; if (rdp_last && rdp != rdp_spawn) rdp_last->nocb_next_follower = rdp; - rdp_last = rdp; - rdp = rdp->nocb_next_follower; - rdp_last->nocb_next_follower = NULL; + if (rdp == rdp_spawn) { + rdp = rdp->nocb_next_follower; + } else { + rdp_last = rdp; + rdp = rdp->nocb_next_follower; + rdp_last->nocb_next_follower = NULL; + } } while (rdp); rdp_spawn->nocb_next_follower = rdp_old_leader; } ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 17:20 ` Paul E. McKenney @ 2014-10-24 17:35 ` Yanko Kaneti 2014-10-24 18:32 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-24 17:35 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > > > > [ . . . ] > > > > > > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > > > > > > > Makes any sense ? > > > > > > > > > > Good question. ;-) > > > > > > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > > > > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > > > to setup its bridge. > > > > > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > > > before. > > > > > Thank you, very interesting. Which 6 of the rcuos are present? > > > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > > Phenom II. > > Ah, you get 8 without the patch because it creates them for potential > CPUs as well as real ones. OK, got it. > > > > > Awating instructions: :) > > > > > > Well, I thought I understood the problem until you found that only 6 of > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > > > > > I am putting together a patch for the part of the problem that I think > > > I understand, of course, but it would help a lot to know which two of > > > the rcuos are missing. ;-) > > > > Ready to test > > Well, if you are feeling aggressive, give the following patch a spin. > I am doing sanity tests on it in the meantime. Doesn't seem to make a difference here > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > index 29fb23f33c18..927c17b081c7 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) > rdp->nocb_leader = rdp_spawn; > if (rdp_last && rdp != rdp_spawn) > rdp_last->nocb_next_follower = rdp; > - rdp_last = rdp; > - rdp = rdp->nocb_next_follower; > - rdp_last->nocb_next_follower = NULL; > + if (rdp == rdp_spawn) { > + rdp = rdp->nocb_next_follower; > + } else { > + rdp_last = rdp; > + rdp = rdp->nocb_next_follower; > + rdp_last->nocb_next_follower = NULL; > + } > } while (rdp); > rdp_spawn->nocb_next_follower = rdp_old_leader; > } > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 17:35 ` Yanko Kaneti @ 2014-10-24 18:32 ` Paul E. McKenney 2014-10-24 18:49 ` Jay Vosburgh 2014-10-24 21:25 ` Yanko Kaneti 0 siblings, 2 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 18:32 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > > > > > > [ . . . ] > > > > > > > > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > > > > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > > > > > > > > > Makes any sense ? > > > > > > > > > > > > Good question. ;-) > > > > > > > > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > > > > > > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > > > > to setup its bridge. > > > > > > > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > > > > before. > > > > > > > Thank you, very interesting. Which 6 of the rcuos are present? > > > > > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > > > Phenom II. > > > > Ah, you get 8 without the patch because it creates them for potential > > CPUs as well as real ones. OK, got it. > > > > > > > Awating instructions: :) > > > > > > > > Well, I thought I understood the problem until you found that only 6 of > > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > > > > > > > I am putting together a patch for the part of the problem that I think > > > > I understand, of course, but it would help a lot to know which two of > > > > the rcuos are missing. ;-) > > > > > > Ready to test > > > > Well, if you are feeling aggressive, give the following patch a spin. > > I am doing sanity tests on it in the meantime. > > Doesn't seem to make a difference here OK, inspection isn't cutting it, so time for tracing. Does the system respond to user input? If so, please enable rcu:rcu_barrier ftrace before the problem occurs, then dump the trace buffer after the problem occurs. Thanx, Paul > > ------------------------------------------------------------------------ > > > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > index 29fb23f33c18..927c17b081c7 100644 > > --- a/kernel/rcu/tree_plugin.h > > +++ b/kernel/rcu/tree_plugin.h > > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) > > rdp->nocb_leader = rdp_spawn; > > if (rdp_last && rdp != rdp_spawn) > > rdp_last->nocb_next_follower = rdp; > > - rdp_last = rdp; > > - rdp = rdp->nocb_next_follower; > > - rdp_last->nocb_next_follower = NULL; > > + if (rdp == rdp_spawn) { > > + rdp = rdp->nocb_next_follower; > > + } else { > > + rdp_last = rdp; > > + rdp = rdp->nocb_next_follower; > > + rdp_last->nocb_next_follower = NULL; > > + } > > } while (rdp); > > rdp_spawn->nocb_next_follower = rdp_old_leader; > > } > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 18:32 ` Paul E. McKenney @ 2014-10-24 18:49 ` Jay Vosburgh 2014-10-24 18:57 ` Paul E. McKenney 2014-10-24 21:25 ` Yanko Kaneti 1 sibling, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 18:49 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: >> On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: >> > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: >> > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: >> > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: >> > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: >> > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: >> > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: >> > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: >> > > > > > > > > >> > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: >> > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: >> > > > >> > > > [ . . . ] >> > > > >> > > > > > > Ok, unless I've messsed up something major, bisecting points to: >> > > > > > > >> > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs >> > > > > > > >> > > > > > > Makes any sense ? >> > > > > > >> > > > > > Good question. ;-) >> > > > > > >> > > > > > Are any of your online CPUs missing rcuo kthreads? There should be >> > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. >> > > > > >> > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 >> > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages >> > > > > to setup its bridge. >> > > > > >> > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as >> > > > > before. >> > > >> > > > Thank you, very interesting. Which 6 of the rcuos are present? >> > > >> > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this >> > > Phenom II. >> > >> > Ah, you get 8 without the patch because it creates them for potential >> > CPUs as well as real ones. OK, got it. >> > >> > > > > Awating instructions: :) >> > > > >> > > > Well, I thought I understood the problem until you found that only 6 of >> > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) >> > > > >> > > > I am putting together a patch for the part of the problem that I think >> > > > I understand, of course, but it would help a lot to know which two of >> > > > the rcuos are missing. ;-) >> > > >> > > Ready to test >> > >> > Well, if you are feeling aggressive, give the following patch a spin. >> > I am doing sanity tests on it in the meantime. >> >> Doesn't seem to make a difference here > >OK, inspection isn't cutting it, so time for tracing. Does the system >respond to user input? If so, please enable rcu:rcu_barrier ftrace before >the problem occurs, then dump the trace buffer after the problem occurs. My system is up and responsive when the problem occurs, so this shouldn't be a problem. Do you want the ftrace with your patch below, or unmodified tip of tree? -J > Thanx, Paul > >> > ------------------------------------------------------------------------ >> > >> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h >> > index 29fb23f33c18..927c17b081c7 100644 >> > --- a/kernel/rcu/tree_plugin.h >> > +++ b/kernel/rcu/tree_plugin.h >> > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) >> > rdp->nocb_leader = rdp_spawn; >> > if (rdp_last && rdp != rdp_spawn) >> > rdp_last->nocb_next_follower = rdp; >> > - rdp_last = rdp; >> > - rdp = rdp->nocb_next_follower; >> > - rdp_last->nocb_next_follower = NULL; >> > + if (rdp == rdp_spawn) { >> > + rdp = rdp->nocb_next_follower; >> > + } else { >> > + rdp_last = rdp; >> > + rdp = rdp->nocb_next_follower; >> > + rdp_last->nocb_next_follower = NULL; >> > + } >> > } while (rdp); >> > rdp_spawn->nocb_next_follower = rdp_old_leader; >> > } >> > --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 18:49 ` Jay Vosburgh @ 2014-10-24 18:57 ` Paul E. McKenney 2014-10-24 20:15 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 18:57 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos On Fri, Oct 24, 2014 at 11:49:48AM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > >> On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > >> > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > >> > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > >> > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > >> > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > >> > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > >> > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > >> > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > >> > > > > > > > > > >> > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > >> > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > >> > > > > >> > > > [ . . . ] > >> > > > > >> > > > > > > Ok, unless I've messsed up something major, bisecting points to: > >> > > > > > > > >> > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > >> > > > > > > > >> > > > > > > Makes any sense ? > >> > > > > > > >> > > > > > Good question. ;-) > >> > > > > > > >> > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > >> > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > >> > > > > > >> > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > >> > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > >> > > > > to setup its bridge. > >> > > > > > >> > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > >> > > > > before. > >> > > > >> > > > Thank you, very interesting. Which 6 of the rcuos are present? > >> > > > >> > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > >> > > Phenom II. > >> > > >> > Ah, you get 8 without the patch because it creates them for potential > >> > CPUs as well as real ones. OK, got it. > >> > > >> > > > > Awating instructions: :) > >> > > > > >> > > > Well, I thought I understood the problem until you found that only 6 of > >> > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > >> > > > > >> > > > I am putting together a patch for the part of the problem that I think > >> > > > I understand, of course, but it would help a lot to know which two of > >> > > > the rcuos are missing. ;-) > >> > > > >> > > Ready to test > >> > > >> > Well, if you are feeling aggressive, give the following patch a spin. > >> > I am doing sanity tests on it in the meantime. > >> > >> Doesn't seem to make a difference here > > > >OK, inspection isn't cutting it, so time for tracing. Does the system > >respond to user input? If so, please enable rcu:rcu_barrier ftrace before > >the problem occurs, then dump the trace buffer after the problem occurs. > > My system is up and responsive when the problem occurs, so this > shouldn't be a problem. Nice! ;-) > Do you want the ftrace with your patch below, or unmodified tip > of tree? Let's please start with the patch. Thanx, Paul > -J > > > > Thanx, Paul > > > >> > ------------------------------------------------------------------------ > >> > > >> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > >> > index 29fb23f33c18..927c17b081c7 100644 > >> > --- a/kernel/rcu/tree_plugin.h > >> > +++ b/kernel/rcu/tree_plugin.h > >> > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) > >> > rdp->nocb_leader = rdp_spawn; > >> > if (rdp_last && rdp != rdp_spawn) > >> > rdp_last->nocb_next_follower = rdp; > >> > - rdp_last = rdp; > >> > - rdp = rdp->nocb_next_follower; > >> > - rdp_last->nocb_next_follower = NULL; > >> > + if (rdp == rdp_spawn) { > >> > + rdp = rdp->nocb_next_follower; > >> > + } else { > >> > + rdp_last = rdp; > >> > + rdp = rdp->nocb_next_follower; > >> > + rdp_last->nocb_next_follower = NULL; > >> > + } > >> > } while (rdp); > >> > rdp_spawn->nocb_next_follower = rdp_old_leader; > >> > } > >> > > > --- > -Jay Vosburgh, jay.vosburgh@canonical.com > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 18:57 ` Paul E. McKenney @ 2014-10-24 20:15 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 20:15 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos On Fri, Oct 24, 2014 at 11:57:53AM -0700, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 11:49:48AM -0700, Jay Vosburgh wrote: > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > >On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > >> On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > >> > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > > >> > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > > >> > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > >> > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > >> > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > >> > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > >> > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > >> > > > > > > > > > > >> > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > >> > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > >> > > > > > >> > > > [ . . . ] > > >> > > > > > >> > > > > > > Ok, unless I've messsed up something major, bisecting points to: > > >> > > > > > > > > >> > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > >> > > > > > > > > >> > > > > > > Makes any sense ? > > >> > > > > > > > >> > > > > > Good question. ;-) > > >> > > > > > > > >> > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > >> > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > >> > > > > > > >> > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > >> > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > >> > > > > to setup its bridge. > > >> > > > > > > >> > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > >> > > > > before. > > >> > > > > >> > > > Thank you, very interesting. Which 6 of the rcuos are present? > > >> > > > > >> > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > > >> > > Phenom II. > > >> > > > >> > Ah, you get 8 without the patch because it creates them for potential > > >> > CPUs as well as real ones. OK, got it. > > >> > > > >> > > > > Awating instructions: :) > > >> > > > > > >> > > > Well, I thought I understood the problem until you found that only 6 of > > >> > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > >> > > > > > >> > > > I am putting together a patch for the part of the problem that I think > > >> > > > I understand, of course, but it would help a lot to know which two of > > >> > > > the rcuos are missing. ;-) > > >> > > > > >> > > Ready to test > > >> > > > >> > Well, if you are feeling aggressive, give the following patch a spin. > > >> > I am doing sanity tests on it in the meantime. > > >> > > >> Doesn't seem to make a difference here > > > > > >OK, inspection isn't cutting it, so time for tracing. Does the system > > >respond to user input? If so, please enable rcu:rcu_barrier ftrace before > > >the problem occurs, then dump the trace buffer after the problem occurs. > > > > My system is up and responsive when the problem occurs, so this > > shouldn't be a problem. > > Nice! ;-) > > > Do you want the ftrace with your patch below, or unmodified tip > > of tree? > > Let's please start with the patch. And I should hasten to add that you need to set CONFIG_RCU_TRACE=y for these tracepoints to be enabled. Thanx, Paul > > -J > > > > > > > Thanx, Paul > > > > > >> > ------------------------------------------------------------------------ > > >> > > > >> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > >> > index 29fb23f33c18..927c17b081c7 100644 > > >> > --- a/kernel/rcu/tree_plugin.h > > >> > +++ b/kernel/rcu/tree_plugin.h > > >> > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) > > >> > rdp->nocb_leader = rdp_spawn; > > >> > if (rdp_last && rdp != rdp_spawn) > > >> > rdp_last->nocb_next_follower = rdp; > > >> > - rdp_last = rdp; > > >> > - rdp = rdp->nocb_next_follower; > > >> > - rdp_last->nocb_next_follower = NULL; > > >> > + if (rdp == rdp_spawn) { > > >> > + rdp = rdp->nocb_next_follower; > > >> > + } else { > > >> > + rdp_last = rdp; > > >> > + rdp = rdp->nocb_next_follower; > > >> > + rdp_last->nocb_next_follower = NULL; > > >> > + } > > >> > } while (rdp); > > >> > rdp_spawn->nocb_next_follower = rdp_old_leader; > > >> > } > > >> > > > > > --- > > -Jay Vosburgh, jay.vosburgh@canonical.com > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 18:32 ` Paul E. McKenney 2014-10-24 18:49 ` Jay Vosburgh @ 2014-10-24 21:25 ` Yanko Kaneti 2014-10-24 21:49 ` Paul E. McKenney 1 sibling, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-24 21:25 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > > On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote: > > > > On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote: > > > > > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote: > > > > > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote: > > > > > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote: > > > > > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote: > > > > > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote: > > > > > > > > > > > > > > > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote: > > > > > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote: > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > Ok, unless I've messsed up something major, bisecting points to: > > > > > > > > > > > > > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs > > > > > > > > > > > > > > > > Makes any sense ? > > > > > > > > > > > > > > Good question. ;-) > > > > > > > > > > > > > > Are any of your online CPUs missing rcuo kthreads? There should be > > > > > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU. > > > > > > > > > > > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8 > > > > > > and the modprobe ppp_generic testcase reliably works, libvirt also manages > > > > > > to setup its bridge. > > > > > > > > > > > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as > > > > > > before. > > > > > > > > > Thank you, very interesting. Which 6 of the rcuos are present? > > > > > > > > Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this > > > > Phenom II. > > > > > > Ah, you get 8 without the patch because it creates them for potential > > > CPUs as well as real ones. OK, got it. > > > > > > > > > Awating instructions: :) > > > > > > > > > > Well, I thought I understood the problem until you found that only 6 of > > > > > the expected 8 rcuos are present with linux-tip without the revert. ;-) > > > > > > > > > > I am putting together a patch for the part of the problem that I think > > > > > I understand, of course, but it would help a lot to know which two of > > > > > the rcuos are missing. ;-) > > > > > > > > Ready to test > > > > > > Well, if you are feeling aggressive, give the following patch a spin. > > > I am doing sanity tests on it in the meantime. > > > > Doesn't seem to make a difference here > > OK, inspection isn't cutting it, so time for tracing. Does the system > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > the problem occurs, then dump the trace buffer after the problem occurs. Sorry for being unresposive here, but I know next to nothing about tracing or most things about the kernel, so I have some cathing up to do. In the meantime some layman observations while I tried to find what exactly triggers the problem. - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd - libvirtd seems to be very active in using all sorts of kernel facilities that are modules on fedora so it seems to cause many simultaneous kworker calls to modprobe - there are 8 kworker/u16 from 0 to 7 - one of these kworkers always deadlocks, while there appear to be two kworker/u16:6 - the seventh 6 vs 8 as in 6 rcuos where before they were always 8 Just observations from someone who still doesn't know what the u16 kworkers are.. -- Yanko > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > > index 29fb23f33c18..927c17b081c7 100644 > > > --- a/kernel/rcu/tree_plugin.h > > > +++ b/kernel/rcu/tree_plugin.h > > > @@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu) > > > rdp->nocb_leader = rdp_spawn; > > > if (rdp_last && rdp != rdp_spawn) > > > rdp_last->nocb_next_follower = rdp; > > > - rdp_last = rdp; > > > - rdp = rdp->nocb_next_follower; > > > - rdp_last->nocb_next_follower = NULL; > > > + if (rdp == rdp_spawn) { > > > + rdp = rdp->nocb_next_follower; > > > + } else { > > > + rdp_last = rdp; > > > + rdp = rdp->nocb_next_follower; > > > + rdp_last->nocb_next_follower = NULL; > > > + } > > > } while (rdp); > > > rdp_spawn->nocb_next_follower = rdp_old_leader; > > > } > > > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 21:25 ` Yanko Kaneti @ 2014-10-24 21:49 ` Paul E. McKenney 2014-10-24 22:02 ` Jay Vosburgh ` (2 more replies) 0 siblings, 3 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 21:49 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos, tj On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: [ . . . ] > > > > Well, if you are feeling aggressive, give the following patch a spin. > > > > I am doing sanity tests on it in the meantime. > > > > > > Doesn't seem to make a difference here > > > > OK, inspection isn't cutting it, so time for tracing. Does the system > > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > > the problem occurs, then dump the trace buffer after the problem occurs. > > Sorry for being unresposive here, but I know next to nothing about tracing > or most things about the kernel, so I have some cathing up to do. > > In the meantime some layman observations while I tried to find what exactly > triggers the problem. > - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > - libvirtd seems to be very active in using all sorts of kernel facilities > that are modules on fedora so it seems to cause many simultaneous kworker > calls to modprobe > - there are 8 kworker/u16 from 0 to 7 > - one of these kworkers always deadlocks, while there appear to be two > kworker/u16:6 - the seventh Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > 6 vs 8 as in 6 rcuos where before they were always 8 > > Just observations from someone who still doesn't know what the u16 > kworkers are.. Could you please run the following diagnostic patch? This will help me see if I have managed to miswire the rcuo kthreads. It should print some information at task-hang time. Thanx, Paul ------------------------------------------------------------------------ rcu: Dump no-CBs CPU state at task-hung time Strictly diagnostic commit for rcu_barrier() hang. Not for inclusion. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h index 0e5366200154..34048140577b 100644 --- a/include/linux/rcutiny.h +++ b/include/linux/rcutiny.h @@ -157,4 +157,8 @@ static inline bool rcu_is_watching(void) #endif /* #else defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */ +static inline void rcu_show_nocb_setup(void) +{ +} + #endif /* __LINUX_RCUTINY_H */ diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h index 52953790dcca..0b813bdb971b 100644 --- a/include/linux/rcutree.h +++ b/include/linux/rcutree.h @@ -97,4 +97,6 @@ extern int rcu_scheduler_active __read_mostly; bool rcu_is_watching(void); +void rcu_show_nocb_setup(void); + #endif /* __LINUX_RCUTREE_H */ diff --git a/kernel/hung_task.c b/kernel/hung_task.c index 06db12434d72..e6e4d0f6b063 100644 --- a/kernel/hung_task.c +++ b/kernel/hung_task.c @@ -118,6 +118,7 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout) " disables this message.\n"); sched_show_task(t); debug_show_held_locks(t); + rcu_show_nocb_setup(); touch_nmi_watchdog(); diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 240fa9094f83..6b373e79ce0e 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -1513,6 +1513,7 @@ rcu_torture_cleanup(void) { int i; + rcu_show_nocb_setup(); rcutorture_record_test_transition(); if (torture_cleanup_begin()) { if (cur_ops->cb_barrier != NULL) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 927c17b081c7..285b3f6fb229 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2699,6 +2699,31 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ +void rcu_show_nocb_setup(void) +{ +#ifdef CONFIG_RCU_NOCB_CPU + int cpu; + struct rcu_data *rdp; + struct rcu_state *rsp; + + for_each_rcu_flavor(rsp) { + pr_alert("rcu_show_nocb_setup(): %s nocb state:\n", rsp->name); + for_each_possible_cpu(cpu) { + if (!rcu_is_nocb_cpu(cpu)) + continue; + rdp = per_cpu_ptr(rsp->rda, cpu); + pr_alert("%3d: %p l:%p n:%p %c%c%c\n", + cpu, + rdp, rdp->nocb_leader, rdp->nocb_next_follower, + ".N"[!!rdp->nocb_head], + ".G"[!!rdp->nocb_gp_head], + ".F"[!!rdp->nocb_follower_head]); + } + } +#endif /* #ifdef CONFIG_RCU_NOCB_CPU */ +} +EXPORT_SYMBOL_GPL(rcu_show_nocb_setup); + /* * An adaptive-ticks CPU can potentially execute in kernel mode for an * arbitrarily long period of time with the scheduling-clock tick turned ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 21:49 ` Paul E. McKenney @ 2014-10-24 22:02 ` Jay Vosburgh 2014-10-24 22:16 ` Paul E. McKenney 2014-10-24 22:34 ` Jay Vosburgh 2014-10-25 12:09 ` Yanko Kaneti 2 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 22:02 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: >> On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: >> > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: >> > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > >[ . . . ] > >> > > > Well, if you are feeling aggressive, give the following patch a spin. >> > > > I am doing sanity tests on it in the meantime. >> > > >> > > Doesn't seem to make a difference here >> > >> > OK, inspection isn't cutting it, so time for tracing. Does the system >> > respond to user input? If so, please enable rcu:rcu_barrier ftrace before >> > the problem occurs, then dump the trace buffer after the problem occurs. >> >> Sorry for being unresposive here, but I know next to nothing about tracing >> or most things about the kernel, so I have some cathing up to do. >> >> In the meantime some layman observations while I tried to find what exactly >> triggers the problem. >> - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd >> - libvirtd seems to be very active in using all sorts of kernel facilities >> that are modules on fedora so it seems to cause many simultaneous kworker >> calls to modprobe >> - there are 8 kworker/u16 from 0 to 7 >> - one of these kworkers always deadlocks, while there appear to be two >> kworker/u16:6 - the seventh > >Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > >> 6 vs 8 as in 6 rcuos where before they were always 8 >> >> Just observations from someone who still doesn't know what the u16 >> kworkers are.. > >Could you please run the following diagnostic patch? This will help >me see if I have managed to miswire the rcuo kthreads. It should >print some information at task-hang time. I can give this a spin after the ftrace (now that I've got CONFIG_RCU_TRACE turned on). I've got an ftrace capture from unmodified -net, it looks like this: ovs-vswitchd-902 [000] .... 471.778441: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 rcuos/0-9 [000] ..s. 471.793150: rcu_barrier: rcu_sched CB cpu -1 remaining 3 # 2 rcuos/1-18 [001] ..s. 471.793308: rcu_barrier: rcu_sched CB cpu -1 remaining 2 # 2 I let it sit through several "hung task" cycles but that was all there was for rcu:rcu_barrier. I should have ftrace with the patch as soon as the kernel is done building, then I can try the below patch (I'll start it building now). -J > Thanx, Paul > >------------------------------------------------------------------------ > >rcu: Dump no-CBs CPU state at task-hung time > >Strictly diagnostic commit for rcu_barrier() hang. Not for inclusion. > >Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > >diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h >index 0e5366200154..34048140577b 100644 >--- a/include/linux/rcutiny.h >+++ b/include/linux/rcutiny.h >@@ -157,4 +157,8 @@ static inline bool rcu_is_watching(void) > > #endif /* #else defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */ > >+static inline void rcu_show_nocb_setup(void) >+{ >+} >+ > #endif /* __LINUX_RCUTINY_H */ >diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h >index 52953790dcca..0b813bdb971b 100644 >--- a/include/linux/rcutree.h >+++ b/include/linux/rcutree.h >@@ -97,4 +97,6 @@ extern int rcu_scheduler_active __read_mostly; > > bool rcu_is_watching(void); > >+void rcu_show_nocb_setup(void); >+ > #endif /* __LINUX_RCUTREE_H */ >diff --git a/kernel/hung_task.c b/kernel/hung_task.c >index 06db12434d72..e6e4d0f6b063 100644 >--- a/kernel/hung_task.c >+++ b/kernel/hung_task.c >@@ -118,6 +118,7 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout) > " disables this message.\n"); > sched_show_task(t); > debug_show_held_locks(t); >+ rcu_show_nocb_setup(); > > touch_nmi_watchdog(); > >diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c >index 240fa9094f83..6b373e79ce0e 100644 >--- a/kernel/rcu/rcutorture.c >+++ b/kernel/rcu/rcutorture.c >@@ -1513,6 +1513,7 @@ rcu_torture_cleanup(void) > { > int i; > >+ rcu_show_nocb_setup(); > rcutorture_record_test_transition(); > if (torture_cleanup_begin()) { > if (cur_ops->cb_barrier != NULL) >diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h >index 927c17b081c7..285b3f6fb229 100644 >--- a/kernel/rcu/tree_plugin.h >+++ b/kernel/rcu/tree_plugin.h >@@ -2699,6 +2699,31 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ > >+void rcu_show_nocb_setup(void) >+{ >+#ifdef CONFIG_RCU_NOCB_CPU >+ int cpu; >+ struct rcu_data *rdp; >+ struct rcu_state *rsp; >+ >+ for_each_rcu_flavor(rsp) { >+ pr_alert("rcu_show_nocb_setup(): %s nocb state:\n", rsp->name); >+ for_each_possible_cpu(cpu) { >+ if (!rcu_is_nocb_cpu(cpu)) >+ continue; >+ rdp = per_cpu_ptr(rsp->rda, cpu); >+ pr_alert("%3d: %p l:%p n:%p %c%c%c\n", >+ cpu, >+ rdp, rdp->nocb_leader, rdp->nocb_next_follower, >+ ".N"[!!rdp->nocb_head], >+ ".G"[!!rdp->nocb_gp_head], >+ ".F"[!!rdp->nocb_follower_head]); >+ } >+ } >+#endif /* #ifdef CONFIG_RCU_NOCB_CPU */ >+} >+EXPORT_SYMBOL_GPL(rcu_show_nocb_setup); >+ > /* > * An adaptive-ticks CPU can potentially execute in kernel mode for an > * arbitrarily long period of time with the scheduling-clock tick turned > --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 22:02 ` Jay Vosburgh @ 2014-10-24 22:16 ` Paul E. McKenney 2014-10-24 22:41 ` Jay Vosburgh 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 22:16 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Fri, Oct 24, 2014 at 03:02:04PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > >> On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > >> > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > >> > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > > >[ . . . ] > > > >> > > > Well, if you are feeling aggressive, give the following patch a spin. > >> > > > I am doing sanity tests on it in the meantime. > >> > > > >> > > Doesn't seem to make a difference here > >> > > >> > OK, inspection isn't cutting it, so time for tracing. Does the system > >> > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > >> > the problem occurs, then dump the trace buffer after the problem occurs. > >> > >> Sorry for being unresposive here, but I know next to nothing about tracing > >> or most things about the kernel, so I have some cathing up to do. > >> > >> In the meantime some layman observations while I tried to find what exactly > >> triggers the problem. > >> - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > >> - libvirtd seems to be very active in using all sorts of kernel facilities > >> that are modules on fedora so it seems to cause many simultaneous kworker > >> calls to modprobe > >> - there are 8 kworker/u16 from 0 to 7 > >> - one of these kworkers always deadlocks, while there appear to be two > >> kworker/u16:6 - the seventh > > > >Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > > > >> 6 vs 8 as in 6 rcuos where before they were always 8 > >> > >> Just observations from someone who still doesn't know what the u16 > >> kworkers are.. > > > >Could you please run the following diagnostic patch? This will help > >me see if I have managed to miswire the rcuo kthreads. It should > >print some information at task-hang time. > > I can give this a spin after the ftrace (now that I've got > CONFIG_RCU_TRACE turned on). > > I've got an ftrace capture from unmodified -net, it looks like > this: > > ovs-vswitchd-902 [000] .... 471.778441: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 > ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 > ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 > ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 > ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 > ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 > ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 OK, so it looks like your system has four CPUs, and rcu_barrier() placed callbacks on them all. > ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 The above removes the extra count used to avoid races between posting new callbacks and completion of previously posted callbacks. > rcuos/0-9 [000] ..s. 471.793150: rcu_barrier: rcu_sched CB cpu -1 remaining 3 # 2 > rcuos/1-18 [001] ..s. 471.793308: rcu_barrier: rcu_sched CB cpu -1 remaining 2 # 2 Two of the four callbacks fired, but the other two appear to be AWOL. And rcu_barrier() won't return until they all fire. > I let it sit through several "hung task" cycles but that was all > there was for rcu:rcu_barrier. > > I should have ftrace with the patch as soon as the kernel is > done building, then I can try the below patch (I'll start it building > now). Sounds very good, looking forward to hearing of the results. Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 22:16 ` Paul E. McKenney @ 2014-10-24 22:41 ` Jay Vosburgh 0 siblings, 0 replies; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 22:41 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 03:02:04PM -0700, Jay Vosburgh wrote: >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >> [...] >> I've got an ftrace capture from unmodified -net, it looks like >> this: >> >> ovs-vswitchd-902 [000] .... 471.778441: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 >> ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 >> ovs-vswitchd-902 [000] .... 471.778452: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 >> ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 >> ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 >> ovs-vswitchd-902 [000] .... 471.778453: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 >> ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 > >OK, so it looks like your system has four CPUs, and rcu_barrier() placed >callbacks on them all. No, the system has only two CPUs. It's an Intel Core 2 Duo E8400, and /proc/cpuinfo agrees that there are only 2. There is a potentially relevant-sounding message early in dmesg that says: [ 0.000000] smpboot: Allowing 4 CPUs, 2 hotplug CPUs >> ovs-vswitchd-902 [000] .... 471.778454: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 > >The above removes the extra count used to avoid races between posting new >callbacks and completion of previously posted callbacks. > >> rcuos/0-9 [000] ..s. 471.793150: rcu_barrier: rcu_sched CB cpu -1 remaining 3 # 2 >> rcuos/1-18 [001] ..s. 471.793308: rcu_barrier: rcu_sched CB cpu -1 remaining 2 # 2 > >Two of the four callbacks fired, but the other two appear to be AWOL. >And rcu_barrier() won't return until they all fire. > >> I let it sit through several "hung task" cycles but that was all >> there was for rcu:rcu_barrier. >> >> I should have ftrace with the patch as soon as the kernel is >> done building, then I can try the below patch (I'll start it building >> now). > >Sounds very good, looking forward to hearing of the results. Going to bounce it for ftrace now, but the cpu count mismatch seemed important enough to mention separately. -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 21:49 ` Paul E. McKenney 2014-10-24 22:02 ` Jay Vosburgh @ 2014-10-24 22:34 ` Jay Vosburgh 2014-10-24 22:59 ` Paul E. McKenney 2014-10-25 12:09 ` Yanko Kaneti 2 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-24 22:34 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: >> On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: >> > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: >> > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > >[ . . . ] > >> > > > Well, if you are feeling aggressive, give the following patch a spin. >> > > > I am doing sanity tests on it in the meantime. >> > > >> > > Doesn't seem to make a difference here >> > >> > OK, inspection isn't cutting it, so time for tracing. Does the system >> > respond to user input? If so, please enable rcu:rcu_barrier ftrace before >> > the problem occurs, then dump the trace buffer after the problem occurs. >> >> Sorry for being unresposive here, but I know next to nothing about tracing >> or most things about the kernel, so I have some cathing up to do. >> >> In the meantime some layman observations while I tried to find what exactly >> triggers the problem. >> - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd >> - libvirtd seems to be very active in using all sorts of kernel facilities >> that are modules on fedora so it seems to cause many simultaneous kworker >> calls to modprobe >> - there are 8 kworker/u16 from 0 to 7 >> - one of these kworkers always deadlocks, while there appear to be two >> kworker/u16:6 - the seventh > >Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > >> 6 vs 8 as in 6 rcuos where before they were always 8 >> >> Just observations from someone who still doesn't know what the u16 >> kworkers are.. > >Could you please run the following diagnostic patch? This will help >me see if I have managed to miswire the rcuo kthreads. It should >print some information at task-hang time. Here's the output of the patch; I let it sit through two hang cycles. -J [ 240.348020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. [ 240.354878] Not tainted 3.17.0-testola+ #4 [ 240.359481] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.367285] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 [ 240.367290] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 [ 240.367293] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 [ 240.367296] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff [ 240.367300] Call Trace: [ 240.367307] [<ffffffff81722b99>] schedule+0x29/0x70 [ 240.367310] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 [ 240.367313] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 [ 240.367316] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 [ 240.367321] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 [ 240.367324] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 [ 240.367328] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 [ 240.367331] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 [ 240.367334] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 [ 240.367338] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 [ 240.367341] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 [ 240.367349] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] [ 240.367354] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] [ 240.367358] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] [ 240.367363] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] [ 240.367367] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 [ 240.367370] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 [ 240.367372] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 [ 240.367376] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 [ 240.367378] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 [ 240.367381] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 [ 240.367383] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 [ 240.367387] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 [ 240.367391] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 [ 240.367395] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 [ 240.367399] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 [ 240.367402] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 [ 240.367406] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 [ 240.367410] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 240.367413] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 240.367416] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 [ 240.367420] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 [ 240.367424] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 [ 240.367428] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 [ 240.367431] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 [ 240.367433] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 [ 240.367436] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd [ 240.367439] rcu_show_nocb_setup(): rcu_sched nocb state: [ 240.372734] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 .G. [ 240.379673] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) .G. [ 240.386611] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. [ 240.393550] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. [ 240.400489] rcu_show_nocb_setup(): rcu_bh nocb state: [ 240.405525] 0: ffff88013fc0e3c0 l:ffff88013fc0e3c0 n:ffff88013fc8e3c0 ... [ 240.412463] 1: ffff88013fc8e3c0 l:ffff88013fc0e3c0 n: (null) ... [ 240.419401] 2: ffff88013fd0e3c0 l:ffff88013fd0e3c0 n:ffff88013fd8e3c0 ... [ 240.426339] 3: ffff88013fd8e3c0 l:ffff88013fd0e3c0 n: (null) ... [ 360.432020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. [ 360.438881] Not tainted 3.17.0-testola+ #4 [ 360.443484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 360.451289] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 [ 360.451293] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 [ 360.451297] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 [ 360.451300] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff [ 360.451303] Call Trace: [ 360.451311] [<ffffffff81722b99>] schedule+0x29/0x70 [ 360.451314] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 [ 360.451317] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 [ 360.451320] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 [ 360.451325] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 [ 360.451327] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 [ 360.451331] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 [ 360.451335] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 [ 360.451338] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 [ 360.451342] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 [ 360.451345] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 [ 360.451353] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] [ 360.451358] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] [ 360.451362] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] [ 360.451366] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] [ 360.451370] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 [ 360.451373] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 [ 360.451376] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 [ 360.451379] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 [ 360.451381] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 [ 360.451384] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 [ 360.451387] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 [ 360.451390] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 [ 360.451394] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 [ 360.451399] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 [ 360.451402] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 [ 360.451406] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 [ 360.451410] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 [ 360.451414] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 360.451417] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 [ 360.451419] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 [ 360.451424] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 [ 360.451427] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 [ 360.451431] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 [ 360.451434] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 [ 360.451437] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 [ 360.451440] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd [ 360.451442] rcu_show_nocb_setup(): rcu_sched nocb state: [ 360.456737] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 ... [ 360.463676] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) ... [ 360.470614] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. [ 360.477554] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. [ 360.484494] rcu_show_nocb_setup(): rcu_bh nocb state: [ 360.489529] 0: ffff88013fc0e3c0 l:ffff88013fc0e3c0 n:ffff88013fc8e3c0 ... [ 360.496469] 1: ffff88013fc8e3c0 l:ffff88013fc0e3c0 n: (null) .G. [ 360.503407] 2: ffff88013fd0e3c0 l:ffff88013fd0e3c0 n:ffff88013fd8e3c0 ... [ 360.510346] 3: ffff88013fd8e3c0 l:ffff88013fd0e3c0 n: (null) ... --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 22:34 ` Jay Vosburgh @ 2014-10-24 22:59 ` Paul E. McKenney 2014-10-24 23:05 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 22:59 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Fri, Oct 24, 2014 at 03:34:07PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > >> On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > >> > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > >> > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > > >[ . . . ] > > > >> > > > Well, if you are feeling aggressive, give the following patch a spin. > >> > > > I am doing sanity tests on it in the meantime. > >> > > > >> > > Doesn't seem to make a difference here > >> > > >> > OK, inspection isn't cutting it, so time for tracing. Does the system > >> > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > >> > the problem occurs, then dump the trace buffer after the problem occurs. > >> > >> Sorry for being unresposive here, but I know next to nothing about tracing > >> or most things about the kernel, so I have some cathing up to do. > >> > >> In the meantime some layman observations while I tried to find what exactly > >> triggers the problem. > >> - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > >> - libvirtd seems to be very active in using all sorts of kernel facilities > >> that are modules on fedora so it seems to cause many simultaneous kworker > >> calls to modprobe > >> - there are 8 kworker/u16 from 0 to 7 > >> - one of these kworkers always deadlocks, while there appear to be two > >> kworker/u16:6 - the seventh > > > >Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > > > >> 6 vs 8 as in 6 rcuos where before they were always 8 > >> > >> Just observations from someone who still doesn't know what the u16 > >> kworkers are.. > > > >Could you please run the following diagnostic patch? This will help > >me see if I have managed to miswire the rcuo kthreads. It should > >print some information at task-hang time. > > Here's the output of the patch; I let it sit through two hang > cycles. > > -J > > > [ 240.348020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. > [ 240.354878] Not tainted 3.17.0-testola+ #4 > [ 240.359481] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 240.367285] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 > [ 240.367290] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 > [ 240.367293] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 > [ 240.367296] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff > [ 240.367300] Call Trace: > [ 240.367307] [<ffffffff81722b99>] schedule+0x29/0x70 > [ 240.367310] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 > [ 240.367313] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 > [ 240.367316] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 > [ 240.367321] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 > [ 240.367324] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 > [ 240.367328] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 > [ 240.367331] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 > [ 240.367334] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 > [ 240.367338] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 > [ 240.367341] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 > [ 240.367349] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] > [ 240.367354] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] > [ 240.367358] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] > [ 240.367363] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] > [ 240.367367] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 > [ 240.367370] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 > [ 240.367372] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 > [ 240.367376] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 > [ 240.367378] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 > [ 240.367381] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 > [ 240.367383] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 > [ 240.367387] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 > [ 240.367391] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 > [ 240.367395] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 > [ 240.367399] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 > [ 240.367402] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 > [ 240.367406] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 > [ 240.367410] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 240.367413] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 240.367416] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 > [ 240.367420] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 > [ 240.367424] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 > [ 240.367428] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 > [ 240.367431] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 > [ 240.367433] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 > [ 240.367436] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd > [ 240.367439] rcu_show_nocb_setup(): rcu_sched nocb state: > [ 240.372734] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 .G. > [ 240.379673] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) .G. > [ 240.386611] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. > [ 240.393550] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. > [ 240.400489] rcu_show_nocb_setup(): rcu_bh nocb state: > [ 240.405525] 0: ffff88013fc0e3c0 l:ffff88013fc0e3c0 n:ffff88013fc8e3c0 ... > [ 240.412463] 1: ffff88013fc8e3c0 l:ffff88013fc0e3c0 n: (null) ... > [ 240.419401] 2: ffff88013fd0e3c0 l:ffff88013fd0e3c0 n:ffff88013fd8e3c0 ... > [ 240.426339] 3: ffff88013fd8e3c0 l:ffff88013fd0e3c0 n: (null) ... > [ 360.432020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. > [ 360.438881] Not tainted 3.17.0-testola+ #4 > [ 360.443484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 360.451289] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 > [ 360.451293] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 > [ 360.451297] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 > [ 360.451300] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff > [ 360.451303] Call Trace: > [ 360.451311] [<ffffffff81722b99>] schedule+0x29/0x70 > [ 360.451314] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 > [ 360.451317] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 > [ 360.451320] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 > [ 360.451325] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 > [ 360.451327] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 > [ 360.451331] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 > [ 360.451335] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 > [ 360.451338] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 > [ 360.451342] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 > [ 360.451345] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 > [ 360.451353] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] > [ 360.451358] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] > [ 360.451362] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] > [ 360.451366] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] > [ 360.451370] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 > [ 360.451373] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 > [ 360.451376] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 > [ 360.451379] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 > [ 360.451381] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 > [ 360.451384] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 > [ 360.451387] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 > [ 360.451390] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 > [ 360.451394] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 > [ 360.451399] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 > [ 360.451402] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 > [ 360.451406] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 > [ 360.451410] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 > [ 360.451414] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 360.451417] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > [ 360.451419] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 > [ 360.451424] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 > [ 360.451427] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 > [ 360.451431] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 > [ 360.451434] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 > [ 360.451437] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 > [ 360.451440] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd > [ 360.451442] rcu_show_nocb_setup(): rcu_sched nocb state: > [ 360.456737] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 ... > [ 360.463676] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) ... > [ 360.470614] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. > [ 360.477554] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. Hmmm... It sure looks like we have some callbacks stuck here. I clearly need to take a hard look at the sleep/wakeup code. Thank you for running this!!! Thanx, Paul > [ 360.484494] rcu_show_nocb_setup(): rcu_bh nocb state: > [ 360.489529] 0: ffff88013fc0e3c0 l:ffff88013fc0e3c0 n:ffff88013fc8e3c0 ... > [ 360.496469] 1: ffff88013fc8e3c0 l:ffff88013fc0e3c0 n: (null) .G. > [ 360.503407] 2: ffff88013fd0e3c0 l:ffff88013fd0e3c0 n:ffff88013fd8e3c0 ... > [ 360.510346] 3: ffff88013fd8e3c0 l:ffff88013fd0e3c0 n: (null) ... > > --- > -Jay Vosburgh, jay.vosburgh@canonical.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 22:59 ` Paul E. McKenney @ 2014-10-24 23:05 ` Paul E. McKenney 2014-10-25 0:20 ` Jay Vosburgh 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-24 23:05 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: > On Fri, Oct 24, 2014 at 03:34:07PM -0700, Jay Vosburgh wrote: > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > >On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > > >> On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > > >> > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > >> > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > > > > >[ . . . ] > > > > > >> > > > Well, if you are feeling aggressive, give the following patch a spin. > > >> > > > I am doing sanity tests on it in the meantime. > > >> > > > > >> > > Doesn't seem to make a difference here > > >> > > > >> > OK, inspection isn't cutting it, so time for tracing. Does the system > > >> > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > > >> > the problem occurs, then dump the trace buffer after the problem occurs. > > >> > > >> Sorry for being unresposive here, but I know next to nothing about tracing > > >> or most things about the kernel, so I have some cathing up to do. > > >> > > >> In the meantime some layman observations while I tried to find what exactly > > >> triggers the problem. > > >> - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > > >> - libvirtd seems to be very active in using all sorts of kernel facilities > > >> that are modules on fedora so it seems to cause many simultaneous kworker > > >> calls to modprobe > > >> - there are 8 kworker/u16 from 0 to 7 > > >> - one of these kworkers always deadlocks, while there appear to be two > > >> kworker/u16:6 - the seventh > > > > > >Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > > > > > >> 6 vs 8 as in 6 rcuos where before they were always 8 > > >> > > >> Just observations from someone who still doesn't know what the u16 > > >> kworkers are.. > > > > > >Could you please run the following diagnostic patch? This will help > > >me see if I have managed to miswire the rcuo kthreads. It should > > >print some information at task-hang time. > > > > Here's the output of the patch; I let it sit through two hang > > cycles. > > > > -J > > > > > > [ 240.348020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. > > [ 240.354878] Not tainted 3.17.0-testola+ #4 > > [ 240.359481] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > [ 240.367285] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 > > [ 240.367290] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 > > [ 240.367293] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 > > [ 240.367296] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff > > [ 240.367300] Call Trace: > > [ 240.367307] [<ffffffff81722b99>] schedule+0x29/0x70 > > [ 240.367310] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 > > [ 240.367313] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 > > [ 240.367316] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 > > [ 240.367321] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 > > [ 240.367324] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 > > [ 240.367328] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 > > [ 240.367331] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 > > [ 240.367334] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 > > [ 240.367338] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 > > [ 240.367341] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 > > [ 240.367349] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] > > [ 240.367354] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] > > [ 240.367358] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] > > [ 240.367363] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] > > [ 240.367367] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 > > [ 240.367370] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 > > [ 240.367372] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 > > [ 240.367376] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 > > [ 240.367378] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 > > [ 240.367381] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 > > [ 240.367383] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 > > [ 240.367387] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 > > [ 240.367391] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 > > [ 240.367395] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 > > [ 240.367399] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 > > [ 240.367402] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 > > [ 240.367406] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 > > [ 240.367410] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > > [ 240.367413] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > > [ 240.367416] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 > > [ 240.367420] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 > > [ 240.367424] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 > > [ 240.367428] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 > > [ 240.367431] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 > > [ 240.367433] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 > > [ 240.367436] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd > > [ 240.367439] rcu_show_nocb_setup(): rcu_sched nocb state: > > [ 240.372734] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 .G. > > [ 240.379673] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) .G. > > [ 240.386611] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. > > [ 240.393550] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. > > [ 240.400489] rcu_show_nocb_setup(): rcu_bh nocb state: > > [ 240.405525] 0: ffff88013fc0e3c0 l:ffff88013fc0e3c0 n:ffff88013fc8e3c0 ... > > [ 240.412463] 1: ffff88013fc8e3c0 l:ffff88013fc0e3c0 n: (null) ... > > [ 240.419401] 2: ffff88013fd0e3c0 l:ffff88013fd0e3c0 n:ffff88013fd8e3c0 ... > > [ 240.426339] 3: ffff88013fd8e3c0 l:ffff88013fd0e3c0 n: (null) ... > > [ 360.432020] INFO: task ovs-vswitchd:902 blocked for more than 120 seconds. > > [ 360.438881] Not tainted 3.17.0-testola+ #4 > > [ 360.443484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > [ 360.451289] ovs-vswitchd D ffff88013fc94600 0 902 901 0x00000004 > > [ 360.451293] ffff8800ab20f7b8 0000000000000002 ffff8800b3304b00 ffff8800ab20ffd8 > > [ 360.451297] 0000000000014600 0000000000014600 ffff8800b0810000 ffff8800b3304b00 > > [ 360.451300] ffff8800b3304b00 ffffffff81c59850 ffffffff81c59858 7fffffffffffffff > > [ 360.451303] Call Trace: > > [ 360.451311] [<ffffffff81722b99>] schedule+0x29/0x70 > > [ 360.451314] [<ffffffff81725b6c>] schedule_timeout+0x1dc/0x260 > > [ 360.451317] [<ffffffff81722f69>] ? _cond_resched+0x29/0x40 > > [ 360.451320] [<ffffffff81723818>] ? wait_for_completion+0x28/0x160 > > [ 360.451325] [<ffffffff811081a7>] ? queue_stop_cpus_work+0xc7/0xe0 > > [ 360.451327] [<ffffffff81723896>] wait_for_completion+0xa6/0x160 > > [ 360.451331] [<ffffffff81099980>] ? wake_up_state+0x20/0x20 > > [ 360.451335] [<ffffffff810d0ecc>] _rcu_barrier+0x20c/0x480 > > [ 360.451338] [<ffffffff810d1195>] rcu_barrier+0x15/0x20 > > [ 360.451342] [<ffffffff81625010>] netdev_run_todo+0x60/0x300 > > [ 360.451345] [<ffffffff8162f9ee>] rtnl_unlock+0xe/0x10 > > [ 360.451353] [<ffffffffa01ffcc5>] internal_dev_destroy+0x55/0x80 [openvswitch] > > [ 360.451358] [<ffffffffa01ff622>] ovs_vport_del+0x32/0x40 [openvswitch] > > [ 360.451362] [<ffffffffa01f8dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch] > > [ 360.451366] [<ffffffffa01f8ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch] > > [ 360.451370] [<ffffffff81651d75>] genl_family_rcv_msg+0x1a5/0x3c0 > > [ 360.451373] [<ffffffff81651f90>] ? genl_family_rcv_msg+0x3c0/0x3c0 > > [ 360.451376] [<ffffffff81652021>] genl_rcv_msg+0x91/0xd0 > > [ 360.451379] [<ffffffff81650091>] netlink_rcv_skb+0xc1/0xe0 > > [ 360.451381] [<ffffffff816505bc>] genl_rcv+0x2c/0x40 > > [ 360.451384] [<ffffffff8164f626>] netlink_unicast+0xf6/0x200 > > [ 360.451387] [<ffffffff8164fa4d>] netlink_sendmsg+0x31d/0x780 > > [ 360.451390] [<ffffffff8164ca74>] ? netlink_rcv_wake+0x44/0x60 > > [ 360.451394] [<ffffffff81606a53>] sock_sendmsg+0x93/0xd0 > > [ 360.451399] [<ffffffff81337700>] ? apparmor_capable+0x60/0x60 > > [ 360.451402] [<ffffffff81614f27>] ? verify_iovec+0x47/0xd0 > > [ 360.451406] [<ffffffff81606e79>] ___sys_sendmsg+0x399/0x3b0 > > [ 360.451410] [<ffffffff812598a2>] ? kernfs_seq_stop_active+0x32/0x40 > > [ 360.451414] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > > [ 360.451417] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90 > > [ 360.451419] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10 > > [ 360.451424] [<ffffffff811277fc>] ? acct_account_cputime+0x1c/0x20 > > [ 360.451427] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0 > > [ 360.451431] [<ffffffff81200bd5>] ? __fget_light+0x25/0x70 > > [ 360.451434] [<ffffffff81607c02>] __sys_sendmsg+0x42/0x80 > > [ 360.451437] [<ffffffff81607c52>] SyS_sendmsg+0x12/0x20 > > [ 360.451440] [<ffffffff81727464>] tracesys_phase2+0xd8/0xdd > > [ 360.451442] rcu_show_nocb_setup(): rcu_sched nocb state: > > [ 360.456737] 0: ffff88013fc0e600 l:ffff88013fc0e600 n:ffff88013fc8e600 ... > > [ 360.463676] 1: ffff88013fc8e600 l:ffff88013fc0e600 n: (null) ... > > [ 360.470614] 2: ffff88013fd0e600 l:ffff88013fd0e600 n:ffff88013fd8e600 N.. > > [ 360.477554] 3: ffff88013fd8e600 l:ffff88013fd0e600 n: (null) N.. > > Hmmm... It sure looks like we have some callbacks stuck here. I clearly > need to take a hard look at the sleep/wakeup code. > > Thank you for running this!!! Could you please try the following patch? If no joy, could you please add rcu:rcu_nocb_wake to the list of ftrace events? Thanx, Paul ------------------------------------------------------------------------ rcu: Kick rcuo kthreads after their CPU goes offline If a no-CBs CPU were to post an RCU callback with interrupts disabled after it entered the idle loop for the last time, there might be no deferred wakeup for the corresponding rcuo kthreads. This commit therefore adds a set of calls to do_nocb_deferred_wakeup() after the CPU has gone completely offline. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 84b41b3c6ebd..f6880052b917 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3493,8 +3493,10 @@ static int rcu_cpu_notify(struct notifier_block *self, case CPU_DEAD_FROZEN: case CPU_UP_CANCELED: case CPU_UP_CANCELED_FROZEN: - for_each_rcu_flavor(rsp) + for_each_rcu_flavor(rsp) { rcu_cleanup_dead_cpu(cpu, rsp); + do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu)); + } break; default: break; ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 23:05 ` Paul E. McKenney @ 2014-10-25 0:20 ` Jay Vosburgh 2014-10-25 2:03 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-25 0:20 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: [...] >> Hmmm... It sure looks like we have some callbacks stuck here. I clearly >> need to take a hard look at the sleep/wakeup code. >> >> Thank you for running this!!! > >Could you please try the following patch? If no joy, could you please >add rcu:rcu_nocb_wake to the list of ftrace events? I tried the patch, it did not change the behavior. I enabled the rcu:rcu_barrier and rcu:rcu_nocb_wake tracepoints and ran it again (with this patch and the first patch from earlier today); the trace output is a bit on the large side so I put it and the dmesg log at: http://people.canonical.com/~jvosburgh/nocb-wake-dmesg.txt http://people.canonical.com/~jvosburgh/nocb-wake-trace.txt -J > Thanx, Paul > >------------------------------------------------------------------------ > >rcu: Kick rcuo kthreads after their CPU goes offline > >If a no-CBs CPU were to post an RCU callback with interrupts disabled >after it entered the idle loop for the last time, there might be no >deferred wakeup for the corresponding rcuo kthreads. This commit >therefore adds a set of calls to do_nocb_deferred_wakeup() after the >CPU has gone completely offline. > >Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > >diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c >index 84b41b3c6ebd..f6880052b917 100644 >--- a/kernel/rcu/tree.c >+++ b/kernel/rcu/tree.c >@@ -3493,8 +3493,10 @@ static int rcu_cpu_notify(struct notifier_block *self, > case CPU_DEAD_FROZEN: > case CPU_UP_CANCELED: > case CPU_UP_CANCELED_FROZEN: >- for_each_rcu_flavor(rsp) >+ for_each_rcu_flavor(rsp) { > rcu_cleanup_dead_cpu(cpu, rsp); >+ do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu)); >+ } > break; > default: > break; > --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 0:20 ` Jay Vosburgh @ 2014-10-25 2:03 ` Paul E. McKenney 2014-10-25 4:33 ` Jay Vosburgh 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-25 2:03 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: > [...] > >> Hmmm... It sure looks like we have some callbacks stuck here. I clearly > >> need to take a hard look at the sleep/wakeup code. > >> > >> Thank you for running this!!! > > > >Could you please try the following patch? If no joy, could you please > >add rcu:rcu_nocb_wake to the list of ftrace events? > > I tried the patch, it did not change the behavior. > > I enabled the rcu:rcu_barrier and rcu:rcu_nocb_wake tracepoints > and ran it again (with this patch and the first patch from earlier > today); the trace output is a bit on the large side so I put it and the > dmesg log at: > > http://people.canonical.com/~jvosburgh/nocb-wake-dmesg.txt > > http://people.canonical.com/~jvosburgh/nocb-wake-trace.txt Thank you again! Very strange part of the trace. The only sign of CPU 2 and 3 are: ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 0 WakeNot ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 1 WakeNot ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 2 WakeNotPoll ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 3 WakeNotPoll ovs-vswitchd-902 [000] .... 109.896843: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 The pair of WakeNotPoll trace entries says that at that point, RCU believed that the CPU 2's and CPU 3's rcuo kthreads did not exist. :-/ More diagnostics in order... Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 2:03 ` Paul E. McKenney @ 2014-10-25 4:33 ` Jay Vosburgh 2014-10-25 5:16 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-25 4:33 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote: >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >> >> >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: >> [...] >> >> Hmmm... It sure looks like we have some callbacks stuck here. I clearly >> >> need to take a hard look at the sleep/wakeup code. >> >> >> >> Thank you for running this!!! >> > >> >Could you please try the following patch? If no joy, could you please >> >add rcu:rcu_nocb_wake to the list of ftrace events? >> >> I tried the patch, it did not change the behavior. >> >> I enabled the rcu:rcu_barrier and rcu:rcu_nocb_wake tracepoints >> and ran it again (with this patch and the first patch from earlier >> today); the trace output is a bit on the large side so I put it and the >> dmesg log at: >> >> http://people.canonical.com/~jvosburgh/nocb-wake-dmesg.txt >> >> http://people.canonical.com/~jvosburgh/nocb-wake-trace.txt > >Thank you again! > >Very strange part of the trace. The only sign of CPU 2 and 3 are: > > ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 > ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 > ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 0 WakeNot > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 > ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 1 WakeNot > ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 > ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 2 WakeNotPoll > ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 > ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 3 WakeNotPoll > ovs-vswitchd-902 [000] .... 109.896843: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 > >The pair of WakeNotPoll trace entries says that at that point, RCU believed >that the CPU 2's and CPU 3's rcuo kthreads did not exist. :-/ On the test system I'm using, CPUs 2 and 3 really do not exist; it is a 2 CPU system (Intel Core 2 Duo E8400). I mentioned this in an earlier message, but perhaps you missed it in the flurry. Looking at the dmesg, the early boot messages seem to be confused as to how many CPUs there are, e.g., [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU debugfs-based tracing is enabled. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-3. but later shows 2: [ 0.233703] x86: Booting SMP configuration: [ 0.236003] .... node #0, CPUs: #1 [ 0.255528] x86: Booted up 1 node, 2 CPUs In any event, the E8400 is a 2 core CPU with no hyperthreading. -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 4:33 ` Jay Vosburgh @ 2014-10-25 5:16 ` Paul E. McKenney 2014-10-25 16:38 ` Jay Vosburgh 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-25 5:16 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote: > >> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > >> > >> >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote: > >> [...] > >> >> Hmmm... It sure looks like we have some callbacks stuck here. I clearly > >> >> need to take a hard look at the sleep/wakeup code. > >> >> > >> >> Thank you for running this!!! > >> > > >> >Could you please try the following patch? If no joy, could you please > >> >add rcu:rcu_nocb_wake to the list of ftrace events? > >> > >> I tried the patch, it did not change the behavior. > >> > >> I enabled the rcu:rcu_barrier and rcu:rcu_nocb_wake tracepoints > >> and ran it again (with this patch and the first patch from earlier > >> today); the trace output is a bit on the large side so I put it and the > >> dmesg log at: > >> > >> http://people.canonical.com/~jvosburgh/nocb-wake-dmesg.txt > >> > >> http://people.canonical.com/~jvosburgh/nocb-wake-trace.txt > > > >Thank you again! > > > >Very strange part of the trace. The only sign of CPU 2 and 3 are: > > > > ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Begin cpu -1 remaining 0 # 0 > > ovs-vswitchd-902 [000] .... 109.896840: rcu_barrier: rcu_sched Check cpu -1 remaining 0 # 0 > > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched Inc1 cpu -1 remaining 0 # 1 > > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 0 remaining 1 # 1 > > ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 0 WakeNot > > ovs-vswitchd-902 [000] .... 109.896841: rcu_barrier: rcu_sched OnlineNoCB cpu 1 remaining 2 # 1 > > ovs-vswitchd-902 [000] d... 109.896841: rcu_nocb_wake: rcu_sched 1 WakeNot > > ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 2 remaining 3 # 1 > > ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 2 WakeNotPoll > > ovs-vswitchd-902 [000] .... 109.896842: rcu_barrier: rcu_sched OnlineNoCB cpu 3 remaining 4 # 1 > > ovs-vswitchd-902 [000] d... 109.896842: rcu_nocb_wake: rcu_sched 3 WakeNotPoll > > ovs-vswitchd-902 [000] .... 109.896843: rcu_barrier: rcu_sched Inc2 cpu -1 remaining 4 # 2 > > > >The pair of WakeNotPoll trace entries says that at that point, RCU believed > >that the CPU 2's and CPU 3's rcuo kthreads did not exist. :-/ > > On the test system I'm using, CPUs 2 and 3 really do not exist; > it is a 2 CPU system (Intel Core 2 Duo E8400). I mentioned this in an > earlier message, but perhaps you missed it in the flurry. Or forgot it. Either way, thank you for reminding me. > Looking at the dmesg, the early boot messages seem to be > confused as to how many CPUs there are, e.g., > > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU debugfs-based tracing is enabled. > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > [ 0.000000] Offload RCU callbacks from all CPUs > [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > > but later shows 2: > > [ 0.233703] x86: Booting SMP configuration: > [ 0.236003] .... node #0, CPUs: #1 > [ 0.255528] x86: Booted up 1 node, 2 CPUs > > In any event, the E8400 is a 2 core CPU with no hyperthreading. Well, this might explain some of the difficulties. If RCU decides to wait on CPUs that don't exist, we will of course get a hang. And rcu_barrier() was definitely expecting four CPUs. So what happens if you boot with maxcpus=2? (Or build with CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, I might have some ideas for a real fix. Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 5:16 ` Paul E. McKenney @ 2014-10-25 16:38 ` Jay Vosburgh 2014-10-25 18:18 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-25 16:38 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: >> Looking at the dmesg, the early boot messages seem to be >> confused as to how many CPUs there are, e.g., >> >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 >> [ 0.000000] Hierarchical RCU implementation. >> [ 0.000000] RCU debugfs-based tracing is enabled. >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 >> [ 0.000000] Offload RCU callbacks from all CPUs >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. >> >> but later shows 2: >> >> [ 0.233703] x86: Booting SMP configuration: >> [ 0.236003] .... node #0, CPUs: #1 >> [ 0.255528] x86: Booted up 1 node, 2 CPUs >> >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > >Well, this might explain some of the difficulties. If RCU decides to wait >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() >was definitely expecting four CPUs. > >So what happens if you boot with maxcpus=2? (Or build with >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, >I might have some ideas for a real fix. Booting with maxcpus=2 makes no difference (the dmesg output is the same). Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and dmesg has different CPU information at boot: [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs [...] [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 [...] [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU debugfs-based tracing is enabled. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-1. -J --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 16:38 ` Jay Vosburgh @ 2014-10-25 18:18 ` Paul E. McKenney 2014-10-27 17:45 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-25 18:18 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > >> Looking at the dmesg, the early boot messages seem to be > >> confused as to how many CPUs there are, e.g., > >> > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > >> [ 0.000000] Hierarchical RCU implementation. > >> [ 0.000000] RCU debugfs-based tracing is enabled. > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > >> [ 0.000000] Offload RCU callbacks from all CPUs > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > >> > >> but later shows 2: > >> > >> [ 0.233703] x86: Booting SMP configuration: > >> [ 0.236003] .... node #0, CPUs: #1 > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > >> > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > > > >Well, this might explain some of the difficulties. If RCU decides to wait > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > >was definitely expecting four CPUs. > > > >So what happens if you boot with maxcpus=2? (Or build with > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > >I might have some ideas for a real fix. > > Booting with maxcpus=2 makes no difference (the dmesg output is > the same). > > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > dmesg has different CPU information at boot: > > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > [...] > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > [...] > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU debugfs-based tracing is enabled. > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > [ 0.000000] Offload RCU callbacks from all CPUs > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. Thank you -- this confirms my suspicions on the fix, though I must admit to being surprised that maxcpus made no difference. Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 18:18 ` Paul E. McKenney @ 2014-10-27 17:45 ` Paul E. McKenney 2014-10-27 20:43 ` Jay Vosburgh 2014-10-28 8:12 ` Yanko Kaneti 0 siblings, 2 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-27 17:45 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: > On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > > >> Looking at the dmesg, the early boot messages seem to be > > >> confused as to how many CPUs there are, e.g., > > >> > > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > >> [ 0.000000] Hierarchical RCU implementation. > > >> [ 0.000000] RCU debugfs-based tracing is enabled. > > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > > >> [ 0.000000] Offload RCU callbacks from all CPUs > > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > > >> > > >> but later shows 2: > > >> > > >> [ 0.233703] x86: Booting SMP configuration: > > >> [ 0.236003] .... node #0, CPUs: #1 > > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > > >> > > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > > > > > >Well, this might explain some of the difficulties. If RCU decides to wait > > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > > >was definitely expecting four CPUs. > > > > > >So what happens if you boot with maxcpus=2? (Or build with > > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > > >I might have some ideas for a real fix. > > > > Booting with maxcpus=2 makes no difference (the dmesg output is > > the same). > > > > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > > dmesg has different CPU information at boot: > > > > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > > [...] > > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > > [...] > > [ 0.000000] Hierarchical RCU implementation. > > [ 0.000000] RCU debugfs-based tracing is enabled. > > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > > [ 0.000000] Offload RCU callbacks from all CPUs > > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. > > Thank you -- this confirms my suspicions on the fix, though I must admit > to being surprised that maxcpus made no difference. And here is an alleged fix, lightly tested at this end. Does this patch help? Thanx, Paul ------------------------------------------------------------------------ rcu: Make rcu_barrier() understand about missing rcuo kthreads Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) avoids creating rcuo kthreads for CPUs that never come online. This fixes a bug in many instances of firmware: Instead of lying about their age, these systems instead lie about the number of CPUs that they have. Before commit 35ce7f29a44a, this could result in huge numbers of useless rcuo kthreads being created. It appears that experience indicates that I should have told the people suffering from this problem to fix their broken firmware, but I instead produced what turned out to be a partial fix. The missing piece supplied by this commit makes sure that rcu_barrier() knows not to post callbacks for no-CBs CPUs that have not yet come online, because otherwise rcu_barrier() will hang on systems having firmware that lies about the number of CPUs. It is tempting to simply have rcu_barrier() refuse to post a callback on any no-CBs CPU that does not have an rcuo kthread. This unfortunately does not work because rcu_barrier() is required to wait for all pending callbacks. It is therefore required to wait even for those callbacks that cannot possibly be invoked. Even if doing so hangs the system. Given that posting a callback to a no-CBs CPU that does not yet have an rcuo kthread can hang rcu_barrier(), It is tempting to report an error in this case. Unfortunately, this will result in false positives at boot time, when it is perfectly legal to post callbacks to the boot CPU before the scheduler has started, in other words, before it is legal to invoke rcu_barrier(). So this commit instead has rcu_barrier() avoid posting callbacks to CPUs having neither rcuo kthread nor pending callbacks, and has it complain bitterly if it finds CPUs having no rcuo kthread but some pending callbacks. And when rcu_barrier() does find CPUs having no rcuo kthread but pending callbacks, as noted earlier, it has no choice but to hang indefinitely. Reported-by: Yanko Kaneti <yaneti@declera.com> Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> Reported-by: Meelis Roos <mroos@linux.ee> Reported-by: Eric B Munson <emunson@akamai.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h index aa8e5eea3ab4..c78e88ce5ea3 100644 --- a/include/trace/events/rcu.h +++ b/include/trace/events/rcu.h @@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, /* * Tracepoint for _rcu_barrier() execution. The string "s" describes * the _rcu_barrier phase: - * "Begin": rcu_barrier_callback() started. - * "Check": rcu_barrier_callback() checking for piggybacking. - * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. - * "Inc1": rcu_barrier_callback() piggyback check counter incremented. - * "Offline": rcu_barrier_callback() found offline CPU - * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. - * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. - * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. + * "Begin": _rcu_barrier() started. + * "Check": _rcu_barrier() checking for piggybacking. + * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. + * "Inc1": _rcu_barrier() piggyback check counter incremented. + * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU + * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. + * "OnlineQ": _rcu_barrier() found online CPU with callbacks. + * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. * "CB": An rcu_barrier_callback() invoked a callback, not the last. * "LastCB": An rcu_barrier_callback() invoked the last callback. - * "Inc2": rcu_barrier_callback() piggyback check counter incremented. + * "Inc2": _rcu_barrier() piggyback check counter incremented. * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument * is the count of remaining callbacks, and "done" is the piggybacking count. */ diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index f6880052b917..7680fc275036 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) continue; rdp = per_cpu_ptr(rsp->rda, cpu); if (rcu_is_nocb_cpu(cpu)) { - _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, - rsp->n_barrier_done); - atomic_inc(&rsp->barrier_cpu_count); - __call_rcu(&rdp->barrier_head, rcu_barrier_callback, - rsp, cpu, 0); + if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { + _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, + rsp->n_barrier_done); + } else { + _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, + rsp->n_barrier_done); + atomic_inc(&rsp->barrier_cpu_count); + __call_rcu(&rdp->barrier_head, + rcu_barrier_callback, rsp, cpu, 0); + } } else if (ACCESS_ONCE(rdp->qlen)) { _rcu_barrier_trace(rsp, "OnlineQ", cpu, rsp->n_barrier_done); diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h index 4beab3d2328c..8e7b1843896e 100644 --- a/kernel/rcu/tree.h +++ b/kernel/rcu/tree.h @@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); static void print_cpu_stall_info_end(void); static void zero_cpu_stall_ticks(struct rcu_data *rdp); static void increment_cpu_stall_ticks(void); +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); static void rcu_init_one_nocb(struct rcu_node *rnp); diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 927c17b081c7..68c5b23b7173 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) } /* + * Does the specified CPU need an RCU callback for the specified flavor + * of rcu_barrier()? + */ +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) +{ + struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); + struct rcu_head *rhp; + + /* No-CBs CPUs might have callbacks on any of three lists. */ + rhp = ACCESS_ONCE(rdp->nocb_head); + if (!rhp) + rhp = ACCESS_ONCE(rdp->nocb_gp_head); + if (!rhp) + rhp = ACCESS_ONCE(rdp->nocb_follower_head); + + /* Having no rcuo kthread but CBs after scheduler starts is bad! */ + if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { + /* RCU callback enqueued before CPU first came online??? */ + pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", + cpu, rhp->func); + WARN_ON_ONCE(1); + } + + return !!rhp; +} + +/* * Enqueue the specified string of rcu_head structures onto the specified * CPU's no-CBs lists. The CPU is specified by rdp, the head of the * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy @@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) #else /* #ifdef CONFIG_RCU_NOCB_CPU */ +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) +{ +} + static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) { } ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-27 17:45 ` Paul E. McKenney @ 2014-10-27 20:43 ` Jay Vosburgh 2014-10-27 21:07 ` Paul E. McKenney 2014-10-28 8:12 ` Yanko Kaneti 1 sibling, 1 reply; 63+ messages in thread From: Jay Vosburgh @ 2014-10-27 20:43 UTC (permalink / raw) To: paulmck Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: >> On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: >> > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: >> > >> > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: >> > >> Looking at the dmesg, the early boot messages seem to be >> > >> confused as to how many CPUs there are, e.g., >> > >> >> > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 >> > >> [ 0.000000] Hierarchical RCU implementation. >> > >> [ 0.000000] RCU debugfs-based tracing is enabled. >> > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. >> > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. >> > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 >> > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 >> > >> [ 0.000000] Offload RCU callbacks from all CPUs >> > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. >> > >> >> > >> but later shows 2: >> > >> >> > >> [ 0.233703] x86: Booting SMP configuration: >> > >> [ 0.236003] .... node #0, CPUs: #1 >> > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs >> > >> >> > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. >> > > >> > >Well, this might explain some of the difficulties. If RCU decides to wait >> > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() >> > >was definitely expecting four CPUs. >> > > >> > >So what happens if you boot with maxcpus=2? (Or build with >> > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, >> > >I might have some ideas for a real fix. >> > >> > Booting with maxcpus=2 makes no difference (the dmesg output is >> > the same). >> > >> > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and >> > dmesg has different CPU information at boot: >> > >> > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 >> > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs >> > [...] >> > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 >> > [...] >> > [ 0.000000] Hierarchical RCU implementation. >> > [ 0.000000] RCU debugfs-based tracing is enabled. >> > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. >> > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 >> > [ 0.000000] Offload RCU callbacks from all CPUs >> > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. >> >> Thank you -- this confirms my suspicions on the fix, though I must admit >> to being surprised that maxcpus made no difference. > >And here is an alleged fix, lightly tested at this end. Does this patch >help? This patch appears to make the problem go away; I've run about 10 iterations. I applied this patch to the same -net tree I was using previously (-net as of Oct 22), with all other test patches removed. FWIW, dmesg is unchanged, and still shows messages like: [ 0.000000] Offload RCU callbacks from CPUs: 0-3. Tested-by: Jay Vosburgh <jay.vosburgh@canonical.com> -J > Thanx, Paul > >------------------------------------------------------------------------ > >rcu: Make rcu_barrier() understand about missing rcuo kthreads > >Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) >avoids creating rcuo kthreads for CPUs that never come online. This >fixes a bug in many instances of firmware: Instead of lying about their >age, these systems instead lie about the number of CPUs that they have. >Before commit 35ce7f29a44a, this could result in huge numbers of useless >rcuo kthreads being created. > >It appears that experience indicates that I should have told the >people suffering from this problem to fix their broken firmware, but >I instead produced what turned out to be a partial fix. The missing >piece supplied by this commit makes sure that rcu_barrier() knows not to >post callbacks for no-CBs CPUs that have not yet come online, because >otherwise rcu_barrier() will hang on systems having firmware that lies >about the number of CPUs. > >It is tempting to simply have rcu_barrier() refuse to post a callback on >any no-CBs CPU that does not have an rcuo kthread. This unfortunately >does not work because rcu_barrier() is required to wait for all pending >callbacks. It is therefore required to wait even for those callbacks >that cannot possibly be invoked. Even if doing so hangs the system. > >Given that posting a callback to a no-CBs CPU that does not yet have an >rcuo kthread can hang rcu_barrier(), It is tempting to report an error >in this case. Unfortunately, this will result in false positives at >boot time, when it is perfectly legal to post callbacks to the boot CPU >before the scheduler has started, in other words, before it is legal >to invoke rcu_barrier(). > >So this commit instead has rcu_barrier() avoid posting callbacks to >CPUs having neither rcuo kthread nor pending callbacks, and has it >complain bitterly if it finds CPUs having no rcuo kthread but some >pending callbacks. And when rcu_barrier() does find CPUs having no rcuo >kthread but pending callbacks, as noted earlier, it has no choice but >to hang indefinitely. > >Reported-by: Yanko Kaneti <yaneti@declera.com> >Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> >Reported-by: Meelis Roos <mroos@linux.ee> >Reported-by: Eric B Munson <emunson@akamai.com> >Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > >diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h >index aa8e5eea3ab4..c78e88ce5ea3 100644 >--- a/include/trace/events/rcu.h >+++ b/include/trace/events/rcu.h >@@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, > /* > * Tracepoint for _rcu_barrier() execution. The string "s" describes > * the _rcu_barrier phase: >- * "Begin": rcu_barrier_callback() started. >- * "Check": rcu_barrier_callback() checking for piggybacking. >- * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. >- * "Inc1": rcu_barrier_callback() piggyback check counter incremented. >- * "Offline": rcu_barrier_callback() found offline CPU >- * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. >- * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. >- * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. >+ * "Begin": _rcu_barrier() started. >+ * "Check": _rcu_barrier() checking for piggybacking. >+ * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. >+ * "Inc1": _rcu_barrier() piggyback check counter incremented. >+ * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU >+ * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. >+ * "OnlineQ": _rcu_barrier() found online CPU with callbacks. >+ * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. > * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. > * "CB": An rcu_barrier_callback() invoked a callback, not the last. > * "LastCB": An rcu_barrier_callback() invoked the last callback. >- * "Inc2": rcu_barrier_callback() piggyback check counter incremented. >+ * "Inc2": _rcu_barrier() piggyback check counter incremented. > * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument > * is the count of remaining callbacks, and "done" is the piggybacking count. > */ >diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c >index f6880052b917..7680fc275036 100644 >--- a/kernel/rcu/tree.c >+++ b/kernel/rcu/tree.c >@@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) > continue; > rdp = per_cpu_ptr(rsp->rda, cpu); > if (rcu_is_nocb_cpu(cpu)) { >- _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, >- rsp->n_barrier_done); >- atomic_inc(&rsp->barrier_cpu_count); >- __call_rcu(&rdp->barrier_head, rcu_barrier_callback, >- rsp, cpu, 0); >+ if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { >+ _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, >+ rsp->n_barrier_done); >+ } else { >+ _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, >+ rsp->n_barrier_done); >+ atomic_inc(&rsp->barrier_cpu_count); >+ __call_rcu(&rdp->barrier_head, >+ rcu_barrier_callback, rsp, cpu, 0); >+ } > } else if (ACCESS_ONCE(rdp->qlen)) { > _rcu_barrier_trace(rsp, "OnlineQ", cpu, > rsp->n_barrier_done); >diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h >index 4beab3d2328c..8e7b1843896e 100644 >--- a/kernel/rcu/tree.h >+++ b/kernel/rcu/tree.h >@@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); > static void print_cpu_stall_info_end(void); > static void zero_cpu_stall_ticks(struct rcu_data *rdp); > static void increment_cpu_stall_ticks(void); >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); > static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); > static void rcu_init_one_nocb(struct rcu_node *rnp); >diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h >index 927c17b081c7..68c5b23b7173 100644 >--- a/kernel/rcu/tree_plugin.h >+++ b/kernel/rcu/tree_plugin.h >@@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) > } > > /* >+ * Does the specified CPU need an RCU callback for the specified flavor >+ * of rcu_barrier()? >+ */ >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) >+{ >+ struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); >+ struct rcu_head *rhp; >+ >+ /* No-CBs CPUs might have callbacks on any of three lists. */ >+ rhp = ACCESS_ONCE(rdp->nocb_head); >+ if (!rhp) >+ rhp = ACCESS_ONCE(rdp->nocb_gp_head); >+ if (!rhp) >+ rhp = ACCESS_ONCE(rdp->nocb_follower_head); >+ >+ /* Having no rcuo kthread but CBs after scheduler starts is bad! */ >+ if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { >+ /* RCU callback enqueued before CPU first came online??? */ >+ pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", >+ cpu, rhp->func); >+ WARN_ON_ONCE(1); >+ } >+ >+ return !!rhp; >+} >+ >+/* > * Enqueue the specified string of rcu_head structures onto the specified > * CPU's no-CBs lists. The CPU is specified by rdp, the head of the > * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy >@@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > #else /* #ifdef CONFIG_RCU_NOCB_CPU */ > >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) >+{ >+} >+ > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > { > } > --- -Jay Vosburgh, jay.vosburgh@canonical.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-27 20:43 ` Jay Vosburgh @ 2014-10-27 21:07 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-27 21:07 UTC (permalink / raw) To: Jay Vosburgh Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Mon, Oct 27, 2014 at 01:43:21PM -0700, Jay Vosburgh wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > >On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: > >> On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > >> > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > >> > > >> > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > >> > >> Looking at the dmesg, the early boot messages seem to be > >> > >> confused as to how many CPUs there are, e.g., > >> > >> > >> > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > >> > >> [ 0.000000] Hierarchical RCU implementation. > >> > >> [ 0.000000] RCU debugfs-based tracing is enabled. > >> > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > >> > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > >> > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > >> > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > >> > >> [ 0.000000] Offload RCU callbacks from all CPUs > >> > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > >> > >> > >> > >> but later shows 2: > >> > >> > >> > >> [ 0.233703] x86: Booting SMP configuration: > >> > >> [ 0.236003] .... node #0, CPUs: #1 > >> > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > >> > >> > >> > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > >> > > > >> > >Well, this might explain some of the difficulties. If RCU decides to wait > >> > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > >> > >was definitely expecting four CPUs. > >> > > > >> > >So what happens if you boot with maxcpus=2? (Or build with > >> > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > >> > >I might have some ideas for a real fix. > >> > > >> > Booting with maxcpus=2 makes no difference (the dmesg output is > >> > the same). > >> > > >> > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > >> > dmesg has different CPU information at boot: > >> > > >> > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > >> > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > >> > [...] > >> > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > >> > [...] > >> > [ 0.000000] Hierarchical RCU implementation. > >> > [ 0.000000] RCU debugfs-based tracing is enabled. > >> > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > >> > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > >> > [ 0.000000] Offload RCU callbacks from all CPUs > >> > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. > >> > >> Thank you -- this confirms my suspicions on the fix, though I must admit > >> to being surprised that maxcpus made no difference. > > > >And here is an alleged fix, lightly tested at this end. Does this patch > >help? > > This patch appears to make the problem go away; I've run about > 10 iterations. I applied this patch to the same -net tree I was using > previously (-net as of Oct 22), with all other test patches removed. So I finally produced a patch that helps! It was bound to happen sooner or later, I guess. ;-) > FWIW, dmesg is unchanged, and still shows messages like: > > [ 0.000000] Offload RCU callbacks from CPUs: 0-3. Yep, at that point in boot, RCU has no way of knowing that the firmware is lying to it about the number of CPUs. ;-) > Tested-by: Jay Vosburgh <jay.vosburgh@canonical.com> Thank you for your testing efforts!!! Thanx, Paul > -J > > > >------------------------------------------------------------------------ > > > >rcu: Make rcu_barrier() understand about missing rcuo kthreads > > > >Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) > >avoids creating rcuo kthreads for CPUs that never come online. This > >fixes a bug in many instances of firmware: Instead of lying about their > >age, these systems instead lie about the number of CPUs that they have. > >Before commit 35ce7f29a44a, this could result in huge numbers of useless > >rcuo kthreads being created. > > > >It appears that experience indicates that I should have told the > >people suffering from this problem to fix their broken firmware, but > >I instead produced what turned out to be a partial fix. The missing > >piece supplied by this commit makes sure that rcu_barrier() knows not to > >post callbacks for no-CBs CPUs that have not yet come online, because > >otherwise rcu_barrier() will hang on systems having firmware that lies > >about the number of CPUs. > > > >It is tempting to simply have rcu_barrier() refuse to post a callback on > >any no-CBs CPU that does not have an rcuo kthread. This unfortunately > >does not work because rcu_barrier() is required to wait for all pending > >callbacks. It is therefore required to wait even for those callbacks > >that cannot possibly be invoked. Even if doing so hangs the system. > > > >Given that posting a callback to a no-CBs CPU that does not yet have an > >rcuo kthread can hang rcu_barrier(), It is tempting to report an error > >in this case. Unfortunately, this will result in false positives at > >boot time, when it is perfectly legal to post callbacks to the boot CPU > >before the scheduler has started, in other words, before it is legal > >to invoke rcu_barrier(). > > > >So this commit instead has rcu_barrier() avoid posting callbacks to > >CPUs having neither rcuo kthread nor pending callbacks, and has it > >complain bitterly if it finds CPUs having no rcuo kthread but some > >pending callbacks. And when rcu_barrier() does find CPUs having no rcuo > >kthread but pending callbacks, as noted earlier, it has no choice but > >to hang indefinitely. > > > >Reported-by: Yanko Kaneti <yaneti@declera.com> > >Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> > >Reported-by: Meelis Roos <mroos@linux.ee> > >Reported-by: Eric B Munson <emunson@akamai.com> > >Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > >diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h > >index aa8e5eea3ab4..c78e88ce5ea3 100644 > >--- a/include/trace/events/rcu.h > >+++ b/include/trace/events/rcu.h > >@@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, > > /* > > * Tracepoint for _rcu_barrier() execution. The string "s" describes > > * the _rcu_barrier phase: > >- * "Begin": rcu_barrier_callback() started. > >- * "Check": rcu_barrier_callback() checking for piggybacking. > >- * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. > >- * "Inc1": rcu_barrier_callback() piggyback check counter incremented. > >- * "Offline": rcu_barrier_callback() found offline CPU > >- * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. > >- * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. > >- * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. > >+ * "Begin": _rcu_barrier() started. > >+ * "Check": _rcu_barrier() checking for piggybacking. > >+ * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. > >+ * "Inc1": _rcu_barrier() piggyback check counter incremented. > >+ * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU > >+ * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. > >+ * "OnlineQ": _rcu_barrier() found online CPU with callbacks. > >+ * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. > > * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. > > * "CB": An rcu_barrier_callback() invoked a callback, not the last. > > * "LastCB": An rcu_barrier_callback() invoked the last callback. > >- * "Inc2": rcu_barrier_callback() piggyback check counter incremented. > >+ * "Inc2": _rcu_barrier() piggyback check counter incremented. > > * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument > > * is the count of remaining callbacks, and "done" is the piggybacking count. > > */ > >diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > >index f6880052b917..7680fc275036 100644 > >--- a/kernel/rcu/tree.c > >+++ b/kernel/rcu/tree.c > >@@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) > > continue; > > rdp = per_cpu_ptr(rsp->rda, cpu); > > if (rcu_is_nocb_cpu(cpu)) { > >- _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > >- rsp->n_barrier_done); > >- atomic_inc(&rsp->barrier_cpu_count); > >- __call_rcu(&rdp->barrier_head, rcu_barrier_callback, > >- rsp, cpu, 0); > >+ if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { > >+ _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, > >+ rsp->n_barrier_done); > >+ } else { > >+ _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > >+ rsp->n_barrier_done); > >+ atomic_inc(&rsp->barrier_cpu_count); > >+ __call_rcu(&rdp->barrier_head, > >+ rcu_barrier_callback, rsp, cpu, 0); > >+ } > > } else if (ACCESS_ONCE(rdp->qlen)) { > > _rcu_barrier_trace(rsp, "OnlineQ", cpu, > > rsp->n_barrier_done); > >diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h > >index 4beab3d2328c..8e7b1843896e 100644 > >--- a/kernel/rcu/tree.h > >+++ b/kernel/rcu/tree.h > >@@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); > > static void print_cpu_stall_info_end(void); > > static void zero_cpu_stall_ticks(struct rcu_data *rdp); > > static void increment_cpu_stall_ticks(void); > >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); > > static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); > > static void rcu_init_one_nocb(struct rcu_node *rnp); > >diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > >index 927c17b081c7..68c5b23b7173 100644 > >--- a/kernel/rcu/tree_plugin.h > >+++ b/kernel/rcu/tree_plugin.h > >@@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) > > } > > > > /* > >+ * Does the specified CPU need an RCU callback for the specified flavor > >+ * of rcu_barrier()? > >+ */ > >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > >+{ > >+ struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > >+ struct rcu_head *rhp; > >+ > >+ /* No-CBs CPUs might have callbacks on any of three lists. */ > >+ rhp = ACCESS_ONCE(rdp->nocb_head); > >+ if (!rhp) > >+ rhp = ACCESS_ONCE(rdp->nocb_gp_head); > >+ if (!rhp) > >+ rhp = ACCESS_ONCE(rdp->nocb_follower_head); > >+ > >+ /* Having no rcuo kthread but CBs after scheduler starts is bad! */ > >+ if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { > >+ /* RCU callback enqueued before CPU first came online??? */ > >+ pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", > >+ cpu, rhp->func); > >+ WARN_ON_ONCE(1); > >+ } > >+ > >+ return !!rhp; > >+} > >+ > >+/* > > * Enqueue the specified string of rcu_head structures onto the specified > > * CPU's no-CBs lists. The CPU is specified by rdp, the head of the > > * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy > >@@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > > > #else /* #ifdef CONFIG_RCU_NOCB_CPU */ > > > >+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > >+{ > >+} > >+ > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > > { > > } > > > > --- > -Jay Vosburgh, jay.vosburgh@canonical.com > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-27 17:45 ` Paul E. McKenney 2014-10-27 20:43 ` Jay Vosburgh @ 2014-10-28 8:12 ` Yanko Kaneti 2014-10-28 12:50 ` Paul E. McKenney 1 sibling, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-28 8:12 UTC (permalink / raw) To: Paul E. McKenney Cc: Jay Vosburgh, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Mon-10/27/14-2014 10:45, Paul E. McKenney wrote: > On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: > > On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > > > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > > > >> Looking at the dmesg, the early boot messages seem to be > > > >> confused as to how many CPUs there are, e.g., > > > >> > > > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > > >> [ 0.000000] Hierarchical RCU implementation. > > > >> [ 0.000000] RCU debugfs-based tracing is enabled. > > > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > > > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > > > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > > > >> [ 0.000000] Offload RCU callbacks from all CPUs > > > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > > > >> > > > >> but later shows 2: > > > >> > > > >> [ 0.233703] x86: Booting SMP configuration: > > > >> [ 0.236003] .... node #0, CPUs: #1 > > > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > > > >> > > > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > > > > > > > >Well, this might explain some of the difficulties. If RCU decides to wait > > > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > > > >was definitely expecting four CPUs. > > > > > > > >So what happens if you boot with maxcpus=2? (Or build with > > > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > > > >I might have some ideas for a real fix. > > > > > > Booting with maxcpus=2 makes no difference (the dmesg output is > > > the same). > > > > > > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > > > dmesg has different CPU information at boot: > > > > > > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > > > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > > > [...] > > > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > > > [...] > > > [ 0.000000] Hierarchical RCU implementation. > > > [ 0.000000] RCU debugfs-based tracing is enabled. > > > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > > > [ 0.000000] Offload RCU callbacks from all CPUs > > > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. > > > > Thank you -- this confirms my suspicions on the fix, though I must admit > > to being surprised that maxcpus made no difference. > > And here is an alleged fix, lightly tested at this end. Does this patch > help? Tested this on top of rc2 (as found in Fedora, and failing without the patch) with all my modprobe scenarios and it seems to have fixed it. Thanks -Yanko > Thanx, Paul > > ------------------------------------------------------------------------ > > rcu: Make rcu_barrier() understand about missing rcuo kthreads > > Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) > avoids creating rcuo kthreads for CPUs that never come online. This > fixes a bug in many instances of firmware: Instead of lying about their > age, these systems instead lie about the number of CPUs that they have. > Before commit 35ce7f29a44a, this could result in huge numbers of useless > rcuo kthreads being created. > > It appears that experience indicates that I should have told the > people suffering from this problem to fix their broken firmware, but > I instead produced what turned out to be a partial fix. The missing > piece supplied by this commit makes sure that rcu_barrier() knows not to > post callbacks for no-CBs CPUs that have not yet come online, because > otherwise rcu_barrier() will hang on systems having firmware that lies > about the number of CPUs. > > It is tempting to simply have rcu_barrier() refuse to post a callback on > any no-CBs CPU that does not have an rcuo kthread. This unfortunately > does not work because rcu_barrier() is required to wait for all pending > callbacks. It is therefore required to wait even for those callbacks > that cannot possibly be invoked. Even if doing so hangs the system. > > Given that posting a callback to a no-CBs CPU that does not yet have an > rcuo kthread can hang rcu_barrier(), It is tempting to report an error > in this case. Unfortunately, this will result in false positives at > boot time, when it is perfectly legal to post callbacks to the boot CPU > before the scheduler has started, in other words, before it is legal > to invoke rcu_barrier(). > > So this commit instead has rcu_barrier() avoid posting callbacks to > CPUs having neither rcuo kthread nor pending callbacks, and has it > complain bitterly if it finds CPUs having no rcuo kthread but some > pending callbacks. And when rcu_barrier() does find CPUs having no rcuo > kthread but pending callbacks, as noted earlier, it has no choice but > to hang indefinitely. > > Reported-by: Yanko Kaneti <yaneti@declera.com> > Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> > Reported-by: Meelis Roos <mroos@linux.ee> > Reported-by: Eric B Munson <emunson@akamai.com> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h > index aa8e5eea3ab4..c78e88ce5ea3 100644 > --- a/include/trace/events/rcu.h > +++ b/include/trace/events/rcu.h > @@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, > /* > * Tracepoint for _rcu_barrier() execution. The string "s" describes > * the _rcu_barrier phase: > - * "Begin": rcu_barrier_callback() started. > - * "Check": rcu_barrier_callback() checking for piggybacking. > - * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. > - * "Inc1": rcu_barrier_callback() piggyback check counter incremented. > - * "Offline": rcu_barrier_callback() found offline CPU > - * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. > - * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. > - * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. > + * "Begin": _rcu_barrier() started. > + * "Check": _rcu_barrier() checking for piggybacking. > + * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. > + * "Inc1": _rcu_barrier() piggyback check counter incremented. > + * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU > + * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. > + * "OnlineQ": _rcu_barrier() found online CPU with callbacks. > + * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. > * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. > * "CB": An rcu_barrier_callback() invoked a callback, not the last. > * "LastCB": An rcu_barrier_callback() invoked the last callback. > - * "Inc2": rcu_barrier_callback() piggyback check counter incremented. > + * "Inc2": _rcu_barrier() piggyback check counter incremented. > * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument > * is the count of remaining callbacks, and "done" is the piggybacking count. > */ > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index f6880052b917..7680fc275036 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) > continue; > rdp = per_cpu_ptr(rsp->rda, cpu); > if (rcu_is_nocb_cpu(cpu)) { > - _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > - rsp->n_barrier_done); > - atomic_inc(&rsp->barrier_cpu_count); > - __call_rcu(&rdp->barrier_head, rcu_barrier_callback, > - rsp, cpu, 0); > + if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { > + _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, > + rsp->n_barrier_done); > + } else { > + _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > + rsp->n_barrier_done); > + atomic_inc(&rsp->barrier_cpu_count); > + __call_rcu(&rdp->barrier_head, > + rcu_barrier_callback, rsp, cpu, 0); > + } > } else if (ACCESS_ONCE(rdp->qlen)) { > _rcu_barrier_trace(rsp, "OnlineQ", cpu, > rsp->n_barrier_done); > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h > index 4beab3d2328c..8e7b1843896e 100644 > --- a/kernel/rcu/tree.h > +++ b/kernel/rcu/tree.h > @@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); > static void print_cpu_stall_info_end(void); > static void zero_cpu_stall_ticks(struct rcu_data *rdp); > static void increment_cpu_stall_ticks(void); > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); > static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); > static void rcu_init_one_nocb(struct rcu_node *rnp); > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > index 927c17b081c7..68c5b23b7173 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) > } > > /* > + * Does the specified CPU need an RCU callback for the specified flavor > + * of rcu_barrier()? > + */ > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > +{ > + struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > + struct rcu_head *rhp; > + > + /* No-CBs CPUs might have callbacks on any of three lists. */ > + rhp = ACCESS_ONCE(rdp->nocb_head); > + if (!rhp) > + rhp = ACCESS_ONCE(rdp->nocb_gp_head); > + if (!rhp) > + rhp = ACCESS_ONCE(rdp->nocb_follower_head); > + > + /* Having no rcuo kthread but CBs after scheduler starts is bad! */ > + if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { > + /* RCU callback enqueued before CPU first came online??? */ > + pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", > + cpu, rhp->func); > + WARN_ON_ONCE(1); > + } > + > + return !!rhp; > +} > + > +/* > * Enqueue the specified string of rcu_head structures onto the specified > * CPU's no-CBs lists. The CPU is specified by rdp, the head of the > * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy > @@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > #else /* #ifdef CONFIG_RCU_NOCB_CPU */ > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > +{ > +} > + > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > { > } > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-28 8:12 ` Yanko Kaneti @ 2014-10-28 12:50 ` Paul E. McKenney 2014-10-28 13:00 ` Yanko Kaneti 0 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-28 12:50 UTC (permalink / raw) To: Yanko Kaneti Cc: Jay Vosburgh, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Tue, Oct 28, 2014 at 10:12:43AM +0200, Yanko Kaneti wrote: > On Mon-10/27/14-2014 10:45, Paul E. McKenney wrote: > > On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: > > > On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > > > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > > > > >> Looking at the dmesg, the early boot messages seem to be > > > > >> confused as to how many CPUs there are, e.g., > > > > >> > > > > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > > > >> [ 0.000000] Hierarchical RCU implementation. > > > > >> [ 0.000000] RCU debugfs-based tracing is enabled. > > > > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > > > > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > > > > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > > > > >> [ 0.000000] Offload RCU callbacks from all CPUs > > > > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > > > > >> > > > > >> but later shows 2: > > > > >> > > > > >> [ 0.233703] x86: Booting SMP configuration: > > > > >> [ 0.236003] .... node #0, CPUs: #1 > > > > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > > > > >> > > > > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > > > > > > > > > >Well, this might explain some of the difficulties. If RCU decides to wait > > > > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > > > > >was definitely expecting four CPUs. > > > > > > > > > >So what happens if you boot with maxcpus=2? (Or build with > > > > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > > > > >I might have some ideas for a real fix. > > > > > > > > Booting with maxcpus=2 makes no difference (the dmesg output is > > > > the same). > > > > > > > > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > > > > dmesg has different CPU information at boot: > > > > > > > > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > > > > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > > > > [...] > > > > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > > > > [...] > > > > [ 0.000000] Hierarchical RCU implementation. > > > > [ 0.000000] RCU debugfs-based tracing is enabled. > > > > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > > > > [ 0.000000] Offload RCU callbacks from all CPUs > > > > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. > > > > > > Thank you -- this confirms my suspicions on the fix, though I must admit > > > to being surprised that maxcpus made no difference. > > > > And here is an alleged fix, lightly tested at this end. Does this patch > > help? > > Tested this on top of rc2 (as found in Fedora, and failing without the patch) > with all my modprobe scenarios and it seems to have fixed it. Very good! May I apply your Tested-by? Thanx, Paul > Thanks > -Yanko > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > rcu: Make rcu_barrier() understand about missing rcuo kthreads > > > > Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) > > avoids creating rcuo kthreads for CPUs that never come online. This > > fixes a bug in many instances of firmware: Instead of lying about their > > age, these systems instead lie about the number of CPUs that they have. > > Before commit 35ce7f29a44a, this could result in huge numbers of useless > > rcuo kthreads being created. > > > > It appears that experience indicates that I should have told the > > people suffering from this problem to fix their broken firmware, but > > I instead produced what turned out to be a partial fix. The missing > > piece supplied by this commit makes sure that rcu_barrier() knows not to > > post callbacks for no-CBs CPUs that have not yet come online, because > > otherwise rcu_barrier() will hang on systems having firmware that lies > > about the number of CPUs. > > > > It is tempting to simply have rcu_barrier() refuse to post a callback on > > any no-CBs CPU that does not have an rcuo kthread. This unfortunately > > does not work because rcu_barrier() is required to wait for all pending > > callbacks. It is therefore required to wait even for those callbacks > > that cannot possibly be invoked. Even if doing so hangs the system. > > > > Given that posting a callback to a no-CBs CPU that does not yet have an > > rcuo kthread can hang rcu_barrier(), It is tempting to report an error > > in this case. Unfortunately, this will result in false positives at > > boot time, when it is perfectly legal to post callbacks to the boot CPU > > before the scheduler has started, in other words, before it is legal > > to invoke rcu_barrier(). > > > > So this commit instead has rcu_barrier() avoid posting callbacks to > > CPUs having neither rcuo kthread nor pending callbacks, and has it > > complain bitterly if it finds CPUs having no rcuo kthread but some > > pending callbacks. And when rcu_barrier() does find CPUs having no rcuo > > kthread but pending callbacks, as noted earlier, it has no choice but > > to hang indefinitely. > > > > Reported-by: Yanko Kaneti <yaneti@declera.com> > > Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> > > Reported-by: Meelis Roos <mroos@linux.ee> > > Reported-by: Eric B Munson <emunson@akamai.com> > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h > > index aa8e5eea3ab4..c78e88ce5ea3 100644 > > --- a/include/trace/events/rcu.h > > +++ b/include/trace/events/rcu.h > > @@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, > > /* > > * Tracepoint for _rcu_barrier() execution. The string "s" describes > > * the _rcu_barrier phase: > > - * "Begin": rcu_barrier_callback() started. > > - * "Check": rcu_barrier_callback() checking for piggybacking. > > - * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. > > - * "Inc1": rcu_barrier_callback() piggyback check counter incremented. > > - * "Offline": rcu_barrier_callback() found offline CPU > > - * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. > > - * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. > > - * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. > > + * "Begin": _rcu_barrier() started. > > + * "Check": _rcu_barrier() checking for piggybacking. > > + * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. > > + * "Inc1": _rcu_barrier() piggyback check counter incremented. > > + * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU > > + * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. > > + * "OnlineQ": _rcu_barrier() found online CPU with callbacks. > > + * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. > > * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. > > * "CB": An rcu_barrier_callback() invoked a callback, not the last. > > * "LastCB": An rcu_barrier_callback() invoked the last callback. > > - * "Inc2": rcu_barrier_callback() piggyback check counter incremented. > > + * "Inc2": _rcu_barrier() piggyback check counter incremented. > > * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument > > * is the count of remaining callbacks, and "done" is the piggybacking count. > > */ > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > index f6880052b917..7680fc275036 100644 > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) > > continue; > > rdp = per_cpu_ptr(rsp->rda, cpu); > > if (rcu_is_nocb_cpu(cpu)) { > > - _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > > - rsp->n_barrier_done); > > - atomic_inc(&rsp->barrier_cpu_count); > > - __call_rcu(&rdp->barrier_head, rcu_barrier_callback, > > - rsp, cpu, 0); > > + if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { > > + _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, > > + rsp->n_barrier_done); > > + } else { > > + _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > > + rsp->n_barrier_done); > > + atomic_inc(&rsp->barrier_cpu_count); > > + __call_rcu(&rdp->barrier_head, > > + rcu_barrier_callback, rsp, cpu, 0); > > + } > > } else if (ACCESS_ONCE(rdp->qlen)) { > > _rcu_barrier_trace(rsp, "OnlineQ", cpu, > > rsp->n_barrier_done); > > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h > > index 4beab3d2328c..8e7b1843896e 100644 > > --- a/kernel/rcu/tree.h > > +++ b/kernel/rcu/tree.h > > @@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); > > static void print_cpu_stall_info_end(void); > > static void zero_cpu_stall_ticks(struct rcu_data *rdp); > > static void increment_cpu_stall_ticks(void); > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); > > static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); > > static void rcu_init_one_nocb(struct rcu_node *rnp); > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > index 927c17b081c7..68c5b23b7173 100644 > > --- a/kernel/rcu/tree_plugin.h > > +++ b/kernel/rcu/tree_plugin.h > > @@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) > > } > > > > /* > > + * Does the specified CPU need an RCU callback for the specified flavor > > + * of rcu_barrier()? > > + */ > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > > +{ > > + struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > > + struct rcu_head *rhp; > > + > > + /* No-CBs CPUs might have callbacks on any of three lists. */ > > + rhp = ACCESS_ONCE(rdp->nocb_head); > > + if (!rhp) > > + rhp = ACCESS_ONCE(rdp->nocb_gp_head); > > + if (!rhp) > > + rhp = ACCESS_ONCE(rdp->nocb_follower_head); > > + > > + /* Having no rcuo kthread but CBs after scheduler starts is bad! */ > > + if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { > > + /* RCU callback enqueued before CPU first came online??? */ > > + pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", > > + cpu, rhp->func); > > + WARN_ON_ONCE(1); > > + } > > + > > + return !!rhp; > > +} > > + > > +/* > > * Enqueue the specified string of rcu_head structures onto the specified > > * CPU's no-CBs lists. The CPU is specified by rdp, the head of the > > * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy > > @@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > > > #else /* #ifdef CONFIG_RCU_NOCB_CPU */ > > > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > > +{ > > +} > > + > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > > { > > } > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-28 12:50 ` Paul E. McKenney @ 2014-10-28 13:00 ` Yanko Kaneti 2014-10-28 15:54 ` Kevin Fenzi 0 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-28 13:00 UTC (permalink / raw) To: Paul E. McKenney Cc: Jay Vosburgh, Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Tue-10/28/14-2014 05:50, Paul E. McKenney wrote: > On Tue, Oct 28, 2014 at 10:12:43AM +0200, Yanko Kaneti wrote: > > On Mon-10/27/14-2014 10:45, Paul E. McKenney wrote: > > > On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote: > > > > On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote: > > > > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > > > > > > > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote: > > > > > >> Looking at the dmesg, the early boot messages seem to be > > > > > >> confused as to how many CPUs there are, e.g., > > > > > >> > > > > > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > > > > >> [ 0.000000] Hierarchical RCU implementation. > > > > > >> [ 0.000000] RCU debugfs-based tracing is enabled. > > > > > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > > > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. > > > > > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > > > > > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0 > > > > > >> [ 0.000000] Offload RCU callbacks from all CPUs > > > > > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3. > > > > > >> > > > > > >> but later shows 2: > > > > > >> > > > > > >> [ 0.233703] x86: Booting SMP configuration: > > > > > >> [ 0.236003] .... node #0, CPUs: #1 > > > > > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs > > > > > >> > > > > > >> In any event, the E8400 is a 2 core CPU with no hyperthreading. > > > > > > > > > > > >Well, this might explain some of the difficulties. If RCU decides to wait > > > > > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier() > > > > > >was definitely expecting four CPUs. > > > > > > > > > > > >So what happens if you boot with maxcpus=2? (Or build with > > > > > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so, > > > > > >I might have some ideas for a real fix. > > > > > > > > > > Booting with maxcpus=2 makes no difference (the dmesg output is > > > > > the same). > > > > > > > > > > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and > > > > > dmesg has different CPU information at boot: > > > > > > > > > > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2 > > > > > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs > > > > > [...] > > > > > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1 > > > > > [...] > > > > > [ 0.000000] Hierarchical RCU implementation. > > > > > [ 0.000000] RCU debugfs-based tracing is enabled. > > > > > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. > > > > > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0 > > > > > [ 0.000000] Offload RCU callbacks from all CPUs > > > > > [ 0.000000] Offload RCU callbacks from CPUs: 0-1. > > > > > > > > Thank you -- this confirms my suspicions on the fix, though I must admit > > > > to being surprised that maxcpus made no difference. > > > > > > And here is an alleged fix, lightly tested at this end. Does this patch > > > help? > > > > Tested this on top of rc2 (as found in Fedora, and failing without the patch) > > with all my modprobe scenarios and it seems to have fixed it. > > Very good! May I apply your Tested-by? Sure. Sorry didn't include this earlier Tested-by: Yanko Kaneti <yaneti@declera.com> > Thanx, Paul > > > Thanks > > -Yanko > > > > > > > Thanx, Paul > > > > > > ------------------------------------------------------------------------ > > > > > > rcu: Make rcu_barrier() understand about missing rcuo kthreads > > > > > > Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs) > > > avoids creating rcuo kthreads for CPUs that never come online. This > > > fixes a bug in many instances of firmware: Instead of lying about their > > > age, these systems instead lie about the number of CPUs that they have. > > > Before commit 35ce7f29a44a, this could result in huge numbers of useless > > > rcuo kthreads being created. > > > > > > It appears that experience indicates that I should have told the > > > people suffering from this problem to fix their broken firmware, but > > > I instead produced what turned out to be a partial fix. The missing > > > piece supplied by this commit makes sure that rcu_barrier() knows not to > > > post callbacks for no-CBs CPUs that have not yet come online, because > > > otherwise rcu_barrier() will hang on systems having firmware that lies > > > about the number of CPUs. > > > > > > It is tempting to simply have rcu_barrier() refuse to post a callback on > > > any no-CBs CPU that does not have an rcuo kthread. This unfortunately > > > does not work because rcu_barrier() is required to wait for all pending > > > callbacks. It is therefore required to wait even for those callbacks > > > that cannot possibly be invoked. Even if doing so hangs the system. > > > > > > Given that posting a callback to a no-CBs CPU that does not yet have an > > > rcuo kthread can hang rcu_barrier(), It is tempting to report an error > > > in this case. Unfortunately, this will result in false positives at > > > boot time, when it is perfectly legal to post callbacks to the boot CPU > > > before the scheduler has started, in other words, before it is legal > > > to invoke rcu_barrier(). > > > > > > So this commit instead has rcu_barrier() avoid posting callbacks to > > > CPUs having neither rcuo kthread nor pending callbacks, and has it > > > complain bitterly if it finds CPUs having no rcuo kthread but some > > > pending callbacks. And when rcu_barrier() does find CPUs having no rcuo > > > kthread but pending callbacks, as noted earlier, it has no choice but > > > to hang indefinitely. > > > > > > Reported-by: Yanko Kaneti <yaneti@declera.com> > > > Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com> > > > Reported-by: Meelis Roos <mroos@linux.ee> > > > Reported-by: Eric B Munson <emunson@akamai.com> > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > > > > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h > > > index aa8e5eea3ab4..c78e88ce5ea3 100644 > > > --- a/include/trace/events/rcu.h > > > +++ b/include/trace/events/rcu.h > > > @@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read, > > > /* > > > * Tracepoint for _rcu_barrier() execution. The string "s" describes > > > * the _rcu_barrier phase: > > > - * "Begin": rcu_barrier_callback() started. > > > - * "Check": rcu_barrier_callback() checking for piggybacking. > > > - * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit. > > > - * "Inc1": rcu_barrier_callback() piggyback check counter incremented. > > > - * "Offline": rcu_barrier_callback() found offline CPU > > > - * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU. > > > - * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks. > > > - * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks. > > > + * "Begin": _rcu_barrier() started. > > > + * "Check": _rcu_barrier() checking for piggybacking. > > > + * "EarlyExit": _rcu_barrier() piggybacked, thus early exit. > > > + * "Inc1": _rcu_barrier() piggyback check counter incremented. > > > + * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU > > > + * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU. > > > + * "OnlineQ": _rcu_barrier() found online CPU with callbacks. > > > + * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks. > > > * "IRQ": An rcu_barrier_callback() callback posted on remote CPU. > > > * "CB": An rcu_barrier_callback() invoked a callback, not the last. > > > * "LastCB": An rcu_barrier_callback() invoked the last callback. > > > - * "Inc2": rcu_barrier_callback() piggyback check counter incremented. > > > + * "Inc2": _rcu_barrier() piggyback check counter incremented. > > > * The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument > > > * is the count of remaining callbacks, and "done" is the piggybacking count. > > > */ > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index f6880052b917..7680fc275036 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp) > > > continue; > > > rdp = per_cpu_ptr(rsp->rda, cpu); > > > if (rcu_is_nocb_cpu(cpu)) { > > > - _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > > > - rsp->n_barrier_done); > > > - atomic_inc(&rsp->barrier_cpu_count); > > > - __call_rcu(&rdp->barrier_head, rcu_barrier_callback, > > > - rsp, cpu, 0); > > > + if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) { > > > + _rcu_barrier_trace(rsp, "OfflineNoCB", cpu, > > > + rsp->n_barrier_done); > > > + } else { > > > + _rcu_barrier_trace(rsp, "OnlineNoCB", cpu, > > > + rsp->n_barrier_done); > > > + atomic_inc(&rsp->barrier_cpu_count); > > > + __call_rcu(&rdp->barrier_head, > > > + rcu_barrier_callback, rsp, cpu, 0); > > > + } > > > } else if (ACCESS_ONCE(rdp->qlen)) { > > > _rcu_barrier_trace(rsp, "OnlineQ", cpu, > > > rsp->n_barrier_done); > > > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h > > > index 4beab3d2328c..8e7b1843896e 100644 > > > --- a/kernel/rcu/tree.h > > > +++ b/kernel/rcu/tree.h > > > @@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu); > > > static void print_cpu_stall_info_end(void); > > > static void zero_cpu_stall_ticks(struct rcu_data *rdp); > > > static void increment_cpu_stall_ticks(void); > > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu); > > > static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq); > > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp); > > > static void rcu_init_one_nocb(struct rcu_node *rnp); > > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > > index 927c17b081c7..68c5b23b7173 100644 > > > --- a/kernel/rcu/tree_plugin.h > > > +++ b/kernel/rcu/tree_plugin.h > > > @@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force) > > > } > > > > > > /* > > > + * Does the specified CPU need an RCU callback for the specified flavor > > > + * of rcu_barrier()? > > > + */ > > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > > > +{ > > > + struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu); > > > + struct rcu_head *rhp; > > > + > > > + /* No-CBs CPUs might have callbacks on any of three lists. */ > > > + rhp = ACCESS_ONCE(rdp->nocb_head); > > > + if (!rhp) > > > + rhp = ACCESS_ONCE(rdp->nocb_gp_head); > > > + if (!rhp) > > > + rhp = ACCESS_ONCE(rdp->nocb_follower_head); > > > + > > > + /* Having no rcuo kthread but CBs after scheduler starts is bad! */ > > > + if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) { > > > + /* RCU callback enqueued before CPU first came online??? */ > > > + pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n", > > > + cpu, rhp->func); > > > + WARN_ON_ONCE(1); > > > + } > > > + > > > + return !!rhp; > > > +} > > > + > > > +/* > > > * Enqueue the specified string of rcu_head structures onto the specified > > > * CPU's no-CBs lists. The CPU is specified by rdp, the head of the > > > * string by rhp, and the tail of the string by rhtp. The non-lazy/lazy > > > @@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > > > > > #else /* #ifdef CONFIG_RCU_NOCB_CPU */ > > > > > > +static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu) > > > +{ > > > +} > > > + > > > static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp) > > > { > > > } > > > > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-28 13:00 ` Yanko Kaneti @ 2014-10-28 15:54 ` Kevin Fenzi 2014-10-28 16:15 ` Paul E. McKenney 0 siblings, 1 reply; 63+ messages in thread From: Kevin Fenzi @ 2014-10-28 15:54 UTC (permalink / raw) To: Yanko Kaneti Cc: Paul E. McKenney, Jay Vosburgh, Josh Boyer, Eric W. Biederman, Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj [-- Attachment #1: Type: text/plain, Size: 166 bytes --] Just FYI, this solves the orig issue for me as well. ;) Thanks for all the work in tracking it down... Tested-by: Kevin Fenzi <kevin@scrye.com> kevin [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-28 15:54 ` Kevin Fenzi @ 2014-10-28 16:15 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-28 16:15 UTC (permalink / raw) To: Kevin Fenzi Cc: Yanko Kaneti, Jay Vosburgh, Josh Boyer, Eric W. Biederman, Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj On Tue, Oct 28, 2014 at 09:54:28AM -0600, Kevin Fenzi wrote: > Just FYI, this solves the orig issue for me as well. ;) > > Thanks for all the work in tracking it down... > > Tested-by: Kevin Fenzi <kevin@scrye.com> And thank you for testing as well! Thanx, Paul ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-24 21:49 ` Paul E. McKenney 2014-10-24 22:02 ` Jay Vosburgh 2014-10-24 22:34 ` Jay Vosburgh @ 2014-10-25 12:09 ` Yanko Kaneti 2014-10-25 13:38 ` Paul E. McKenney 2 siblings, 1 reply; 63+ messages in thread From: Yanko Kaneti @ 2014-10-25 12:09 UTC (permalink / raw) To: Paul E. McKenney Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos, tj On Fri-10/24/14-2014 14:49, Paul E. McKenney wrote: > On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > > On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > > > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > [ . . . ] > > > > > > Well, if you are feeling aggressive, give the following patch a spin. > > > > > I am doing sanity tests on it in the meantime. > > > > > > > > Doesn't seem to make a difference here > > > > > > OK, inspection isn't cutting it, so time for tracing. Does the system > > > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > > > the problem occurs, then dump the trace buffer after the problem occurs. > > > > Sorry for being unresposive here, but I know next to nothing about tracing > > or most things about the kernel, so I have some cathing up to do. > > > > In the meantime some layman observations while I tried to find what exactly > > triggers the problem. > > - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > > - libvirtd seems to be very active in using all sorts of kernel facilities > > that are modules on fedora so it seems to cause many simultaneous kworker > > calls to modprobe > > - there are 8 kworker/u16 from 0 to 7 > > - one of these kworkers always deadlocks, while there appear to be two > > kworker/u16:6 - the seventh > > Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > > > 6 vs 8 as in 6 rcuos where before they were always 8 > > > > Just observations from someone who still doesn't know what the u16 > > kworkers are.. > > Could you please run the following diagnostic patch? This will help > me see if I have managed to miswire the rcuo kthreads. It should > print some information at task-hang time. So here the output with todays linux tip and the diagnostic patch. This is the case with just starting libvird in runlevel 1. Also a snapshot of the kworker/u16 s 6 ? S 0:00 \_ [kworker/u16:0] 553 ? S 0:00 | \_ [kworker/u16:0] 554 ? D 0:00 | \_ /sbin/modprobe -q -- bridge 78 ? S 0:00 \_ [kworker/u16:1] 92 ? S 0:00 \_ [kworker/u16:2] 93 ? S 0:00 \_ [kworker/u16:3] 94 ? S 0:00 \_ [kworker/u16:4] 95 ? S 0:00 \_ [kworker/u16:5] 96 ? D 0:00 \_ [kworker/u16:6] 105 ? S 0:00 \_ [kworker/u16:7] 108 ? S 0:00 \_ [kworker/u16:8] INFO: task kworker/u16:6:96 blocked for more than 120 seconds. Not tainted 3.18.0-rc1+ #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:6 D ffff8800ca9ecec0 11552 96 2 0x00000000 Workqueue: netns cleanup_net ffff880221fff9c8 0000000000000096 ffff8800ca9ecec0 00000000001d5f00 ffff880221ffffd8 00000000001d5f00 ffff880223260000 ffff8800ca9ecec0 ffffffff82c44010 7fffffffffffffff ffffffff81ee3798 ffffffff81ee3790 Call Trace: [<ffffffff81866219>] schedule+0x29/0x70 [<ffffffff8186b43c>] schedule_timeout+0x26c/0x410 [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 [<ffffffff8110748c>] ? mark_held_locks+0x7c/0xb0 [<ffffffff8186c4c0>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff8110761d>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffff81867c4c>] wait_for_completion+0x10c/0x150 [<ffffffff810e4dc0>] ? wake_up_state+0x20/0x20 [<ffffffff81133627>] _rcu_barrier+0x677/0xcd0 [<ffffffff81133cd5>] rcu_barrier+0x15/0x20 [<ffffffff81720edf>] netdev_run_todo+0x6f/0x310 [<ffffffff81715aa5>] ? rollback_registered_many+0x265/0x2e0 [<ffffffff8172df4e>] rtnl_unlock+0xe/0x10 [<ffffffff81717906>] default_device_exit_batch+0x156/0x180 [<ffffffff810fd280>] ? abort_exclusive_wait+0xb0/0xb0 [<ffffffff8170f9b3>] ops_exit_list.isra.1+0x53/0x60 [<ffffffff81710560>] cleanup_net+0x100/0x1f0 [<ffffffff810cc988>] process_one_work+0x218/0x850 [<ffffffff810cc8ef>] ? process_one_work+0x17f/0x850 [<ffffffff810cd0a7>] ? worker_thread+0xe7/0x4a0 [<ffffffff810cd02b>] worker_thread+0x6b/0x4a0 [<ffffffff810ccfc0>] ? process_one_work+0x850/0x850 [<ffffffff810d337b>] kthread+0x10b/0x130 [<ffffffff81028c69>] ? sched_clock+0x9/0x10 [<ffffffff810d3270>] ? kthread_create_on_node+0x250/0x250 [<ffffffff8186d1fc>] ret_from_fork+0x7c/0xb0 [<ffffffff810d3270>] ? kthread_create_on_node+0x250/0x250 4 locks held by kworker/u16:6/96: #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc8ef>] #process_one_work+0x17f/0x850 #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc8ef>] #process_one_work+0x17f/0x850 #2: (net_mutex){+.+.+.}, at: [<ffffffff817104ec>] cleanup_net+0x8c/0x1f0 #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff81133025>] #_rcu_barrier+0x75/0xcd0 rcu_show_nocb_setup(): rcu_sched nocb state: 0: ffff8802267ced40 l:ffff8802267ced40 n:ffff8802269ced40 .G. 1: ffff8802269ced40 l:ffff8802267ced40 n: (null) ... 2: ffff880226bced40 l:ffff880226bced40 n:ffff880226dced40 .G. 3: ffff880226dced40 l:ffff880226bced40 n: (null) N.. 4: ffff880226fced40 l:ffff880226fced40 n:ffff8802271ced40 .G. 5: ffff8802271ced40 l:ffff880226fced40 n: (null) ... 6: ffff8802273ced40 l:ffff8802273ced40 n:ffff8802275ced40 N.. 7: ffff8802275ced40 l:ffff8802273ced40 n: (null) N.. rcu_show_nocb_setup(): rcu_bh nocb state: 0: ffff8802267ceac0 l:ffff8802267ceac0 n:ffff8802269ceac0 ... 1: ffff8802269ceac0 l:ffff8802267ceac0 n: (null) ... 2: ffff880226bceac0 l:ffff880226bceac0 n:ffff880226dceac0 ... 3: ffff880226dceac0 l:ffff880226bceac0 n: (null) ... 4: ffff880226fceac0 l:ffff880226fceac0 n:ffff8802271ceac0 ... 5: ffff8802271ceac0 l:ffff880226fceac0 n: (null) ... 6: ffff8802273ceac0 l:ffff8802273ceac0 n:ffff8802275ceac0 ... 7: ffff8802275ceac0 l:ffff8802273ceac0 n: (null) ... INFO: task modprobe:554 blocked for more than 120 seconds. Not tainted 3.18.0-rc1+ #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D ffff8800c85dcec0 12456 554 553 0x00000000 ffff8802178afbf8 0000000000000096 ffff8800c85dcec0 00000000001d5f00 ffff8802178affd8 00000000001d5f00 ffffffff81e1b580 ffff8800c85dcec0 ffff8800c85dcec0 ffffffff81f90c08 0000000000000246 ffff8800c85dcec0 Call Trace: [<ffffffff818667c1>] schedule_preempt_disabled+0x31/0x80 [<ffffffff81868013>] mutex_lock_nested+0x183/0x440 [<ffffffff8171037f>] ? register_pernet_subsys+0x1f/0x50 [<ffffffff8171037f>] ? register_pernet_subsys+0x1f/0x50 [<ffffffffa0619000>] ? 0xffffffffa0619000 [<ffffffff8171037f>] register_pernet_subsys+0x1f/0x50 [<ffffffffa0619048>] br_init+0x48/0xd3 [bridge] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 [<ffffffff8115bc22>] load_module+0x20c2/0x2870 [<ffffffff81156c00>] ? store_uevent+0x70/0x70 [<ffffffff81281327>] ? kernel_read+0x57/0x90 [<ffffffff8115c5b6>] SyS_finit_module+0xa6/0xe0 [<ffffffff8186d2d5>] ? sysret_check+0x22/0x5d [<ffffffff8186d2a9>] system_call_fastpath+0x12/0x17 1 lock held by modprobe/554: #0: (net_mutex){+.+.+.}, at: [<ffffffff8171037f>] #register_pernet_subsys+0x1f/0x50 rcu_show_nocb_setup(): rcu_sched nocb state: 0: ffff8802267ced40 l:ffff8802267ced40 n:ffff8802269ced40 .G. 1: ffff8802269ced40 l:ffff8802267ced40 n: (null) ... 2: ffff880226bced40 l:ffff880226bced40 n:ffff880226dced40 .G. 3: ffff880226dced40 l:ffff880226bced40 n: (null) N.. 4: ffff880226fced40 l:ffff880226fced40 n:ffff8802271ced40 .G. 5: ffff8802271ced40 l:ffff880226fced40 n: (null) ... 6: ffff8802273ced40 l:ffff8802273ced40 n:ffff8802275ced40 N.. 7: ffff8802275ced40 l:ffff8802273ced40 n: (null) N.. rcu_show_nocb_setup(): rcu_bh nocb state: 0: ffff8802267ceac0 l:ffff8802267ceac0 n:ffff8802269ceac0 ... 1: ffff8802269ceac0 l:ffff8802267ceac0 n: (null) ... 2: ffff880226bceac0 l:ffff880226bceac0 n:ffff880226dceac0 ... 3: ffff880226dceac0 l:ffff880226bceac0 n: (null) ... 4: ffff880226fceac0 l:ffff880226fceac0 n:ffff8802271ceac0 ... 5: ffff8802271ceac0 l:ffff880226fceac0 n: (null) ... 6: ffff8802273ceac0 l:ffff8802273ceac0 n:ffff8802275ceac0 ... 7: ffff8802275ceac0 l:ffff8802273ceac0 n: (null) ... > Thanx, Paul > > ------------------------------------------------------------------------ > > rcu: Dump no-CBs CPU state at task-hung time > > Strictly diagnostic commit for rcu_barrier() hang. Not for inclusion. > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h > index 0e5366200154..34048140577b 100644 > --- a/include/linux/rcutiny.h > +++ b/include/linux/rcutiny.h > @@ -157,4 +157,8 @@ static inline bool rcu_is_watching(void) > > #endif /* #else defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */ > > +static inline void rcu_show_nocb_setup(void) > +{ > +} > + > #endif /* __LINUX_RCUTINY_H */ > diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h > index 52953790dcca..0b813bdb971b 100644 > --- a/include/linux/rcutree.h > +++ b/include/linux/rcutree.h > @@ -97,4 +97,6 @@ extern int rcu_scheduler_active __read_mostly; > > bool rcu_is_watching(void); > > +void rcu_show_nocb_setup(void); > + > #endif /* __LINUX_RCUTREE_H */ > diff --git a/kernel/hung_task.c b/kernel/hung_task.c > index 06db12434d72..e6e4d0f6b063 100644 > --- a/kernel/hung_task.c > +++ b/kernel/hung_task.c > @@ -118,6 +118,7 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout) > " disables this message.\n"); > sched_show_task(t); > debug_show_held_locks(t); > + rcu_show_nocb_setup(); > > touch_nmi_watchdog(); > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c > index 240fa9094f83..6b373e79ce0e 100644 > --- a/kernel/rcu/rcutorture.c > +++ b/kernel/rcu/rcutorture.c > @@ -1513,6 +1513,7 @@ rcu_torture_cleanup(void) > { > int i; > > + rcu_show_nocb_setup(); > rcutorture_record_test_transition(); > if (torture_cleanup_begin()) { > if (cur_ops->cb_barrier != NULL) > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > index 927c17b081c7..285b3f6fb229 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -2699,6 +2699,31 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ > > +void rcu_show_nocb_setup(void) > +{ > +#ifdef CONFIG_RCU_NOCB_CPU > + int cpu; > + struct rcu_data *rdp; > + struct rcu_state *rsp; > + > + for_each_rcu_flavor(rsp) { > + pr_alert("rcu_show_nocb_setup(): %s nocb state:\n", rsp->name); > + for_each_possible_cpu(cpu) { > + if (!rcu_is_nocb_cpu(cpu)) > + continue; > + rdp = per_cpu_ptr(rsp->rda, cpu); > + pr_alert("%3d: %p l:%p n:%p %c%c%c\n", > + cpu, > + rdp, rdp->nocb_leader, rdp->nocb_next_follower, > + ".N"[!!rdp->nocb_head], > + ".G"[!!rdp->nocb_gp_head], > + ".F"[!!rdp->nocb_follower_head]); > + } > + } > +#endif /* #ifdef CONFIG_RCU_NOCB_CPU */ > +} > +EXPORT_SYMBOL_GPL(rcu_show_nocb_setup); > + > /* > * An adaptive-ticks CPU can potentially execute in kernel mode for an > * arbitrarily long period of time with the scheduling-clock tick turned > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-25 12:09 ` Yanko Kaneti @ 2014-10-25 13:38 ` Paul E. McKenney 0 siblings, 0 replies; 63+ messages in thread From: Paul E. McKenney @ 2014-10-25 13:38 UTC (permalink / raw) To: Yanko Kaneti Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos, tj On Sat, Oct 25, 2014 at 03:09:36PM +0300, Yanko Kaneti wrote: > On Fri-10/24/14-2014 14:49, Paul E. McKenney wrote: > > On Sat, Oct 25, 2014 at 12:25:57AM +0300, Yanko Kaneti wrote: > > > On Fri-10/24/14-2014 11:32, Paul E. McKenney wrote: > > > > On Fri, Oct 24, 2014 at 08:35:26PM +0300, Yanko Kaneti wrote: > > > > > On Fri-10/24/14-2014 10:20, Paul E. McKenney wrote: > > > > [ . . . ] > > > > > > > > Well, if you are feeling aggressive, give the following patch a spin. > > > > > > I am doing sanity tests on it in the meantime. > > > > > > > > > > Doesn't seem to make a difference here > > > > > > > > OK, inspection isn't cutting it, so time for tracing. Does the system > > > > respond to user input? If so, please enable rcu:rcu_barrier ftrace before > > > > the problem occurs, then dump the trace buffer after the problem occurs. > > > > > > Sorry for being unresposive here, but I know next to nothing about tracing > > > or most things about the kernel, so I have some cathing up to do. > > > > > > In the meantime some layman observations while I tried to find what exactly > > > triggers the problem. > > > - Even in runlevel 1 I can reliably trigger the problem by starting libvirtd > > > - libvirtd seems to be very active in using all sorts of kernel facilities > > > that are modules on fedora so it seems to cause many simultaneous kworker > > > calls to modprobe > > > - there are 8 kworker/u16 from 0 to 7 > > > - one of these kworkers always deadlocks, while there appear to be two > > > kworker/u16:6 - the seventh > > > > Adding Tejun on CC in case this duplication of kworker/u16:6 is important. > > > > > 6 vs 8 as in 6 rcuos where before they were always 8 > > > > > > Just observations from someone who still doesn't know what the u16 > > > kworkers are.. > > > > Could you please run the following diagnostic patch? This will help > > me see if I have managed to miswire the rcuo kthreads. It should > > print some information at task-hang time. > > So here the output with todays linux tip and the diagnostic patch. > This is the case with just starting libvird in runlevel 1. Thank you for testing this! > Also a snapshot of the kworker/u16 s > > 6 ? S 0:00 \_ [kworker/u16:0] > 553 ? S 0:00 | \_ [kworker/u16:0] > 554 ? D 0:00 | \_ /sbin/modprobe -q -- bridge > 78 ? S 0:00 \_ [kworker/u16:1] > 92 ? S 0:00 \_ [kworker/u16:2] > 93 ? S 0:00 \_ [kworker/u16:3] > 94 ? S 0:00 \_ [kworker/u16:4] > 95 ? S 0:00 \_ [kworker/u16:5] > 96 ? D 0:00 \_ [kworker/u16:6] > 105 ? S 0:00 \_ [kworker/u16:7] > 108 ? S 0:00 \_ [kworker/u16:8] You had six CPUs, IIRC, so the last two kworker/u16 kthreads are surplus to requirements. Not sure if they are causing any trouble, though. > INFO: task kworker/u16:6:96 blocked for more than 120 seconds. > Not tainted 3.18.0-rc1+ #16 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/u16:6 D ffff8800ca9ecec0 11552 96 2 0x00000000 > Workqueue: netns cleanup_net > ffff880221fff9c8 0000000000000096 ffff8800ca9ecec0 00000000001d5f00 > ffff880221ffffd8 00000000001d5f00 ffff880223260000 ffff8800ca9ecec0 > ffffffff82c44010 7fffffffffffffff ffffffff81ee3798 ffffffff81ee3790 > Call Trace: > [<ffffffff81866219>] schedule+0x29/0x70 > [<ffffffff8186b43c>] schedule_timeout+0x26c/0x410 > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0 > [<ffffffff8110748c>] ? mark_held_locks+0x7c/0xb0 > [<ffffffff8186c4c0>] ? _raw_spin_unlock_irq+0x30/0x50 > [<ffffffff8110761d>] ? trace_hardirqs_on_caller+0x15d/0x200 > [<ffffffff81867c4c>] wait_for_completion+0x10c/0x150 > [<ffffffff810e4dc0>] ? wake_up_state+0x20/0x20 > [<ffffffff81133627>] _rcu_barrier+0x677/0xcd0 > [<ffffffff81133cd5>] rcu_barrier+0x15/0x20 > [<ffffffff81720edf>] netdev_run_todo+0x6f/0x310 > [<ffffffff81715aa5>] ? rollback_registered_many+0x265/0x2e0 > [<ffffffff8172df4e>] rtnl_unlock+0xe/0x10 > [<ffffffff81717906>] default_device_exit_batch+0x156/0x180 > [<ffffffff810fd280>] ? abort_exclusive_wait+0xb0/0xb0 > [<ffffffff8170f9b3>] ops_exit_list.isra.1+0x53/0x60 > [<ffffffff81710560>] cleanup_net+0x100/0x1f0 > [<ffffffff810cc988>] process_one_work+0x218/0x850 > [<ffffffff810cc8ef>] ? process_one_work+0x17f/0x850 > [<ffffffff810cd0a7>] ? worker_thread+0xe7/0x4a0 > [<ffffffff810cd02b>] worker_thread+0x6b/0x4a0 > [<ffffffff810ccfc0>] ? process_one_work+0x850/0x850 > [<ffffffff810d337b>] kthread+0x10b/0x130 > [<ffffffff81028c69>] ? sched_clock+0x9/0x10 > [<ffffffff810d3270>] ? kthread_create_on_node+0x250/0x250 > [<ffffffff8186d1fc>] ret_from_fork+0x7c/0xb0 > [<ffffffff810d3270>] ? kthread_create_on_node+0x250/0x250 > 4 locks held by kworker/u16:6/96: > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc8ef>] > #process_one_work+0x17f/0x850 > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc8ef>] > #process_one_work+0x17f/0x850 > #2: (net_mutex){+.+.+.}, at: [<ffffffff817104ec>] cleanup_net+0x8c/0x1f0 > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff81133025>] > #_rcu_barrier+0x75/0xcd0 > rcu_show_nocb_setup(): rcu_sched nocb state: > 0: ffff8802267ced40 l:ffff8802267ced40 n:ffff8802269ced40 .G. > 1: ffff8802269ced40 l:ffff8802267ced40 n: (null) ... > 2: ffff880226bced40 l:ffff880226bced40 n:ffff880226dced40 .G. > 3: ffff880226dced40 l:ffff880226bced40 n: (null) N.. > 4: ffff880226fced40 l:ffff880226fced40 n:ffff8802271ced40 .G. > 5: ffff8802271ced40 l:ffff880226fced40 n: (null) ... > 6: ffff8802273ced40 l:ffff8802273ced40 n:ffff8802275ced40 N.. > 7: ffff8802275ced40 l:ffff8802273ced40 n: (null) N.. And this looks like rcu_barrier() has posted callbacks for the non-existent CPUs 7 and 8, similar to what Jay was seeing. I am working on a fix -- chasing down corner cases. Thanx, Paul > rcu_show_nocb_setup(): rcu_bh nocb state: > 0: ffff8802267ceac0 l:ffff8802267ceac0 n:ffff8802269ceac0 ... > 1: ffff8802269ceac0 l:ffff8802267ceac0 n: (null) ... > 2: ffff880226bceac0 l:ffff880226bceac0 n:ffff880226dceac0 ... > 3: ffff880226dceac0 l:ffff880226bceac0 n: (null) ... > 4: ffff880226fceac0 l:ffff880226fceac0 n:ffff8802271ceac0 ... > 5: ffff8802271ceac0 l:ffff880226fceac0 n: (null) ... > 6: ffff8802273ceac0 l:ffff8802273ceac0 n:ffff8802275ceac0 ... > 7: ffff8802275ceac0 l:ffff8802273ceac0 n: (null) ... > INFO: task modprobe:554 blocked for more than 120 seconds. > Not tainted 3.18.0-rc1+ #16 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > modprobe D ffff8800c85dcec0 12456 554 553 0x00000000 > ffff8802178afbf8 0000000000000096 ffff8800c85dcec0 00000000001d5f00 > ffff8802178affd8 00000000001d5f00 ffffffff81e1b580 ffff8800c85dcec0 > ffff8800c85dcec0 ffffffff81f90c08 0000000000000246 ffff8800c85dcec0 > Call Trace: > [<ffffffff818667c1>] schedule_preempt_disabled+0x31/0x80 > [<ffffffff81868013>] mutex_lock_nested+0x183/0x440 > [<ffffffff8171037f>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffff8171037f>] ? register_pernet_subsys+0x1f/0x50 > [<ffffffffa0619000>] ? 0xffffffffa0619000 > [<ffffffff8171037f>] register_pernet_subsys+0x1f/0x50 > [<ffffffffa0619048>] br_init+0x48/0xd3 [bridge] > [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > [<ffffffff8115bc22>] load_module+0x20c2/0x2870 > [<ffffffff81156c00>] ? store_uevent+0x70/0x70 > [<ffffffff81281327>] ? kernel_read+0x57/0x90 > [<ffffffff8115c5b6>] SyS_finit_module+0xa6/0xe0 > [<ffffffff8186d2d5>] ? sysret_check+0x22/0x5d > [<ffffffff8186d2a9>] system_call_fastpath+0x12/0x17 > 1 lock held by modprobe/554: > #0: (net_mutex){+.+.+.}, at: [<ffffffff8171037f>] > #register_pernet_subsys+0x1f/0x50 > rcu_show_nocb_setup(): rcu_sched nocb state: > 0: ffff8802267ced40 l:ffff8802267ced40 n:ffff8802269ced40 .G. > 1: ffff8802269ced40 l:ffff8802267ced40 n: (null) ... > 2: ffff880226bced40 l:ffff880226bced40 n:ffff880226dced40 .G. > 3: ffff880226dced40 l:ffff880226bced40 n: (null) N.. > 4: ffff880226fced40 l:ffff880226fced40 n:ffff8802271ced40 .G. > 5: ffff8802271ced40 l:ffff880226fced40 n: (null) ... > 6: ffff8802273ced40 l:ffff8802273ced40 n:ffff8802275ced40 N.. > 7: ffff8802275ced40 l:ffff8802273ced40 n: (null) N.. > rcu_show_nocb_setup(): rcu_bh nocb state: > 0: ffff8802267ceac0 l:ffff8802267ceac0 n:ffff8802269ceac0 ... > 1: ffff8802269ceac0 l:ffff8802267ceac0 n: (null) ... > 2: ffff880226bceac0 l:ffff880226bceac0 n:ffff880226dceac0 ... > 3: ffff880226dceac0 l:ffff880226bceac0 n: (null) ... > 4: ffff880226fceac0 l:ffff880226fceac0 n:ffff8802271ceac0 ... > 5: ffff8802271ceac0 l:ffff880226fceac0 n: (null) ... > 6: ffff8802273ceac0 l:ffff8802273ceac0 n:ffff8802275ceac0 ... > 7: ffff8802275ceac0 l:ffff8802273ceac0 n: (null) ... > > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > rcu: Dump no-CBs CPU state at task-hung time > > > > Strictly diagnostic commit for rcu_barrier() hang. Not for inclusion. > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h > > index 0e5366200154..34048140577b 100644 > > --- a/include/linux/rcutiny.h > > +++ b/include/linux/rcutiny.h > > @@ -157,4 +157,8 @@ static inline bool rcu_is_watching(void) > > > > #endif /* #else defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */ > > > > +static inline void rcu_show_nocb_setup(void) > > +{ > > +} > > + > > #endif /* __LINUX_RCUTINY_H */ > > diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h > > index 52953790dcca..0b813bdb971b 100644 > > --- a/include/linux/rcutree.h > > +++ b/include/linux/rcutree.h > > @@ -97,4 +97,6 @@ extern int rcu_scheduler_active __read_mostly; > > > > bool rcu_is_watching(void); > > > > +void rcu_show_nocb_setup(void); > > + > > #endif /* __LINUX_RCUTREE_H */ > > diff --git a/kernel/hung_task.c b/kernel/hung_task.c > > index 06db12434d72..e6e4d0f6b063 100644 > > --- a/kernel/hung_task.c > > +++ b/kernel/hung_task.c > > @@ -118,6 +118,7 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout) > > " disables this message.\n"); > > sched_show_task(t); > > debug_show_held_locks(t); > > + rcu_show_nocb_setup(); > > > > touch_nmi_watchdog(); > > > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c > > index 240fa9094f83..6b373e79ce0e 100644 > > --- a/kernel/rcu/rcutorture.c > > +++ b/kernel/rcu/rcutorture.c > > @@ -1513,6 +1513,7 @@ rcu_torture_cleanup(void) > > { > > int i; > > > > + rcu_show_nocb_setup(); > > rcutorture_record_test_transition(); > > if (torture_cleanup_begin()) { > > if (cur_ops->cb_barrier != NULL) > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > index 927c17b081c7..285b3f6fb229 100644 > > --- a/kernel/rcu/tree_plugin.h > > +++ b/kernel/rcu/tree_plugin.h > > @@ -2699,6 +2699,31 @@ static bool init_nocb_callback_list(struct rcu_data *rdp) > > > > #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ > > > > +void rcu_show_nocb_setup(void) > > +{ > > +#ifdef CONFIG_RCU_NOCB_CPU > > + int cpu; > > + struct rcu_data *rdp; > > + struct rcu_state *rsp; > > + > > + for_each_rcu_flavor(rsp) { > > + pr_alert("rcu_show_nocb_setup(): %s nocb state:\n", rsp->name); > > + for_each_possible_cpu(cpu) { > > + if (!rcu_is_nocb_cpu(cpu)) > > + continue; > > + rdp = per_cpu_ptr(rsp->rda, cpu); > > + pr_alert("%3d: %p l:%p n:%p %c%c%c\n", > > + cpu, > > + rdp, rdp->nocb_leader, rdp->nocb_next_follower, > > + ".N"[!!rdp->nocb_head], > > + ".G"[!!rdp->nocb_gp_head], > > + ".F"[!!rdp->nocb_follower_head]); > > + } > > + } > > +#endif /* #ifdef CONFIG_RCU_NOCB_CPU */ > > +} > > +EXPORT_SYMBOL_GPL(rcu_show_nocb_setup); > > + > > /* > > * An adaptive-ticks CPU can potentially execute in kernel mode for an > > * arbitrarily long period of time with the scheduling-clock tick turned > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:37 ` Cong Wang 2014-10-22 17:49 ` Josh Boyer 2014-10-22 17:53 ` Eric W. Biederman @ 2014-10-22 17:59 ` Paul E. McKenney 2014-10-22 18:03 ` Josh Boyer 2 siblings, 1 reply; 63+ messages in thread From: Paul E. McKenney @ 2014-10-22 17:59 UTC (permalink / raw) To: Cong Wang Cc: Josh Boyer, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, Eric W. Biederman On Wed, Oct 22, 2014 at 10:37:53AM -0700, Cong Wang wrote: > (Adding Paul and Eric in Cc) > > I am not aware of any change in net/core/dev.c related here, > so I guess it's a bug in rcu_barrier(). > > Thanks. Does commit 789cbbeca4e (workqueue: Add quiescent state between work items) and 3e28e3772 (workqueue: Use cond_resched_rcu_qs macro) help this? Thanx, Paul > On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: > > > > Someone else is seeing this when they try and modprobe ppp_generic: > > > > [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. > > [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > > [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables this message. > > [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 > > [ 240.599744] Workqueue: netns cleanup_net > > [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 > > 00000000001d5f00 > > [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 > > ffff8802202db480 > > [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 > > ffffffff81ee2690 > > [ 240.600386] Call Trace: > > [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 > > [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 > > [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 > > [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 > > [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 > > [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 > > [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 > > [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 > > [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 > > [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 > > [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 > > [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 > > [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 > > [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 > > [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 > > [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 > > [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 > > [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 > > [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 > > [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 > > [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 > > [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 > > [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > > [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 > > [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 > > [ 240.603224] 4 locks held by kworker/u16:5/100: > > [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] > > process_one_work+0x17f/0x850 > > [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: > > [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 > > [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] > > cleanup_net+0x8c/0x1f0 > > [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: > > [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 > > [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. > > [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > > [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables this message. > > [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 > > [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 > > 00000000001d5f00 > > [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 > > ffff8800cb4f1a40 > > [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 > > ffff8800cb4f1a40 > > [ 240.605228] Call Trace: > > [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > > [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > > [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > > [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 > > [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 > > [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 > > [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] > > [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > > [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > > [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > > [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > > [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > > [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > > [ 240.606773] 1 lock held by modprobe/1387: > > [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] > > register_pernet_subsys+0x1f/0x50 > > [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. > > [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 > > [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables this message. > > [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 > > [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 > > 00000000001d5f00 > > [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 > > ffff88020fbab480 > > [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 > > ffff88020fbab480 > > [ 240.608138] Call Trace: > > [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 > > [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 > > [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > > [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 > > [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 > > [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 > > [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] > > [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 > > [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 > > [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 > > [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 > > [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 > > [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 > > [ 240.609677] 1 lock held by modprobe/1466: > > [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] > > register_pernet_device+0x1d/0x70 > > > > Looks like contention on net_mutex or something, but I honestly have > > no idea yet. I can't recreate it myself at the moment or I would > > bisect. > > > > Has nobody else run into this with the pre-3.18 kernels? Fedora isn't > > carrying any patches in this area. > > > > josh > > -- > > To unsubscribe from this list: send the line "unsubscribe netdev" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: localed stuck in recent 3.18 git in copy_net_ns? 2014-10-22 17:59 ` Paul E. McKenney @ 2014-10-22 18:03 ` Josh Boyer 0 siblings, 0 replies; 63+ messages in thread From: Josh Boyer @ 2014-10-22 18:03 UTC (permalink / raw) To: Paul McKenney Cc: Cong Wang, Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, Eric W. Biederman On Wed, Oct 22, 2014 at 1:59 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Oct 22, 2014 at 10:37:53AM -0700, Cong Wang wrote: >> (Adding Paul and Eric in Cc) >> >> I am not aware of any change in net/core/dev.c related here, >> so I guess it's a bug in rcu_barrier(). >> >> Thanks. > > Does commit 789cbbeca4e (workqueue: Add quiescent state between work items) > and 3e28e3772 (workqueue: Use cond_resched_rcu_qs macro) help this? I don't believe so. The output below is from a post 3.18-rc1 kernel (Linux v3.18-rc1-221-gc3351dfabf5c to be exact), and both of those commits are included in that if I'm reading the git output correctly. josh >> On Wed, Oct 22, 2014 at 10:12 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote: >> > >> > Someone else is seeing this when they try and modprobe ppp_generic: >> > >> > [ 240.599195] INFO: task kworker/u16:5:100 blocked for more than 120 seconds. >> > [ 240.599338] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> > [ 240.599446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> > disables this message. >> > [ 240.599583] kworker/u16:5 D ffff8802202db480 12400 100 2 0x00000000 >> > [ 240.599744] Workqueue: netns cleanup_net >> > [ 240.599823] ffff8802202eb9e8 0000000000000096 ffff8802202db480 >> > 00000000001d5f00 >> > [ 240.600066] ffff8802202ebfd8 00000000001d5f00 ffff8800368c3480 >> > ffff8802202db480 >> > [ 240.600228] ffffffff81ee2690 7fffffffffffffff ffffffff81ee2698 >> > ffffffff81ee2690 >> > [ 240.600386] Call Trace: >> > [ 240.600445] [<ffffffff8185e239>] schedule+0x29/0x70 >> > [ 240.600541] [<ffffffff8186345c>] schedule_timeout+0x26c/0x410 >> > [ 240.600651] [<ffffffff81865ef7>] ? retint_restore_args+0x13/0x13 >> > [ 240.600765] [<ffffffff818644e4>] ? _raw_spin_unlock_irq+0x34/0x50 >> > [ 240.600879] [<ffffffff8185fc6c>] wait_for_completion+0x10c/0x150 >> > [ 240.601025] [<ffffffff810e53e0>] ? wake_up_state+0x20/0x20 >> > [ 240.601133] [<ffffffff8112a749>] _rcu_barrier+0x159/0x200 >> > [ 240.601237] [<ffffffff8112a845>] rcu_barrier+0x15/0x20 >> > [ 240.601335] [<ffffffff81718ebf>] netdev_run_todo+0x6f/0x310 >> > [ 240.601442] [<ffffffff8170da85>] ? rollback_registered_many+0x265/0x2e0 >> > [ 240.601564] [<ffffffff81725f2e>] rtnl_unlock+0xe/0x10 >> > [ 240.601660] [<ffffffff8170f8e6>] default_device_exit_batch+0x156/0x180 >> > [ 240.601781] [<ffffffff810fd8a0>] ? abort_exclusive_wait+0xb0/0xb0 >> > [ 240.601895] [<ffffffff81707993>] ops_exit_list.isra.1+0x53/0x60 >> > [ 240.602028] [<ffffffff81708540>] cleanup_net+0x100/0x1f0 >> > [ 240.602131] [<ffffffff810ccfa8>] process_one_work+0x218/0x850 >> > [ 240.602241] [<ffffffff810ccf0f>] ? process_one_work+0x17f/0x850 >> > [ 240.602350] [<ffffffff810cd6c7>] ? worker_thread+0xe7/0x4a0 >> > [ 240.602454] [<ffffffff810cd64b>] worker_thread+0x6b/0x4a0 >> > [ 240.602555] [<ffffffff810cd5e0>] ? process_one_work+0x850/0x850 >> > [ 240.602665] [<ffffffff810d399b>] kthread+0x10b/0x130 >> > [ 240.602762] [<ffffffff81028cc9>] ? sched_clock+0x9/0x10 >> > [ 240.602862] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> > [ 240.603004] [<ffffffff818651fc>] ret_from_fork+0x7c/0xb0 >> > [ 240.603106] [<ffffffff810d3890>] ? kthread_create_on_node+0x250/0x250 >> > [ 240.603224] 4 locks held by kworker/u16:5/100: >> > [ 240.603304] #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810ccf0f>] >> > process_one_work+0x17f/0x850 >> > [ 240.603495] #1: (net_cleanup_work){+.+.+.}, at: >> > [<ffffffff810ccf0f>] process_one_work+0x17f/0x850 >> > [ 240.603691] #2: (net_mutex){+.+.+.}, at: [<ffffffff817084cc>] >> > cleanup_net+0x8c/0x1f0 >> > [ 240.603869] #3: (rcu_sched_state.barrier_mutex){+.+...}, at: >> > [<ffffffff8112a625>] _rcu_barrier+0x35/0x200 >> > [ 240.604211] INFO: task modprobe:1387 blocked for more than 120 seconds. >> > [ 240.604329] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> > [ 240.604434] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> > disables this message. >> > [ 240.604570] modprobe D ffff8800cb4f1a40 13112 1387 1386 0x00000080 >> > [ 240.604719] ffff8800cafbbbe8 0000000000000096 ffff8800cb4f1a40 >> > 00000000001d5f00 >> > [ 240.604878] ffff8800cafbbfd8 00000000001d5f00 ffff880223280000 >> > ffff8800cb4f1a40 >> > [ 240.605068] ffff8800cb4f1a40 ffffffff81f8fb48 0000000000000246 >> > ffff8800cb4f1a40 >> > [ 240.605228] Call Trace: >> > [ 240.605283] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> > [ 240.605400] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> > [ 240.605510] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> > [ 240.605626] [<ffffffff8170835f>] ? register_pernet_subsys+0x1f/0x50 >> > [ 240.605757] [<ffffffffa0701000>] ? 0xffffffffa0701000 >> > [ 240.605854] [<ffffffff8170835f>] register_pernet_subsys+0x1f/0x50 >> > [ 240.606005] [<ffffffffa0701048>] br_init+0x48/0xd3 [bridge] >> > [ 240.606112] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> > [ 240.606224] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> > [ 240.606327] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> > [ 240.606433] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> > [ 240.606557] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> > [ 240.606664] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> > [ 240.606773] 1 lock held by modprobe/1387: >> > [ 240.606845] #0: (net_mutex){+.+.+.}, at: [<ffffffff8170835f>] >> > register_pernet_subsys+0x1f/0x50 >> > [ 240.607114] INFO: task modprobe:1466 blocked for more than 120 seconds. >> > [ 240.607231] Not tainted 3.18.0-0.rc1.git2.1.fc22.x86_64 #1 >> > [ 240.607337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> > disables this message. >> > [ 240.607473] modprobe D ffff88020fbab480 13096 1466 1399 0x00000084 >> > [ 240.607622] ffff88020d1bbbe8 0000000000000096 ffff88020fbab480 >> > 00000000001d5f00 >> > [ 240.607791] ffff88020d1bbfd8 00000000001d5f00 ffffffff81e1b580 >> > ffff88020fbab480 >> > [ 240.607949] ffff88020fbab480 ffffffff81f8fb48 0000000000000246 >> > ffff88020fbab480 >> > [ 240.608138] Call Trace: >> > [ 240.608193] [<ffffffff8185e7e1>] schedule_preempt_disabled+0x31/0x80 >> > [ 240.608316] [<ffffffff81860033>] mutex_lock_nested+0x183/0x440 >> > [ 240.608425] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> > [ 240.608542] [<ffffffff817083ad>] ? register_pernet_device+0x1d/0x70 >> > [ 240.608662] [<ffffffffa071d000>] ? 0xffffffffa071d000 >> > [ 240.608759] [<ffffffff817083ad>] register_pernet_device+0x1d/0x70 >> > [ 240.608881] [<ffffffffa071d020>] ppp_init+0x20/0x1000 [ppp_generic] >> > [ 240.609021] [<ffffffff81002148>] do_one_initcall+0xd8/0x210 >> > [ 240.609131] [<ffffffff81153c02>] load_module+0x20c2/0x2870 >> > [ 240.609235] [<ffffffff8114ebe0>] ? store_uevent+0x70/0x70 >> > [ 240.609339] [<ffffffff8110ac26>] ? lock_release_non_nested+0x3c6/0x3d0 >> > [ 240.609462] [<ffffffff81154497>] SyS_init_module+0xe7/0x140 >> > [ 240.609568] [<ffffffff818652a9>] system_call_fastpath+0x12/0x17 >> > [ 240.609677] 1 lock held by modprobe/1466: >> > [ 240.609749] #0: (net_mutex){+.+.+.}, at: [<ffffffff817083ad>] >> > register_pernet_device+0x1d/0x70 >> > >> > Looks like contention on net_mutex or something, but I honestly have >> > no idea yet. I can't recreate it myself at the moment or I would >> > bisect. >> > >> > Has nobody else run into this with the pre-3.18 kernels? Fedora isn't >> > carrying any patches in this area. >> > >> > josh >> > -- >> > To unsubscribe from this list: send the line "unsubscribe netdev" in >> > the body of a message to majordomo@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2014-10-28 16:15 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-20 20:15 localed stuck in recent 3.18 git in copy_net_ns? Kevin Fenzi
2014-10-20 20:43 ` Dave Jones
2014-10-20 20:53 ` Kevin Fenzi
2014-10-21 21:12 ` Kevin Fenzi
2014-10-22 17:12 ` Josh Boyer
2014-10-22 17:37 ` Cong Wang
2014-10-22 17:49 ` Josh Boyer
2014-10-22 17:53 ` Eric W. Biederman
2014-10-22 18:11 ` Paul E. McKenney
2014-10-22 18:25 ` Eric W. Biederman
2014-10-22 18:55 ` Paul E. McKenney
2014-10-22 19:33 ` Josh Boyer
2014-10-22 22:40 ` Yanko Kaneti
2014-10-22 23:24 ` Paul E. McKenney
2014-10-23 6:09 ` Yanko Kaneti
2014-10-23 12:27 ` Paul E. McKenney
2014-10-23 15:33 ` Paul E. McKenney
[not found] ` <CA+5PVA4H6EAf6cBc4a_8W8x4Mgppjc5GsskKaCRry2jq+LP+FA@mail.gmail.com>
2014-10-23 16:28 ` Paul E. McKenney
2014-10-23 19:51 ` Yanko Kaneti
2014-10-23 20:05 ` Paul E. McKenney
2014-10-23 21:45 ` Yanko Kaneti
2014-10-23 22:04 ` Paul E. McKenney
2014-10-24 4:48 ` Jay Vosburgh
2014-10-24 14:50 ` Paul E. McKenney
2014-10-24 18:20 ` Jay Vosburgh
2014-10-24 18:33 ` Paul E. McKenney
2014-10-24 9:08 ` Yanko Kaneti
2014-10-24 15:40 ` Paul E. McKenney
2014-10-24 16:29 ` Yanko Kaneti
2014-10-24 16:54 ` Paul E. McKenney
2014-10-24 17:09 ` Yanko Kaneti
2014-10-24 17:20 ` Paul E. McKenney
2014-10-24 17:35 ` Yanko Kaneti
2014-10-24 18:32 ` Paul E. McKenney
2014-10-24 18:49 ` Jay Vosburgh
2014-10-24 18:57 ` Paul E. McKenney
2014-10-24 20:15 ` Paul E. McKenney
2014-10-24 21:25 ` Yanko Kaneti
2014-10-24 21:49 ` Paul E. McKenney
2014-10-24 22:02 ` Jay Vosburgh
2014-10-24 22:16 ` Paul E. McKenney
2014-10-24 22:41 ` Jay Vosburgh
2014-10-24 22:34 ` Jay Vosburgh
2014-10-24 22:59 ` Paul E. McKenney
2014-10-24 23:05 ` Paul E. McKenney
2014-10-25 0:20 ` Jay Vosburgh
2014-10-25 2:03 ` Paul E. McKenney
2014-10-25 4:33 ` Jay Vosburgh
2014-10-25 5:16 ` Paul E. McKenney
2014-10-25 16:38 ` Jay Vosburgh
2014-10-25 18:18 ` Paul E. McKenney
2014-10-27 17:45 ` Paul E. McKenney
2014-10-27 20:43 ` Jay Vosburgh
2014-10-27 21:07 ` Paul E. McKenney
2014-10-28 8:12 ` Yanko Kaneti
2014-10-28 12:50 ` Paul E. McKenney
2014-10-28 13:00 ` Yanko Kaneti
2014-10-28 15:54 ` Kevin Fenzi
2014-10-28 16:15 ` Paul E. McKenney
2014-10-25 12:09 ` Yanko Kaneti
2014-10-25 13:38 ` Paul E. McKenney
2014-10-22 17:59 ` Paul E. McKenney
2014-10-22 18:03 ` Josh Boyer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).