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
next prev parent 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