Re: configfs: Q: item leak in a failing configfs_attach_group()?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Louis Rilling
Date: Wednesday, June 25, 2008 - 2:55 am

On Tue, Jun 24, 2008 at 02:34:39PM -0700, Joel Becker wrote:
ode

So, my scenario is realistic. Process 2 only locks "B"'s inode in
lookup_create() ("B" is the parent of the new directory "C"), and never has=
 to
lock "A" or "A"'s parent. IOW, process 2 does not have to wait on any i_mut=
ex
locked by process 1.

Back to the two solutions that I've suggested (copy-pasted below), which one
would you prefer?

If I'm right, two kinds of solutions for issue 1 (new item created while
attaching a default group hierarchy):
i/ tag new directories with CONFIGFS_USET_NEW before calling d_instantiate,=
 and
validate the whole group+default groups hierarchy in a second pass by clear=
ing
CONFIGFS_USET_NEW

ii/ do not call d_instantiate() immediately in configfs_create() if called =
=66rom
configfs_create_dir(), and d_instantitate() the group+default groups hierar=
chy
in a second pass. Problem: is it correct to add children to a dentry which =
is
not yet instantiated?

For issue 2/ (detach_item() called without locking the detached item's inod=
e),
locking the inode before calling detach_item() (as is done from
configfs_rmdir()), plus a solution for 1/ should be sufficient.

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
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: configfs: Q: item leak in a failing configfs_attach_gr ..., Louis Rilling, (Wed Jun 25, 2:55 am)