Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: David Jeffery <david_jeffery@adaptec.com>
Cc: "Guzovsky, Eduard" <Edg@CROSSBEAMSYS.COM>,
	"nfs@lists.sourceforge.net" <nfs@lists.sourceforge.net>
Subject: Re: linux 2.4.18-5 nfs/rpc problem
Date: 10 Oct 2003 14:58:02 -0400	[thread overview]
Message-ID: <shsoewo2a4l.fsf@charged.uio.no> (raw)
In-Reply-To: <1065805973.874.41.camel@blackmagic>

>>>>> " " == David Jeffery <david_jeffery@adaptec.com> writes:

     > Eduard, I have also seen this problem with both Red Hat and
     > stock kernels.  I've got some patches That I'm testing to try
     > and fix the problem for me, but it takes a while for my setup
     > to reproduce the problem.  How easy is it for you to trigger?

     > I've attached two patches for 2.4.22 that I'm currently
     > testing.  The first (nfsiput.patch) is to fix the deadlocked
     > processes you see by moving the iput() call to happen after the
     > waited on request is unlocked.

I take it you're assuming that the problem is a deadlock due to
clear_inode() hanging on our page lock? That does indeed appear to be
a possible source of contention.

Instead of your 2 patches, though, how about just ensuring that
anybody calling nfs_wait_on_requests() already has a reference to the
inode?

There is indeed one case where this is not being done: in
page_launder() you only have a lock on the page. This means that you
may end up calling nfs_wait_on_request() in order to flush out a page
only to discover that it called iput() from beneath you and is now
waiting in clear_inode() on your page lock.

Cheers,
  Trond

--- linux-2.4.23-pre5/fs/nfs/write.c.orig	2003-07-09 14:11:04.000000000 -0400
+++ linux-2.4.23-pre5/fs/nfs/write.c	2003-10-10 14:54:16.000000000 -0400
@@ -225,8 +225,19 @@
 	struct inode *inode = page->mapping->host;
 	unsigned long end_index;
 	unsigned offset = PAGE_CACHE_SIZE;
+	int inode_referenced = 0;
 	int err;
 
+	/*
+	 * Note: We need to ensure that we have a reference to the inode
+	 *       if we are to do asynchronous writes. If not, waiting
+	 *       in nfs_wait_on_request() may deadlock with clear_inode().
+	 *
+	 *       If igrab() fails here, then it is in any case safe to
+	 *       call nfs_wb_page(), since there will be no pending writes.
+	 */
+	if (igrab(inode) != 0)
+		inode_referenced = 1;
 	end_index = inode->i_size >> PAGE_CACHE_SHIFT;
 
 	/* Ensure we've flushed out any previous writes */
@@ -244,7 +255,8 @@
 		goto out;
 do_it:
 	lock_kernel();
-	if (NFS_SERVER(inode)->wsize >= PAGE_CACHE_SIZE && !IS_SYNC(inode)) {
+	if (NFS_SERVER(inode)->wsize >= PAGE_CACHE_SIZE && !IS_SYNC(inode) &&
+			inode_referenced) {
 		err = nfs_writepage_async(NULL, inode, page, 0, offset);
 		if (err >= 0)
 			err = 0;
@@ -256,7 +268,9 @@
 	unlock_kernel();
 out:
 	UnlockPage(page);
-	return err; 
+	if (inode_referenced)
+		iput(inode);
+	return err;
 }
 
 /*


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2003-10-10 18:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 22:42 linux 2.4.18-5 nfs/rpc problem Guzovsky, Eduard
2003-10-10 17:12 ` David Jeffery
2003-10-10 18:58   ` Trond Myklebust [this message]
2003-10-10 19:44     ` Trond Myklebust
2003-10-13 14:17       ` David Jeffery
  -- strict thread matches above, loose matches on Subject: below --
2003-10-11  0:18 Guzovsky, Eduard
2003-10-11  0:20 Guzovsky, Eduard

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=shsoewo2a4l.fsf@charged.uio.no \
    --to=trond.myklebust@fys.uio.no \
    --cc=Edg@CROSSBEAMSYS.COM \
    --cc=david_jeffery@adaptec.com \
    --cc=nfs@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox