{"push_id":615637230,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"5d605bd6c28e93a5498ef68ee7fd6a2620ee07ba","before":"00f5481596507bba41546066598618546b59c7a8","commits":[{"sha":"5d605bd6c28e93a5498ef68ee7fd6a2620ee07ba","author":{"email":"9b26f769475fafc2d25107053b1bdd774d49438a@jp.fujitsu.com","name":"Yasuaki Ishimatsu"},"message":"workqueue: zero cpumask of wq_numa_possible_cpumask on init\n\ncommit 5a6024f1604eef119cf3a6fa413fe0261a81a8f3 upstream.\n\nWhen hot-adding and onlining CPU, kernel panic occurs, showing following\ncall trace.\n\n  BUG: unable to handle kernel paging request at 0000000000001d08\n  IP: [<ffffffff8114acfd>] __alloc_pages_nodemask+0x9d/0xb10\n  PGD 0\n  Oops: 0000 [#1] SMP\n  ...\n  Call Trace:\n   [<ffffffff812b8745>] ? cpumask_next_and+0x35/0x50\n   [<ffffffff810a3283>] ? find_busiest_group+0x113/0x8f0\n   [<ffffffff81193bc9>] ? deactivate_slab+0x349/0x3c0\n   [<ffffffff811926f1>] new_slab+0x91/0x300\n   [<ffffffff815de95a>] __slab_alloc+0x2bb/0x482\n   [<ffffffff8105bc1c>] ? copy_process.part.25+0xfc/0x14c0\n   [<ffffffff810a3c78>] ? load_balance+0x218/0x890\n   [<ffffffff8101a679>] ? sched_clock+0x9/0x10\n   [<ffffffff81105ba9>] ? trace_clock_local+0x9/0x10\n   [<ffffffff81193d1c>] kmem_cache_alloc_node+0x8c/0x200\n   [<ffffffff8105bc1c>] copy_process.part.25+0xfc/0x14c0\n   [<ffffffff81114d0d>] ? trace_buffer_unlock_commit+0x4d/0x60\n   [<ffffffff81085a80>] ? kthread_create_on_node+0x140/0x140\n   [<ffffffff8105d0ec>] do_fork+0xbc/0x360\n   [<ffffffff8105d3b6>] kernel_thread+0x26/0x30\n   [<ffffffff81086652>] kthreadd+0x2c2/0x300\n   [<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60\n   [<ffffffff815f20ec>] ret_from_fork+0x7c/0xb0\n   [<ffffffff81086390>] ? kthread_create_on_cpu+0x60/0x60\n\nIn my investigation, I found the root cause is wq_numa_possible_cpumask.\nAll entries of wq_numa_possible_cpumask is allocated by\nalloc_cpumask_var_node(). And these entries are used without initializing.\nSo these entries have wrong value.\n\nWhen hot-adding and onlining CPU, wq_update_unbound_numa() is called.\nwq_update_unbound_numa() calls alloc_unbound_pwq(). And alloc_unbound_pwq()\ncalls get_unbound_pool(). In get_unbound_pool(), worker_pool->node is set\nas follow:\n\n3592         /* if cpumask is contained inside a NUMA node, we belong to that node */\n3593         if (wq_numa_enabled) {\n3594                 for_each_node(node) {\n3595                         if (cpumask_subset(pool->attrs->cpumask,\n3596                                            wq_numa_possible_cpumask[node])) {\n3597                                 pool->node = node;\n3598                                 break;\n3599                         }\n3600                 }\n3601         }\n\nBut wq_numa_possible_cpumask[node] does not have correct cpumask. So, wrong\nnode is selected. As a result, kernel panic occurs.\n\nBy this patch, all entries of wq_numa_possible_cpumask are allocated by\nzalloc_cpumask_var_node to initialize them. And the panic disappeared.\n\nSigned-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>\nReviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nFixes: bce903809ab3 (\"workqueue: add wq_numa_tbl_len and wq_numa_possible_cpumask[]\")\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/friedrich420/N4-AEL-KERNEL-LOLLIPOP/commits/5d605bd6c28e93a5498ef68ee7fd6a2620ee07ba"}]}