Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 10 Oct 2002 18:35:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 10 Oct 2002 18:35:22 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.103]:58851 "EHLO e3.ny.us.ibm.com") by vger.kernel.org with ESMTP id ; Thu, 10 Oct 2002 18:35:22 -0400 Importance: Normal Sensitivity: Subject: Re: [PATCH] EVMS core (3/9) discover.c To: Andi Kleen Cc: linux-kernel@vger.kernel.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Mark Peloquin" Date: Thu, 10 Oct 2002 17:53:55 -0500 X-MIMETrack: Serialize by Router on D01ML072/01/M/IBM(Release 5.0.11 |July 29, 2002) at 10/10/2002 06:40:59 PM 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: 1107 Lines: 33 On 10/10/2002 at 05:19 PM, Andi Kleen wrote: > > We plan to register a "__this_module.can_unload()" that > > should prevent plugin modules from unloading during > > discovery. > Ok in this case. But how about when you search that list later after > discovery for some reason and drop the lock. Then you could race with someone > else removing the plugin inbetween, no ? The only time the lock is released while actively searching the list is during discovery and direct ioctl communication. So yes, you are correct, the can_unload() would have to take both operations into account. All other list operations take place completely inside the lock. All in-use plugins are kept from unloading by module ref counts. Outside of the scope of the discover and direct ioctl operations, any unused plugins should be safe to unload. Is something being missed? Mark - 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/