Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3661676imu; Fri, 30 Nov 2018 04:09:40 -0800 (PST) X-Google-Smtp-Source: AFSGD/WWoCXOIgu55rw1XrNhkGPQdRaLMjS+PNjNcp2XtIrxqBoODTwCU5vOHeLUgbn+sGGObk3E X-Received: by 2002:aa7:8354:: with SMTP id z20mr5285779pfm.81.1543579780688; Fri, 30 Nov 2018 04:09:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543579780; cv=none; d=google.com; s=arc-20160816; b=fA1FUsrVc/wdY80RhaLKQH6RzjgH4isrLXD8BgDW//hM/VlWpE+FMWLLIwC+r+cJ9T sFnELJCIkLWSzn/qXVmIEg0PWEr2p9E1QFAxPMELFyY38z0Eh+FREYy0hDmRS8MExcVU 0raxZuFZbqEo3w4+YJ/moxW8ajRcBNiD1ywLScQ2dwXwncHHzTn4VNKXUb9G1Isb1Y+C 7+myvqyckrdDAe6GW6vYRlFybY7ab5OvnZGMuHg38SigehstFgUqW09ZyRc1dJAyl3eo nDyS+GFq5b3hkh9P9r0ZRlhNFUzhVxmXwIG5RNth/drbV6SVbnZ309UM5BbNS/InR65C OIvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=D3jwzpMoHRT+f0aB8dnx9/gOhWa3+MYaIx9PIIFmycQ=; b=bfcQZrLn8HC3Q/5wBU7bWTEzPYprLVXMXE2LOWfr/u5IBAcmrshaU3MQ7sX6ZMlDmG RFRAqDojIn6/LdDXF8Z6iUm1GrAKh9HmUYZwwsq6pSf7isxWTvbqmSWqrSrb0jQdxS0b tSSfiSDnDd2IBye8HSEpEfkol0NmR0CnSjYAUalJQYA22Q5kSyCSxxCbVyZBq6MiYbsl LlMNgT43+1AdL0XzDNqPhUlVmogKg9Dpo/QKyU7mSdUS21XkZvpZaR5Jg4MCfo+yOp6S 5J4HqMzFrBpu/yl+SRWfDfPnVXU0/+HhIVtBolIxCDzrTNdYTak/AxwO1WmRM6xu7qWO Y95w== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j3si4923450plk.199.2018.11.30.04.09.25; Fri, 30 Nov 2018 04:09:40 -0800 (PST) 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726637AbeK3XQN (ORCPT + 99 others); Fri, 30 Nov 2018 18:16:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726521AbeK3XQN (ORCPT ); Fri, 30 Nov 2018 18:16:13 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7BB8230025E0; Fri, 30 Nov 2018 12:07:09 +0000 (UTC) Received: from dustball.brq.redhat.com (unknown [10.43.17.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id 80A3426345; Fri, 30 Nov 2018 12:07:04 +0000 (UTC) From: Jan Stancek To: linux-mm@kvack.org, lersek@redhat.com, alex.williamson@redhat.com, aarcange@redhat.com, rientjes@google.com, kirill@shutemov.name, mgorman@techsingularity.net, mhocko@suse.com, jstancek@redhat.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP Date: Fri, 30 Nov 2018 13:06:57 +0100 Message-Id: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 30 Nov 2018 12:07:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org LTP proc01 testcase has been observed to rarely trigger crashes on arm64: page_mapped+0x78/0xb4 stable_page_flags+0x27c/0x338 kpageflags_read+0xfc/0x164 proc_reg_read+0x7c/0xb8 __vfs_read+0x58/0x178 vfs_read+0x90/0x14c SyS_read+0x60/0xc0 Issue is that page_mapped() assumes that if compound page is not huge, then it must be THP. But if this is 'normal' compound page (COMPOUND_PAGE_DTOR), then following loop can keep running (for HPAGE_PMD_NR iterations) until it tries to read from memory that isn't mapped and triggers a panic: for (i = 0; i < hpage_nr_pages(page); i++) { if (atomic_read(&page[i]._mapcount) >= 0) return true; } I could replicate this on x86 (v4.20-rc4-98-g60b548237fed) only with a custom kernel module [1] which: - allocates compound page (PAGEC) of order 1 - allocates 2 normal pages (COPY), which are initialized to 0xff (to satisfy _mapcount >= 0) - 2 PAGEC page structs are copied to address of first COPY page - second page of COPY is marked as not present - call to page_mapped(COPY) now triggers fault on access to 2nd COPY page at offset 0x30 (_mapcount) [1] https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c Fix the loop to iterate for "1 << compound_order" pages. Debugged-by: Laszlo Ersek Suggested-by: "Kirill A. Shutemov" Signed-off-by: Jan Stancek --- mm/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Changes in v2: - change the loop instead so we check also mapcount of subpages diff --git a/mm/util.c b/mm/util.c index 8bf08b5b5760..5c9c7359ee8a 100644 --- a/mm/util.c +++ b/mm/util.c @@ -478,7 +478,7 @@ bool page_mapped(struct page *page) return true; if (PageHuge(page)) return false; - for (i = 0; i < hpage_nr_pages(page); i++) { + for (i = 0; i < (1 << compound_order(page)); i++) { if (atomic_read(&page[i]._mapcount) >= 0) return true; } -- 1.8.3.1