From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752686AbcJOB0H (ORCPT ); Fri, 14 Oct 2016 21:26:07 -0400 Received: from mail-pa0-f67.google.com ([209.85.220.67]:33399 "EHLO mail-pa0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbcJOB0G (ORCPT ); Fri, 14 Oct 2016 21:26:06 -0400 Subject: Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot) To: Tejun Heo , Michael Ellerman References: <1473967821-24363-1-git-send-email-tj@kernel.org> <1473967821-24363-2-git-send-email-tj@kernel.org> <20160917172314.GB10771@mtj.duckdns.org> <87twck5wqo.fsf@concordia.ellerman.id.au> <20161010130253.GB29742@mtj.duckdns.org> <87a8eb5dwa.fsf@concordia.ellerman.id.au> <20161014150757.GA11102@mtj.duckdns.org> Cc: "linuxppc-dev@lists.ozlabs.org" , jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, kernel-team@fb.com From: Balbir Singh Message-ID: <6b395b55-03a8-38bc-8581-d310e6a0ef65@gmail.com> Date: Sat, 15 Oct 2016 12:25:50 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161014150757.GA11102@mtj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/10/16 02:07, Tejun Heo wrote: > Hello, Michael. > > On Tue, Oct 11, 2016 at 10:22:13PM +1100, Michael Ellerman wrote: >> The oops happens because we're in enqueue_task_fair() and p->se->cfs_rq >> is NULL. >> >> The cfs_rq is NULL because we did set_task_rq(p, 2048), where 2048 is >> NR_CPUS. That causes us to index past the end of the tg->cfs_rq array in >> set_task_rq() and happen to get NULL. >> >> We never should have done set_task_rq(p, 2048), because 2048 is >= >> nr_cpu_ids, which means it's not a valid CPU number, and set_task_rq() >> doesn't cope with that. > > Hmm... it doesn't reproduce it here and can't see how the commit would > affect this given that it doesn't really change when the kworker > kthreads are being created. > >> Presumably we shouldn't be ending up with tsk_cpus_allowed() being >> empty, but I haven't had time to track down why that's happening. > I think the basic analysis shows the change to creation of unbounded workqueues from the unbound_hash, but those have a pool cpumask empty. > Can you please add WARN_ON_ONCE(!tsk_nr_cpus_allowed(p)) to > select_task_rq() and post what that says? > > Thanks. > Balbir Singh.