Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 17 Oct 2002 13:14:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 17 Oct 2002 13:14:12 -0400 Received: from dsl-212-144-194-127.arcor-ip.net ([212.144.194.127]:51111 "EHLO starship") by vger.kernel.org with ESMTP id ; Thu, 17 Oct 2002 13:13:42 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Rusty Russell , S@samba.org Subject: Re: [RFC] change format of LSM hooks Date: Thu, 17 Oct 2002 19:20:10 +0200 X-Mailer: KMail [version 1.3.2] Cc: Roman Zippel , linux-kernel@vger.kernel.org References: <20021017075539.8DE762C0CA@lists.samba.org> In-Reply-To: <20021017075539.8DE762C0CA@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: 4138 Lines: 93 On Thursday 17 October 2002 09:41, Rusty Russell wrote: > In message you write: > > On Thursday 17 October 2002 00:48, Rusty Russell wrote: > > > > On Wednesday 16 October 2002 08:11, Rusty Russell wrote: > > > > > It needs to be turned off when dealing with any interface which > > > > > might be used by one of the hard modules. Which is pretty bad. > > > > > > > > As far as I can see, preemption only has to be disabled during the > > > > synchronize_kernel phase of unloading that one module, and this > > > > requirement is inherited neither by dependant or depending modules. > > > > > > No, someone could already have been preempted before you start > > > synchronize_kernel(). > > > > I don't get that. The sequence is: > > > > - turn off preemption > > - unhook call points > > - synchronize_kernel > > - ... > > > > which doesn't leave any preemption hole that I can see, so I can't comment > > on a couple of the other points until you clear that one up. > > You mean that "turn off preemption" also wakes up anyone currently > preempted? Otherwise they're preempted just inside one of those call > points. Urk, yes, or just those preempted in kernel. Which looks doable and not intrusive, modulo my limited scheduler knowledge. So synchronize_kernel isn't dead yet, though it just got a new flesh wound. > > > Still a race between the zero check and the can't-increment state > > > setting. > > > > But that one is easy: the zero check just takes the same spinlock as > > TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count > > is zero, considerably simpler than: > > The current spinlock is horrible. Is it? You must be thinking about much more intensive use of the spinlock as with per-op calls as opposed to per-attach (mount). I'd planned to make the spinlocks per-module, but your per-cpu code looks just fine. > > ...The still-initializing case is also easy, e.g., a filesystem module > > simply doesn't call register_filesystem until it's completely ready to > > service calls, so nobody is able to do TRY_INC_MOD_COUNT. > > Consider some code which needs to know when cpus go up and down, so > registers a notifier. If the notifier fires before the init is > finished, the notifier code will fail to "try_inc_mod_count()" and > won't call it (it doesn't do try_inc_mod_count at the moment, but > that's a bug). > > I don't know of any code which does this now, but it is at least a > theoretical problem. To resolve this, start the module in can-increment state, do the module initialization, register the notifiers, and finally register the interface. In other words, the module never needs to be in can't-increment state at initialization. (The module writer must ensure they have the correct, raceless initial state of whatever the notifiers are notifying about, which strikes me as a little tricky in itself.) > IMHO, the benifits of having it in-kernel outweigh the slight extra > size. I'll cast my vote for your in-kernel linker, in the mistaken belief that democracy has anything to do with the question. Does this make progress towards eliminating one of create_module or init_module? > > > ...The second is the "die-mother-fucker-die" > > > version, which taints the kernel and just removes the damn thing. For > > > most people, this is better than a reboot, and will usually "work". > > > > Is there a case where removing a module would actually help? What is > > the user going to do next, try to reinsert the same module? > > Insert a fixed one, hopefully 8). I'd use this feature in filesystem development, regardless of the risks, since I regularly do worse things to the kernel anyway. But don't you think the rmmod parameter should be different for the ask-nicely vs the shoot-in-the-head flavor? How about -f -f or -F for the latter? -- 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/