From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by kanga.kvack.org (Postfix) with ESMTP id 2BCDA6B0005 for ; Wed, 20 Jul 2016 08:16:49 -0400 (EDT) Received: by mail-lf0-f69.google.com with SMTP id p41so31449588lfi.0 for ; Wed, 20 Jul 2016 05:16:49 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 124si10900809wmw.37.2016.07.20.05.16.47 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Jul 2016 05:16:47 -0700 (PDT) Date: Wed, 20 Jul 2016 14:16:46 +0200 From: Michal Hocko Subject: Re: [PATCH v2] mm/hugetlb: fix race when migrate pages Message-ID: <20160720121645.GJ11249@dhcp22.suse.cz> References: <1468935958-21810-1-git-send-email-zhongjiang@huawei.com> <20160720073859.GE11249@dhcp22.suse.cz> <578F4C7C.6000706@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <578F4C7C.6000706@huawei.com> Sender: owner-linux-mm@kvack.org List-ID: To: zhong jiang Cc: vbabka@suse.cz, qiuxishi@huawei.com, akpm@linux-foundation.org, linux-mm@kvack.org, Mike Kravetz , Naoya Horiguchi On Wed 20-07-16 18:03:40, zhong jiang wrote: > On 2016/7/20 15:38, Michal Hocko wrote: > > [CC Mike and Naoya] > > On Tue 19-07-16 21:45:58, zhongjiang wrote: > >> From: zhong jiang > >> > >> I hit the following code in huge_pte_alloc when run the database and > >> online-offline memory in the system. > >> > >> BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte)); > >> > >> when pmd share function enable, we may be obtain a shared pmd entry. > >> due to ongoing offline memory , the pmd entry points to the page will > >> turn into migrate condition. therefore, the bug will come up. > >> > >> The patch fix it by checking the pmd entry when we obtain the lock. > >> if the shared pmd entry points to page is under migration. we should > >> allocate a new pmd entry. > > > > I am still not 100% sure this is correct. Does huge_pte_lockptr work > > properly for the migration swapentry? What about this part? > > If yes and we populate the pud > > with a migration entry then is it really bad/harmful (other than hitting > > the BUG_ON which might be update to handle that case)? This might be a > > stupid question, sorry about that, but I have really problem to grasp > > the whole issue properly and the changelog didn't help me much. I would > > really appreciate some clarification here. The pmd sharing code is clear > > as mud and adding new tweaks there doesn't sound like it would make it > > more clear. > > ok, Maybe the following explain will better. > cpu0 cpu1 > try_to_unmap_one huge_pmd_share > page_check_address huge_pte_lockptr > spin_lock > (page entry can be set to migrate or > Posion ) > > pte_unmap_unlock > spin_lock > (page entry have changed) Well, but this is just one possible race. We can also race after pud_populate: cpu0 cpu1 try_to_unmap_on huge_pmd_share page_check_address huge_pte_lockptr spin_lock pud_populate spin_unlock spin_lock(ptl) set_migration_entry spun_unlock() pmd_alloc # we will get migration entry So unless I am missing something here we either have to be able to cope with migration entries somehow already or we need some additional care for shared pmd entries (aka shared pud page) for this to behave properly. -- Michal Hocko SUSE Labs -- 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