[PATCH 0/9] fsnotify: change locking order

[Lino Sanfilippo <LinoSanfilippo@gmx.de>]

Hi Eric,

After the patch series "decouple mark lock and marks fsobject lock" 
I sent on Feb. 21 this is another attempt to change the locking order
used in fsnotify from 

	mark->lock
	group->mark_lock
	inode/mnt->lock
to 
	group->mark_lock
	mark->lock
	inode/mnt->lock

The former series still contained some flaws:
1. inodes/mounts that have marks and are not pinned could dissappear while 
another thread still wants to access a marks inode/mount (see https://lkml.org/lkml/2011/3/1/373)
2. in the new introduced function remove_mark_locked() a group could be freed 
while the groups mark mutex is held

Both issues should be fixed with this series.

The reason for changing the locking order is, as you may remember, that there are 
still some races when adding/removing marks to a group 
(see also https://lkml.org/lkml/2010/11/30/189).

So what this series does is change the locking order (PATCH 4) to

	group->mark_mutex
	mark->lock
	inode/mnt->lock

Beside this the group mark_lock is turned into a mutex (PATCH 6), which allows us to 
call functions that may sleep while this lock is held. 

At some places there is only a mark and no group available 
(i.e. clear_marks_by_[inode|mount]()), so we first have to get the group from the mark
to use the group->mark_mutex (PATCH 7).  

Since we cant get a group from a mark and use it without the danger that the group is 
unregistered and freed, reference counting for groups is introduced and used 
(PATCHES 1 to 3) for each mark that is added to the group. 
With this freeing a group does not longer depend on the number of marks, but is 
simply destroyed when the reference counter hits 0.

Since a group ref is now taken for each mark that is added to the group we first
have to explicitly call fsnotify_destroy_group() to remove all marks from the group
and release all group references held by those marks. This will also release the
- possibly final - ref of the group held by the caller (PATCH 1).

Furthermore we now can take the mark lock with the group mutex held so we dont need an
extra "clear list" any more if we clear all marks by group (PATCH 9).

For [add|remove]_mark() locked versions are introduced (PATCH 8) that can be 
used if a caller already has the mark lock held. Thus we now have the possibility
to use the groups mark mutex to also synchronize addition/removal of a mark or to
replace the dnotify mutex. 
This is not part of these patches. It would be the next step if these patches are 
accepted to be merged.

This is against 2.6.39