--ahZICQ7iXVM/oLYH

Content-Type: text/plain; charset=us-ascii

Content-Disposition: inline

Content-Transfer-Encoding: quoted-printable
Hi, the following patch fixes the symlink bug I mentioned a few days ago.

Thanks for your comments.
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
--ahZICQ7iXVM/oLYH

Content-Type: text/x-diff; charset=us-ascii

Content-Disposition: attachment; filename="configfs-do-not-symlink-to-removing-item.patch"

Content-Transfer-Encoding: quoted-printable
configfs: Fix symlink() to a removing item
[Applies on top of rename() vs rmdir() deadlock fix patchset]
The rule for configfs symlinks is that symlinks always point to valid

config_items, and prevent the target from being removed. However,

configfs_symlink() only checks that it can grab a reference on the target i=

tem,

without ensuring that it remains alive until the symlink is correctly attac=

hed.
This patch makes configfs_symlink() fail whenever the target is being remov=

ed,

using the CONFIGFS_USET_DROPPING flag set by configfs_detach_prep() and

protected by configfs_dirent_lock.
This patch introduces a similar (weird?) behavior as with mkdir failures ma=

king

rmdir fail: if symlink() races with rmdir() of the parent directory (or its

youngest user-created ancestor if parent is a default group) or rmdir() of =

the

target directory, and then fails in configfs_create(), this can make the ra=

cing

rmdir() fail despite the concerned directory having no user-created entry (=

resp.

no symlink pointing to it or one of its default groups) in the end.

If this behavior is found unacceptable, I'll submit a fix in the same spiri=

t as

the racing mkdir() fix.
Signed-off-by: Louis Rilling <Louis.Rilling@kerlabs.com>

---

 fs/configfs/dir.c     |   14 +++++++-------

 fs/configfs/symlink.c |    6 ++++++

 2 files changed, 13 insertions(+), 7 deletions...
[ message continues ]

Ahh, but you can't wait on the mutex like you do in mkdir(),

because they're not ordered - it can race rename again.
Joel
-- 
Dort wo man Bücher verbrennt, verbrennt man am Ende auch Mensch.

(Wherever they burn books, they will also end up burning people.)

	- Heinrich Heine
Joel Becker

Principal Software Developer

Oracle

E-mail: joel.becker@oracle.com

Phone: (650) 506-8127

--

Yes I can. In the mkdir() case, rmdir() waits on the mutex of one of the de=

fault

groups. The symlink case will be handled the same. The difference is that w=

hile

mkdir() tags the parent with CONFIGFS_USET_IN_MKDIR, symlink() will tag bot=

h the

parent and the target with CONFIGFS_USET_IN_SYMLINK. [ We can actually merg=

e the

two flags in something like CONFIGFS_USET_ATTACHING. ] Since tagging requir=

es

only to take configfs_dirent_lock, there will be no deadlock.
I'll send a patch later.
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

Hm, you were right, sorry. We can only solve the race with rmdir() removing=

 the

item where the symlink is created. For the target item, I don't know yet...
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