From mboxrd@z Thu Jan 1 00:00:00 1970 From: Louis Rilling Subject: Re: [Ocfs2-devel] [RFC] configfs: Pin configfs subsystems separately from new config_items. Date: Wed, 18 Jun 2008 18:51:01 +0200 Message-ID: <20080618165101.GI30804@localhost> References: <1213742460-26331-1-git-send-email-joel.becker@oracle.com> <20080618123134.GC30804@localhost> <20080618161215.GA16780@ca-server1.us.oracle.com> Reply-To: Louis.Rilling@kerlabs.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_bohort-14469-1213807772-0001-2" Cc: linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com To: Joel Becker Return-path: Received: from bohort.kerlabs.com ([62.160.40.57]:37349 "EHLO bohort.kerlabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbYFRQvE (ORCPT ); Wed, 18 Jun 2008 12:51:04 -0400 Content-Disposition: inline In-Reply-To: <20080618161215.GA16780@ca-server1.us.oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_bohort-14469-1213807772-0001-2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 18, 2008 at 09:12:15AM -0700, Joel Becker wrote: > On Wed, Jun 18, 2008 at 02:31:34PM +0200, Louis Rilling wrote: > > On Tue, Jun 17, 2008 at 03:41:00PM -0700, Joel Becker wrote: > > > However, if the subsystem is made up of multiple modules, this may not > > > pin the subsystem. Thus, it would be possible to unload the toplevel > > > subsystem module while there is still a child item. Thus, we now > > > try_module_get() the subsystem's module. This only really affects > > > children of the toplevel subsystem group. Deeper children already ha= ve > > > their parents pinned. > >=20 > > Looks good to me. > >=20 > > What about new item module pinning versus a concurrent sys_delete_modul= e() in a > > preemptible kernel? AFAICS new_item pinning is just done too late to pr= otect > > anybody against sys_delete_module(). Shouldn't we remove new item modul= e pinning > > and let the subsystem do it? >=20 > Good catch. Preempt doesn't matter - it could just be another > CPU. > Certainly if there are multiple modules the make_item() will > have to pin the submodule before calling it. But the common case isn't > multiple modules. What we absolutely don't want is making the common > case have to pin itself. I suspect the common case to not need to pin the new item: if we assume tha= t the parent is already pinned, it will remain pinned until the new item is dropp= ed. I think that the following rules ensure that the parent's module is always pinned: 1/ The subsystem root is pinned before creating any other subdir under a de= fault group of its module (ok with your patch). 2/ A subsystem root having default groups in other modules pins these modul= es before register() and until unregister() (ok with in-tree subsystems I t= hink, thanks to automatic module dependency tracking). This should mostly be d= one implicitly thanks to the module dependency tracking based on used symbol= s. 3/ Same as 2 but for a new group between allocation and release(). Here aga= in, module dependency tracking should do the job most of the time. 4/ make_item()/make_group() pins the module of the new item/group if it dif= fers from the current one, and at least until drop_item() (must check in-tree subsystems, but I suspect that module dependency tracking already does t= he job). If you agree with these rules, which seem to be just reasonable, we should = be able to get rid of the new item's module pinning inside configfs. Louis --=20 Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes --=_bohort-14469-1213807772-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIWTz1VKcRuvQ9Q1QRAkfuAJ0adhaylg198bJxz8IvcYuSSF//iACeLCR1 G3Hvojh3rsqWq2R1pPEswDY= =S9uF -----END PGP SIGNATURE----- --=_bohort-14469-1213807772-0001-2--