From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: Problems running netvsc multiq
Date: Fri, 7 Dec 2018 09:31:06 -0800
Message-ID: <20181207093106.0d070d4b@xeon-e3>
References: <1543575881.5400.33.camel@redhat.com>
 <20181130102756.41332fc2@xeon-e3>
 <1879110132.59852748.1543604812639.JavaMail.zimbra@redhat.com>
 <20181204084858.03ecdf98@shemminger-XPS-13-9360>
 <1543942571.5400.38.camel@redhat.com>
 <20181205143238.5b4b1ae7@xeon-e3>
 <1544181343.5629.1.camel@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org, maxime coquelin <maxime.coquelin@redhat.com>, Yuhui Jiang
 <yujiang@redhat.com>, Wei Shi <wshi@redhat.com>
To: Mohammed Gamal <mgamal@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com
 [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 4817D5B40
 for <dev@dpdk.org>; Fri,  7 Dec 2018 18:31:10 +0100 (CET)
Received: by mail-pg1-f194.google.com with SMTP id v28so2003030pgk.10
 for <dev@dpdk.org>; Fri, 07 Dec 2018 09:31:10 -0800 (PST)
In-Reply-To: <1544181343.5629.1.camel@redhat.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, 07 Dec 2018 13:15:43 +0200
Mohammed Gamal <mgamal@redhat.com> wrote:

> On Wed, 2018-12-05 at 14:32 -0800, Stephen Hemminger wrote:
> > The problem is a regression in 4.20 kernel. Bisecting now. =20
>=20
> I was bisecting the kernel and the change that seems to introduce this
> regression is this one:
>=20
> commit ae6935ed7d424ffa74d634da00767e7b03c98fd3
> Author: Stephen Hemminger <stephen@networkplumber.org>
> Date:=C2=A0=C2=A0=C2=A0Fri Sep 14 09:10:17 2018 -0700
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0vmbus: split ring buffer allocation from open
> =C2=A0=C2=A0=C2=A0=C2=A0
> =C2=A0=C2=A0=C2=A0=C2=A0The UIO driver needs the ring buffer to be persis=
tent(reused)
> =C2=A0=C2=A0=C2=A0=C2=A0across open/close. Split the allocation and setup=
 of ring buffer
> =C2=A0=C2=A0=C2=A0=C2=A0out of vmbus_open. For normal usage vmbus_open/vm=
bus_close there
> =C2=A0=C2=A0=C2=A0=C2=A0are no changes; only impacts uio_hv_generic which=
 needs to keep
> =C2=A0=C2=A0=C2=A0=C2=A0ring buffer memory and reuse when application res=
tarts.
> =C2=A0=C2=A0=C2=A0=C2=A0
> =C2=A0=C2=A0=C2=A0=C2=A0Signed-off-by: Stephen Hemminger <sthemmin@micros=
oft.com>
> =C2=A0=C2=A0=C2=A0=C2=A0Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfo=
undation.org>
>=20

Yes, this is the kernel problem that introduces the problem.
The issue is actually back in the unbind logic.  When device is unbound
from the netvsc driver all the subchannels aren't cleaned up.

Still debugging.