Re: [PATCH 0/4] Fix probe failed when modprobe modules

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: axboe@kernel.dk, rusty@rustcorp.com.au, ericvh@gmail.com,
	netdev@vger.kernel.org, linux_oss@crudebyte.com,
	Li Zetao <lizetao1@huawei.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-block@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net, edumazet@google.com,
	stefanha@redhat.com, kuba@kernel.org, pbonzini@redhat.com,
	pabeni@redhat.com, davem@davemloft.net
Subject: Re: [PATCH 0/4] Fix probe failed when modprobe modules
Date: Mon, 19 Dec 2022 05:15:09 -0500	[thread overview]
Message-ID: <20221219050716-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CACGkMEtuOk+wyCsvY0uayGAvy926G381PC-csoXVAwCfiKCZQw@mail.gmail.com>

On Tue, Nov 29, 2022 at 11:37:09AM +0800, Jason Wang wrote:
> >
> >
> > Quite a lot of core work here. Jason are you still looking into
> > hardening?
> 
> Yes, last time we've discussed a solution that depends on the first
> kick to enable the interrupt handler. But after some thought, it seems
> risky since there's no guarantee that the device work in this way.
> 
> One example is the current vhost_net, it doesn't wait for the kick to
> process the rx packets. Any more thought on this?
> 
> Thanks

Specifically virtio net is careful to call virtio_device_ready
under rtnl lock so buffers are only added after DRIVER_OK.

However we do not need to tie this to kick, this is what I wrote:

> BTW Jason, I had the idea to disable callbacks until driver uses the
> virtio core for the first time (e.g. by calling virtqueue_add* family of
> APIs). Less aggressive than your ideas but I feel it will add security
> to the init path at least.

So not necessarily kick, we can make adding buffers allow the
interrupt.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization