Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Oct 2002 11:22:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Oct 2002 11:22:25 -0400 Received: from dsl-213-023-038-160.arcor-ip.net ([213.23.38.160]:35987 "EHLO starship") by vger.kernel.org with ESMTP id ; Tue, 15 Oct 2002 11:22:14 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Rusty Russell Subject: Re: [PATCH] In-kernel module loader 1/7 Date: Tue, 15 Oct 2002 17:28:33 +0200 X-Mailer: KMail [version 1.3.2] Cc: Roman Zippel , Rusty Russell , linux-kernel@vger.kernel.org References: <20021015052656.5ED272C18E@lists.samba.org> In-Reply-To: <20021015052656.5ED272C18E@lists.samba.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 43 On Tuesday 15 October 2002 05:25, Rusty Russell wrote: > In message you write: > > Not being able to unload LSM would suck enormously. At last count, we > > knew how to do this: > > > > 1) Unhook the function hooks (using a call table simplifies this) > > 2) Schedule on each CPU to ensure all tasks are out of the module > > 3) A schedule where the module count is incremented doesn't count > > > > and we rely on the rule that and module code that could sleep must be > > bracketed by inc/dec of the module count. > > > > Did somebody come up with a reason why this will not work? > > It won't quite work if the hooks can sleep. You can say "don't sleep" > or have a wedge which does the "try_inc_mod_count()" then calls into > the module (and returns some default if it can't inc the module count). Right. By coincidence, I found myself thinking about this very problem as I re-materialized this morning. If TRY_INC_MOD_COUNT also ors a flag (which it does now, for other reasons) then: 1) Clear the mod_inc flag 2) Unhook the function hooks 3) Schedule on each CPU 4) If the mod_inc flag is set, repeat from (1) This should perform acceptably well, and would only be done in cases where the existing TRY_INC_MOD_COUNT strategy can't be used. > You can't disable preemption before calling in, because there is no > way to sleep with preemption disabled. 8( Why is that harder than bumping a counter that makes preempt_schedule return without doing anything? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/