All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: xfs@oss.sgi.com
Cc: t-nagano@ah.jp.nec.com, xfs-dev@sgi.com
Subject: [REVIEW 3 of 4] Fix recalim handling in xfs_iget_core
Date: Tue, 24 Oct 2006 17:20:54 +1000	[thread overview]
Message-ID: <20061024072054.GT11034@melbourne.sgi.com> (raw)


-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


Fix the xfs_iget_core() handling of the XFS_IRECLAIMABLE flag so it
doesn't violate the guarantee we need to provide to xfs_iunpin()
w.r.t. the existence of a linux inode.

---
 fs/xfs/xfs_iget.c |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

Index: 2.6.x-xfs-new/fs/xfs/xfs_iget.c
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_iget.c	2006-10-19 10:25:07.000000000 +1000
+++ 2.6.x-xfs-new/fs/xfs/xfs_iget.c	2006-10-19 10:29:26.460972850 +1000
@@ -238,6 +238,34 @@ again:
 					goto again;
 				}
 
+				/*
+				 * If IRECLAIMABLE is set on this inode and lookup is
+				 * racing with unlink, then we should return an error
+				 * immediately so we don't remove it from the reclaim
+				 * list and potentially leak the inode.
+				 *
+				 * Also, there may be transactions sitting in the
+				 * incore log buffers or being flushed to disk at this
+				 * time.  We can't clear the XFS_IRECLAIMABLE flag
+				 * until these transactions have hit the disk,
+				 * otherwise we will void the guarantee the flag
+				 * provides xfs_iunpin()
+				 */
+				if (xfs_iflags_test(ip, XFS_IRECLAIMABLE)) {
+					if ((ip->i_d.di_mode == 0) &&
+					    !(flags & XFS_IGET_CREATE)) {
+						read_unlock(&ih->ih_lock);
+							return ENOENT;
+					}
+					if (xfs_ipincount(ip)) {
+						read_unlock(&ih->ih_lock);
+						xfs_log_force(mp, 0,
+							XFS_LOG_FORCE|XFS_LOG_SYNC);
+						XFS_STATS_INC(xs_ig_frecycle);
+						goto again;
+					}
+				}
+
 				vn_trace_exit(vp, "xfs_iget.alloc",
 					(inst_t *)__return_address);
 

             reply	other threads:[~2006-10-24  7:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-24  7:20 David Chinner [this message]
2006-10-24 18:23 ` [REVIEW 3 of 4] Fix recalim handling in xfs_iget_core Shailendra Tripathi
2006-10-26  9:58   ` David Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061024072054.GT11034@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=t-nagano@ah.jp.nec.com \
    --cc=xfs-dev@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.