Re: WARNING in __mmdrop

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

 




On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:
Really let's just use kfree_rcu. It's way cleaner: fire and forget.
Looks not, you need rate limit the fire as you've figured out?
See the discussion that followed. Basically no, it's good enough
already and is only going to be better.

And in fact,
the synchronization is not even needed, does it help if I leave a comment to
explain?
Let's try to figure it out in the mail first. I'm pretty sure the
current logic is wrong.


Here is what the code what to achieve:

- The map was protected by RCU

- Writers are: MMU notifier invalidation callbacks, file operations (ioctls etc), meta_prefetch (datapath)

- Readers are: memory accessor

Writer are synchronized through mmu_lock. RCU is used to synchronized between writers and readers.

The synchronize_rcu() in vhost_reset_vq_maps() was used to synchronized it with readers (memory accessors) in the path of file operations. But in this case, vq->mutex was already held, this means it has been serialized with memory accessor. That's why I think it could be removed safely.

Anything I miss here?



Btw, for kvm ioctl it still uses synchronize_rcu() in kvm_vcpu_ioctl(),
(just a little bit more hard to trigger):
AFAIK these never run in response to guest events.
So they can take very long and guests still won't crash.
What if guest manages to escape to qemu?

Thanks
Then it's going to be slow. Why do we care?
What we do not want is synchronize_rcu that guest is blocked on.


Ok, this looks like that I have some misunderstanding here of the reason why synchronize_rcu() is not preferable in the path of ioctl. But in kvm case, if rcu_expedited is set, it can triggers IPIs AFAIK.

Thanks





[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux