[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121019124454.316ecfac@notabene.brown>
Date: Fri, 19 Oct 2012 12:44:54 +1100
From: NeilBrown <neilb@...e.de>
To: Jan Kara <jack@...e.cz>,
"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc: Paul Bolle <pebolle@...cali.nl>,
Fabio Coatti <fabio.coatti@...il.com>,
linux-kernel@...r.kernel.org, Jeff Layton <jlayton@...hat.com>
Subject: Re: ext3 issue on 3.6.1
On Fri, 19 Oct 2012 00:08:09 +0200 Jan Kara <jack@...e.cz> wrote:
> On Thu 18-10-12 23:40:25, Paul Bolle wrote:
> > On Thu, 2012-10-18 at 23:23 +0200, Jan Kara wrote:
> > > On Fri 12-10-12 14:57:55, Fabio Coatti wrote:
> > > > [13031.051521] ------------[ cut here ]------------
> > > > [13031.051576] WARNING: at fs/inode.c:280 drop_nlink+0x1b/0x35()
> > > > [13031.051624] Hardware name: ProLiant BL465c G7
> > > > [13031.051668] Pid: 3344, comm: php Tainted: G W
> > > > 3.6.1-1000hz-preempt #2
> > > > [13031.051746] Call Trace:
> > > > [13031.051787] [<ffffffff810578c4>] ? warn_slowpath_common+0x73/0x87
> > > > [13031.051837] [<ffffffff810ec628>] ? drop_nlink+0x1b/0x35
> > > > [13031.051885] [<ffffffff8118ad51>] ? nfs_dentry_iput+0x33/0x49
> > > > [13031.051934] [<ffffffff810ea920>] ? d_kill+0xe8/0x108
> > > > [13031.051980] [<ffffffff810eb001>] ? dput+0x147/0x154
> > > > [13031.052027] [<ffffffff810d9e46>] ? __fput+0x19a/0x1b2
> > > > [13031.052073] [<ffffffff8106bdf0>] ? task_work_run+0x4c/0x60
> > > > [13031.052123] [<ffffffff815ff5e8>] ? int_signal+0x12/0x17
> > > > [13031.052169] ---[ end trace e60232a455c8e2dd ]---
> > > And this seems unrelated - likely an NFS problem... Let's sort this out
> > > if you still see it after ext3 issue is solved.
> >
> > Looks rather similar too https://lkml.org/lkml/2012/8/29/165 , doesn't
> > it?
> Yup. I wonder why that patch didn't get merged. Neil?
>
> Honza
Don't know. Maybe I slipped under Trond's radar some how.
Trond: can you comment on and hopefully apply this patch?
Subject of original email was "WARNING: at fs/inode.c:280 drop_nlink+0x31/0x33()
Thanks,
NeilBrown
------
Subject: NFS: avoid warning from nfs_drop_nlink
If you remove a file which is open, NFS will 'silly-rename' it to a
hidden file.
If you then remove that hidden file, and then close the open file,
then nfs_dentry_iput will perform an extra drop_nlink().
Since 3.3-rc1, this has produced a warning.
The simplest way to suppress it is to use "nfs_drop_nlink" which
checks for i_nlink being zero.
Reviewed-by: Jeff Layton <jlayton@...hat.com>
Signed-off-by: NeilBrown <neilb@...e.de>
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 627f108..268af03 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1174,7 +1174,7 @@ static void nfs_dentry_iput(struct dentry *dentry,
struct inode *inode) NFS_I(inode)->cache_validity |= NFS_INO_INVALID_DATA;
if (dentry->d_flags & DCACHE_NFSFS_RENAMED) {
- drop_nlink(inode);
+ nfs_drop_nlink(inode);
nfs_complete_unlink(dentry, inode);
}
iput(inode);
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists