netdev - Re: [PATCH net] Revert "vhost: cache used event for better performance"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170726190745-mutt-send-email-mst@kernel.org>
Date:   Wed, 26 Jul 2017 19:08:26 +0300
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] Revert "vhost: cache used event for better
 performance"

On Wed, Jul 26, 2017 at 09:37:15PM +0800, Jason Wang wrote:
> 
> 
> On 2017年07月26日 21:18, Jason Wang wrote:
> > 
> > 
> > On 2017年07月26日 20:57, Michael S. Tsirkin wrote:
> > > On Wed, Jul 26, 2017 at 04:03:17PM +0800, Jason Wang wrote:
> > > > This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
> > > > was reported to break vhost_net. We want to cache used event and use
> > > > it to check for notification. We try to valid cached used event by
> > > > checking whether or not it was ahead of new, but this is not correct
> > > > all the time, it could be stale and there's no way to know about this.
> > > > 
> > > > Signed-off-by: Jason Wang<jasowang@...hat.com>
> > > Could you supply a bit more data here please?  How does it get stale?
> > > What does guest need to do to make it stale?  This will be helpful if
> > > anyone wants to bring it back, or if we want to extend the protocol.
> > > 
> > 
> > The problem we don't know whether or not guest has published a new used
> > event. The check vring_need_event(vq->last_used_event, new + vq->num,
> > new) is not sufficient to check for this.
> > 
> > Thanks
> 
> More notes, the previous assumption is that we don't move used event back,
> but this could happen in fact if idx is wrapper around.

You mean if the 16 bit index wraps around after 64K entries.
Makes sense.

> Will repost and add
> this into commit log.
> 
> Thanks