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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90B7CC43334 for ; Mon, 13 Jun 2022 16:09:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B0D88D01A2; Mon, 13 Jun 2022 12:09:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 960CA8D01A1; Mon, 13 Jun 2022 12:09:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 800AC8D01A2; Mon, 13 Jun 2022 12:09:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6D9BC8D01A1 for ; Mon, 13 Jun 2022 12:09:05 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 46321BCB for ; Mon, 13 Jun 2022 16:09:05 +0000 (UTC) X-FDA: 79573696650.20.46A1F22 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 7906D10007B for ; Mon, 13 Jun 2022 16:09:04 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 88AEC6134A for ; Mon, 13 Jun 2022 16:09:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB07DC3411C for ; Mon, 13 Jun 2022 16:09:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655136543; bh=bOQG7gHnDdMGBfklDl16uIKgl5y6vxCT/QANX4VnjVo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=r0oMkD6t6j9A8O1qWPidf3LYxVqoSuU0o6E93x93yd43BNTtaQO7RhJ/oaKyjVamT kSrjlVBDhwql3LmeyBRUD9gqXj6LNZvhfKfqHgcMnvI+XfXn7S5bpOoD9tmcCwPFq5 JNuXjXdA4KrgUXSYioyJzF3PKs9FOUzHGRiMvewKoLmfw3V3rlq/Yo7/037S7wNx34 0X0G1wDf8/EzUh6cyBfVz1699IWD2ahdXVxK3cQj/Uz6ucQ9j3/kshJKBGB0V+y03p sj6DTCVUCrFNkYW10n2QccfhJyEBo2pZFVfAag3vV/L8KD8roxg3DLfzKs1y1Z2TBL vgUL/0jE5LI0g== Received: by mail-vs1-f51.google.com with SMTP id x187so6392174vsb.0 for ; Mon, 13 Jun 2022 09:09:02 -0700 (PDT) X-Gm-Message-State: AJIora+6MFXDJtntZBqHlEdk2wosK5btMKt+bEAZcorHbl/PjCzL5+KY /wP6hkWdp+YAoB/e3r7/Ecy5Yf2RhJKUF3Nartc= X-Google-Smtp-Source: AGRyM1vLi3E8SWmkdM9nCm5n2BpOcbavapE8yYOserlNgFyoFHEgZr/TUqEVQn9swzwoPnbDrMNvtR/KHlQJQK9KO84= X-Received: by 2002:a05:6102:184:b0:34b:9e95:14cf with SMTP id r4-20020a056102018400b0034b9e9514cfmr31667vsq.59.1655136541881; Mon, 13 Jun 2022 09:09:01 -0700 (PDT) MIME-Version: 1.0 References: <20220613131046.3009889-1-xianting.tian@linux.alibaba.com> In-Reply-To: <20220613131046.3009889-1-xianting.tian@linux.alibaba.com> From: Guo Ren Date: Tue, 14 Jun 2022 00:08:50 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RESEND PATCH] mm: page_alloc: validate buddy before check the migratetype To: Xianting Tian Cc: Andrew Morton , Vlastimil Babka , ziy@nvidia.com, Linux-MM , Linux Kernel Mailing List , stable@vger.kernel.org, huanyi.xj@alibaba-inc.com, zjb194813@alibaba-inc.com, tianhu.hh@alibaba-inc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655136544; a=rsa-sha256; cv=none; b=qaHUu/tIxOpz1w66P7aHZc0lNYTCsJyuGU26TCYgS0wYnNERjfB8lxNtXG5gpeAMqs+pjs L+Nvq1sSxWz3ePCMrl5ilVAhlhWfH4VDRCmZg6g74ASJyCNvI6MQdQ2r7Aw0zVpRvOcdXF J5InVJodd5HLCSOtCR1AKRg0w5LdvB4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r0oMkD6t; spf=pass (imf14.hostedemail.com: domain of guoren@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=guoren@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655136544; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tV7oDlgcfudkQASwQ3PKApeQsWFQy6BEVI5FhG0OsiQ=; b=LNQcMsMbQPC086IAMVF1FO/ZRo0SOzAqjLWvPi6iU+E6H5/ysEuJurQ3aqdDK+ld1X53JP LSJ/c0/VRHhW5jxJJX6pkzHzHpUTzSHEKOOywPSIdt1rZcuhvlwdVOtGfxCO8hKA8qtXoF 0S2cFATnAS9+yXbzT/wSbCH59vRDszY= X-Stat-Signature: qqah1sbwjmq9hoirpywgikicnqwmmq3a X-Rspamd-Queue-Id: 7906D10007B Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=r0oMkD6t; spf=pass (imf14.hostedemail.com: domain of guoren@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=guoren@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1655136544-349243 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 Mon, Jun 13, 2022 at 9:11 PM Xianting Tian wrote: > > Commit 787af64d05cd ("mm: page_alloc: validate buddy before check its mig= ratetype.") > added buddy check code. But unfortunately, this fix isn't backported to > linux-5.17.y and the former stable branches. The reason is it added wrong > fixes message: > Fixes: 1dd214b8f21c ("mm: page_alloc: avoid merging non-fallbackable > pageblocks with others") > Actually, this issue is involved by commit: > commit d9dddbf55667 ("mm/page_alloc: prevent merging between isolate= d and other pageblocks") > > For RISC-V arch, the first 2M is reserved for sbi, so the start PFN is 51= 2, > but it got buddy PFN 0 for PFN 0x2000: > 0 =3D 0x2000 ^ (1 << 12) How did we get 0? =EF=BC=88Try it in gdb) (gdb) p /x (0x2000 ^ (1<<12)) $3 =3D 0x3000 I think it got buddy PFN 0 for PFN 0x1000, right? (gdb) p /x (0x1000 ^ (1<<12)) $4 =3D 0x0 > With the illegal buddy PFN 0, it got an illegal buddy page, which caused > crash in __get_pfnblock_flags_mask(). > > With the patch, it can avoid the calling of get_pageblock_migratetype() i= f > it isn't buddy page. > > Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and= other pageblocks") > Cc: stable@vger.kernel.org > Reported-by: zjb194813@alibaba-inc.com > Reported-by: tianhu.hh@alibaba-inc.com > Signed-off-by: Xianting Tian > --- > mm/page_alloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b1caa1c6c887..5b423caa68fd 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1129,6 +1129,9 @@ static inline void __free_one_page(struct page *pag= e, > > buddy_pfn =3D __find_buddy_pfn(pfn, order); > buddy =3D page + (buddy_pfn - pfn); > + > + if (!page_is_buddy(page, buddy, order)) Right, we need to check the buddy_pfn valid, because some SoCs would start dram address with an offset that has an order smaller than MAX_ORDER. > + goto done_merging; > buddy_mt =3D get_pageblock_migratetype(buddy); > > if (migratetype !=3D buddy_mt > -- > 2.17.1 > Fixup the comment and Reviewed-by: Guo Ren --=20 Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/