This is a note to let you know that I've just added the patch titled

    xfs: bulkstat doesn't release AGI buffer on error

to the 3.17-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     xfs-bulkstat-doesn-t-release-agi-buffer-on-error.patch
and it can be found in the queue-3.17 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From a6bbce54efa9145dbcf3029c885549f7ebc40a3b Mon Sep 17 00:00:00 2001
From: Dave Chinner <[email protected]>
Date: Wed, 29 Oct 2014 08:22:18 +1100
Subject: xfs: bulkstat doesn't release AGI buffer on error

From: Dave Chinner <[email protected]>

commit a6bbce54efa9145dbcf3029c885549f7ebc40a3b upstream.

The recent refactoring of the bulkstat code left a small landmine in
the code. If a inobt read fails, then the tree walk is aborted and
returns without releasing the AGI buffer or freeing the cursor. This
can lead to a subsequent bulkstat call hanging trying to grab the
AGI buffer again.

Signed-off-by: Dave Chinner <[email protected]>
Reviewed-by: Brian Foster <[email protected]>
Reviewed-by: Eric Sandeen <[email protected]>
Signed-off-by: Dave Chinner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 fs/xfs/xfs_itable.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

--- a/fs/xfs/xfs_itable.c
+++ b/fs/xfs/xfs_itable.c
@@ -427,7 +427,7 @@ xfs_bulkstat(
 
                        error = xfs_bulkstat_grab_ichunk(cur, agino, &icount, 
&r);
                        if (error)
-                               break;
+                               goto del_cursor;
                        if (icount) {
                                irbp->ir_startino = r.ir_startino;
                                irbp->ir_freecount = r.ir_freecount;
@@ -442,7 +442,7 @@ xfs_bulkstat(
                        error = xfs_inobt_lookup(cur, 0, XFS_LOOKUP_GE, &tmp);
                }
                if (error)
-                       break;
+                       goto del_cursor;
 
                /*
                 * Loop through inode btree records in this ag,
@@ -454,7 +454,7 @@ xfs_bulkstat(
                        error = xfs_inobt_get_rec(cur, &r, &i);
                        if (error || i == 0) {
                                end_of_ag = 1;
-                               break;
+                               goto del_cursor;
                        }
 
                        /*
@@ -476,13 +476,17 @@ xfs_bulkstat(
                        error = xfs_btree_increment(cur, 0, &tmp);
                        cond_resched();
                }
+
                /*
-                * Drop the btree buffers and the agi buffer.
-                * We can't hold any of the locks these represent
-                * when calling iget.
+                * Drop the btree buffers and the agi buffer as we can't hold 
any
+                * of the locks these represent when calling iget. If there is a
+                * pending error, then we are done.
                 */
+del_cursor:
                xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR);
                xfs_buf_relse(agbp);
+               if (error)
+                       break;
                /*
                 * Now format all the good inodes into the user's buffer.
                 */


Patches currently in stable-queue which might be from [email protected] are

queue-3.17/xfs-bulkstat-main-loop-logic-is-a-mess.patch
queue-3.17/xfs-bulkstat-doesn-t-release-agi-buffer-on-error.patch
queue-3.17/xfs-bulkstat-chunk-formatter-has-issues.patch
queue-3.17/xfs-track-bulkstat-progress-by-agino.patch
queue-3.17/mm-remove-false-warn_on-from-pagecache_isize_extended.patch
queue-3.17/xfs-bulkstat-chunk-formatting-cursor-is-broken.patch
queue-3.17/xfs-bulkstat-error-handling-is-broken.patch
queue-3.17/xfs-bulkstat-btree-walk-doesn-t-terminate.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to