Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1136992imu; Fri, 4 Jan 2019 13:58:10 -0800 (PST) X-Google-Smtp-Source: AFSGD/Xv2NsNfWM3KahcEXkz+wT4/wCc+UwO2u+Aro1m9YDM4zb++RDONCGFOR10TMXVUoxqOuLH X-Received: by 2002:a62:2f06:: with SMTP id v6mr54623764pfv.216.1546639090888; Fri, 04 Jan 2019 13:58:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546639090; cv=none; d=google.com; s=arc-20160816; b=NiWHdryaA2+ZeCmE4fFMiB2kb9uPAb/zn7fNNltu+vYnnRHpghLSLU405MxjkkNfY0 pj0ePKbsY+2zHBOkDhPerzAsrDo4duqgOmAj8ON9AlmnXf8/YnlyUEM+PQAV8klGbbhr eUJ90uAmzjjt8atMDzgfOQJLcK7nK37KLbdNz/lf/9A/HOpgnmsLCcfLry6dalWfUH5b LzJd9PlQhwaaKmydpN0cCZyuk/g2IZ12UN5D6VOpHrFDFrKJRx5d6LuVY6dZMHmaupNG fLHcN4B32SKdDSefvCw7z7wwtGEzFkqidBxA53X8oUHIHz7cy8AmM7+fJxT06uuaoVlZ B/Tg== 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=fL01iDY4GOBIMja13LcPpFUSppBuGcy1oDs3UTnv5S0=; b=unWezct5PU9PbKzBrUxOFpMZL6YAzDuTzbo374lPzmznKju5lC2TcReybIl4KSQpy5 G+UTDonf6Dw9AjIU/JU/+X+QXZ6ZkujbrQ/HXpups7hxawXy8s7r5bzRjnNU4LCQ4Yoa I/g87A2OtWGfPhswUGA/KWibucv8S+4bhi8Z1QffnHfVoeNM2EGjJ2xqBHvyTuRPVVJ3 6xgxk8XSAK56zk0IreDrajoFnL78yt1yBujE5nN+DZoKZf3FzcULIZcsuyFU+b1g0tn8 p+PmhchTNLLmPg5fmBXbQjEeTFXWGgVSDxV5sy5iuAoWaDPEQLcoKVpq7V57aTv4ESrN OV9g== 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 n1si55290872pgh.172.2019.01.04.13.57.55; Fri, 04 Jan 2019 13:58:10 -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 S1726255AbfADV4l (ORCPT + 99 others); Fri, 4 Jan 2019 16:56:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726056AbfADV4l (ORCPT ); Fri, 4 Jan 2019 16:56:41 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 280F42D7EF; Fri, 4 Jan 2019 21:56:41 +0000 (UTC) Received: from sky.random (ovpn-121-144.rdu2.redhat.com [10.10.121.144]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 370AA60A97; Fri, 4 Jan 2019 21:56:38 +0000 (UTC) Date: Fri, 4 Jan 2019 16:56:36 -0500 From: Andrea Arcangeli To: Jan Stancek Cc: linux-mm@kvack.org, lersek@redhat.com, alex.williamson@redhat.com, rientjes@google.com, kirill@shutemov.name, mgorman@techsingularity.net, mhocko@suse.com, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP Message-ID: <20190104215636.GM19981@redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 04 Jan 2019 21:56:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ CC'ed Andrew for potential inclusion in -mm ] On Fri, Nov 30, 2018 at 01:06:57PM +0100, 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. > > 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 Reviewed-by: Andrea Arcangeli Thanks, Andrea