Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753265AbbKZIf3 (ORCPT ); Thu, 26 Nov 2015 03:35:29 -0500 Received: from out4133-34.mail.aliyun.com ([42.120.133.34]:35897 "EHLO out4133-34.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752892AbbKZIf0 (ORCPT ); Thu, 26 Nov 2015 03:35:26 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03284;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_----4GZKXC2; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Naoya Horiguchi'" , "'Andrew Morton'" Cc: "'David Rientjes'" , "'Hugh Dickins'" , "'Dave Hansen'" , "'Mel Gorman'" , "'Joonsoo Kim'" , "'Mike Kravetz'" , , , "'Naoya Horiguchi'" References: <1448524936-10501-1-git-send-email-n-horiguchi@ah.jp.nec.com> In-Reply-To: <1448524936-10501-1-git-send-email-n-horiguchi@ah.jp.nec.com> Subject: Re: [PATCH v1] mm: hugetlb: call huge_pte_alloc() only if ptep is null Date: Thu, 26 Nov 2015 16:29:30 +0800 Message-ID: <00d301d12824$932eda30$b98c8e90$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCq1PhjRc7lRwOCCScrNwknb9jVNKD6nqfg Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2042 Lines: 53 > > Currently at the beginning of hugetlb_fault(), we call huge_pte_offset() > and check whether the obtained *ptep is a migration/hwpoison entry or not. > And if not, then we get to call huge_pte_alloc(). This is racy because the > *ptep could turn into migration/hwpoison entry after the huge_pte_offset() > check. This race results in BUG_ON in huge_pte_alloc(). > > We don't have to call huge_pte_alloc() when the huge_pte_offset() returns > non-NULL, so let's fix this bug with moving the code into else block. > > Note that the *ptep could turn into a migration/hwpoison entry after > this block, but that's not a problem because we have another !pte_present > check later (we never go into hugetlb_no_page() in that case.) > > Fixes: 290408d4a250 ("hugetlb: hugepage migration core") > Signed-off-by: Naoya Horiguchi > Cc: [2.6.36+] > --- Acked-by: Hillf Danton > mm/hugetlb.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git next-20151123/mm/hugetlb.c next-20151123_patched/mm/hugetlb.c > index 1101ccd..6ad5e91 100644 > --- next-20151123/mm/hugetlb.c > +++ next-20151123_patched/mm/hugetlb.c > @@ -3696,12 +3696,12 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, > } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) > return VM_FAULT_HWPOISON_LARGE | > VM_FAULT_SET_HINDEX(hstate_index(h)); > + } else { > + ptep = huge_pte_alloc(mm, address, huge_page_size(h)); > + if (!ptep) > + return VM_FAULT_OOM; > } > > - ptep = huge_pte_alloc(mm, address, huge_page_size(h)); > - if (!ptep) > - return VM_FAULT_OOM; > - > mapping = vma->vm_file->f_mapping; > idx = vma_hugecache_offset(h, vma, address); > > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/