On Tue, May 13, 2014 at 05:18:41PM -0400, bfields wrote:
> On Tue, May 13, 2014 at 10:48:26AM -0400, J. Bruce Fields wrote:
> > On Tue, May 13, 2014 at 04:09:45AM -0700, Christoph Hellwig wrote:
> > > On Mon, May 12, 2014 at 09:11:28AM -0700, Christoph Hellwig wrote:
> > > > On Mon, May 12, 2014 at 12:07:41PM -0400, J. Bruce Fields wrote:
> > > > > On Mon, May 12, 2014 at 01:20:59AM -0700, Christoph Hellwig wrote:
> > > > > > This series seem to cause hangs during xfstests against a server on the
> > > > > > same VM. The trace is fairly similar every the hang happens, but the
> > > > > > point at which it happens differs:
> > > > >
> > > > > Ouch, OK, and you're sure it starts with this series?
> > > > >
> > > > > I guess I should try to replicate it here. Might take a copule days.
> > >
> > > Seems lile "nfsd4: allow exotic read compounds" is the culprit.
> >
> > OK, it makes sense that the problem would be there. Looking....
>
> I got xfstests set up and can reproduce some problems (a hang, the
> nfs4svc_encode_compoundres WARN, and some allocation failures), though
> not exactly what you reported.
>
> I also notice that commit ("nfsd4: allow exotic read compounds") has a
> lot of extraneous cleanup that I should split out.
In fact, the change to handle multiple reads per compound *should* only
affect the nfsd4_encode_readv() case. Whereas you're probably
exercising only the nfsd4_encode_splice_read() case. So probably some
of the extraneous cleanup in that patch is bogus.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
