Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758892AbbLCI2I (ORCPT ); Thu, 3 Dec 2015 03:28:08 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:38604 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758800AbbLCI2E (ORCPT ); Thu, 3 Dec 2015 03:28:04 -0500 Date: Thu, 3 Dec 2015 09:28:00 +0100 From: Ingo Molnar To: Xunlei Pang Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Steven Rostedt Subject: Re: [PATCH] sched/core: Clear the root_domain cpumasks in init_rootdomain() Message-ID: <20151203082800.GA2321@gmail.com> References: <1449057179-29321-1-git-send-email-xlpang@redhat.com> <20151202123414.GB9928@worktop.ger.corp.intel.com> <565EEE3E.30301@redhat.com> <20151202162542.GT3816@twins.programming.kicks-ass.net> <565FAC78.3030205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565FAC78.3030205@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1625 Lines: 45 * Xunlei Pang wrote: > Hi Peter, > > On 12/03/2015 at 12:25 AM, Peter Zijlstra wrote: > > On Wed, Dec 02, 2015 at 09:12:30PM +0800, Xunlei Pang wrote: > >> Hi Peter, > >> > >> On 12/02/2015 at 08:34 PM, Peter Zijlstra wrote: > >>> On Wed, Dec 02, 2015 at 07:52:59PM +0800, Xunlei Pang wrote: > >>>> The patch cleans the garbage by using zalloc_cpumask_var() > >>>> instead of alloc_cpumask_var() for root_domain::rto_mask > >>>> allocation, thereby addressing the issues. > >>> How did you notice this? Also do we want to do the same for the kmalloc > >> When doing review. > > Nice, will you be looking for similar issues elsewhere in the scheduler > > too? > > Sure :-) Hm, is the alloc_cpumask_var() done in alloc_sched_domains() safe? At least the usage pattern in init_sched_domains() looks unsafe: doms_cur = alloc_sched_domains(ndoms_cur); if (!doms_cur) doms_cur = &fallback_doms; cpumask_andnot(doms_cur[0], cpu_map, cpu_isolated_map); I think alloc_cpumask_var() is a fundamentally unsafe or at least fragile operation, because the uninitialized variable bug will only happen on large CPU count kernels AFAICS - so it's inviting such bugs. How about we rename alloc_cpumask_var() to alloc_cpumask_var_noinit() or at least __alloc_cpumask_var(), to make this property easier to see? Thanks, Ingo -- 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/