From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Stephen Hemminger" <stephen@networkplumber.org>
Subject: Re: [PATCH 03/21] vhost: protect virtio_net device struct
Date: Tue, 5 Sep 2017 19:59:28 -0700
Message-ID: <000e01d326bc$27fdfbe0$77f9f3a0$@networkplumber.org>
References: <20170831095023.21037-1-maxime.coquelin@redhat.com>
 <20170831095023.21037-4-maxime.coquelin@redhat.com>
 <20170905044516.GC31895@debian-ZGViaWFuCg>
 <68468145-5b45-5875-b37f-35df3482379a@redhat.com>
 <20170905100751.GA7290@debian-ZGViaWFuCg>
 <0362ed01-211f-d4fc-d4ae-11ea81ad5df1@redhat.com>
 <20170906011459.GA3965@debian-ZGViaWFuCg>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
Cc: <dev@dpdk.org>, <yliu@fridaylinux.org>, <jfreiman@redhat.com>,
 <mst@redhat.com>, <vkaplans@redhat.com>, <jasowang@redhat.com>,
 <lei.a.yao@intel.com>, <cunming.liang@intel.com>
To: "'Tiwei Bie'" <tiwei.bie@intel.com>,
 "'Maxime Coquelin'" <maxime.coquelin@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com
 [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id 18658237
 for <dev@dpdk.org>; Wed,  6 Sep 2017 04:59:31 +0200 (CEST)
Received: by mail-pf0-f171.google.com with SMTP id m1so10773669pfk.1
 for <dev@dpdk.org>; Tue, 05 Sep 2017 19:59:30 -0700 (PDT)
In-Reply-To: <20170906011459.GA3965@debian-ZGViaWFuCg>
Content-Language: en-us
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> > > This lock has currently two purposes:
> > > 1. Prevent referencing freed virtio_dev struct in case of numa_realloc.
> > > 2. Protect vring pages against invalidation.
> > > 
> > > For 2., it can be fixed by using the per-vq IOTLB lock (it was not the
> > > case in my early prototypes that had per device IOTLB cache).
> > > 
> > > For 1., this is an existing problem, so we might consider it is
> > > acceptable to keep current state. Maybe it could be improved by only
> > > reallocating in case VQ0 is not on the right NUMA node, the other VQs
> > > not being initialized at this point.

Something like RCU does a better job of protecting against freed virtio_dev.
But using RCU requires quiescent callback in the main loop.