From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) Subject: Re: try_module_get and friends Date: Wed, 05 Mar 2008 15:46:59 -0500 Message-ID: References: <1204608058.11912.3.camel@perihelion> <1204608506.11912.9.camel@perihelion> <1204661228.8244.15.camel@jcmlaptop> <1204745455.17630.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Daniel Walker , Jon Masters , linux-rt-users , Ingo Molnar , Thomas Gleixner To: Steven Rostedt Return-path: Received: from mx1.redhat.com ([66.187.233.31]:46348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758459AbYCEUwr (ORCPT ); Wed, 5 Mar 2008 15:52:47 -0500 In-Reply-To: (Steven Rostedt's message of "Wed, 5 Mar 2008 14:47:28 -0500 (EST)") Sender: linux-rt-users-owner@vger.kernel.org List-ID: Steven Rostedt writes: > [...] > There's a theoretical potential for the system to crash in -rt when > unloading a module. Simply because interrupts are threads. > > Some device has an interrupt handler that is called and preempted. > At that moment the module for that device is unloaded. [...] > Since the code for the interrupt handler no longer exists... KABOOM! Perhaps you can identify those modules that have asked for interrupts, and block only them from unloading. Or, would it be outrageously expensive to increment the module refcount while one of its interrupt handlers is running? - FChE