Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1177032AbdDYI7T (ORCPT ); Tue, 25 Apr 2017 04:59:19 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59293 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1177000AbdDYI6n (ORCPT ); Tue, 25 Apr 2017 04:58:43 -0400 To: wujianguo@huawei.com Cc: n-horiguchi@ah.jp.nec.com, Linux Memory Management List , Linux Kernel Mailing List From: Anshuman Khandual Subject: Freeing HugeTLB page into buddy allocator Date: Tue, 25 Apr 2017 14:27:27 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17042508-0016-0000-0000-000002335181 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17042508-0017-0000-0000-000006AEB979 Message-Id: <4f609205-fb69-4af5-3235-3abf05aa822a@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-25_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250165 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2454 Lines: 65 Hello Jianguo, In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being freed into buddy allocator instead of hugepage_freelists. But if I look the code closely for the function unmap_and_move_huge_page() it only calls putback_active_hugepage() which puts the page into the huge page active list to free up the source HugeTLB page after any successful migration. I might be missing something here, so can you please point me where we release the HugeTLB page into buddy allocator directly during migration ? commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8 Author: Jianguo Wu Date: Wed Dec 18 17:08:54 2013 -0800 mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully After a successful hugetlb page migration by soft offline, the source page will either be freed into hugepage_freelists or buddy(over-commit page). If page is in buddy, page_hstate(page) will be NULL. It will hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page(). BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [] dequeue_hwpoisoned_huge_page+0x131/0x1d0 PGD c23762067 PUD c24be2067 PMD 0 Oops: 0000 [#1] SMP So check PageHuge(page) after call migrate_pages() successfully. Signed-off-by: Jianguo Wu Tested-by: Naoya Horiguchi Reviewed-by: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds diff --git a/mm/memory-failure.c b/mm/memory-failure.c index b7c1716..db08af9 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1505,10 +1505,16 @@ static int soft_offline_huge_page(struct page *page, int flags) if (ret > 0) ret = -EIO; } else { - set_page_hwpoison_huge_page(hpage); - dequeue_hwpoisoned_huge_page(hpage); - atomic_long_add(1 << compound_order(hpage), - &num_poisoned_pages); + /* overcommit hugetlb page will be freed to buddy */ + if (PageHuge(page)) { + set_page_hwpoison_huge_page(hpage); + dequeue_hwpoisoned_huge_page(hpage); + atomic_long_add(1 << compound_order(hpage), + &num_poisoned_pages); + } else { + SetPageHWPoison(page); + atomic_long_inc(&num_poisoned_pages); + } } return ret; } Regards Anshuman