From owner-freebsd-current@FreeBSD.ORG Thu Nov 20 23:26:32 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73C18106564A for ; Thu, 20 Nov 2008 23:26:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 242878FC0C for ; Thu, 20 Nov 2008 23:26:31 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so326644yxb.13 for ; Thu, 20 Nov 2008 15:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qdQdk+cksiJ0M0yLtVqkfhmMCkcMCnRnsqgr3rhDHWM=; b=b6DzaDY04Ifl8DCO7STOWxbFoJV2TN8UvaKAemZnJAmfMo3O2GFVKuZSbsw7jhz66b qG4TiW0f/C9yM8t3z7fYrLtOTfezRZvq+nphP3nYnl41MSVrFsOooq4libRKl1Krlni5 thx2DLyVK6/jK0612X2IZYkn9xkAdJR5x3frs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BsPoplhy+BSPaUNRjRbWSMSu14JrtDr0WhzSxqlYlYo4Q+0mqQMyW8TS+AfihdE2as ffviOF4OWfpgFwI9WtH4mPGZu6919HWL+kBT5mFjHXtHd+KwcTEdxhxwTV9VlX3P89tV tsuzxO1c7wxGzt6AxipMYdLsPrx0ffSwS8OIk= Received: by 10.231.15.130 with SMTP id k2mr25816iba.3.1227223591424; Thu, 20 Nov 2008 15:26:31 -0800 (PST) Received: by 10.231.15.70 with HTTP; Thu, 20 Nov 2008 15:26:31 -0800 (PST) Message-ID: <3a142e750811201526r4eb6e9d9xabc4f9ba0bd918cb@mail.gmail.com> Date: Fri, 21 Nov 2008 00:26:31 +0100 From: "Paul B. Mahol" To: "John Baldwin" In-Reply-To: <200811201747.28540.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> <200811201747.28540.jhb@freebsd.org> Cc: current@freebsd.org Subject: Re: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 23:26:32 -0000 On 11/20/08, John Baldwin wrote: > On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> On 11/19/08, John Baldwin wrote: >> > This is a relatively simple patch to mark cd9660 MPSAFE and enable >> > shared >> > lookups. The changes to cd9660_lookup() mirror similar changes to >> > ufs_lookup() to use static variables for local data rather than abusing >> > i-node members of the parent directory. I've done some light testing of >> > this, but not super-strenuous. This patch also includes simple locking > for >> > the iconv support in the kernel. That locking uses an sx lock to > serialize >> > open and close of translator tables and the associated refcount. Actual >> > conversions do not need any locks, however as the mount holds a >> > reference > on >> > the table. >> > >> > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> > >> >> With this patch I'm unable to kldunload libiconv.ko once it is loaded. >> And trying to kldunload libiconv.ko will make any next > kldload/kldstat/kldunload >> to fail waiting forever(livelock). >> >> Regression were not encountered while only cd9660.ko were kldloaded. > > So this is actually due to a bug in the module code. If you have two > modules > like this: > > DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > > The SI_* constants ensure that foo's module handler is called before bar's > module handler for MOD_LOAD. However, we don't enforce a reverse order (bar > then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is random > and has no relation to the SI_* constants. :( Exactly, next time I tried it again and it did not livelock. > > What is happening here is that one of the 'bar' modules in libiconv.ko is > getting unloaded after 'foo' gets unloaded and using a destroyed lock (you > get a panic if you run with INVARIANTS). Yes, I tested it on kernel without ddb and friends.