On Mon, 2008-07-21 at 04:10 -0400, Christoph Hellwig wrote:
> On Sun, Jul 20, 2008 at 09:43:50AM -0700, David Woodhouse wrote:
> > The way GFS1 (and also XFS iirc) handles it is to build up a complete
> > list of responses to readdir() in a buffer, drop the lock, and then
> > iterate over that buff
On Sun, Jul 20, 2008 at 09:43:50AM -0700, David Woodhouse wrote:
> The way GFS1 (and also XFS iirc) handles it is to build up a complete
> list of responses to readdir() in a buffer, drop the lock, and then
> iterate over that buffer calling filldir(). I don't much like that
> version either.
Yes.
On Mon, 2008-07-21 at 01:06 +0530, Balaji Rao wrote:
> The idea of the patch seems correct to me, that once we "own" the
> lock, an attempt to take it again should be a nop.
Well, kind of correct. There are potentially race conditions with the
handling of f->readdir_process, but given that we only
On Sunday 20 July 2008 10:13:50 pm David Woodhouse wrote:
> On Mon, 2008-07-21 at 00:41 +0530, Balaji Rao wrote:
> > Hi,
> >
> > There's a problem in btrfs_readdir that tries to lock a root node with
> > one being held. This happens when NFS calls vfs_readdir function with a
> > nfs specific filldi
On Mon, 2008-07-21 at 00:41 +0530, Balaji Rao wrote:
> Hi,
>
> There's a problem in btrfs_readdir that tries to lock a root node with one
> being held. This happens when NFS calls vfs_readdir function with a nfs
> specific filldir function pointer. This filldir function, called with the
> lock
