Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030400AbVJ1WPz (ORCPT ); Fri, 28 Oct 2005 18:15:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030409AbVJ1WPz (ORCPT ); Fri, 28 Oct 2005 18:15:55 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:39353 "EHLO e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S1030400AbVJ1WPy (ORCPT ); Fri, 28 Oct 2005 18:15:54 -0400 Subject: Re: Notifier chains are unsafe From: Chandra Seetharaman Reply-To: sekharan@us.ibm.com To: Alan Stern Cc: Keith Owens , Kernel development list In-Reply-To: References: Content-Type: text/plain Organization: IBM Date: Fri, 28 Oct 2005 15:15:49 -0700 Message-Id: <1130537749.3586.336.camel@linuxchandra> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2005 Lines: 48 On Fri, 2005-10-28 at 10:23 -0400, Alan Stern wrote: > On Thu, 27 Oct 2005, Chandra Seetharaman wrote: > > > So, requirements to fix the bug are: > > - no sleeping in register/unregister(if we want to keep the > > current way of use. We can change it and make the relevant > > changes in the kernel code, if it is agreeable) > > I think we will have to make these changes. In principal it shouldn't be > hard to add a simple "enabled" flag to each callout which currently is > registered/unregistered atomically or while running. We could even put > such a flag into the notifier_block structure and add routines to set or > clear it, using appropriate barriers. I do not understand the purpose of enabled flag. Can you clarify > > > - notifier_call_chain could be called from any context > > - callout function could sleep > > - no acquiring locks in notifier_call_chain > > - make sure the list is consistent :) (which is problem Alan > > started to fix) > > - anything else ? > > Let's clarify the "list is consistent" statement. Obviously it implies > that no more than one thread can modify the list pointers at any time. > Beyond that, there should be a guarantee that when unregister returns, the > routine being removed is not in use and will not be called by any thread. > Likewise, after register returns, any invocation of notifier_call_chain > should see the new routine. true > > Alan Stern > > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sekharan@us.ibm.com | .......you may get it. ---------------------------------------------------------------------- - 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/