1. 01 8月, 2008 1 次提交
    • L
      [PATCH] configfs: Fix failing symlink() making rmdir() fail · 9a73d78c
      Louis Rilling 提交于
      On a similar pattern as mkdir() vs rmdir(), a failing symlink() may make rmdir()
      fail for the symlink's parent and the symlink's target as well.
      
      failing symlink() making target's rmdir() fail:
      
      	process 1:				process 2:
      	symlink("A/S" -> "B")
      	  allow_link()
      	  create_link()
      	    attach to "B" links list
      						rmdir("B")
      						  detach_prep("B")
      						    error because of new link
      	    configfs_create_link("A", "S")
      	      error (eg -ENOMEM)
      
      failing symlink() making parent's rmdir() fail:
      
      	process 1:				process 2:
      	symlink("A/D/S" -> "B")
      	  allow_link()
      	  create_link()
      	    attach to "B" links list
      	    configfs_create_link("A/D", "S")
      	      make_dirent("A/D", "S")
      						rmdir("A")
      						  detach_prep("A")
      						    detach_prep("A/D")
      						      error because of "S"
      	      create("S")
      	        error (eg -ENOMEM)
      
      We cannot use the same solution as for mkdir() vs rmdir(), since rmdir() on the
      target cannot wait on the i_mutex of the new symlink's parent without risking a
      deadlock (with other symlink() or sys_rename()). Instead we define a global
      mutex protecting all configfs symlinks attachment, so that rmdir() can avoid the
      races above.
      Signed-off-by: NLouis Rilling <louis.rilling@kerlabs.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      Signed-off-by: NMark Fasheh <mfasheh@suse.com>
      9a73d78c
  2. 15 7月, 2008 2 次提交
    • L
      configfs: Fix failing mkdir() making racing rmdir() fail · 6d8344ba
      Louis Rilling 提交于
      When fixing the rename() vs rmdir() deadlock, we stopped locking default groups'
      inodes in configfs_detach_prep(), letting racing mkdir() in default groups
      proceed concurrently. This enables races like below happen, which leads to a
      failing mkdir() making rmdir() fail, despite the group to remove having no
      user-created directory under it in the end.
      
      	process A: 			process B:
      	/* PWD=A/B */
      	mkdir("C")
      	  make_item("C")
      	  attach_group("C")
      					rmdir("A")
      					  detach_prep("A")
      					    detach_prep("B")
      					      error because of "C"
      					  return -ENOTEMPTY
      	    attach_group("C/D")
      	      error (eg -ENOMEM)
      	  return -ENOMEM
      
      This patch prevents such scenarii by making rmdir() wait as long as
      detach_prep() fails because a racing mkdir() is in the middle of attach_group().
      To achieve this, mkdir() sets a flag CONFIGFS_USET_IN_MKDIR in parent's
      configfs_dirent before calling attach_group(), and clears the flag once
      attach_group() is done. detach_prep() fails with -EAGAIN whenever the flag is
      hit and returns the guilty inode's mutex so that rmdir() can wait on it.
      Signed-off-by: NLouis Rilling <Louis.Rilling@kerlabs.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      6d8344ba
    • L
      configfs: Introduce configfs_dirent_lock · 6f610764
      Louis Rilling 提交于
      This patch introduces configfs_dirent_lock spinlock to protect configfs_dirent
      traversals against linkage mutations (add/del/move). This will allow
      configfs_detach_prep() to avoid locking i_mutexes.
      
      Locking rules for configfs_dirent linkage mutations are the same plus the
      requirement of taking configfs_dirent_lock. For configfs_dirent walking, one can
      either take appropriate i_mutex as before, or take configfs_dirent_lock.
      
      The spinlock could actually be a mutex, but the critical sections are either
      O(1) or should not be too long (default groups walking in last patch).
      
      ChangeLog:
        - Clarify the comment on configfs_dirent_lock usage
        - Move sd->s_element init before linking the new dirent
        - In lseek(), do not release configfs_dirent_lock before the dirent is
          relinked.
      Signed-off-by: NLouis Rilling <Louis.Rilling@kerlabs.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      6f610764
  3. 17 10月, 2007 1 次提交
  4. 11 7月, 2007 1 次提交
    • J
      configfs: config item dependancies. · 631d1feb
      Joel Becker 提交于
      Sometimes other drivers depend on particular configfs items.  For
      example, ocfs2 mounts depend on a heartbeat region item.  If that
      region item is removed with rmdir(2), the ocfs2 mount must BUG or go
      readonly.  Not happy.
      
      This provides two additional API calls: configfs_depend_item() and
      configfs_undepend_item().  A client driver can call
      configfs_depend_item() on an existing item to tell configfs that it is
      depended on.  configfs will then return -EBUSY from rmdir(2) for that
      item.  When the item is no longer depended on, the client driver calls
      configfs_undepend_item() on it.
      
      These API cannot be called underneath any configfs callbacks, as
      they will conflict.  They can block and allocate.  A client driver
      probably shouldn't calling them of its own gumption.  Rather it should
      be providing an API that external subsystems call.
      
      How does this work?  Imagine the ocfs2 mount process.  When it mounts,
      it asks for a heart region item.  This is done via a call into the
      heartbeat code.  Inside the heartbeat code, the region item is looked
      up.  Here, the heartbeat code calls configfs_depend_item().  If it
      succeeds, then heartbeat knows the region is safe to give to ocfs2.
      If it fails, it was being torn down anyway, and heartbeat can gracefully
      pass up an error.
      
      [ Fixed some bad whitespace in configfs.txt. --Mark ]
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      Signed-off-by: NMark Fasheh <mark.fasheh@oracle.com>
      631d1feb
  5. 13 2月, 2007 1 次提交
  6. 08 12月, 2006 1 次提交
  7. 29 3月, 2006 1 次提交
  8. 04 2月, 2006 1 次提交
  9. 04 1月, 2006 1 次提交