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 14:31:34 +0200 Message-ID: <20080618123134.GC30804@localhost> References: <1213742460-26331-1-git-send-email-joel.becker@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-10875-1213792205-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]:55084 "EHLO bohort.kerlabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755462AbYFRMbg (ORCPT ); Wed, 18 Jun 2008 08:31:36 -0400 Content-Disposition: inline In-Reply-To: <1213742460-26331-1-git-send-email-joel.becker@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-10875-1213792205-0001-2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 17, 2008 at 03:41:00PM -0700, Joel Becker wrote: > configfs_mkdir() creates a new item by calling its parent's > ->make_item/group() functions. Once that object is created, > configfs_mkdir() calls try_module_get() on the new item's module. If it > succeeds, the module owning the new item cannot be unloaded, and > configfs is safe to reference the item. >=20 > If the item and the subsystem it belongs to are part of the same module, > the subsystem is also pinned. This is the common case. >=20 > 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 have > their parents pinned. Looks good to me. What about new item module pinning versus a concurrent sys_delete_module() = in a preemptible kernel? AFAICS new_item pinning is just done too late to protect anybody against sys_delete_module(). Shouldn't we remove new item module pi= nning and let the subsystem do it? process 1: process 2: confifs_mkdir() item =3D make_item() --- preemption schedule --- sys_delete_module() ok --- end of preemption --- new_item_owner =3D item->ci_type.ct_owner Possible access to freed memory if type statically allocated! try_module_get(new_item_owner) Access to freed memory of the module metadata! 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-10875-1213792205-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) iD8DBQFIWQAmVKcRuvQ9Q1QRAgQ6AJ9MyqmJmahz0Ihdqsn7LmroiN3Y3wCgluwI 5iAgdShOQ12T94kqgBQD4Oo= =TK/z -----END PGP SIGNATURE----- --=_bohort-10875-1213792205-0001-2--