Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3673129imu; Fri, 30 Nov 2018 04:20:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/UQp15p2YdTGxZ1FY5ZS8/rg4KTtxBZbhf5sSqJ9gnVQXX5AH9n/nKDU0ydky10yVZ8PIY+ X-Received: by 2002:a17:902:b787:: with SMTP id e7mr5489742pls.246.1543580416667; Fri, 30 Nov 2018 04:20:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543580416; cv=none; d=google.com; s=arc-20160816; b=iVLVOayb6n32/GIStZ3vrpMJLjDcunhDQtv5Cj6Lm2AgoaWLEtC1k+Sv7Zvv8lM7HV TKE3hF8mghOip0AGJH7PPlWCOpe5w691O9ezkHstprjjDMEAjbyUjfkA2Ff8DYwvqvc2 sclsALIkWnOsIIq96AMGs1TMM7NVfuSPrJCOwqY3xwy8WrLoX2TbuAajffNvc67v8NEG fg8bN94sKpm3cJjBMyNMKhBtcUqfONjfBfkHkG59bWJlxk4oQMxDTPXvVlD047dVakLr IBhVON5MCxSvAeTBiIOzPAdKN++y1wA48VwzmON+XKhfEbE7xha7ywa5lIaAFG6fMBm4 jT5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ZPMhWD30JdvMZFcbRO5PhZAkIPCUu478haEAwGJ7vkE=; b=JbxRx04tSPVytvqk7NoBE9DWaESe2UHhfDZbAUSTQmsUGhCnomfbDZAAa0GckV/MEy Bsn5uU4BFS43L3vC4Ch/8DkEhfVY6fZK3/qNMMLykrZZaqi58BbY2a3rQycFPN0P8MhV yKjmeiDnl3dr1dxnGJUThWXbJPrMRCSV6PUOLaqA8dlbmbmSfIubP59YIJb8nE0pm1x6 0rLDwneaVIm5aU/whm45KhtcIWm0amrrgARMfbTVdlOUbWFGvN6tcBnJYYB99m2y2viN CywelZu0naZ9F5d7piyCAep2rRNvjIbqYp2AYn/atDb3K8XB8G9cT+R4vaoNH9NIW0R3 N6Pg== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l63-v6si5194306plb.385.2018.11.30.04.19.56; Fri, 30 Nov 2018 04:20:16 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726900AbeK3X2A (ORCPT + 99 others); Fri, 30 Nov 2018 18:28:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:44830 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726521AbeK3X2A (ORCPT ); Fri, 30 Nov 2018 18:28:00 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A47D3AE98; Fri, 30 Nov 2018 12:18:52 +0000 (UTC) Date: Fri, 30 Nov 2018 13:18:51 +0100 From: Michal Hocko To: Jan Stancek Cc: linux-mm@kvack.org, lersek@redhat.com, alex.williamson@redhat.com, aarcange@redhat.com, rientjes@google.com, kirill@shutemov.name, mgorman@techsingularity.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP Message-ID: <20181130121851.GI6923@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 30-11-18 13:06:57, Jan Stancek wrote: > 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. This is much less magic than the previous version. It is still not clear to me how is mapping higher order pages to page tables other than THP though. So a more detailed information about the source would bre really welcome. Once we know that we can add a Fixes tag and also mark the patch for stable because that sounds like a stable material. > Debugged-by: Laszlo Ersek > Suggested-by: "Kirill A. Shutemov" > Signed-off-by: Jan Stancek The patch looks sensible to me Acked-by: Michal Hocko Thanks! > --- > 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 > -- Michal Hocko SUSE Labs