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 26167C433F5 for ; Mon, 18 Apr 2022 07:24:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30AD86B009B; Mon, 18 Apr 2022 03:24:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B9F26B009C; Mon, 18 Apr 2022 03:24:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1353B8D0007; Mon, 18 Apr 2022 03:24:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id F27746B009B for ; Mon, 18 Apr 2022 03:24:14 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 91FC91831AFED for ; Mon, 18 Apr 2022 07:24:14 +0000 (UTC) X-FDA: 79369161228.27.3B4CBED Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf14.hostedemail.com (Postfix) with ESMTP id EDF6810000A for ; Mon, 18 Apr 2022 07:24:13 +0000 (UTC) Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 23I7G1mo026797; Mon, 18 Apr 2022 07:24:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : content-transfer-encoding : mime-version; s=pp1; bh=D6CBfan09eIT1E3CmNWuMcsc/lZWABsYnRNEbvHvyv0=; b=C5RwCnsVZ0l8aV54MpmE4lMJFH9FkrYa/tMX+36ugcTgzZgH/yjgCACCjjupuobv38zk B1KGb3V0gA/s8cAIr484+14Ohfu/VExBqJ80XHAmlhRCXpqeYcSr2t1K6z1AdZyOq7Yz 5ItGWvr8CYeAPpckn/COO3+ZyINaF2YT7/O2R4ZWkGODxdY+MGprmHHRFGVuBfpIjPuN Ir71k/uMgCb4kSxy8I2NBkoCVXu2UVaEfbb9iyrKAg6pW9EroplfAzW+GHgMcVFjnurS tagGMtDBMUlYqYrhV7GH3gJHtVAcbyK4WnDS0cFw17bYpdxgVqI9Ktcz17t7RnG5AWyV Rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3fg7916k5f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Apr 2022 07:24:09 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 23I7O99c034890; Mon, 18 Apr 2022 07:24:09 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 3fg7916k4v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Apr 2022 07:24:09 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 23I7NpkW008302; Mon, 18 Apr 2022 07:24:06 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma04fra.de.ibm.com with ESMTP id 3ffvt99hrt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Apr 2022 07:24:06 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 23I7O4iY33161696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Apr 2022 07:24:04 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6C8D0AE056; Mon, 18 Apr 2022 07:24:04 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BA192AE04D; Mon, 18 Apr 2022 07:24:03 +0000 (GMT) Received: from linux.ibm.com (unknown [9.145.146.209]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 18 Apr 2022 07:24:03 +0000 (GMT) Date: Mon, 18 Apr 2022 10:24:02 +0300 From: Mike Rapoport To: Sudarshan Rajagopalan Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Anshuman Khandual , Suren Baghdasaryan Subject: Re: [PATCH] mm, page_alloc: check pfn is valid before moving to freelist Message-ID: References: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: fo9tXEcuP3tXt9eND5OvGuk3RvwYI5dM X-Proofpoint-GUID: fiXGtzHx8PQL0ieEOwaNWuySMQU6Lhma X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-18_02,2022-04-15_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 malwarescore=0 phishscore=0 suspectscore=0 spamscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 mlxlogscore=992 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204180041 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: EDF6810000A X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=C5RwCnsV; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf14.hostedemail.com: domain of rppt@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=rppt@linux.ibm.com X-Stat-Signature: ckz4h6pudntugh9s4at5zmut18fep6nx X-HE-Tag: 1650266653-87633 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 Fri, Apr 15, 2022 at 02:30:52AM +0530, Sudarshan Rajagopalan wrote: >=20 > On 4/14/2022 2:18 AM, Mike Rapoport wrote: > > On Tue, Apr 12, 2022 at 01:16:23PM -0700, Sudarshan Rajagopalan wrote= : > > > Check if pfn is valid before or not before moving it to freelist. > > >=20 > > > There are possible scenario where a pageblock can have partial phys= ical > > > hole and partial part of System RAM. This happens when base address= in RAM > > > partition table is not aligned to pageblock size. > > >=20 > > > Example: > > >=20 > > > Say we have this first two entries in RAM partition table - > > >=20 > > > Base Addr: 0x0000000080000000 Length: 0x0000000058000000 > > > Base Addr: 0x00000000E3930000 Length: 0x0000000020000000 > > I wonder what was done to memory DIMMs to get such an interesting > > physical memory layout... >=20 > We have a feature where we carve out some portion of memory in RAM part= ition > table, hence we see such base addresses here. Cannot the firmware align that portion at some sensible boundary? Or at least report the carved out range as "reserved" (and maybe NOMAP) rather than as hole? > > > Physical hole: 0xD8000000 - 0xE3930000 > > >=20 > > > With the pageblock which has partial physical hole at the beginning= , we will > > > run into PFNs from the physical hole whose struct page is not initi= alized and > > > is invalid, and system would crash as we operate on invalid struct = page to find > > > out of page is in Buddy or LRU or not > > > > struct page must be initialized and valid even for holes in the physi= cal > > memory. When a pageblock spans both existing memory and a hole, the s= truct > > pages for the "hole" part should be marked as PG_Reserved. > > If you see that struct pages for memory holes exist but invalid, we s= hould > > solve the underlying issue that causes wrong struct pages contents. >=20 > We are using 5.15 kernel, arm64 platform. For the pages belonging to th= e > physical hole, I don't see that pages are being initialized. >=20 > Looking into memmap_init code, we call init_unavailable_range() to > initialize the pages that belong to holes in the zone. But again we onl= y do > this for PFNs that are valid according to below code snippet - >=20 > init_unavailable_range() { >=20 > 6667 =A0=A0=A0 for (pfn =3D spfn; pfn < epfn; pfn++) { > 6668 =A0=A0=A0 =A0=A0=A0 if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pa= ges))) { > 6669 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 pfn =3D ALIGN_DOWN(pfn, pageblock_nr= _pages) > 6670 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 + pageblock_nr_pages - 1; > 6671 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 continue; > 6672 =A0=A0=A0 =A0=A0=A0 } >=20 > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/m= m/page_alloc.c?h=3Dv5.15.34#n6668 >=20 > With arm64 specific definition of pfn_valid(), a PFN which isn't presen= t in > RAM partition table (i.e. belongs to physical hole), pfn_valid will ret= urn > FALSE. Hence we don't initialize any pages that belongs to physical hol= e > here. >=20 > Or am I missing anything in kernel that initializes pages belonging to > physical holes too? If so could you point me to that? I agree with your analysis for 5.15, you just didn't mention that the problem happens with 5.15. =20 > I see that in next kernel versions, we are removing arm64 specific > definition of pfn_valid by Anshuman. Doing so, PFNs in hole would have > pfn_valid return TRUE and we would then initialize pages in holes as we= ll. That said, your patch will not fix anything in the current kernel because the issue should not happen there, right? > But this patch was reverted by Will Deacon on 5.15 kernel. >=20 > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit= /arch/arm64/mm?h=3Dv5.17.3&id=3D3de360c3fdb34fbdbaf6da3af94367d3fded95d3 The reason for the revert was fixed by the commit a9c38c5d267c ("dma-mapping: remove bogus test for pfn_valid from dma_map_resource"). ... > > > Hence, avoid operating on invalid pages within the same pageblock b= y checking > > > if pfn is valid or not. > > > Signed-off-by: Sudarshan Rajagopalan > > > Fixes: 4c7b9896621be ("mm: remove pfn_valid_within() and CONFIG_HOL= ES_IN_ZONE") > > > Cc: Mike Rapoport > > For now the patch looks like a band-aid for more fundamental bug, so > >=20 > > NAKED-by: Mike Rapoport > >=20 > This patch may look like work around solution but yes I think there's a > fundamental problem where kernel takes a pageblock which has partial ho= les > and partial System RAM as valid pageblock, which occurs when Base Addre= ss in > RAM partition table are not aligned to pageblock size. >=20 > This fundamental problem needs to be fixed, and looking for your > suggestions. I'd suggest backporting a9c38c5d267c ("dma-mapping: remove bogus test for pfn_valid from dma_map_resource") and 3de360c3fdb3 ("arm64/mm: drop HAVE_ARCH_PFN_VALID") to 5.15. --=20 Sincerely yours, Mike.