From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 11 Sep 2002 17:22:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 11 Sep 2002 17:22:17 -0400 Received: from pc-62-30-255-50-az.blueyonder.co.uk ([62.30.255.50]:27311 "EHLO kushida.apsleyroad.org") by vger.kernel.org with ESMTP id ; Wed, 11 Sep 2002 17:22:16 -0400 Date: Wed, 11 Sep 2002 22:26:14 +0100 From: Jamie Lokier To: Daniel Phillips Cc: Oliver Neukum , Roman Zippel , Alexander Viro , Rusty Russell , linux-kernel@vger.kernel.org Subject: Re: [RFC] Raceless module interface Message-ID: <20020911222614.A12614@kushida.apsleyroad.org> References: <200209112229.11975.oliver@neukum.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from phillips@arcor.de on Wed, Sep 11, 2002 at 11:15:34PM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Daniel Phillips wrote: > Really, that's not so, there are limits. 30 seconds? Whatever. > Remember, during this time the service provided by the module is > unavailable, so this is denial-of-service land. You could of > course put in extra code to abort the unload process on demand, > but, hmm, it probably wouldn't work ;-) If you're going to do it right, you should fix that denial-of-service by waiting until the module has finished unloading and then demand-loading the module again. Ideally, those periodic "rmmod -a" calls should _never_ cause a denial-of-service. -- Jamie