From: olof@lixom.net (Olof Johansson)
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nfs: init req_lock in nfs_alloc_inode
Date: Tue, 20 Feb 2007 11:23:45 -0600 [thread overview]
Message-ID: <20070220172345.GA19249@lixom.net> (raw)
In-Reply-To: <1171984200.6271.15.camel@heimdal.trondhjem.org>
On Tue, Feb 20, 2007 at 10:10:00AM -0500, Trond Myklebust wrote:
> > Trond, is your MAINTAINERS entry up to date? Seems like you mostly post
> > from @netapp.com these days.
>
> I tend to be easier to get hold of via the fys.uio.no address, since
> that isn't hidden behind a VPN. I use the netapp.com address when
> posting patches etc since that is sort of required by the developers
> certificate of origin.
Ok, no problem. Just figured I'd ask.
> > Index: linux-2.6/fs/nfs/inode.c
> > ===================================================================
> > --- linux-2.6.orig/fs/nfs/inode.c
> > +++ linux-2.6/fs/nfs/inode.c
> > @@ -1123,6 +1123,7 @@ struct inode *nfs_alloc_inode(struct sup
> > nfsi->flags = 0UL;
> > nfsi->cache_validity = 0UL;
> > nfsi->cache_change_attribute = jiffies;
> > + nfsi->req_lock = SPIN_LOCK_UNLOCKED;
> > #ifdef CONFIG_NFS_V3_ACL
> > nfsi->acl_access = ERR_PTR(-EAGAIN);
> > nfsi->acl_default = ERR_PTR(-EAGAIN);
>
> As Andrew implied, this spin lock should already be initialised by the
> slab allocator in the "init_once" callback. Is this a vanilla kernel, or
> do you have any extra patches applied?
Plain 2.6.20 on an old dual g5 with g5_defconfig + NFS_ROOT +
serial port enabled. To see the error instead of lockup I enable
CONFIG_DEBUG_SPINLOCK.
In my original reproduction, I had to boot with nfs root, and try to mount
my sata drive (/dev/sda3). This is with a static /dev, no udev. Seems like it
happens when trying to mount any block device that's located on NFS.
Since this is what nfs_sync_mapping_wait does:
long nfs_sync_mapping_wait(struct address_space *mapping, struct
writeback_control *wbc, int how) {
struct inode *inode = mapping->host;
struct nfs_inode *nfsi = NFS_I(inode);
[...]
spin_lock(&nfsi->req_lock);
[...]
I added this and it pops when mounting:
@@ -421,6 +421,10 @@ int nfs_getattr(struct vfsmount *mnt, st
int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME;
int err;
+ if (inode->i_mapping->host != inode) {
+ printk("inode %p host %p\n", inode, inode->i_mapping->host);
+ printk("inode_nfs %p host_nfs %p\n", NFS_I(inode), NFS_I(inode->i_mapping->host));
+ }
/* Flush out writes to the server in order to update c/mtime */
nfs_sync_mapping_range(inode->i_mapping, 0, 0, FLUSH_NOCOMMIT);
I don't claim to know VFS internals, but doesn't it make sense that the
device node is backed against the actual device, not an NFS inode? And
if so, NFS can't expect to do nfs_sync_mapping_range() on it, or at
least not dereference ->host and use it as an NFS inode, right?
What I'm not sure I understand is why it disappears in the first place
when I add the spin lock init -- I never even see the i_mapping->host
pointer being allocated as an nfs inode. Maybe I just messed that one
up somehow.
-Olof
next prev parent reply other threads:[~2007-02-20 17:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 17:05 [PATCH] nfs: init req_lock in nfs_alloc_inode Olof Johansson
2007-02-17 0:15 ` Andrew Morton
2007-02-17 1:24 ` Andrew Morton
2007-02-18 20:32 ` Olof Johansson
2007-02-20 15:10 ` Trond Myklebust
2007-02-20 17:23 ` Olof Johansson [this message]
2007-02-21 0:37 ` Trond Myklebust
2007-02-22 20:13 ` Olof Johansson
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=20070220172345.GA19249@lixom.net \
--to=olof@lixom.net \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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