Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-05 Thread Michael S. Tsirkin
On Wed, Jun 04, 2014 at 10:51:12PM +0300, Michael S. Tsirkin wrote: > On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: > > On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: > > > Il 02/06/2014 23:58, Eric Dumazet ha scritto: > > > > This looks dubious > > > > > > > > What about

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-05 Thread Michael S. Tsirkin
On Wed, Jun 04, 2014 at 10:51:12PM +0300, Michael S. Tsirkin wrote: On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu()

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: > On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: > > Il 02/06/2014 23:58, Eric Dumazet ha scritto: > > > This looks dubious > > > > > > What about using kfree_rcu() instead ? > > > > It would lead to unbound allocation from

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Mon, Jun 02, 2014 at 02:58:00PM -0700, Eric Dumazet wrote: > On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: > > All memory accesses are done under some VQ mutex. > > So lock/unlock all VQs is a faster equivalent of synchronize_rcu() > > for memory access changes. > > Some guests

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Mon, Jun 02, 2014 at 02:58:00PM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: All memory accesses are done under some VQ mutex. So lock/unlock all VQs is a faster equivalent of synchronize_rcu() for memory access changes. Some guests cause a

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:57, Eric Dumazet ha scritto: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look at how we did this in

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Eric Dumazet
On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: > Il 02/06/2014 23:58, Eric Dumazet ha scritto: > > This looks dubious > > > > What about using kfree_rcu() instead ? > > It would lead to unbound allocation from userspace. Look at how we did this in commit

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:35, Vlad Yasevich ha scritto: > Yes, vhost_get_vq_desc must be called with the vq mutex held. > > The rcu_read_lock/unlock in translate_desc is unnecessary. If that's true, then does dev->memory really needs to be rcu protected? It appears to always be read under mutex. It's

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Vlad Yasevich
On 06/03/2014 08:48 AM, Paolo Bonzini wrote: > Il 02/06/2014 23:58, Eric Dumazet ha scritto: >> This looks dubious >> >> What about using kfree_rcu() instead ? > > It would lead to unbound allocation from userspace. > >> translate_desc() still uses rcu_read_lock(), its not clear if the mutex >>

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really held. Yes, vhost_get_vq_desc must be called with

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really held. Yes, vhost_get_vq_desc must be called with

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Vlad Yasevich
On 06/03/2014 08:48 AM, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:35, Vlad Yasevich ha scritto: Yes, vhost_get_vq_desc must be called with the vq mutex held. The rcu_read_lock/unlock in translate_desc is unnecessary. If that's true, then does dev-memory really needs to be rcu protected? It appears to always be read under mutex. It's

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Eric Dumazet
On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look at how we did this in commit c3059477fce2d956a0bb3e04357324780c5d8eeb

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:57, Eric Dumazet ha scritto: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look at how we did this in

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-02 Thread Eric Dumazet
On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: > All memory accesses are done under some VQ mutex. > So lock/unlock all VQs is a faster equivalent of synchronize_rcu() > for memory access changes. > Some guests cause a lot of these changes, so it's helpful > to make them faster. > >

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-02 Thread Eric Dumazet
On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: All memory accesses are done under some VQ mutex. So lock/unlock all VQs is a faster equivalent of synchronize_rcu() for memory access changes. Some guests cause a lot of these changes, so it's helpful to make them faster.