Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/8/20 上午5:08, Michael S. Tsirkin wrote:
On Tue, Aug 13, 2019 at 04:12:49PM +0800, Jason Wang wrote:
On 2019/8/12 下午5:49, Michael S. Tsirkin wrote:
On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote:
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
Hi all:

This series try to fix several issues introduced by meta data
accelreation series. Please review.

Changes from V4:
- switch to use spinlock synchronize MMU notifier with accessors

Changes from V3:
- remove the unnecessary patch

Changes from V2:
- use seqlck helper to synchronize MMU notifier with vhost worker

Changes from V1:
- try not use RCU to syncrhonize MMU notifier with vhost worker
- set dirty pages after no readers
- return -EAGAIN only when we find the range is overlapped with
     metadata

Jason Wang (9):
     vhost: don't set uaddr for invalid address
     vhost: validate MMU notifier registration
     vhost: fix vhost map leak
     vhost: reset invalidate_count in vhost_set_vring_num_addr()
     vhost: mark dirty pages during map uninit
     vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
     vhost: do not use RCU to synchronize MMU notifier with worker
     vhost: correctly set dirty pages in MMU notifiers callback
     vhost: do not return -EAGAIN for non blocking invalidation too early

    drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
    drivers/vhost/vhost.h |   6 +-
    2 files changed, 122 insertions(+), 86 deletions(-)
This generally looks more solid.

But this amounts to a significant overhaul of the code.

At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
for this release, and then re-apply a corrected version
for the next one?
If possible, consider we've actually disabled the feature. How about just
queued those patches for next release?

Thanks
Sorry if I was unclear. My idea is that
1. I revert the disabled code
2. You send a patch readding it with all the fixes squashed
3. Maybe optimizations on top right away?
4. We queue *that* for next and see what happens.

And the advantage over the patchy approach is that the current patches
are hard to review. E.g.  it's not reasonable to ask RCU guys to review
the whole of vhost for RCU usage but it's much more reasonable to ask
about a specific patch.

Ok. Then I agree to revert.

Thanks
Great, so please send the following:
- revert
- squashed and fixed patch


Just to confirm, do you want me to send a single series or two?

Thanks







[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux