Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 173174
b: refs/heads/master
c: c72e057
h: refs/heads/master
v: v3
  • Loading branch information
Frederic Weisbecker committed Sep 14, 2009
1 parent f3af5a9 commit c6760e0
Show file tree
Hide file tree
Showing 4 changed files with 38 additions and 37 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 2ac626955ed62ee8596f00581f959cc86e6198d1
refs/heads/master: c72e05756b900b3be24cd73a16de52bab80984c0
34 changes: 0 additions & 34 deletions trunk/fs/reiserfs/journal.c
Original file line number Diff line number Diff line change
Expand Up @@ -537,40 +537,6 @@ static inline void insert_journal_hash(struct reiserfs_journal_cnode **table,
journal_hash(table, cn->sb, cn->blocknr) = cn;
}

/*
* Several mutexes depend on the write lock.
* However sometimes we want to relax the write lock while we hold
* these mutexes, according to the release/reacquire on schedule()
* properties of the Bkl that were used.
* Reiserfs performances and locking were based on this scheme.
* Now that the write lock is a mutex and not the bkl anymore, doing so
* may result in a deadlock:
*
* A acquire write_lock
* A acquire j_commit_mutex
* A release write_lock and wait for something
* B acquire write_lock
* B can't acquire j_commit_mutex and sleep
* A can't acquire write lock anymore
* deadlock
*
* What we do here is avoiding such deadlock by playing the same game
* than the Bkl: if we can't acquire a mutex that depends on the write lock,
* we release the write lock, wait a bit and then retry.
*
* The mutexes concerned by this hack are:
* - The commit mutex of a journal list
* - The flush mutex
* - The journal lock
*/
static inline void reiserfs_mutex_lock_safe(struct mutex *m,
struct super_block *s)
{
reiserfs_write_unlock(s);
mutex_lock(m);
reiserfs_write_lock(s);
}

/* lock the current transaction */
static inline void lock_journal(struct super_block *sb)
{
Expand Down
4 changes: 2 additions & 2 deletions trunk/fs/reiserfs/xattr.c
Original file line number Diff line number Diff line change
Expand Up @@ -975,7 +975,7 @@ int reiserfs_lookup_privroot(struct super_block *s)
int err = 0;

/* If we don't have the privroot located yet - go find it */
mutex_lock(&s->s_root->d_inode->i_mutex);
reiserfs_mutex_lock_safe(&s->s_root->d_inode->i_mutex, s);
dentry = lookup_one_len(PRIVROOT_NAME, s->s_root,
strlen(PRIVROOT_NAME));
if (!IS_ERR(dentry)) {
Expand Down Expand Up @@ -1011,7 +1011,7 @@ int reiserfs_xattr_init(struct super_block *s, int mount_flags)

if (privroot->d_inode) {
s->s_xattr = reiserfs_xattr_handlers;
mutex_lock(&privroot->d_inode->i_mutex);
reiserfs_mutex_lock_safe(&privroot->d_inode->i_mutex, s);
if (!REISERFS_SB(s)->xattr_root) {
struct dentry *dentry;
dentry = lookup_one_len(XAROOT_NAME, privroot,
Expand Down
35 changes: 35 additions & 0 deletions trunk/include/linux/reiserfs_fs.h
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,41 @@ void reiserfs_write_unlock(struct super_block *s);
int reiserfs_write_lock_once(struct super_block *s);
void reiserfs_write_unlock_once(struct super_block *s, int lock_depth);

/*
* Several mutexes depend on the write lock.
* However sometimes we want to relax the write lock while we hold
* these mutexes, according to the release/reacquire on schedule()
* properties of the Bkl that were used.
* Reiserfs performances and locking were based on this scheme.
* Now that the write lock is a mutex and not the bkl anymore, doing so
* may result in a deadlock:
*
* A acquire write_lock
* A acquire j_commit_mutex
* A release write_lock and wait for something
* B acquire write_lock
* B can't acquire j_commit_mutex and sleep
* A can't acquire write lock anymore
* deadlock
*
* What we do here is avoiding such deadlock by playing the same game
* than the Bkl: if we can't acquire a mutex that depends on the write lock,
* we release the write lock, wait a bit and then retry.
*
* The mutexes concerned by this hack are:
* - The commit mutex of a journal list
* - The flush mutex
* - The journal lock
* - The inode mutex
*/
static inline void reiserfs_mutex_lock_safe(struct mutex *m,
struct super_block *s)
{
reiserfs_write_unlock(s);
mutex_lock(m);
reiserfs_write_lock(s);
}

/*
* When we schedule, we usually want to also release the write lock,
* according to the previous bkl based locking scheme of reiserfs.
Expand Down

0 comments on commit c6760e0

Please sign in to comment.