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()
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
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
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
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
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
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
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
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.
Reported-by: Gonglei (Arei) arei.gong...@huawei.com
Signed-off-by: Michael
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.
10 matches
Mail list logo