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 8C313C7619A for ; Tue, 11 Apr 2023 10:34:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C610D900003; Tue, 11 Apr 2023 06:34:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C11A9900002; Tue, 11 Apr 2023 06:34:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A63B4900003; Tue, 11 Apr 2023 06:34:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 96A5C900002 for ; Tue, 11 Apr 2023 06:34:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 60607AC08E for ; Tue, 11 Apr 2023 10:34:17 +0000 (UTC) X-FDA: 80668750554.08.8B58308 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf09.hostedemail.com (Postfix) with ESMTP id CAE8614000B for ; Tue, 11 Apr 2023 10:34:12 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=rzgvbxbn; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=io7bj6l4; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf09.hostedemail.com: domain of joao.m.martins@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681209253; 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=hOrxY4XDVB/G3b4l5bDZbSSLGZBigDVcuyUKYxBaO9k=; b=gQn11i6G3d5sLariJD+IG8JQHFDF/QKKlOMfbpAKRFgGKPHq63R5Umifl1Lko2swKeP93S t4IW8pacKmE3U7Rc/77PHZRS7Q4J6CarhA5tuXiWw4mUNqx/iwuG6fYyz5WbLSwyrCXAgm 42fj0EBbJoySfva8adJOjOboinC6ql0= ARC-Authentication-Results: i=2; imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=rzgvbxbn; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=io7bj6l4; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf09.hostedemail.com: domain of joao.m.martins@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=joao.m.martins@oracle.com; dmarc=pass (policy=none) header.from=oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1681209253; a=rsa-sha256; cv=pass; b=zJkGEmKLKOOk32Q/6grVvbijD6WYfWiJNKXkJq0RTB20gv6PieGDjot2pPnkzYNUDvtROJ TNDQyhhePhnGlzdRHfE5TDBUnwsdGsj78VhSzl41RbFiMz5ug44Vxj1Q86EJ0GLViDx35u yImSGL+UxlZPvQtU2TD5g5XUhfXpRYI= Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33B7OOm0006169; Tue, 11 Apr 2023 10:33:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=hOrxY4XDVB/G3b4l5bDZbSSLGZBigDVcuyUKYxBaO9k=; b=rzgvbxbnMcP0t+24oBMVd4lVqJm/k2+P51jyZfeQMxNaZV+uKnmvx84k0OFX9zU0NeTa BedfP1j2l0/sQAa/vtOJa5X77gKZVf4bzJIhweqF0yLl2SlkhQHC16o88CzcIkkz8rjA 3apSfxNZ3KFMWg9ndXVm7IrY+DKomlO0Zdw2KppyKlStAvB+xUyYu8o/1ELuhW9AMx0B cabEdXKEZCcCZC5cLt8RI4D90xo1Sz94PsjYWKab4UMCG3fhKll7tPaL18psf4DO17dS u//JcNTwC+FDVi2e9YBFJ9illGrTELViWJ+yaVpgLN035R9pJiiOWfGpHxrQngIFbZWN Gg== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3pu0hc5248-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Apr 2023 10:33:54 +0000 Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 33B8nHIB020835; Tue, 11 Apr 2023 10:33:54 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3puw86jm17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Apr 2023 10:33:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DPy2sn+4RBiKZ+8X9q/4cu90O87uivTtj5P2MVlXqrRLJ7koGwZCIyQWzZpiBKKQCR5k1HO/5OBoS9ALf99SzeIK2qu+H+G9Viej8H0w8DdqBUtQA0sOaB25b83kG/UDkwuq+gFjYHHCcALCVnPSyM4sUdxtN9HFqt7o4bZY5YPrlNjeA33K5M5RtqlLNSuZG4MFM9/DmNxVesm0iQL7YhXs9os2qhymIccJ4a6r4xVBv9+yRfl2n4wxBrvzYsHKbXUKXyjtwBuHfKdPR87N1jxx2HK/PnAAGeslSxCIcATk0VgOIiR0a6xM0N2OKWxjmJgL1Nc3WzDBX6rJ4hfYtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hOrxY4XDVB/G3b4l5bDZbSSLGZBigDVcuyUKYxBaO9k=; b=hZhZmNCskY1vargXqMujIy1anlbVieP34gEu+VwGyLvJa2ZpyELo/JXrIUs3TzzSjFyrihNiICzMnrq9qfZH/Ls5JeCFAQnsi32/MhccD24JNe8O5WiKHSgdt3jJ59/C1luA9ywSrbk5Jq0nbeqtmALVl6zm8ChFruXiygYuU43euiel5AlrQ0hU0vRejkFX2Az4Ykn1jKDXIYep5DKUdSBI5N8aPG57pisexErer3V5rKVu3CHljRFr2gt5CnwVB+FY+Sd4u5chvqRB5u2O//iVgJwVIyuapl37QlcfgyXdPh7KNIwMuRE+0CEWc3Z/hfj/D8LIbDTngnA2HIIWLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hOrxY4XDVB/G3b4l5bDZbSSLGZBigDVcuyUKYxBaO9k=; b=io7bj6l4LJG4drIe0JMH36yQT78IKNtSRVlCH/Bw+H6o0uC3ETc2XtVF0Csn9U4Um9WRyHmkEuJX1L+vGRu7UsSgngyrL7rDze9kEarGk0KxX/RJpJWEXhWh4Wyb8Go2CoaWcUPh3DzLgnAleo/MHGSSrHhTxnw1N8/Uuhz6gJ0= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by MW4PR10MB5750.namprd10.prod.outlook.com (2603:10b6:303:18e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6277.36; Tue, 11 Apr 2023 10:33:51 +0000 Received: from BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::b176:d5b0:55e9:1c2b]) by BLAPR10MB4835.namprd10.prod.outlook.com ([fe80::b176:d5b0:55e9:1c2b%3]) with mapi id 15.20.6277.038; Tue, 11 Apr 2023 10:33:51 +0000 Message-ID: <0a69f3b8-88c9-db31-ddb6-5e372f339459@oracle.com> Date: Tue, 11 Apr 2023 11:33:45 +0100 Subject: Re: [PATCH] mm/vmemmap/devdax: Fix kernel crash when probing devdax devices Content-Language: en-US To: "Aneesh Kumar K.V" Cc: Muchun Song , Dan Williams , Tarun Sahu , linux-mm@kvack.org, akpm@linux-foundation.org References: <20230407122353.12018-1-aneesh.kumar@linux.ibm.com> <5c30292b-7e68-8897-9ca0-cc800b866ba7@oracle.com> <871qkqdepe.fsf@linux.ibm.com> From: Joao Martins In-Reply-To: <871qkqdepe.fsf@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0509.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:272::13) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BLAPR10MB4835:EE_|MW4PR10MB5750:EE_ X-MS-Office365-Filtering-Correlation-Id: adc05ebc-fbea-4009-abac-08db3a783dd8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vO/iJC03t3qQcIhm+asEQyIfDxPe39AMD2EKuU1kDKN+YHTm2wIsPYSoxnMGZwwLuYwv5XkfGecbACdO91gftogmSMPSJLmRy0FlaPrST2cwCo1L79l2V0v2oJ/Y3CymQ6DaxTL6jSvyCGCfcmJH8bP61V4eTWxI3QEW4qlXPDypjOcqD+pVuhGHFpseoFuIV7PWQNYnogIkvjVrA99OTEajriOQp8Eb61aq52ZtVxbw3T6+zYTDREG64DAcUcUCcOWoBDYumV4LskKqU3yoMI+eILlpx5t3XH1kuszOQjqWBT0UdWcPYFy/Sj1fLate3BIpM7/ZT9YS1+5CTs7nbIGxCMBD2setJYHGckNGOpU3wVNC+leDdrgk2IDrFh8lRkrVfwSsfUXtsvdK6c9Uyw8kAOqWxI5mcH1cgQuhJuAKmcJmOSWzbIbKjnLYEpaVwILH0Fft50m/58LkPKPDTnCHbQSXx/q4jGlGHh36Inb/WE2Fm2XUgdLS4hBptWpj+PrCFD8wDbZr/CTbcJMMY114eksLz4MW++xoWZOTn9BrJwqJ+3DBIf6vV4b7LSqtMBr99d1RVhB+3tPIvp8L+gPI+pqdsrJcEZQaBlVTvtBXVFq69vFrciOGY3fkKB6I X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BLAPR10MB4835.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(346002)(39860400002)(376002)(136003)(396003)(366004)(451199021)(36756003)(31696002)(86362001)(41300700001)(316002)(4326008)(54906003)(6916009)(66946007)(8676002)(6486002)(66476007)(478600001)(66556008)(5660300002)(8936002)(2906002)(30864003)(186003)(38100700002)(6666004)(6512007)(6506007)(26005)(2616005)(83380400001)(53546011)(31686004)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZVphYzlHb1dybXU3NlJ3eit3WGE2Z21ZNmdTZmVTMHY5ZXNrNTZ6bFYvN3l0?= =?utf-8?B?ZjIvOURsRy8vZFJVVFZiaDBKVmI3aS9mZFljc2hyTXJndVhuTGZmWUpKbUVT?= =?utf-8?B?RDkwbld4R0lmcXJpMWlaTEZ6SERUNS83ZzV5d0hGOGRwcW9YME5PTUd4OC93?= =?utf-8?B?RjhVYVl3LzJ0VVg4cDJ0TDhmUExXdUZPRzFrT0RoRjRWUCtVMTlCTCtTNng2?= =?utf-8?B?d3YwcmhOT3VoVzBJd2lGUXlGK0VSSUtlUGZGRE51anVtRytPa0JsU3k5WW5Y?= =?utf-8?B?SU4yWEc5ZS8rTkZYT1BrczNYbThzMlc4RFdaQUl6L1NvaEwya0RpMXhDUG12?= =?utf-8?B?VU1qMFF4Y3dsMGUvT1BsR0lYUEpLSElMUGM0amtmTjhFRzhrTHZzRm0wVzRC?= =?utf-8?B?ZFoyVUZtR2tWSXFDODF0d25vdGVsYnJBOG11L1oyY09qamF1TG1IUWpmYjRz?= =?utf-8?B?SzFsK0x3czF5TkFwMG1UL0dtamJRZjlmKzJrb2V5YXZwSW5zZXVLUDA4bTl2?= =?utf-8?B?UHZHcStLS3VRNmNGRmt0NWVlKzdsVWZkSWpYMWxRUUROQSt4bkRWWm5UZEdF?= =?utf-8?B?MkwvRHhoQjJGR2FQUlJvb3VreldaUm5waWhRN0hLUDRPUlprRDk4Z3I5SzI3?= =?utf-8?B?S3E5RXh2RlRVWG5tWHovck9HL2hNL0pxcjRrOVBNbUIxT1YxT3pPMmRZV090?= =?utf-8?B?M2F1K0JJd0g3VUZVWjU0MGNXVU94bUlIQmEzVnhvTGFrUE5QbnRBT2pBVUpu?= =?utf-8?B?WUl3aHZIZjJ5U3RUdzlEVkJTQjJBdzFibktBenlYRFIvR2VWQjc0K2lBUmpz?= =?utf-8?B?MGJueEwzOWxUaER1K2VuNFplend5RGFmRTF1QUN3TmJHZDd0czJjYlFwVDFh?= =?utf-8?B?OGtDMjJDMFVPdVVneGt0QUFPVkQ1c0NPclpCUWFpMFpncUM2MFo2cTlRNnRl?= =?utf-8?B?dDNCVWNUYi95Q1hDb1RxTXdJZml4NGdMSm5YbjJyeXlkQzBVYVBjZmhxSUE5?= =?utf-8?B?NDRGRk4yemtOQkRyaDhqSDg2dG41STIvTGhzc3p4bk82eW9lNFg1bjZCZmRs?= =?utf-8?B?WFB4ckY4cUpEWFpVSHdBODMxb3NaMDNpSGxMUk8xK0lHRDdoaHZwTVBjaUg5?= =?utf-8?B?aEVZU3BoRXFjdkZvOEpzTkRIeDkvdlNFN2dISU8zc0RSZ2JXUlE1NGd4VXN0?= =?utf-8?B?T3FodHkveFRUeWZPR09RZnlCSDRjT2ZCN1VjdnJEZ2JzQUh4K25VZGliV1VQ?= =?utf-8?B?RmtHYk9iclZhRWVJS09vZDBIa1FkTHZnWGpzbUMxY3ZoNEJSd1lLbThKTFgw?= =?utf-8?B?TG5ETGZvbkVmbC9rcVNqVkYrbUl3SkwwNjRLQzRlQnJpUlVMdTRtRWdyUzFw?= =?utf-8?B?OHJ4dTFLSTh4dlhYNldMMndlTERtUVZWWTFDdklXbEhZT05rbjAvRExzNmRQ?= =?utf-8?B?N003c08yYm1waHhzTTRpZU5idllFODRwRENZRHlmWi8zd0M2eFh5T1YxU0NR?= =?utf-8?B?RnZsN1c5NHNiWmRwZjZyVTFjNVhYanFKUERhaCtkNlgrWEhXRVhFSlJTMU1L?= =?utf-8?B?a29KOWhqNEtVSEFQZHlJSjBaQVFHbkZXNm80M3hPMkZ2bGVKZFdicTdHNzJP?= =?utf-8?B?WTR3Q1psOWhEWC96eURzN3JVSGh3WTVQMVJldHNYb0M4UTM4RDBNLzVJS21G?= =?utf-8?B?dVVhbS81RHl4RTNGK25paTBSV1FDbk1CY0l2RFBJREVuR2NVZ0JpUU5HcHk3?= =?utf-8?B?aDJtUnVsbzg5WCtxelZnQTdZd1hSWTVVWUVYOGhjWWtmVGJIdGhxYUlVckti?= =?utf-8?B?bVNHUml5MnR4b3lza21WY2pSVkNxSk9tS1pOWGovdG9NUmZNdS9JYTgvZWtL?= =?utf-8?B?MWpxbzZIS29pUDAxalVoZlg3VTlpN3o0TVRWZS9UeWtNekNnV1Y2T3NjZks4?= =?utf-8?B?MlJCQ29QaU9oTjBkQ1BFcS9WMnBFUnBHYTJxT1hTUW1rN1BDZHFNTHRqeXIz?= =?utf-8?B?UmFJaDBkV2YxRUc1N1F0dC85cHNESHMvdHBXUjBBVDRZYytBM25ZNnNpNGVC?= =?utf-8?B?UFBDa0lKVTBhWGtxczBlbVlmSCtPaTViTzJpWlVsMFh3RWU2N2hlMFFQNm9q?= =?utf-8?B?UFpTbnVWMlFzTVB1OXlBd2dBd1VCNjhXY3V2S21DSmlrYloxTkh4ZkdVd2lV?= =?utf-8?B?QVE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: cgMMv8fXlDP3mUN/jkxsYBHl3wc7kor44bQkM3TUU2tdP/G4rKwZvKpWVb0GaojEqh6ommXvHmS7u7lTBNrcy8izTN09lVp55tEfDTlTOczTVcPoJAjUjS161lI1XcJhY3RvZ5liaQc5+BCyeV+Uujdy4lw9AC4oqeLSnmZVEkX+ln5JhJpJOBPXK1eYfUw5gjhG0vl137Y1KwnKWcYdGl10lXpUqma2Bqw7zeC1jiBcea6BkEc130PTCck35m4t0CS3tFRLIwvtt/L6gC4I1e0HH9e6gf1pW5wfIhlJEitXlXZTqKBmJnm5Bx/UGwtKXRFcQVGpq3F6Dyn1jHPcxcgmJ6mRmayicEhQJYLkaTfhKYsywZRjJxUcXBCCJUfP/KvgFy1m7yq0PhOuFqZy7h+5++RjpT0pM5NUB2GrFYGBcTkPvjfF0f1Qw0MdqN1yToCnxgSBAbc2mkn/iZIPEZOFEVRCI+JfSu4rLubQcyg337tcFYzSToA4aGbMQpKPKOh6iBpYj05Np+tPHwf7iCyiXApwuUPNWN5Pdfi/asWS4M8p6dcjUHONGYsa1GIAYvQQA+OYgR9oA0GsqfxBdK8U/hvZMNdN6b9vFADueqQFsq5k+J+Ymml6rYjE7EbIMpFqMvH4uMvycucPUIuzvtWb/HyKNOrh43o6aNuKQDzkaY4stjLAq/jlnHaXPO6C4xtJa0M8BLljC4gRUj3RS75XZlS42fqahhNjfUHRV6pUnqT0Rw3bSP1s3kSa0qOf/XF0l8/dskxXfmw0vP8BaISqRRmYFcV0kChqmijFt4dCtbikM3Fe31h16q9nfTwXHEbwvaNdbXbW0s50Qkhjz/N3II3VBw6O9eb/csOXPP30VQ1K9VJHZTt9hH2mpjmbpFwjhwM9tlJWpswGLrvfEQ== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: adc05ebc-fbea-4009-abac-08db3a783dd8 X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2023 10:33:51.3548 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: W0967W62c2y97EDMpbAcLin7OowR747k6nZIQcdcCEE+psZZDLi6ggvVIw2DZQ7OguIfHxMI/3gClXwedssFyJyizAn3RU12L+jwt+oKep0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB5750 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-11_06,2023-04-11_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 malwarescore=0 suspectscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304110099 X-Proofpoint-GUID: vc8yw2XUjklbomB48jcwcGXns-wbyD5t X-Proofpoint-ORIG-GUID: vc8yw2XUjklbomB48jcwcGXns-wbyD5t X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CAE8614000B X-Stat-Signature: g4w6z7nbe6iuuc9fhr783hj466nufi4a X-Rspam-User: X-HE-Tag: 1681209252-891399 X-HE-Meta: U2FsdGVkX18U2AN5rVOlzzHO5Hv2uXWzs0t7DD/L5Dwoce7UVyfT42OphhJAFh4qYD26BOh/0pHttUYqIb2IrbOyuNsvfjcOJofQvS349T8CG6yQ++9+iwm0qcxyb3Z++8P/Sl16vRb4kMH8mwvoz2MFbYR4QKf7j8TtT/zpArXL0bbu9+z9iuPcuuG0sBUFqjeVGmpB7fWBZK94+M1HLuCZtl5XKbkFsirR7wKqcWyE7pUdA8rgtQ2QS5rYm/lDUbuGD5ajb1j0dwMfza8mflkSiY23sNkW2xIdXBFtlUDC+GF+33rBFFPrEJvJzf30ofXN9GSi/T1EyMvGQPmSEa+ngT2IDQvsr7QUaHxclG/YVfodfb8iDBGYMr/Cjahuef69lWNrn9lFTsDFMmtUcGwyuhzPKgtBBXcqbPiSnkuwF3YHoU6kJSEIyzGs2WShVKeUgwg5q0TFlebn+aqpEz7xwj28kmB3bfJ5WEV2qbOQFTbmaGa2ig4VyXjTW1eaUrxR087n87tJpmKaC8HCtL54Mp1n3UnTFJNvUdGSJnZaMwGBX/uEov/a2Jbqk6W1/pgCoD5U0E+NJFVpodVuwN8s0ycHPkUv8iojpSoNrpfkxL0iDfvGIM8WgzUXQvCJ898EpaGSCXVGjE0v0ZI7TmrKY9pl5BskxUXBRCgRXJHfFEw8zkP76Jwgw3B0dbvJPiE6VEbyMCGO1Lc/vnRaq656aw/dULfiC+RJHpm6WD+v13RuQxyzH5xeCymaaDQ0jntRVPPX224Ozl1Zrp133I/R0ROJsuj/YgFXKFDXLl9k1Scj4DWlN9OLTRk3FPa0lZYmwK9AUHSoZfX9QJvWmmwyH2Ueix7Y0SVMUVrfm5vc7EfCqbhf+kfV+vFXcSAQiO4iibAh7TgqV6zM63Vr4vw4qw5erdA55yEEndQuhWwS3cO4VrAG8Ji0/shByD3bcxrstXXypqqu4Ddr55o Hf+DGVxs inLjao0/oDRLd4aJ/4iVq+2c3CeDec20DTSJYl+jyqIEvNg2osJE7X/HEmn/IIaaPSiCKMNphQDba4V1VbFIo5sGplC7iBT+cT9qZ+URK8t41TYbcnwbaQcTyY8/QK/YA0pulNzOzx2KfPPYF27qDUm0I3ziHoL1+g++LjfyhJvXXu9zKqzazn3L2t8R5VWMynpiLvoxkWMl+8Mq6ffmo2tFdyFLsBUeh8Ny9DVSVwC7f9Nub/MEy56vm+dttAGjxVXupqjbI5vJEBdKEQUN2+6Zd2DDctFB6nNWkBgsM+LJeYFD//VCO0eJoB1EI9h9pFFMHezSeVAK+2xl9kS9v4U/lnoQYBzCGf3LMFTOq4wxBwD8OKG45jP7sqTvkZtFJcfeBjdRf2QjYfbXCcGT0pRAK2l8XYe4HnKemDJ2mrrKWGSQE91sVEjNRFMsglh90ecgjO7s0WwXuE64lAX0pLJiyReVkezTNd29xAscHikR/2vn/K2dfVTEL2ZW5MfR/cnzEJSycN+Gtjg5+M6X6dkwBM+Ni1M1o8k7K 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 11/04/2023 09:07, Aneesh Kumar K.V wrote: > Joao Martins writes: > >> On 07/04/2023 13:23, Aneesh Kumar K.V wrote: >>> commit c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") >>> added support for using optimized vmmemap for devdax devices. >> >> Not really. It added *compound pages* for devdax ZONE device which is what the >> commit describes. It is meant to represent the non base page metadata. Should >> fsdax support the equivalent, we can have GUP performance on the dax path and >> remove today's special zone device case of ref-per-base-page GUP-fast path. >> >> One was tied when it was brought in but in theory[*] we didn't require anything >> from arch-es to do this (contrary to vmemmap_populate()). The commit you should >> refer to is this instead: > > ok the compound page dependency came via > commit 6fd3620b3428 ("mm/page_alloc: reuse tail struct pages for compound devmaps") > It's an optimization to remove unnecessary work, not exactly a real dependency. But I understand what you mean. > I have now reworked it such that we do > > static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, > unsigned long nr_pages) > { > #ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP > /* > * this depends on how vmemmap is populated by > * vmemmap_populate_compound_pages() > */ > return is_power_of_2(sizeof(struct page)) && > !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; > #else > return nr_pages; > #endif > } > I would instead just simplify it to: static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, unsigned long nr_pages) { return IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP) && is_power_of_2(sizeof(struct page)) && !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; } As the ternary false condition already handles the non-optimized-vmemmap case. With your vmemmap_can_optimize() helper perhaps: static inline unsigned long compound_nr_pages(struct dev_pagemap *pgmap, struct vmem_altmap *altmap, unsigned long nr_pages) { return vmemmap_can_optimize(pgmap, altmap) ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; } >> >> 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") >> >> [*] or so I thought before next paragraph >> >>> But how vmemmap >>> mappings are created are architecture specific. For example, powerpc with hash >>> translation doesn't have vmemmap mappings in init_mm page table instead they are >>> bolted table entries in the hardware page table >>> >> >> Very interesting, I didn't know this (no init_mm) was an option. And my >> apologies for regressing s390 :/ So, s390 does not support >> vmemmap_populate_basepages() then and always need to go to arch >> vmemmap_populate() to create the vmemmap entries. >> >>> vmemmap_populate_compound_pages() used by vmemmap optimization code is not aware >>> of these architecture-specific mapping. Hence allow architecture to opt for this >>> feature. I selected architectures supporting HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>> option as also supporting this feature. I added vmemmap_can_optimize() even >>> though page_vmemmap_nr(pgmap) > 1 check should filter architecture not >>> supporting this. > IMHO that brings clarity to the code where we are populating >>> vmemmap. >>> >> I am not sure the last two sentences are right. I would remove, see above and >> below comments at the end on why. > > That is true because i had vmemmap_shift = 0 if arch didn't support > vmemmap optimization. Based on your reply above, I have now moved that > out and kept vmemmap_can_optimize() > /me nods > modified mm/page_alloc.c > @@ -6846,8 +6846,16 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, > static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, > unsigned long nr_pages) > { > +#ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP > + /* > + * this depends on how vmemmap is populated by > + * vmemmap_populate_compound_pages() > + */ > return is_power_of_2(sizeof(struct page)) && > !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; > +#else > + return nr_pages; > +#endif > } > > static void __ref memmap_init_compound(struct page *head, > modified mm/sparse-vmemmap.c > @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, > !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) > return NULL; > > - if (is_power_of_2(sizeof(struct page)) && > - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) > + if (vmemmap_can_optimize(altmap, pgmap)) > r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); > else > r = vmemmap_populate(start, end, nid, altmap); > > .... > >> >>> Fixes: c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") >> >> It should be: >> >> Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound >> devmaps") > > updated. > >> >> But if what you included in your patch was what lead to the crash, then your >> problem is not the vmemmap optimization ... as the latter came after. If it's >> the hash I included above, it would reduce the affected trees to v5.19+ >> >>> Cc: Joao Martins >>> Cc: Muchun Song >>> Cc: Dan Williams >>> Reported-by: Tarun Sahu >>> Signed-off-by: Aneesh Kumar K.V >>> --- >>> arch/arm64/Kconfig | 1 + >>> arch/loongarch/Kconfig | 1 + >>> arch/s390/Kconfig | 1 + >>> arch/x86/Kconfig | 1 + >>> drivers/dax/device.c | 3 ++- >>> include/linux/mm.h | 16 ++++++++++++++++ >>> mm/Kconfig | 3 +++ >>> mm/sparse-vmemmap.c | 3 +-- >>> 8 files changed, 26 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>> index 27b2592698b0..d3f5945f0aff 100644 >>> --- a/arch/arm64/Kconfig >>> +++ b/arch/arm64/Kconfig >>> @@ -103,6 +103,7 @@ config ARM64 >>> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>> select ARCH_WANT_LD_ORPHAN_WARN >>> select ARCH_WANTS_NO_INSTR >>> + select ARCH_WANT_OPTIMIZE_VMEMMAP >>> select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES >>> select ARCH_HAS_UBSAN_SANITIZE_ALL >>> select ARM_AMBA >>> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig >>> index 9cc8b84f7eb0..ce5802066d0e 100644 >>> --- a/arch/loongarch/Kconfig >>> +++ b/arch/loongarch/Kconfig >>> @@ -56,6 +56,7 @@ config LOONGARCH >>> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>> select ARCH_WANT_LD_ORPHAN_WARN >>> select ARCH_WANTS_NO_INSTR >>> + select ARCH_WANT_OPTIMIZE_VMEMMAP >>> select BUILDTIME_TABLE_SORT >>> select COMMON_CLK >>> select CPU_PM >>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig >>> index 933771b0b07a..abffccd937b2 100644 >>> --- a/arch/s390/Kconfig >>> +++ b/arch/s390/Kconfig >>> @@ -127,6 +127,7 @@ config S390 >>> select ARCH_WANT_DEFAULT_BPF_JIT >>> select ARCH_WANT_IPC_PARSE_VERSION >>> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>> + select ARCH_WANT_OPTIMIZE_VMEMMAP >>> select BUILDTIME_TABLE_SORT >>> select CLONE_BACKWARDS2 >>> select DMA_OPS if PCI >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >>> index a825bf031f49..e8d66d834b4f 100644 >>> --- a/arch/x86/Kconfig >>> +++ b/arch/x86/Kconfig >>> @@ -127,6 +127,7 @@ config X86 >>> select ARCH_WANT_HUGE_PMD_SHARE >>> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP if X86_64 >>> select ARCH_WANT_LD_ORPHAN_WARN >>> + select ARCH_WANT_OPTIMIZE_VMEMMAP if X86_64 >>> select ARCH_WANTS_THP_SWAP if X86_64 >>> select ARCH_HAS_PARANOID_L1D_FLUSH >>> select BUILDTIME_TABLE_SORT >> >> I would remove these and instead use the >> ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP, and have your other snip be a second >> patch to drop the 'HUGETLB_' part >> >>> diff --git a/drivers/dax/device.c b/drivers/dax/device.c >>> index 5494d745ced5..05be8e79d64b 100644 >>> --- a/drivers/dax/device.c >>> +++ b/drivers/dax/device.c >>> @@ -448,7 +448,8 @@ int dev_dax_probe(struct dev_dax *dev_dax) >>> } >>> >>> pgmap->type = MEMORY_DEVICE_GENERIC; >>> - if (dev_dax->align > PAGE_SIZE) >>> + if (dev_dax->align > PAGE_SIZE && >>> + IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP)) >>> pgmap->vmemmap_shift = >>> order_base_2(dev_dax->align >> PAGE_SHIFT); >> >> vmemmap_shift relates to the compound page size we will use in >> memmap_init_zone_device(). Otherwise we are back to the base struct page on >> PMD/PUD case. Instead move the: >> >> IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP) >> >> further below to __populate_section_memmap() ... >> >>> addr = devm_memremap_pages(dev, pgmap); >>> diff --git a/include/linux/mm.h b/include/linux/mm.h >>> index 716d30d93616..fb71e21df23d 100644 >>> --- a/include/linux/mm.h >>> +++ b/include/linux/mm.h >>> @@ -3442,6 +3442,22 @@ void vmemmap_populate_print_last(void); >>> void vmemmap_free(unsigned long start, unsigned long end, >>> struct vmem_altmap *altmap); >>> #endif >>> + >>> +#ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP >>> +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, >>> + struct dev_pagemap *pgmap) >>> +{ >>> + return is_power_of_2(sizeof(struct page)) && >>> + pgmap && (pgmap_vmemmap_nr(pgmap) > 1) && !altmap; >>> +} >>> +#else >>> +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, >>> + struct dev_pagemap *pgmap) >>> +{ >>> + return false; >>> +} >>> +#endif >>> + >>> void register_page_bootmem_memmap(unsigned long section_nr, struct page *map, >>> unsigned long nr_pages); >>> >>> diff --git a/mm/Kconfig b/mm/Kconfig >>> index ff7b209dec05..99f87c1be1e8 100644 >>> --- a/mm/Kconfig >>> +++ b/mm/Kconfig >>> @@ -461,6 +461,9 @@ config SPARSEMEM_VMEMMAP >>> pfn_to_page and page_to_pfn operations. This is the most >>> efficient option when sufficient kernel resources are available. >>> >>> +config ARCH_WANT_OPTIMIZE_VMEMMAP >>> + bool >>> + >>> config HAVE_MEMBLOCK_PHYS_MAP >>> bool >>> >> As you mentioned in your other followup email it probably makes sense that you >> just use ARCH_HUGETLB_WANT_OPTIMIZE_VMEMMAP if we switch this to per-arch. And >> then have that kconfig name be renamed into the above. It simplifies the fix in >> case it pickups stable trees (the dax vmemmap deduplication came after hugetlb). >> The case for the head page reusal case for hugetlb is anyways captured by a >> hugetlb static key. > > will do > >> >> >>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c >>> index c5398a5960d0..10d73a0dfcec 100644 >>> --- a/mm/sparse-vmemmap.c >>> +++ b/mm/sparse-vmemmap.c >>> @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, >>> !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) >>> return NULL; >>> >>> - if (is_power_of_2(sizeof(struct page)) && >>> - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) >>> + if (vmemmap_can_optimize(altmap, pgmap)) >>> r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); >>> else >>> r = vmemmap_populate(start, end, nid, altmap); >> >> Same comment(s) as further above. I think it should be: >> >> if (IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP)) >> r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); >> else >> r = vmemmap_populate(start, end, nid, altmap); > > Even if arch want vmemmap optimization the ability to use compound > vmemmap_populate is further restricted by > > if (is_power_of_2(sizeof(struct page)) && > pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) > > Hence we still want if (vmemmap_can_optimize(..)) right? > Correct. It would become: if (IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP) && is_power_of_2(sizeof(struct page)) && pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); I suppose a helper could have this in vmemmap_can_optimize() as you suggest, as the condition is getting more unreadable. Probably worth using it too in compound_nr_pages(), but you would need to add a pgmap argument to that function and change its caller. vmemmap_can_optimize() is not really the greatest name, but I can't think of anything better that aligns with the rest of naming of this feature. >> >> In principle all these arches below can support >> vmemmap_populate_compound_pages() but now it would require them enable it >> explicitly, which I guess makes sense considering this bug you are fixing. But >> the arch-requirement is not really if we support optimized-vmemmap or not but if >> we support the init-mm at all. OTOH tieing both hugetlb and dax additionally >> eliminates confusion around an optimization shared by both, even if the dax >> could encompass more. I am not sure what is the arch requirement for hugetlb >> vmemmap opt these days. >> >> arch/arm64/mm/mmu.c: return vmemmap_populate_basepages(start, end, >> node, altmap); >> arch/ia64/mm/discontig.c: return vmemmap_populate_basepages(start, end, >> node, NULL); >> arch/loongarch/mm/init.c: return vmemmap_populate_basepages(start, end, >> node, NULL); >> arch/riscv/mm/init.c: return vmemmap_populate_basepages(start, end, node, NULL); >> arch/x86/mm/init_64.c: err = vmemmap_populate_basepages(start, end, >> node, NULL); >> arch/x86/mm/init_64.c: err = vmemmap_populate_basepages(start, end, >> node, NULL);