Re: WARNING in __mmdrop
From: Jason Wang <hidden>
Date: 2019-07-23 13:31:50
Also in:
linux-mm, lkml
On 2019/7/23 下午5:26, Michael S. Tsirkin wrote:
On Tue, Jul 23, 2019 at 04:49:01PM +0800, Jason Wang wrote:quoted
On 2019/7/23 下午4:10, Michael S. Tsirkin wrote:quoted
On Tue, Jul 23, 2019 at 03:53:06PM +0800, Jason Wang wrote:quoted
On 2019/7/23 下午3:23, Michael S. Tsirkin wrote:quoted
quoted
quoted
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.quoted
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?So invalidate callbacks need to reset the map, and they do not have vq mutex. How can they do this and free the map safely? They need synchronize_rcu or kfree_rcu right?Invalidation callbacks need but file operations (e.g ioctl) not.quoted
And I worry somewhat that synchronize_rcu in an MMU notifier is a problem, MMU notifiers are supposed to be quick:Looks not, since it can allow to be blocked and lots of driver depends on this. (E.g mmu_notifier_range_blockable()).Right, they can block. So why don't we take a VQ mutex and be done with it then? No RCU tricks.
This is how I want to go with RFC and V1. But I end up with deadlock between vq locks and some MM internal locks. So I decide to use RCU which is 100% under the control of vhost. Thanks _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel