All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Benny Halevy <bhalevy@panasas.com>,
	NFS list <linux-nfs@vger.kernel.org>,
	Andy Adamson <andros@netapp.com>,
	Fred Isaman <iisaman@netapp.com>
Subject: [PATCH] SQUASHME: pnfs: FIX stupid recall_layout BUG
Date: Sun, 27 Feb 2011 17:04:19 +0200	[thread overview]
Message-ID: <4D6A67F3.3060308@panasas.com> (raw)
In-Reply-To: <4D686893.7010106@panasas.com>


OK, who wrote this code? He did not stop to think for even a
second. And surely it was never tested, since it is 100%
repeatable. Smack yourself on the head!

Simple: layout is in use, a recall comes in. _DELAY is returned
meanwhile, a flag is set and no new IOs are allowed. The last
IO dereference the layout, there are no more layouts. The server
persists, sends a second recall, boom below code crash.

* While at it fix an if();else {} style violation
* The added BUG_ON is important because the address taken from
  a member of a null pointer is not null, and the crash is not
  at all clean.

It no longer crashes my trunc_test, Now I need to verify the recall
is actually honoured.

Signed-off-by: Boaz Harrosh <Boaz Harrosh bharrosh@panasas.com>
---
 fs/nfs/callback_proc.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c
index 12ab7b3..34aee16 100644
--- a/fs/nfs/callback_proc.c
+++ b/fs/nfs/callback_proc.c
@@ -252,9 +252,9 @@ static int initiate_layout_draining(struct pnfs_cb_lrecall_info *cb_info)
 			if (nfs_compare_fh(&args->cbl_fh,
 					   &NFS_I(lo->plh_inode)->fh))
 				continue;
-			if (test_bit(NFS_LAYOUT_BULK_RECALL, &lo->plh_flags))
+			if (test_bit(NFS_LAYOUT_BULK_RECALL, &lo->plh_flags)) {
 				rv = NFS4ERR_DELAY;
-			else {
+			} else {
 				/* FIXME I need to better understand igrab and
 				 * does having a layout ref keep ino around?
 				 *  It should.
@@ -270,6 +270,11 @@ static int initiate_layout_draining(struct pnfs_cb_lrecall_info *cb_info)
 		}
 		spin_unlock(&clp->cl_lock);
 
+		if (rv == NFS4ERR_NOMATCHING_LAYOUT)
+			/* Nothing found */
+			return rv;
+
+		BUG_ON(!lo->plh_inode);
 		spin_lock(&lo->plh_inode->i_lock);
 		if (rv == NFS4_OK) {
 			lo->plh_block_lgets++;
-- 
1.7.3.4



  reply	other threads:[~2011-02-27 15:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-26  2:42 Client still crashing on 2nd callback after NFS4_ERR_DELAY Boaz Harrosh
2011-02-27 15:04 ` Boaz Harrosh [this message]
2011-02-27 22:09   ` [PATCH] SQUASHME: pnfs: FIX stupid recall_layout BUG Fred Isaman
2011-02-28 18:24     ` Boaz Harrosh

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=4D6A67F3.3060308@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=andros@netapp.com \
    --cc=bhalevy@panasas.com \
    --cc=iisaman@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.