From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx189.postini.com [74.125.245.189]) by kanga.kvack.org (Postfix) with SMTP id 01DD56B0006 for ; Fri, 18 Jan 2013 07:51:55 -0500 (EST) Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 Jan 2013 18:19:59 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id ED90AE0050 for ; Fri, 18 Jan 2013 18:22:12 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0ICpleE47317236 for ; Fri, 18 Jan 2013 18:21:47 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0ICpmqc010053 for ; Fri, 18 Jan 2013 23:51:49 +1100 Message-ID: <50F94562.6010909@linux.vnet.ibm.com> Date: Fri, 18 Jan 2013 20:51:46 +0800 From: Xiao Guangrong MIME-Version: 1.0 Subject: Re: [PATCH] [Patch] mmu_notifier_unregister NULL Pointer deref fix. References: <20130115162956.GH3438@sgi.com> <20130116200018.GA3460@sgi.com> <20130116210124.GB3460@sgi.com> <50F765CC.9040608@linux.vnet.ibm.com> <20130117111213.GM3438@sgi.com> <50F7EC6B.6030401@linux.vnet.ibm.com> <20130117134523.GN3438@sgi.com> <50F8B67F.4090901@linux.vnet.ibm.com> <20130118024856.GC3460@sgi.com> <50F8BBAA.1020904@linux.vnet.ibm.com> <20130118121439.GR3438@sgi.com> In-Reply-To: <20130118121439.GR3438@sgi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Robin Holt Cc: Andrea Arcangeli , linux-mm@kvack.org, Wanpeng Li , Avi Kivity , Hugh Dickins , Marcelo Tosatti , Sagi Grimberg , Haggai Eran On 01/18/2013 08:14 PM, Robin Holt wrote: > On Fri, Jan 18, 2013 at 11:04:10AM +0800, Xiao Guangrong wrote: >> On 01/18/2013 10:48 AM, Robin Holt wrote: >>> On Fri, Jan 18, 2013 at 10:42:07AM +0800, Xiao Guangrong wrote: >>>> On 01/17/2013 09:45 PM, Robin Holt wrote: >>>>> On Thu, Jan 17, 2013 at 08:19:55PM +0800, Xiao Guangrong wrote: >>>>>> On 01/17/2013 07:12 PM, Robin Holt wrote: >>>>>>> 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. >>>>>> >>>>>> Yes, sorry for my careless. So, That can not be fixed by using >>>>>> hlist_del_init_rcu instead? >>>>> >>>>> The problem is the race described above. Thread 'A' has checked to see >>>>> if n->pprev != NULL. Based upon that, it did called the mn->release() >>>>> method. While it was trying to call the release method, thread 'B' ended >>>>> up calling hlist_del_init_rcu() which set n->pprev = NULL. Then thread >>>>> 'A' got to run again and now it tries to do the hlist_del_rcu() which, as >>>>> part of __hlist_del(), the pprev will be set to n->pprev (which is NULL) >>>>> and then *pprev = n->next; hits the NULL pointer deref hits. >>>> >>>> I mean using hlist_del_init_rcu instead of hlist_del_rcu in >>>> mmu_notifier_unregister(), hlist_del_init_rcu is aware of ->pprev. >>> >>> How does that address the calling of the ->release() method twice? >> >> Hmm, what is the problem of it? If it is just for "performance issue", i think >> it is not worth introducing so complex lock rule just for the really rare case. > > Complex lock rule? We merely moved the lock up earlier in code path. > Without this, we have some cases where you get called on ->release() > twice, while the majority of cases your notifier gets called once and > it hits a NULL pointer deref at that. What is so complex about that? Aha, if we use hlist_del_init_rcu() instead of hlist_del_rcu, can the NULL deref bug be fixed? - If yes, you'd better make it as a simple patch, it is good for backport. Then make the second patch to fix the "problem" of calling ->release twice. - if no. Could you please detail the changelog. From the changelog, i only see the bug is cased by calling hlist_del_rcu on the unhashed node. Thank you! :) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org