From: Steve Dickson <SteveD@redhat.com>
To: NFS@lists.sourceforge.net
Subject: [PATCH] spinlock recursion on inode number mismatches
Date: Thu, 17 Nov 2005 17:07:15 -0500 [thread overview]
Message-ID: <437CFF13.50606@RedHat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]
When compiling over NFS using a 2.6.14 kernel, the following
spinlock recursion BUG popped:
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x100000000000000)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x0)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
BUG: spinlock recursion on CPU#0, bhc/22635 (Not tainted)
lock: db7294e8, .magic: dead4ead, .owner: bhc/22635, .owner_cpu: 0
[<c01f53b3>] spin_bug+0xa3/0xd7
[<c01f551e>] _raw_spin_lock+0x68/0x6a
[<f8db1151>] nfs_zap_caches+0x1a/0xaa [nfs]
[<f8db2445>] nfs_update_inode+0x9f/0x618 [nfs]
[<c033be8c>] _spin_unlock_irq+0x5/0x7
[<f8db236b>] nfs_post_op_update_inode+0x2c/0x67 [nfs]
[<f8dba716>] nfs3_proc_remove+0x9e/0xd7 [nfs]
[<f8daed5a>] nfs_safe_remove+0x68/0xc4 [nfs]
[<f8daee5e>] nfs_unlink+0xa8/0x10e [nfs]
[<c017c8df>] vfs_unlink+0x19f/0x1a6
[<c017c9a3>] sys_unlink+0xbd/0x13e
[<c033cee2>] do_page_fault+0x262/0x650
[<c016cb1d>] do_sync_read+0x0/0x116
[<c01040a5>] syscall_call+0x7/0xb
Kernel panic - not syncing: bad locking
[<c01250a8>] panic+0x45/0x1c5
[<c01f53e7>] __spin_lock_debug+0x0/0xcf
[<c01f551e>] _raw_spin_lock+0x68/0x6a
[<f8db1151>] nfs_zap_caches+0x1a/0xaa [nfs]
[<f8db2445>] nfs_update_inode+0x9f/0x618 [nfs]
[<c033be8c>] _spin_unlock_irq+0x5/0x7
[<f8db236b>] nfs_post_op_update_inode+0x2c/0x67 [nfs]
[<f8dba716>] nfs3_proc_remove+0x9e/0xd7 [nfs]
[<f8daed5a>] nfs_safe_remove+0x68/0xc4 [nfs]
[<f8daee5e>] nfs_unlink+0xa8/0x10e [nfs]
[<c017c8df>] vfs_unlink+0x19f/0x1a6
[<c017c9a3>] sys_unlink+0xbd/0x13e
[<c033cee2>] do_page_fault+0x262/0x650
[<c016cb1d>] do_sync_read+0x0/0x116
[<c01040a5>] syscall_call+0x7/0xb
The attached patch solve the problem by the problem by moving
the call to nfs_invalidate_inode() out of nfs_invalidate_inode().
Commments?
steved.
[-- Attachment #2: linux-2.6.14-nfs-spinlock.patch --]
[-- Type: text/x-patch, Size: 1724 bytes --]
The following patch stop a spinlock recursion BUG() from
popping by moving the call to nfs_invalidate_inode()
out of nfs_update_inode(). The nfs_invalidate_inode() is now
down only when nfs_update_inode() returns -ESTALE.
Signed-off-by: Steve Dickson <steved@redhat.com>
----------------------------------------------
--- linux-2.6.14/fs/nfs/inode.c.orig 2005-11-16 12:04:36.464685000 -0500
+++ linux-2.6.14/fs/nfs/inode.c 2005-11-16 14:23:45.790210000 -0500
@@ -1129,6 +1129,8 @@ __nfs_revalidate_inode(struct nfs_server
dfprintk(PAGECACHE, "nfs_revalidate_inode: (%s/%Ld) refresh failed, error=%d\n",
inode->i_sb->s_id,
(long long)NFS_FILEID(inode), status);
+ if (status == -ESTALE)
+ nfs_invalidate_inode(inode);
goto out;
}
cache_validity = nfsi->cache_validity;
@@ -1355,6 +1357,8 @@ int nfs_refresh_inode(struct inode *inod
status = nfs_check_inode_attributes(inode, fattr);
spin_unlock(&inode->i_lock);
+ if (status == -ESTALE)
+ nfs_invalidate_inode(inode);
return status;
}
@@ -1382,6 +1386,8 @@ int nfs_post_op_update_inode(struct inod
nfsi->cache_change_attribute = jiffies;
out:
spin_unlock(&inode->i_lock);
+ if (status == -ESTALE)
+ nfs_invalidate_inode(inode);
return status;
}
@@ -1528,12 +1534,6 @@ static int nfs_update_inode(struct inode
printk(KERN_DEBUG "%s: inode %ld mode changed, %07o to %07o\n",
__FUNCTION__, inode->i_ino, inode->i_mode, fattr->mode);
#endif
- /*
- * No need to worry about unhashing the dentry, as the
- * lookup validation will know that the inode is bad.
- * (But we fall through to invalidate the caches.)
- */
- nfs_invalidate_inode(inode);
out_err:
set_bit(NFS_INO_STALE, &NFS_FLAGS(inode));
return -ESTALE;
next reply other threads:[~2005-11-17 22:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 22:07 Steve Dickson [this message]
2005-11-17 23:30 ` [PATCH] spinlock recursion on inode number mismatches Trond Myklebust
2005-11-18 11:42 ` Steve Dickson
-- strict thread matches above, loose matches on Subject: below --
2005-11-17 22:34 Lever, Charles
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=437CFF13.50606@RedHat.com \
--to=steved@redhat.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 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.