From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932455AbdJ0TnN (ORCPT ); Fri, 27 Oct 2017 15:43:13 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35985 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbdJ0TnK (ORCPT ); Fri, 27 Oct 2017 15:43:10 -0400 Date: Fri, 27 Oct 2017 21:43:02 +0200 (CEST) From: Thomas Gleixner To: Abderrahmane Benbachir cc: David Daney , linux-kernel@vger.kernel.org, mingo@kernel.org, akpm@linux-foundation.org, keescook@chromium.org, jeyu@redhat.com, rostedt@goodmis.org, mhocko@suse.com, viresh.kumar@linaro.org, thomas.lendacky@amd.com Subject: Re: [PATCH] init/main.c: check for null pointer before calling initcall In-Reply-To: <20171027185340.Horde.lrfWRcBHRmhKk906QJGixBF@www.imp.polymtl.ca> Message-ID: References: <1509122847.11787.5.camel@polymtl.ca> <7fc6e471-3ff9-83ea-f0c8-638959395494@caviumnetworks.com> <20171027185340.Horde.lrfWRcBHRmhKk906QJGixBF@www.imp.polymtl.ca> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-201661391-1509133383=:1922" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-201661391-1509133383=:1922 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Fri, 27 Oct 2017, Abderrahmane Benbachir wrote: > David Daney a écrit : > > > On 10/27/2017 11:22 AM, Thomas Gleixner wrote: > > > On Fri, 27 Oct 2017, David Daney wrote: > > > > > > > On 10/27/2017 09:47 AM, Abderrahmane Benbachir wrote: > > > > > Simple check to prevent kernel panic when initcall does not exit > > > > > > > > Interesting, under what circumstances do you observe the panic? > > > > > > > > It would be best to include this information in the patch changelog. > > > > > > device_initcall(NULL); > > > > > > might do that, but then it rightfully crashes on boot. > > > > > > > That was kind of my point. The module loader case already checks for a > > non-NULL pointer, and any NULLs in the in-kernel initializer tables would > > indicate a bigger problem that should be fixed instead. > > > > David Daney > > But this code can still be written : > > static initcall_t __initcall_mymod \ > __used __section(".initcall6.init") = NULL; You can write that, but it's simply wrong and abusing the initcall system. As I said, the system rightfully crashes. There are sane ways to do conditional initialization from within a fixed initcall. Thanks, tglx --8323329-201661391-1509133383=:1922--