All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wedgwood <cw@f00f.org>,
	linux-xfs@oss.sgi.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.24-rc2 XFS nfsd hang
Date: Wed, 14 Nov 2007 12:39:22 -0500	[thread overview]
Message-ID: <20071114173922.GC14254@fieldses.org> (raw)
In-Reply-To: <20071114152952.GA4210@infradead.org>

On Wed, Nov 14, 2007 at 03:29:52PM +0000, Christoph Hellwig wrote:
> On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote:
> > With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
> > see a hang when accessing some NFS exported XFS filesystems.  Local
> > access to these filesystems ahead of time works without problems.
> > 
> > This does not occur with 2.6.23.1.  The filesystem does not appear to
> > be corrupt.
> > 
> 
> >     [ 1462.911360]  ffffffff80744020 ffffffff80746dc0 ffff81010129c140 ffff8101000ad100
> >     [ 1462.911391] Call Trace:
> >     [ 1462.911417]  [<ffffffff8052e638>] __down+0xe9/0x101
> >     [ 1462.911437]  [<ffffffff8022cc80>] default_wake_function+0x0/0xe
> >     [ 1462.911458]  [<ffffffff8052e275>] __down_failed+0x35/0x3a
> >     [ 1462.911480]  [<ffffffff8035ac25>] _xfs_buf_find+0x84/0x24d
> >     [ 1462.911501]  [<ffffffff8035ad34>] _xfs_buf_find+0x193/0x24d
> >     [ 1462.911522]  [<ffffffff803599b1>] xfs_buf_lock+0x43/0x45
> 
> this is bp->b_sema which lookup wants.
> 
> >     [ 1462.915534]  [<ffffffff8032b6da>] xfs_readdir+0x91/0xb6
> >     [ 1462.915557]  [<ffffffff8030415b>] nfs3svc_encode_entry_plus+0x0/0x13
> >     [ 1462.915579]  [<ffffffff8035be9d>] xfs_file_readdir+0x31/0x40
> >     [ 1462.915599]  [<ffffffff8028c9f8>] vfs_readdir+0x61/0x93
> >     [ 1462.915619]  [<ffffffff8030415b>] nfs3svc_encode_entry_plus+0x0/0x13
> >     [ 1462.915642]  [<ffffffff802fc78e>] nfsd_readdir+0x6d/0xc5
> 
> and this is the nasty nfsd case where a filldir callback calls back
> into lookup.  I suspect we're somehow holding b_sema already.  Previously
> this was okay because we weren't inside the actualy readdir code when
> calling filldir but operate on a copy of the data.
> 
> This gem has bitten other filesystem before, I'll see if I can find a
> way around it.

This must have come up before; feel free to remind me: is there any way
to make the interface easier to use?  (E.g. would it help if the filldir
callback could be passed a dentry?)

--b.

  reply	other threads:[~2007-11-14 17:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14  7:04 2.6.24-rc2 XFS nfsd hang Chris Wedgwood
2007-11-14  7:43 ` Benny Halevy
2007-11-14 12:59   ` J. Bruce Fields
2007-11-14 22:31     ` Christian Kujau
2007-11-15  7:51       ` 2.6.24-rc2 XFS nfsd hang / smbd too Christian Kujau
2007-11-15 14:44         ` Christian Kujau
2007-11-15 22:01         ` Christian Kujau
2007-11-16  0:34         ` Chris Wedgwood
2007-11-16  9:17           ` 2.6.24-rc2 XFS nfsd hang Christian Kujau
2007-11-16 11:03             ` Chris Wedgwood
2007-11-16 14:19               ` Trond Myklebust
2007-11-16 21:43                 ` Chris Wedgwood
2007-11-18 14:44                   ` Christian Kujau
2007-11-18 15:31                     ` Justin Piszcz
2007-11-18 22:07                       ` Christian Kujau
2007-11-14 11:49 ` 2.6.24-rc2 XFS nfsd hang --- filldir change responsible? Chris Wedgwood
2007-11-14 22:48   ` Christian Kujau
2007-11-14 15:29 ` 2.6.24-rc2 XFS nfsd hang Christoph Hellwig
2007-11-14 17:39   ` J. Bruce Fields [this message]
2007-11-14 17:44     ` Christoph Hellwig
2007-11-14 17:53       ` J. Bruce Fields
2007-11-14 18:02         ` Christoph Hellwig
2007-11-14 18:08           ` J. Bruce Fields
2007-11-21 15:07             ` Christoph Hellwig
2007-11-21 19:03               ` J. Bruce Fields
2007-11-25 16:30 ` [PATCH] xfs: revert to double-buffering readdir Christoph Hellwig
2007-11-27 19:43   ` Chris Wedgwood
2007-11-29 23:45   ` Christian Kujau
2007-11-30  7:47     ` David Chinner
2007-11-30  7:22   ` Timothy Shimmin
2007-11-30 22:36     ` Stephen Lord
2007-11-30 23:04       ` Chris Wedgwood
2007-12-01 13:04         ` Stephen Lord
2007-12-03 15:11       ` Christoph Hellwig
2007-12-03 15:09     ` Christoph Hellwig

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=20071114173922.GC14254@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=cw@f00f.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    /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.