On Thu, Jan 17, 2013 at 10:45:32AM +0800, Xiao Guangrong wrote: > 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. If you look at __mmu_notifier_release() it is using hlist_del_init_rcu() which will set the hlist->pprev to NULL. When hlist_del_rcu() is called, it attempts to update *hlist->pprev = hlist->next and that is where it takes the NULL pointer deref. > > > > > 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? I could but it would be very useless. It depends upon having a SGI UV system with GRUs and and xpmem kernel module loaded. If you would really like all the bits, I could provide them, but you will not be able to reproduce the failure. Thanks, Robin -- 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>