From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 23 11:56:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD839106566C for ; Tue, 23 Aug 2011 11:56:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8404C8FC08 for ; Tue, 23 Aug 2011 11:56:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 368D046B98; Tue, 23 Aug 2011 07:56:28 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B56A28A02E; Tue, 23 Aug 2011 07:56:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 23 Aug 2011 07:56:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108230756.27259.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 23 Aug 2011 07:56:27 -0400 (EDT) Cc: Garrett Cooper , Sergey Kandaurov Subject: Re: module_register_init fails, but driver is still loaded? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:56:28 -0000 On Thursday, August 04, 2011 12:23:15 pm Garrett Cooper wrote: > Hi hackers, > I noticed that if anything fails while initializing a driver, the > driver stays attached to the kernel as a module instead of being > kicked when all references to the driver go to 0. Is this desired > behavior (it doesn't seem like it, but I can see potential pros and > cons of kicking the driver out of the kernel immediately when a > failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example > sourcecode and invocation attached below. This is sort of a feature actually. Consider the hard cases avg@ mentioned such as a kld that contains multiple modules. What one could possibly do is notice that all modules failed MOD_LOAD and do an unload in that case. This untested patch tries to do that: Index: kern_linker.c =================================================================== --- kern_linker.c (revision 225077) +++ kern_linker.c (working copy) @@ -378,7 +378,7 @@ linker_load_file(const char *filename, linker_file { linker_class_t lc; linker_file_t lf; - int foundfile, error; + int foundfile, error, modules; /* Refuse to load modules if securelevel raised */ if (prison0.pr_securelevel > 0) @@ -417,11 +417,22 @@ linker_load_file(const char *filename, linker_file linker_file_unload(lf, LINKER_UNLOAD_FORCE); return (error); } + modules = !TAILQ_EMPTY(&lf->modules); KLD_UNLOCK(); linker_file_register_sysctls(lf); linker_file_sysinit(lf); KLD_LOCK(); lf->flags |= LINKER_FILE_LINKED; + + /* + * If all of the modules in this file failed + * to load, unload the file and return an + * error of ENOEXEC. + */ + if (modules && TAILQ_EMPTY(&lf->modules)) { + linker_file_unload(lf, LINKER_UNLOAD_FORCE); + return (ENOEXEC); + } *result = lf; return (0); } @@ -625,7 +636,7 @@ linker_file_unload(linker_file_t file, int flags) /* * Inform any modules associated with this file that they are - * being be unloaded. + * being unloaded. */ MOD_XLOCK; for (mod = TAILQ_FIRST(&file->modules); mod; mod = next) { -- John Baldwin