1. 04 Feb, 2009 7 commits
  2. 03 Feb, 2009 29 commits
  3. 02 Feb, 2009 4 commits
    • Mark Fasheh's avatar
      ocfs2: add quota call to ocfs2_remove_btree_range() · fd4ef231
      Mark Fasheh authored
      We weren't reclaiming the clusters which get free'd from this function,
      so any user punching holes in a file would still have those bytes accounted
      against him/her. Add the call to vfs_dq_free_space_nodirty() to fix this.
      Interestingly enough, the journal credits calculation already took this into
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Acked-by: default avatarJan Kara <jack@suse.cz>
    • Sunil Mushran's avatar
      ocfs2: Wakeup the downconvert thread after a successful cancel convert · a4b91965
      Sunil Mushran authored
      When two nodes holding PR locks on a resource concurrently attempt to
      upconvert the locks to EX, the master sends a BAST to one of the nodes. This
      message tells that node to first cancel convert the upconvert request,
      followed by downconvert to a NL. Only when this lock is downconverted to NL,
      can the master upconvert the first node's lock to EX.
      While the fs was doing the cancel convert, it was forgetting to wake up the
      dc thread after a successful cancel, leading to a deadlock.
      Reported-and-Tested-by: default avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarSunil Mushran <sunil.mushran@oracle.com>
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
    • Tao Ma's avatar
      ocfs2: Access the xattr bucket only before modifying it. · 554e7f9e
      Tao Ma authored
      In ocfs2_xattr_value_truncate, we may call b-tree codes which will
      extend the journal transaction. It has a potential problem that it
      may let the already-accessed-but-not-dirtied buffers gone. So we'd
      better access the bucket after we call ocfs2_xattr_value_truncate.
      And as for the root buffer for the xattr value, b-tree code will
      acess and dirty it, so we don't need to worry about it.
      Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
    • Joel Becker's avatar
      configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item() · 0e033342
      Joel Becker authored
      When attaching default groups (subdirs) of a new group (in mkdir() or
      in configfs_register()), configfs recursively takes inode's mutexes
      along the path from the parent of the new group to the default
      subdirs. This is needed to ensure that the VFS will not race with
      operations on these sub-dirs. This is safe for the following reasons:
      - the VFS allows one to lock first an inode and second one of its
        children (The lock subclasses for this pattern are respectively
      - from this rule any inode path can be recursively locked in
        descending order as long as it stays under a single mountpoint and
        does not follow symlinks.
      Unfortunately lockdep does not know (yet?) how to handle such
      I've tried to use Peter Zijlstra's lock_set_subclass() helper to
      upgrade i_mutexes from I_MUTEX_CHILD to I_MUTEX_PARENT when we know
      that we might recursively lock some of their descendant, but this
      usage does not seem to fit the purpose of lock_set_subclass() because
      it leads to several i_mutex locked with subclass I_MUTEX_PARENT by
      the same task.
      >From inside configfs it is not possible to serialize those recursive
      locking with a top-level one, because mkdir() and rmdir() are already
      called with inodes locked by the VFS. So using some
      mutex_lock_nest_lock() is not an option.
      I am proposing two solutions:
      1) one that wraps recursive mutex_lock()s with
      2) (as suggested earlier by Peter Zijlstra) one that puts the
         i_mutexes recursively locked in different classes based on their
         depth from the top-level config_group created. This
         induces an arbitrary limit (MAX_LOCK_DEPTH - 2 == 46) on the
         nesting of configfs default groups whenever lockdep is activated
         but this limit looks reasonably high. Unfortunately, this alos
         isolates VFS operations on configfs default groups from the others
         and thus lowers the chances to detect locking issues.
      This patch implements solution 1).
      Solution 2) looks better from lockdep's point of view, but fails with
      configfs_depend_item(). This needs to rework the locking
      scheme of configfs_depend_item() by removing the variable lock recursion
      depth, and I think that it's doable thanks to the configfs_dirent_lock.
      For now, let's stick to solution 1).
      Signed-off-by: default avatarLouis Rilling <louis.rilling@kerlabs.com>
      Acked-by: default avatarJoel Becker <joel.becker@oracle.com>
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>