On 01/17/2013 05:01 AM, Robin Holt wrote: > > There is a race condition between mmu_notifier_unregister() and > __mmu_notifier_release(). > > Assume two tasks, one calling mmu_notifier_unregister() as a result > of a filp_close() ->flush() callout (task A), and the other calling > mmu_notifier_release() from an mmput() (task B). > > A B > t1 srcu_read_lock() > t2 if (!hlist_unhashed()) > t3 srcu_read_unlock() > t4 srcu_read_lock() > t5 hlist_del_init_rcu() > t6 synchronize_srcu() > t7 srcu_read_unlock() > t8 hlist_del_rcu() <--- NULL pointer deref. The detailed code here is: hlist_del_rcu(&mn->hlist); Can mn be NULL? I do not think so since mn is always the embedded struct of the caller, it be freed after calling mmu_notifier_unregister. > > Tested with this patch applied. My test case which was failing > approximately every 300th iteration passed 25,000 tests. Could you please share your test case? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>