Received: by 10.213.65.68 with SMTP id h4csp158625imn; Mon, 12 Mar 2018 09:44:02 -0700 (PDT) X-Google-Smtp-Source: AG47ELthoZWxkFRXYNerrWdDihP9JLGxsjgLYg7PU7zNH+RB2zGgoWfXSZW9foGofIIZSUzMDth4 X-Received: by 10.101.83.65 with SMTP id w1mr7250323pgr.313.1520873042558; Mon, 12 Mar 2018 09:44:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520873042; cv=none; d=google.com; s=arc-20160816; b=eo7o0JhIZ4W425QzFMlFTIR7JPvjhEIKmbiiHazJLR+16pPyGqxoHVqFgEt5URO/JF czYUjoc5emCercR5pelvvYigI4zP2mRs3k4YuvD2pFwIUczILRypc5kZSLUO37/FM6hn K73Y7r1HXAeDY5D2vzVwRR+MdjzP8BPzNJls1fQ4OEOFlDqCdz4OmMlm+WLBNEtTDQxd D/MlhOpvSQKrPH5hR7X3lBOmgkneJ0dAYagZeO8Kw6hTYJxb+g/RtcqXdddw1eR+SjXa P5BCoPTxXfWXWm8Rn0gSZOiQXzQ+ycrtUDYhjuPgTQBHUjPmKO2Pt7H/ybDMQGYDHcmw a6uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Ag8o3qy2PFuKjRNTqAlvLC2UVEqL0rSTuhhvOfTs82s=; b=S4BrvJZJ0Y6Ge0VB0Kp6xSkB6zEO3n52HDMbVWivNSd3YMDOEPRiDuSIec6Avb3cZn 3MSriIxpVqxxag5Jn6Nh5rYRwQovMNoGkgsxjsBd8/uMCYYr+T/0Wyqi9OCDc1g7UD9m dsNlp8rGX31g5keayBaFTTSh1QAxdcUA0YM1OqzlFmq2qqRYs/sMDJdtUd7OBSYH7TYw tzzllR9xTiA1Fr/OGEfLu8eOAvD4mu9/ezCa24l3kEfRAfg3+lFXlkkBm4ok9Qi3C6kj n5NzWEOy81CFUw7Yu+eH9G+92PyWCVtb+Qf8qI8fDrjPaSUBaqvR3K4YCW8oCoC1nYLw CNsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x87si6095303pff.17.2018.03.12.09.43.47; Mon, 12 Mar 2018 09:44:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751727AbeCLQm1 (ORCPT + 99 others); Mon, 12 Mar 2018 12:42:27 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59124 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751344AbeCLQm0 (ORCPT ); Mon, 12 Mar 2018 12:42:26 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2CGda88036067 for ; Mon, 12 Mar 2018 12:42:25 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gnvrksp9p-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Mon, 12 Mar 2018 12:42:24 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Mar 2018 16:42:22 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 12 Mar 2018 16:42:18 -0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w2CGgIOR65536040; Mon, 12 Mar 2018 16:42:18 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94BA4A4040; Mon, 12 Mar 2018 16:35:09 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40DA6A404D; Mon, 12 Mar 2018 16:35:09 +0000 (GMT) Received: from p-imbrenda.boeblingen.de.ibm.com (unknown [9.152.224.168]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 12 Mar 2018 16:35:09 +0000 (GMT) From: Claudio Imbrenda To: linux-kernel@vger.kernel.org Cc: akpm@linux-foundation.org, aarcange@redhat.com, minchan@kernel.org, kirill.shutemov@linux.intel.com, linux-mm@kvack.org, hughd@google.com, pholasek@redhat.com, borntraeger@de.ibm.com, gerald.schaefer@de.ibm.com Subject: [PATCH v1 1/1] mm/ksm: fix interaction with THP Date: Mon, 12 Mar 2018 17:42:17 +0100 X-Mailer: git-send-email 2.7.4 X-TM-AS-GCONF: 00 x-cbid: 18031216-0020-0000-0000-00000402741D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18031216-0021-0000-0000-00004296C5A3 Message-Id: <1520872937-15351-1-git-send-email-imbrenda@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-12_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803120189 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch fixes a corner case for KSM. When two pages belong or belonged to the same transparent hugepage, and they should be merged, KSM fails to split the page, and therefore no merging happens. This bug can be reproduced by: * making sure ksm is running (in case disabling ksmtuned) * enabling transparent hugepages * allocating a THP-aligned 1-THP-sized buffer e.g. on amd64: posix_memalign(&p, 1<<21, 1<<21) * filling it with the same values e.g. memset(p, 42, 1<<21) * performing madvise to make it mergeable e.g. madvise(p, 1<<21, MADV_MERGEABLE) * waiting for KSM to perform a few scans The expected outcome is that the all the pages get merged (1 shared and the rest sharing); the actual outcome is that no pages get merged (1 unshared and the rest volatile) The reason of this behaviour is that we increase the reference count once for both pages we want to merge, but if they belong to the same hugepage (or compound page), the reference counter used in both cases is the one of the head of the compound page. This means that split_huge_page will find a value of the reference counter too high and will fail. This patch solves this problem by testing if the two pages to merge belong to the same hugepage when attempting to merge them. If so, the hugepage is split safely. This means that the hugepage is not split if not necessary. Signed-off-by: Gerald Schaefer Signed-off-by: Claudio Imbrenda --- mm/ksm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mm/ksm.c b/mm/ksm.c index 293721f..7a826fa 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -2001,7 +2001,7 @@ static void cmp_and_merge_page(struct page *page, struct rmap_item *rmap_item) struct page *kpage; unsigned int checksum; int err; - bool max_page_sharing_bypass = false; + bool split, max_page_sharing_bypass = false; stable_node = page_stable_node(page); if (stable_node) { @@ -2084,6 +2084,8 @@ static void cmp_and_merge_page(struct page *page, struct rmap_item *rmap_item) if (tree_rmap_item) { kpage = try_to_merge_two_pages(rmap_item, page, tree_rmap_item, tree_page); + split = PageTransCompound(page) && PageTransCompound(tree_page) + && compound_head(page) == compound_head(tree_page); put_page(tree_page); if (kpage) { /* @@ -2110,6 +2112,11 @@ static void cmp_and_merge_page(struct page *page, struct rmap_item *rmap_item) break_cow(tree_rmap_item); break_cow(rmap_item); } + } else if (split) { + if (!trylock_page(page)) + return; + split_huge_page(page); + unlock_page(page); } } } -- 2.7.4