Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755777AbcLBUL0 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Dec 2016 15:11:26 -0500
Received: from mx2.mpynet.fi ([82.197.21.85]:45548 "EHLO mx2.mpynet.fi"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752252AbcLBULZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Dec 2016 15:11:25 -0500
Date: Fri, 2 Dec 2016 22:11:22 +0200
From: Tuomas Tynkkynen <tuomas@tuxera.com>
To: Eric Van Hensbergen <ericvh@gmail.com>
CC: V9FS Developers <v9fs-developer@lists.sourceforge.net>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 9pfs hangs since 4.7
Message-ID: <20161202221122.296f130e@duuni>
In-Reply-To: <CAFkjPTkLVCf363Mi1zc5+5jUNGLtU2t=Xk-YiwMkCmHhAiyn2g@mail.gmail.com>
References: <20161124215023.02deb03c@duuni>
        <CAFkjPTkLVCf363Mi1zc5+5jUNGLtU2t=Xk-YiwMkCmHhAiyn2g@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: tuxera-exch.ad.tuxera.com (10.20.48.11) To
 tuxera-exch.ad.tuxera.com (10.20.48.11)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1569
Lines: 38

On Tue, 29 Nov 2016 10:39:39 -0600
Eric Van Hensbergen <ericvh@gmail.com> wrote:

> Any idea of what xfstests is doing at this point in time?  I'd be a
> bit worried about some sort of loop in the namespace since it seems to
> be in path traversal.  Could also be some sort of resource leak or
> fragmentation, I'll admit that many of the regression tests we do are
> fairly short in duration.  Another approach would be to look at doing
> this with a different server (over a network link instead of virtio)
> to isolate it as a client versus server side problem (although from
> the looks of things this does seem to be a client issue).

The xfstests part where it hangs is either of these loops:

FILES=1000
for i in `seq 0 1 $FILES`; do
        (
                sleep 5
                xfs_io -f -c "truncate 10485760" $SCRATCH_MNT/testfile.$i
                dd if=/dev/zero of=$SCRATCH_MNT/testfile.$i bs=4k conv=notrunc
        ) > /dev/null 2>&1 &
done
wait

for i in `seq 0 1 $FILES`; do
        dd of=/dev/null if=$SCRATCH_MNT/testfile.$i bs=512k iflag=direct > /dev/null 2>&1 &
done
wait

So all what's happening on the 9p is a bunch of reads+opens
on the binaries (sleep, xfs_io, dd) and their .so dependencies
(which includes some readlinks as well apparently).

I also tried building QEMU with tracing support enabled and
according to its own 9p event log the server did end up replying
to each client request (i.e. each v9fs_foo with a given tag was
was matched up with a v9fs_foo_return or a v9fs_rerror)...
so yes, looking more like a client problem.