Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 8 Jul 2002 09:13:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 8 Jul 2002 09:13:02 -0400 Received: from mail.ocs.com.au ([203.34.97.2]:43280 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Mon, 8 Jul 2002 09:13:02 -0400 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Linux-Kernel Mailing List Subject: Re: simple handling of module removals Re: [OKS] Module removal In-reply-to: Your message of "Mon, 08 Jul 2002 23:06:05 +1000." <17584.1026133565@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jul 2002 23:15:32 +1000 Message-ID: <17857.1026134132@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1153 Lines: 23 On Mon, 08 Jul 2002 23:06:05 +1000, Keith Owens wrote: >The current code tries to use 'increment use count outside module' but >that has its own race in getting the address of the module. Closing >that race relies on the interaction between three (yes, three) >unrelated locks which have to be obtained and released in the right >order. Not only is this complex and fragile, a quick scan of the >kernel found one outright bug and several dubious sections of code. Correction: make that two outright bugs. I have just been told that one of the dubious bits of code is broken. Tracking the interaction of multiple locks to ensure that they correctly prevent a race on incrementing the use count is too messy and fragile. The offending bits of code were not written by beginners but by experienced kernel programmers. If experienced programmers get it wrong, then the method is wrong. - 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/