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
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 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
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
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 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
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
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 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
>>
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
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
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.
>
>
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.
18 matches
Mail list logo