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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
