Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Mar 2003 19:46:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Mar 2003 19:46:53 -0500 Received: from modemcable092.130-200-24.mtl.mc.videotron.ca ([24.200.130.92]:9222 "EHLO montezuma.mastecende.com") by vger.kernel.org with ESMTP id ; Wed, 12 Mar 2003 19:46:50 -0500 Date: Wed, 12 Mar 2003 19:54:28 -0500 (EST) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: Paul McKenney cc: David Miller , Linux Kernel Mailing List , "" , "" , Stephen Hemminger , Linus Torvalds Subject: Re: [PATCH] (1/8) Eliminate brlock in psnap In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1167 Lines: 30 On Wed, 12 Mar 2003, Paul McKenney wrote: > You are saying that we can omit locking because this is > called only from a module-exit function, and thus protected > by the module_mutex semaphore? (I must defer to > others who have a better handle on modules...) > > If in fact only one module-exit function can be > executing at a given time, then we should be able to > use the following approach: Yes the ->exit call is protected by module_mutex globally. > Module unloading should be rare enough to tolerate > the grace period under the module_mutex, right? > > Thoughts? I would agree. However can't unregister_snap_client be used in other paths apart from module_unload? I wouldn't worry too much since if register_snap_client and unregister_snap_client for the same protocol races it's a bug in the caller's code. The safe RCU list removal and synchronize_kernel should protect us from sane usage. Zwane - 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/