1. 23 10月, 2008 1 次提交
  2. 01 8月, 2008 3 次提交
    • L
      [PATCH] configfs: Prevent userspace from creating new entries under attaching directories · 2a109f2a
      Louis Rilling 提交于
      process 1: 					process 2:
      configfs_mkdir("A")
        attach_group("A")
          attach_item("A")
            d_instantiate("A")
          populate_groups("A")
            mutex_lock("A")
            attach_group("A/B")
              attach_item("A")
                d_instantiate("A/B")
      						mkdir("A/B/C")
      						  do_path_lookup("A/B/C", LOOKUP_PARENT)
      						    ok
      						  lookup_create("A/B/C")
      						    mutex_lock("A/B")
      						    ok
      						  configfs_mkdir("A/B/C")
      						    ok
            attach_group("A/C")
              attach_item("A/C")
                d_instantiate("A/C")
              populate_groups("A/C")
                mutex_lock("A/C")
                attach_group("A/C/D")
                  attach_item("A/C/D")
                    failure
                mutex_unlock("A/C")
                detach_groups("A/C")
                  nothing to do
      						mkdir("A/C/E")
      						  do_path_lookup("A/C/E", LOOKUP_PARENT)
      						    ok
      						  lookup_create("A/C/E")
      						    mutex_lock("A/C")
      						    ok
      						  configfs_mkdir("A/C/E")
      						    ok
              detach_item("A/C")
              d_delete("A/C")
            mutex_unlock("A")
            detach_groups("A")
              mutex_lock("A/B")
              detach_group("A/B")
      	  detach_groups("A/B")
      	    nothing since no _default_ group
                detach_item("A/B")
              mutex_unlock("A/B")
              d_delete("A/B")
          detach_item("A")
          d_delete("A")
      
      Two bugs:
      
      1/ "A/B/C" and "A/C/E" are created, but never removed while their parent are
      removed in the end. The same could happen with symlink() instead of mkdir().
      
      2/ "A" and "A/C" inodes are not locked while detach_item() is called on them,
         which may probably confuse VFS.
      
      This commit fixes 1/, tagging new directories with CONFIGFS_USET_CREATING before
      building the inode and instantiating the dentry, and validating the whole
      group+default groups hierarchy in a second pass by clearing
      CONFIGFS_USET_CREATING.
      	mkdir(), symlink(), lookup(), and dir_open() simply return -ENOENT if
      called in (or linking to) a directory tagged with CONFIGFS_USET_CREATING. This
      does not prevent userspace from calling stat() successfuly on such directories,
      but this prevents userspace from adding (children to | symlinking from/to |
      read/write attributes of | listing the contents of) not validated items. In
      other words, userspace will not interact with the subsystem on a new item until
      the new item creation completes correctly.
      	It was first proposed to re-use CONFIGFS_USET_IN_MKDIR instead of a new
      flag CONFIGFS_USET_CREATING, but this generated conflicts when checking the
      target of a new symlink: a valid target directory in the middle of attaching
      a new user-created child item could be wrongly detected as being attached.
      
      2/ is fixed by next commit.
      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>
      2a109f2a
    • 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
    • L
      [PATCH] configfs: Fix symlink() to a removing item · 4768e9b1
      Louis Rilling 提交于
      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 item,
      without ensuring that it remains alive until the symlink is correctly attached.
      
      This patch makes configfs_symlink() fail whenever the target is being removed,
      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 making
      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 racing
      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.
      This behavior is fixed in later patches.
      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>
      4768e9b1
  3. 15 7月, 2008 3 次提交
    • L
      configfs: call drop_link() to cleanup after create_link() failure · e7520651
      Louis Rilling 提交于
      When allow_link() succeeds but create_link() fails, the subsystem is not
      informed of the failure.
      
      This patch fixes this by calling drop_link() on create_link() failures.
      Signed-off-by: NLouis Rilling <Louis.Rilling@kerlabs.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      e7520651
    • L
      configfs: Protect configfs_dirent s_links list mutations · 5301a77d
      Louis Rilling 提交于
      Symlinks to a config_item are listed under its configfs_dirent s_links, but the
      list mutations are not protected by any common lock.
      
      This patch uses the configfs_dirent_lock spinlock to add the necessary
      protection.
      
      Note: we should also protect the list_empty() test in configfs_detach_prep() but
      1/ the lock should not be released immediately because nothing would prevent the
      list from being filled after a successful list_empty() test, making the problem
      tricky,
      2/ this will be solved by the rmdir() vs rename() deadlock bugfix.
      Signed-off-by: NLouis Rilling <Louis.Rilling@kerlabs.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      5301a77d
    • 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
  4. 30 4月, 2008 1 次提交
  5. 15 2月, 2008 2 次提交
  6. 13 2月, 2007 1 次提交
  7. 30 6月, 2006 1 次提交
  8. 04 2月, 2006 2 次提交
  9. 04 1月, 2006 1 次提交