3.2.43-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Al Viro <v...@zeniv.linux.org.uk>

commit 7ea600b5314529f9d1b9d6d3c41cb26fce6a7a4a upstream.

... lest we get livelocks between path_is_under() and d_path() and friends.

The thing is, wrt fairness lglocks are more similar to rwsems than to rwlocks;
it is possible to have thread B spin on attempt to take lock shared while thread
A is already holding it shared, if B is on lower-numbered CPU than A and there's
a thread C spinning on attempt to take the same lock exclusive.

As the result, we need consistent ordering between vfsmount_lock (lglock) and
rename_lock (seq_lock), even though everything that takes both is going to take
vfsmount_lock only shared.

Spotted-by: Brad Spengler <spen...@grsecurity.net>
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
[bwh: Backported to 3.2:
 - Adjust context
 - s/&vfsmount_lock/vfsmount_lock/]
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
 fs/dcache.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2445,7 +2445,6 @@ static int prepend_path(const struct pat
        bool slash = false;
        int error = 0;
 
-       br_read_lock(vfsmount_lock);
        while (dentry != root->dentry || vfsmnt != root->mnt) {
                struct dentry * parent;
 
@@ -2475,8 +2474,6 @@ static int prepend_path(const struct pat
        if (!error && !slash)
                error = prepend(buffer, buflen, "/", 1);
 
-out:
-       br_read_unlock(vfsmount_lock);
        return error;
 
 global_root:
@@ -2493,7 +2490,7 @@ global_root:
                error = prepend(buffer, buflen, "/", 1);
        if (!error)
                error = vfsmnt->mnt_ns ? 1 : 2;
-       goto out;
+       return error;
 }
 
 /**
@@ -2520,9 +2517,11 @@ char *__d_path(const struct path *path,
        int error;
 
        prepend(&res, &buflen, "\0", 1);
+       br_read_lock(vfsmount_lock);
        write_seqlock(&rename_lock);
        error = prepend_path(path, root, &res, &buflen);
        write_sequnlock(&rename_lock);
+       br_read_unlock(vfsmount_lock);
 
        if (error < 0)
                return ERR_PTR(error);
@@ -2539,9 +2538,11 @@ char *d_absolute_path(const struct path
        int error;
 
        prepend(&res, &buflen, "\0", 1);
+       br_read_lock(vfsmount_lock);
        write_seqlock(&rename_lock);
        error = prepend_path(path, &root, &res, &buflen);
        write_sequnlock(&rename_lock);
+       br_read_unlock(vfsmount_lock);
 
        if (error > 1)
                error = -EINVAL;
@@ -2605,11 +2606,13 @@ char *d_path(const struct path *path, ch
                return path->dentry->d_op->d_dname(path->dentry, buf, buflen);
 
        get_fs_root(current->fs, &root);
+       br_read_lock(vfsmount_lock);
        write_seqlock(&rename_lock);
        error = path_with_deleted(path, &root, &res, &buflen);
+       write_sequnlock(&rename_lock);
+       br_read_unlock(vfsmount_lock);
        if (error < 0)
                res = ERR_PTR(error);
-       write_sequnlock(&rename_lock);
        path_put(&root);
        return res;
 }
@@ -2764,6 +2767,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
        get_fs_root_and_pwd(current->fs, &root, &pwd);
 
        error = -ENOENT;
+       br_read_lock(vfsmount_lock);
        write_seqlock(&rename_lock);
        if (!d_unlinked(pwd.dentry)) {
                unsigned long len;
@@ -2773,6 +2777,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
                prepend(&cwd, &buflen, "\0", 1);
                error = prepend_path(&pwd, &root, &cwd, &buflen);
                write_sequnlock(&rename_lock);
+               br_read_unlock(vfsmount_lock);
 
                if (error < 0)
                        goto out;
@@ -2793,6 +2798,7 @@ SYSCALL_DEFINE2(getcwd, char __user *, b
                }
        } else {
                write_sequnlock(&rename_lock);
+               br_read_unlock(vfsmount_lock);
        }
 
 out:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to