Date:   Thu, 9 Dec 2021 10:25:15 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Jiasheng Jiang <jiasheng@iscas.ac.cn>
Cc:     mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
        vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
        bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/uclamp: potential dereference of null pointer
Message-ID: <20211209102515.3f5af7f5@gandalf.local.home>
In-Reply-To: <20211209102313.1360b39b@gandalf.local.home>
References: <20211209033127.2051504-1-jiasheng@iscas.ac.cn>
        <20211209102313.1360b39b@gandalf.local.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 9 Dec 2021 10:23:13 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -8125,6 +8125,8 @@ void __init sched_init(void)
> >  #endif
> >  	if (ptr) {
> >  		ptr = (unsigned long)kzalloc(ptr, GFP_NOWAIT);
> > +		if (!ptr)
> > +			return;  
> 
> If this were to happen the system would crash immediately, with or without
> the return.
> 
> If you are worried about not being able to allocate ptr, then the only
> reasonable fix here is
> 
> 		BUG_ON(!ptr);
> 
> That way you would know exactly why your system crashed. Because just
> returning would crash for other reasons and make it less debuggable.

And this is not worth the churn (because if it failed to allocate, you have
bigger problems to deal with).

So NAK on this change.

-- Steve