All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Li Zetao <lizetao1@huawei.com>,
	pbonzini@redhat.com, stefanha@redhat.com, axboe@kernel.dk,
	kraxel@redhat.com, david@redhat.com, ericvh@gmail.com,
	lucho@ionkov.net, asmadeus@codewreck.org,
	linux_oss@crudebyte.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	rusty@rustcorp.com.au, virtualization@lists.linux-foundation.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org
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


WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2022-12-19 10:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28  2:10 [PATCH 0/4] Fix probe failed when modprobe modules Li Zetao
2022-11-28  2:10 ` [PATCH 1/4] 9p: Fix probe failed when modprobe 9pnet_virtio Li Zetao
2022-11-28 14:27   ` Christian Schoenebeck
2022-11-28  2:10 ` [PATCH 2/4] virtio-mem: Fix probe failed when modprobe virtio_mem Li Zetao
2022-11-28  8:22   ` David Hildenbrand
2022-11-28  8:22     ` David Hildenbrand
2022-11-28  2:10 ` [PATCH 3/4] virtio-input: Fix probe failed when modprobe virtio_input Li Zetao
2022-11-28  9:29   ` Michael S. Tsirkin
2022-11-28  9:29     ` Michael S. Tsirkin
2022-11-28  2:10 ` [PATCH 4/4] virtio-blk: Fix probe failed when modprobe virtio_blk Li Zetao
2022-11-28 10:14 ` [PATCH 0/4] Fix probe failed when modprobe modules Michael S. Tsirkin
2022-11-28 10:14   ` Michael S. Tsirkin
2022-11-29  3:37   ` Jason Wang
2022-11-29  3:37     ` Jason Wang
2022-12-19 10:15     ` Michael S. Tsirkin [this message]
2022-12-19 10:15       ` Michael S. Tsirkin
2022-12-20  6:44       ` Jason Wang
2022-12-20  6:44         ` Jason Wang
2023-01-27 11:11   ` Michael S. Tsirkin
2023-01-27 11:11     ` Michael S. Tsirkin
2023-01-29  5:50     ` Jason Wang
2023-01-29  5:50       ` Jason Wang
2022-11-29 16:06 ` [PATCH v2 0/5] " Li Zetao
2022-11-29 16:06   ` Li Zetao
2022-11-29 16:06   ` [PATCH v2 1/5] 9p: Fix probe failed when modprobe 9pnet_virtio Li Zetao
2022-11-29 16:06     ` Li Zetao
2022-11-29 16:06   ` [PATCH v2 2/5] virtio-mem: Fix probe failed when modprobe virtio_mem Li Zetao
2022-11-29 16:06     ` Li Zetao
2022-11-29 16:06   ` [PATCH v2 3/5] virtio-input: Fix probe failed when modprobe virtio_input Li Zetao
2022-11-29 16:06     ` Li Zetao
2022-11-29 16:06   ` [PATCH v2 4/5] virtio-blk: Fix probe failed when modprobe virtio_blk Li Zetao
2022-11-29 16:06     ` Li Zetao
2022-11-29 16:06   ` [PATCH v2 5/5] drm/virtio: Fix probe failed when modprobe virtio_gpu Li Zetao
2022-11-29 16:06     ` Li Zetao
2022-11-29 17:08   ` [PATCH v2 0/5] Fix probe failed when modprobe modules Jens Axboe
2022-11-29 17:08     ` Jens Axboe
2022-11-29 17:08     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221219050716-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=asmadeus@codewreck.org \
    --cc=axboe@kernel.dk \
    --cc=davem@davemloft.net \
    --cc=david@redhat.com \
    --cc=edumazet@google.com \
    --cc=ericvh@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lizetao1@huawei.com \
    --cc=lucho@ionkov.net \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=stefanha@redhat.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.