From owner-freebsd-current@freebsd.org Wed Aug 2 16:51:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F0D0DD4E2C for ; Wed, 2 Aug 2017 16:51:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70FEF6C73F for ; Wed, 2 Aug 2017 16:51:01 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a4f2c083-77a2-11e7-bfd0-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id a4f2c083-77a2-11e7-bfd0-afd4446ba3af; Wed, 02 Aug 2017 16:50:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v72GnpWp006880; Wed, 2 Aug 2017 10:49:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1501692591.90400.142.camel@freebsd.org> Subject: Re: order of executing MOD_LOAD and registering module sysctl-s From: Ian Lepore To: John Baldwin , freebsd-current@freebsd.org Cc: Hans Petter Selasky , Andriy Gapon , FreeBSD Hackers Date: Wed, 02 Aug 2017 10:49:51 -0600 In-Reply-To: <2718016.8bPh6cqhGc@ralph.baldwin.cx> References: <62e7ab4d-8956-545e-b204-4fb63cfe5fbf@FreeBSD.org> <2718016.8bPh6cqhGc@ralph.baldwin.cx> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 16:51:01 -0000 On Wed, 2017-08-02 at 08:49 -0700, John Baldwin wrote: > On Wednesday, August 02, 2017 12:39:36 PM Hans Petter Selasky wrote: > > > > On 08/02/17 12:13, Andriy Gapon wrote: > > > > > > > > > As far as I understand a module initialization routine is > > > executed via the > > > sysinit mechanism.  Specifically, module_register_init is set up > > > as the sysinit > > > function for every module and it calls MOD_EVENT(mod, MOD_LOAD) > > > to invoke the > > > module event handler. > > > > > > In linker_load_file() I see the following code: > > >                          linker_file_register_sysctls(lf); > > >                          linker_file_sysinit(lf); > > > > > > I think that this means that any statically declared sysctl-s in > > > the module > > > would be registered before the module receives the MOD_LOAD > > > event. > > > It's possible that some of the sysctl-s could have procedures as > > > handlers and > > > they might access data that is supposed to be initialized by the > > > module event > > > handler. > > > > > > So, for example, running sysctl -a at just the right moment > > > during the loading > > > of a module might end up in an expected behavior (including a > > > crash). > > > > > > Is my interpretation of how the code works correct? > > > Can the order of linker_file_sysinit and > > > linker_file_register_sysctls be changed > > > without a great risk? > > > > > > Thank you! > > > > > > P.S. > > > The same applies to: > > >                  linker_file_sysuninit(file); > > >                  linker_file_unregister_sysctls(file); > > > > > Hi, > > > > Not sure if this answers your question. > > > > If a SYSCTL() is TUNABLE, it's procedure can be called when the > > sysctl  > > is created. Else the SYSCTL() procedure callback might be called > > right  > > after it's registered. I think there is an own subsystem in > > sys/kernel.h  > > which takes care of the actual SYSCTL() creation/destruction - > > after the  > > linker is involved. > sysctl nodes are created explicitly via linker_file_register_sysctls, > not via > SYSINITs, so you can't order them with respect to other init > functions. > > I think Andriy's suggestion of doing sysctls "inside" sysinits (so > they are > registered last and unregistered first) is probably better than the > current > state and is a simpler fix than changing all sysctls to use SYSINITs. > But if module sysctls are registered last then the ones flagged as CTLFLAG_TUN won't have their tunable values populated before the MOD_LOAD handler runs, is that going to cause trouble?  It would suck to have to handle things differently in a driver depending on whether you're compiled into the kernel or kldload'd interactively. -- Ian