From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D366CC433E0 for ; Wed, 17 Feb 2021 19:02:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62AE264E15 for ; Wed, 17 Feb 2021 19:02:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62AE264E15 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C97146B0006; Wed, 17 Feb 2021 14:02:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C47EB6B006C; Wed, 17 Feb 2021 14:02:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5EEC6B006E; Wed, 17 Feb 2021 14:02:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 9C7B46B0006 for ; Wed, 17 Feb 2021 14:02:54 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 65B706109 for ; Wed, 17 Feb 2021 19:02:54 +0000 (UTC) X-FDA: 77828681868.09.grade15_3f01c492764e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 491A6180AD820 for ; Wed, 17 Feb 2021 19:02:54 +0000 (UTC) X-HE-Tag: grade15_3f01c492764e X-Filterd-Recvd-Size: 2845 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Wed, 17 Feb 2021 19:02:53 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 90D3E6186A; Wed, 17 Feb 2021 19:02:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1613588572; bh=odEQGZsuO+lEqXY7esyTBK2QgwaJ1DoXNXR2BQ1SGlc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=zOE7O/FpIEoPbTe+GWOPDp8/ki03sqzNLQavTgdbhGlzxCACNYMYDEhpwElSTFUBL Yfl2GW/J+6CTXv3m9VJE3WvAMVoOeEs9OSFrC0+zD5g5d9qL7KeS4Ny3PlR9JNKEre Mxh3+R1H1GFO9zDdiQ2Egb0nNz/TTDgN7jsz0T9E= Date: Wed, 17 Feb 2021 11:02:52 -0800 From: Andrew Morton To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Zi Yan , Davidlohr Bueso , "Kirill A . Shutemov" , Andrea Arcangeli , Matthew Wilcox , Oscar Salvador , Joao Martins , stable@vger.kernel.org Subject: Re: [PATCH 1/2] hugetlb: fix update_and_free_page contig page struct assumption Message-Id: <20210217110252.185c7f5cd5a87c3f7b0c0144@linux-foundation.org> In-Reply-To: <20210217184926.33567-1-mike.kravetz@oracle.com> References: <20210217184926.33567-1-mike.kravetz@oracle.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 17 Feb 2021 10:49:25 -0800 Mike Kravetz = wrote: > page structs are not guaranteed to be contiguous for gigantic pages. T= he > routine update_and_free_page can encounter a gigantic page, yet it assu= mes > page structs are contiguous when setting page flags in subpages. >=20 > If update_and_free_page encounters non-contiguous page structs, we can > see =E2=80=9CBUG: Bad page state in process =E2=80=A6=E2=80=9D errors. >=20 > Non-contiguous page structs are generally not an issue. However, they = can > exist with a specific kernel configuration and hotplug operations. For > example: Configure the kernel with CONFIG_SPARSEMEM and > !CONFIG_SPARSEMEM_VMEMMAP. Then, hotplug add memory for the area where= the > gigantic page will be allocated. > Zi Yan outlined steps to reproduce here [1]. >=20 > [1] https://lore.kernel.org/linux-mm/16F7C58B-4D79-41C5-9B64-A1A1628F4A= F2@nvidia.com/ >=20 > Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation= at runtime") June 2014. That's a long lurk time for a bug. I wonder if some later commit revealed it. I guess it doesn't matter a lot, but some -stable kernel maintainers might wonder if they really need this fix...