Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp450637ybl; Wed, 4 Dec 2019 05:33:44 -0800 (PST) X-Google-Smtp-Source: APXvYqx0HJjeyCcesGT1AIqjYLtA0/2c614WsO5o5I7pH4oRwPOTC4ZjT373xzSr7J9Z7HnHkXu8 X-Received: by 2002:a9d:53c2:: with SMTP id i2mr2262569oth.43.1575466424623; Wed, 04 Dec 2019 05:33:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575466424; cv=none; d=google.com; s=arc-20160816; b=xO4kFKo4DeZYnD5vDu68sJDGUP4yW/S5rf/Wf4oWTQm0VTxa7CrbkjHxjsHJqgMZg9 3PPqUK4mPjURXJfDtmyBhJX48i2qumulk67RqT8vvAOsJJmao85UnsLIVzsjbOYhckil AZgFp85gO6XFyD6/+dq3OtMQb0ujvAOwJB3krgUB7M8oXw4J9BNkq1DTSSre6Uznj9N4 d9HTT7HvmX8uXE4rU+qwPLnMRKaKXXu2owhyusL66hhxKAuQ6HJLYakAcTJ7+3rVaqhP BseA4hgTmNXm1xJ8mGdlrWBGqTWbNfCKPEtvI4CepWNLJzu+fQMQUWBxwf+xyWkjGRMq JGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dwJfQgYyCjxLN/r3NHPdPWSJtUOOmcZPCOc5Cay3OZA=; b=tg0eY4C5m6nCOEJxDjml7l/XnFscl4RYePFfxMtKrWOdJFizczBPjlthFjKXZwDjRr iPI+pgVRBmEeSwxX48t2lKtuAR7CR7SOmqtYwu8SPPoSXp8SwLSEOfweblup/wk387VV DvxZ0bVoUnF6/k1l5+JzPa5DhyBb7R1Z6A1awcdugimKH1DYBoHFGWMbTda6Mw0KbESu QtQVg1AyHofdp4Xy2u1DImWDOsjnMgNrJu/ckvOVhTGaqvtASinNu/VRaD7UkUBsKH2n sDgB1i23rotyuwvHAbUjAuBBr1d/SmG8+RcPbDsuKusRYESwvuWYdJwtpeu+SkD61o7l zm6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 90si3217718otv.13.2019.12.04.05.33.30; Wed, 04 Dec 2019 05:33:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727910AbfLDNca (ORCPT + 99 others); Wed, 4 Dec 2019 08:32:30 -0500 Received: from foss.arm.com ([217.140.110.172]:55918 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727798AbfLDNca (ORCPT ); Wed, 4 Dec 2019 08:32:30 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2781B1FB; Wed, 4 Dec 2019 05:32:29 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBA633F68E; Wed, 4 Dec 2019 05:32:27 -0800 (PST) Date: Wed, 4 Dec 2019 13:32:25 +0000 From: Qais Yousef To: Vincent Guittot Cc: Valentin Schneider , John Stultz , Quentin Perret , Peter Zijlstra , Dietmar Eggemann , Juri Lelli , Patrick Bellasi , Ingo Molnar , lkml Subject: Re: Null pointer crash at find_idlest_group on db845c w/ linus/master Message-ID: <20191204133224.uiqbkbpseree7xou@e107158-lin.cambridge.arm.com> References: <20191204094216.u7yld5r3zelp22lf@e107158-lin.cambridge.arm.com> <20191204100925.GA15727@linaro.org> <629cca09-dde7-5d77-42e1-c68f2c1820d2@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/04/19 13:08, Vincent Guittot wrote: > On Wed, 4 Dec 2019 at 11:41, Valentin Schneider > wrote: > > > > On 04/12/2019 10:09, Vincent Guittot wrote: > > > Now, we test that a group has at least one allowed CPU for the task so we > > > could skip the local group with the correct/wrong p->cpus_ptr > > > > > > The path is used for fork/exec ibut also for wakeup path for b.L when the task doesn't fit in the CPUs > > > > > > So we can probably imagine a scenario where we change task affinity while > > > sleeping. If the wakeup happens on a CPU that belongs to the group that is not > > > allowed, we can imagine that we skip the local_group > > > > > > > Shoot, I think you're right. If it is the local group that is NULL, then > > we most likely splat on: > > > > if (local->sgc->max_capacity >= idlest->sgc->max_capacity) > > return NULL; > > > > We don't splat before because we just use local_sgs, which is uninitialized > > but on the stack. > > > > Also; does it really have to involve an affinity "race"? AFAIU affinity > > could have been changed a while back, but the waking CPU isn't allowed > > so we skip the local_group (in simpler cases where each CPU is a group). > > In fact, this will depend of the uninitialized values of local_sgs. I > have been able to reproduce the situation where we skip local group > but not to trigger the crash because the values already in the stack > don't trigger the misfit comparison. Will it be expensive to initialize local_sgs = {0}? -- Qais Yousef