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 87D9BC77B61 for ; Mon, 10 Apr 2023 10:34:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9DBC6B0085; Mon, 10 Apr 2023 06:34:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A4D0E6B0087; Mon, 10 Apr 2023 06:34:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A00D280002; Mon, 10 Apr 2023 06:34:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 762506B0085 for ; Mon, 10 Apr 2023 06:34:25 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 42E2840137 for ; Mon, 10 Apr 2023 10:34:25 +0000 (UTC) X-FDA: 80665122090.10.B46D53A Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf03.hostedemail.com (Postfix) with ESMTP id C281820010 for ; Mon, 10 Apr 2023 10:34:21 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=vS8rHID3; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=oVhaemZy; spf=pass (imf03.hostedemail.com: domain of joao.m.martins@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=joao.m.martins@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); 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=1681122861; 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=TCT3921TLetwQKJLfZ8pddoLle0lv+dYdVMd08D4T+I=; b=l5aeqFZ2x5sPC22LoC41WocxaC3Pq9E6Egrgh3ET9V8dl3MxZTSAH5PU94U3nHcW3hIlVp vA7z7VOjBPyhUz6Aa8EBwRMpqJ1g9ff0/vlxvoDwxKtcRT88fD1v8JGcWzZ60dxAEl3XgF 1f/ldr8d/x6NXbSy2SBEtfYCkQOFqAw= ARC-Authentication-Results: i=2; imf03.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2022-7-12 header.b=vS8rHID3; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=oVhaemZy; spf=pass (imf03.hostedemail.com: domain of joao.m.martins@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=joao.m.martins@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1681122861; a=rsa-sha256; cv=pass; b=xbgsz5WQcg3lEhWpxhIb0Z1xKH4ZAgpUh9w/E3Zq9XEET6z7nvbErQ/C+swLsJFbfZvYp6 WnMn4TUDQ5dBI6HgtBI7A5ZI+2Nbx29Fl0GPQO44KiZ4Dq0z086fRcU+3AOndTZJyUcwgP a4Eo2ZdG2j7wyE9nCt62kbjOqmABy28= Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33A0Nw55002872; Mon, 10 Apr 2023 10:33:54 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=TCT3921TLetwQKJLfZ8pddoLle0lv+dYdVMd08D4T+I=; b=vS8rHID32KAj+8lkMJ/1sIkIWXJshU+4Cgn2V2TLx4pDZxmZgkbW45P/K/+49XdB+6C9 q+bXCDVT0d7WDgS6xtO8l0M9WWM8hl4P/D3sQDHYHPlG64ySrgn90DuX5EjWkhhz/Kqq 6yiRMcDTp0YshCO45KrTGTKX3bRYEEdApEhrPpznA8Av+gD1RlD1aoC08EFHSHv/WZ/6 WS8x3kZvlhFgJC2mUDuEFMEG+6pHLxVpeGDIqtAfBYtfwAfYr/ixWCLpZJ4YKddA6E8b jBw/xF51gjXjr63GIGS6nmLQxiYW1iR4nVvOgFHAS92pmZXyIqXsK+ehrIlLj/eWc7BE Tw== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3pu0bwah64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Apr 2023 10:33:54 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 33A9V25L034137; Mon, 10 Apr 2023 10:33:53 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2174.outbound.protection.outlook.com [104.47.57.174]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3puwc1y9pv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Apr 2023 10:33:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JFBtpn5hxWSnA5f9xqkVeKmXUgAoeXvFNmh92b+uNrxkkFJWfq6yVHKoI3HNTNgorF8mxULyzctiQ1B/f9Bg8UHupNW0XRN6py0loatleRDpv3yZEwRDuBnQcj804chEJdAlfUrl3dMAyYVWUGKgfirG+qggCMY34EMIpvBlYH5PMArenIs/jqY7gm0yeSG8pvSLyhHfUBWKzyp2u6L7OVPm3dLMx/0W2oksth/x5B5ElA6+AmykXilVBLNVzx3OVlyW2C3wAQNJt/UV8+E0oQjoNyLIQ0RMYzKzqUxjUU8CFxPqXcdbhMkU3j4fb2dsTUF22n/p2fPpOZl/OzIGog== 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=TCT3921TLetwQKJLfZ8pddoLle0lv+dYdVMd08D4T+I=; b=aMffuOW1kZ4sdRGYeJS8FBvgcw0PBN87vVbpOvF1qhJPt2qGXU9BZELGRzLxwpyS0qy9hELY4i6iuZcCMH+/Vou8YEoSglOpTsQCoHLK6BLqv2Tx96UsD0gyhLeosapjX+Mz0/E7ZleZk8K5s/fJk7B+I6cywrt5+xIO2nk5uT6LTbm7loSAdQCvsQufObzDQj2uaHC+G6Kb6KwiyD/ucWRhvnGSlCkr0lmwqVwoWUt19vWb5/WhvR8QVSGBGTk6OTzfsY+/hxtreAou6x9Oi6UXaMmUvVRUcb8UMWpjx+2WhKwn6cdY7yDqx3r0ukOJ7rYCzZAOJJfbutT7wTqp+w== 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=TCT3921TLetwQKJLfZ8pddoLle0lv+dYdVMd08D4T+I=; b=oVhaemZyDjCsBd+I9cLr0aG6XakzzMzAx1KBWAd+hAUf64jLTJGV6OAB6xFlZ9JHxrfYWM8ZeyoOwSm191bWrMU0yOrdoRDWxf8rY9NrCJPJkKxQTC048gCpq4gChDUxfUwSpfAWfQux1T7qVWVGNC92og/g2pkldA/N49uZCM0= Received: from BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) by PH7PR10MB5855.namprd10.prod.outlook.com (2603:10b6:510:13f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6277.38; Mon, 10 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; Mon, 10 Apr 2023 10:33:51 +0000 Message-ID: <5c30292b-7e68-8897-9ca0-cc800b866ba7@oracle.com> Date: Mon, 10 Apr 2023 11:33:45 +0100 Subject: Re: [PATCH] mm/vmemmap/devdax: Fix kernel crash when probing devdax devices 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> Content-Language: en-US From: Joao Martins In-Reply-To: <20230407122353.12018-1-aneesh.kumar@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM4PR07CA0007.eurprd07.prod.outlook.com (2603:10a6:205:1::20) To BLAPR10MB4835.namprd10.prod.outlook.com (2603:10b6:208:331::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BLAPR10MB4835:EE_|PH7PR10MB5855:EE_ X-MS-Office365-Filtering-Correlation-Id: 158cadc4-8460-484d-962b-08db39af1379 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: i4R1uC5MrQEhxAcfNFLgAsxuM6FFrpE4edhbBTHiPVzM/LqRWer8uqe9LXiN+lunCEvJh2dUun8Yhn/Jvc39ggjPcPupAbddfQg6wG4DuL2JfjVdqhicbEXyJSjWxIVo8VgvlCeqHrVu6b2QfBqpHIY2UC4vdugFgWsEqdclfS0fw3ZHdrVsaJVp38dazizt1rHi97qeY9r1ZPIDyTYntpTH8xfteebS/n6lRq3cYtMdZCVq/UOB9+JTHB0aHaXXcro5PbyevGQOl1STWQ66ChVDD8+y8nfFfGX+Uyi4QZ8YZ6oTpSL8Rkn9eoekXOSfDX5XxU8LQ7+EIusZhqxaVxj2lUlQVbQjkB5Ti7TYUEWPEtm3e9O5mMAbRX0oj50IHN1rB7NkulBVOuel8wpkBOcIknhzlER/G/QI/RUtWaMEjHMcloHDtYGDgVrSBQeBri/ICSFfipK+rTKvP2mFSLps4upkEN28Y0cMPc4EYDLR7LCEU0AHsSzGqDGpsQRAgWKp7+Z4Mb+wDYo31qAyjvP7fab8htHtzgfXSnz6loPOSTRuFBeqVKp35Rd3KnsGzfbZZbRe/1QGBhe94hSicFpoMV1u2mXHLY1XLdISAF5/XBtohrGC6UEkV02vMIil 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)(376002)(346002)(396003)(136003)(366004)(39860400002)(451199021)(8936002)(6666004)(30864003)(6486002)(5660300002)(86362001)(31696002)(66556008)(66476007)(66946007)(8676002)(6916009)(4326008)(478600001)(38100700002)(316002)(31686004)(54906003)(2906002)(53546011)(6512007)(6506007)(26005)(2616005)(83380400001)(45080400002)(186003)(41300700001)(36756003)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a2oxamV0dlJaVlBOYUQxdzNkMFdYM2F0S0QrSGtSVUg1eU9HT3lrTDhFY1lI?= =?utf-8?B?eW1BOWZtQ3BydGt4djBHdk42MUZiNW40YzRrTHFJaGQwK1cyVTZZK2Q0RTBT?= =?utf-8?B?dG11d0hmdUk1N2FXcndrTG05QXhRaWIzUTY5aTBtckNDK1hmdW96K1JOZkM2?= =?utf-8?B?L2JDb21BV2JBUXRJN2xXK3VIS0RxczJOYzlkcUxod2puVG9rU2Y0SGFDVGZD?= =?utf-8?B?NzZNaHhqNm4vWVVxUVA2RWhUejlkZTZuclo5azArR01yQ09yK2ZsZGE1NDhQ?= =?utf-8?B?bW5mVUQ2alV4NW9wV2lFZTFpUjNpRU41bWpadGtRTWVoNFo4bmY2MHIrWjA1?= =?utf-8?B?U0dFQ2VUWmJHc1JjNjl6OTd5NTBQOXpBaW9RMVQ4ZzhKSjZNRmNHYlNLLzg0?= =?utf-8?B?Uy80ekZYQWVlL28wOTVlZ010MzVzQlJxeFh5d3JlVHNOak5EMUhjc3ZDNVdL?= =?utf-8?B?Ni9RUzlBci9yTi9iazFUTXdicmt5aUNqd0ZwQnA2Y0FIYlQxRXBPcXI4VlNu?= =?utf-8?B?RDZDNm5ERmF1b0Q0c0pnWTZTK3lKVE5DOVBRUGV2TzdQcEgwMERaVjFQK096?= =?utf-8?B?eXc1aWVvRjhYZjJZblhKcStjdVV2N2JFM2NpdVVJaXJqdkVHbnA2N2lTVzNR?= =?utf-8?B?VkN3VnhEWWlZcjRIMG9uU01OQ1d1ckR1azNMZjk2S1ZScGNEL2h3SmF5Zlpp?= =?utf-8?B?ZEQyTTBLUGthclFuTktGVCtoRkNZZFNHdElIWHc2eWJDak9ZMlY0c1pXR1VS?= =?utf-8?B?VnNYQSsxaWdPZ1ZBcnRMSERYblRTVDN1YWc1SXJWTWJQUXhrUWNRTUpsWE91?= =?utf-8?B?WVJjVmJyVUY0cm9aRE8zVTZBYXBsVWMrS1RQWWJwWWVqb2tKSmNXK1dnM3Q5?= =?utf-8?B?QmYzQlpGODNCUTZrUzVZbmtwYWhXa3UyRGZVLzJoK0Z5YXh5WTFBTnVrYmZx?= =?utf-8?B?K0luUmU3dWp5Nm90Ym50ZFRRRWlxblh5YzNJVlQvUGpyWkZSY0ZYcTNnTHp1?= =?utf-8?B?S0twUldYb1ZFd1IydUJpb1JOWnlFaWc2aGxkekptR2VyWXIzMERybUlFRVRB?= =?utf-8?B?b2xSS2J5bVRWWFVFTnoyUlFRVzRIcWFTanJqRFdPdVZEald4aXhIa2FQellM?= =?utf-8?B?dmpJSFRFRDRlY3ZVTWl0V1lpTUZqY2dUdFUwMkY0eUJZNWRDUzgwMTRvUW8x?= =?utf-8?B?YVFMSTUwNUFQMEZBNEhMOGsvYnhYejFTUmNZU0NTOXpaTFA2Mzg4ZGY0dlFO?= =?utf-8?B?NklpWkZvMnV3bVpFUXB3dDVqcTBpYm4wTU52K0RsNklXeHNGY2kvaUx5d0xm?= =?utf-8?B?NmgxWUdXTXlrTWhYM25nZ0JoVE91UnBvbjVleXl3M3NQOElwQzAvWEovMGQz?= =?utf-8?B?T1o0MlZGS2RHS1crcXRLaFNubkwvSGZXbDZUeUZaU0Q0VDU0YzJHNTV4Nk9K?= =?utf-8?B?NGVYTStFSkorQWYvcFBZOWhLUlAzODB5U2pBSTRCWHYzdFFtNTRYMENkOVFt?= =?utf-8?B?Yi9zMVJscXFxRVJEaVZ6eVpSVkR6TGR5SUMwVzZxcHZUN0pCMklCeWNIbEtl?= =?utf-8?B?RWtGckRlK0oySEtubnEvZ092ZjF0dHMxVTFsekdsRUU3SVZML1VNQXFqdXFa?= =?utf-8?B?VnBYTldxRGVpdDJ2aVBQTHB0Um5iYWdYR0Z3UzNOUmNpc3QxQ3pxOWthVG52?= =?utf-8?B?U2lTcnR0ZlB3bFZHMWRBKzJHQ2JWQ2FGeW1GVVBvZjBHenBCTGsxTGR6Q29m?= =?utf-8?B?T096aGZ6b1dmMnJIWS9XVk1FamQ1QXBiWjd5N0RSd0s5UVhoOHEzYjE3UXFU?= =?utf-8?B?Y2NFeFFJQ0FVUklWTEpoTmQ2QldsOEdzQy85MFZjaUd1OXRBYW9FNDYxemsr?= =?utf-8?B?T1FvRUx6WmFad2xKQStUTDF1UkdTZXVCTVRnWUphb1ZXNXRUMTlxeXNWNWx1?= =?utf-8?B?a3BQeFFZYlFVMk5GZjRhMlNmRUJHWFR5YThYdXc4YjlKbmpFNkoxdmYya3Bi?= =?utf-8?B?YlY4VHBlMTRxekNTVkoxR2lHTHpzOTFOZ3Iyb1Bxa2pHdFhTK2IvcUFBakt3?= =?utf-8?B?YjBqNTg4Tkhxd01ycHNYNm5Xd24yT0wrbWJxWUFEYStIUFhvNFdRVTdXY3Zy?= =?utf-8?B?MysrekpMNHNvZGo1WC9ERzZxSU1majI1L2l1cHJ5WlMzQnA0LzRPQjU5UnZ3?= =?utf-8?B?YVE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: PuHixLxZ3miEO2nRAWL+IoCxGG49G6r6n1HXUbqgEKVV8NZ8jvgvTMCrbgwgluVb7DPNKRAMdkNkvx4mDAvPrrveYuDlrjYWxA/tddYKQqp4L6Pm2F9JaSHGfmB1E1eq4mT1a5H0Bv1PbVBmAqSwGebXb10RHkNQgAmYYtLC1Yhjg7bk/nVj0JcGip8Njlj1+XGWm3Nekfott6Uca4bbuwEhbpXlFjZ92KCF7QxQbF7Oj9ZylmXiPiQq6YZf2SA+KHc1IAifWBUSXXTkIrGCmwKwuUTjUwjKV5B7yftYbFeFc4ziKs41Lw27zExl+8togJlf/Z7iN5zFk8HqeOZQuztv9MlBqpCYafiQp56abf0eHGahzMjpD4cgyKg6u/j2Z/4W+AYnw/73NALT2aLeyd9TDXi0QXSGv3UCIVxqW4vYauu2//M2wqmeX2IyHkffhQVp8tZO8mUfAyWEz4dMH46f78rG4xSi+xHZYs0yOYy03BL2x/TwdTMiXJ0seY+J0IFdebGPwXs/lKBtlszcIX9Kiw36yUttugMvj/5h8oDW7tpmmPxHi0DgtuMHbO5FrP5S58LM3P88Kb4IoMxxqHeEF1z3HVyg9ILW9Fx68GaCibNM5IxWDcZpXAVPCGihIloZ7pKeTh8Dlqs6hI+8xHHCCrsU9kq0JB2TJBRbrL307YT/BD0mBV/Ga/lXH7C4gpPznRr2JcHf8czoawxEP6hU9LDuVviYHJk1TYiRxdJOZnbODYYkjCR72HKHIikBG3X8sja2kCfBUqxfI/jNzU44eYhIpu8KwNR1huj1vaSLxorSAHY4ew1uaz3FwQ2/l1fkbRC50M7fyK+IuYiu5dC6ABBfafFU2R6FChEgJo/UHPO+bbsnqE1DAQLqtTLXs6LuKJt5h7g1JovlwkR0LQ== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 158cadc4-8460-484d-962b-08db39af1379 X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4835.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2023 10:33:51.5303 (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: VvT2XBm1eZLZuLKNnLXc4kOcn9CFWfuAJPSN7PcI5PQrmiMzSfoJHu2HtWauT657TTmXHljz3aQ7Xns48AghmsxcNxiuT4swEfic+hKmvQo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB5855 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-10_07,2023-04-06_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 adultscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304100090 X-Proofpoint-ORIG-GUID: fB6To5Q74yPSIeJGUEapwZlVCbISIt7y X-Proofpoint-GUID: fB6To5Q74yPSIeJGUEapwZlVCbISIt7y X-Stat-Signature: czbq9uikwcz7yupt4bu3h67c5kak19uk X-Rspam-User: X-Rspamd-Queue-Id: C281820010 X-Rspamd-Server: rspam06 X-HE-Tag: 1681122861-122511 X-HE-Meta: U2FsdGVkX1/JPgHQGGZiJqATU3Z+Z6diJB0YqPWfwjxjpxaiwocveNmX07TllQuCSPDoNA8QoQ7FX8sjamDuRDOECjt/5cPDCuf7MvCOBr0qEueJ7vIVJExajzvHqVQ5HR1YZILKlk+r1fWWxoRsl/helRTJZaPGnZRoMrXmA9rFGre7+mjyIDgiTzsvPApVC5BESPZAhDMQpZ2deIaagMDmRbIvo04YVkDw/nzSLU+CgHRSpET8uEHV4gawx0TVQpgMLRG0Vy87n8ZfY/CCIvT1ntILz0gGn7sq+ljccNzG9uJf2NkyvOeXwJfgDyHltHoVEr49DAoW3AG/uAMjXdWEHt7x5UWzZhBDTo36UFU9M3EMesSQT2PmoN2C0rSM1I+jZHNZtvDWCG5NEM19PTiEzKDqOcI82zL6K8zDS+rMA5iT/KwdmzTlS2uOPauzFiy92gAuEFV8eq8NOoYKVbMrgTmTm//TocxkXjLldQkpeDMXRQTFZcSyzf05uXVmkpdWzkwsqccPiH/OgGWVX5UIjrNZitGSQYdeM3nDJ7lf6K1UO+kynl+eSF3CtJz4DrZkwxFMKFuwWT4nLfxxQ0MnzjjwjaA7XoYJEWF7pfD4cgn1tltMChAVE7atUWfQdDHG2iLu3rZxXf6neb9YHpQixXhdOPOq9zvM5IXCrR6akqryg2TjG8gsCLEy0m3nYr0Emrzt+RhG3YFlvP7hYI6HMqUdUEamXP8di4D/SmbMrJD9SjLqyOx6B1QkpvOvW3iURaRUlFuM4ePgcwB3MJuYcF2mPT1CGf2q8TEh+l0xYKsR2kYDwPKIMgvTelHMlfiWk7USoZUREZF4YVw307bc+aUojN4sB5VNUyvFIgApCuT41F7qkN+SbJLO9YK/q/194c9ipKRn5fG9L3hxorQKVqcDgjkc6n0ngTRmE8GPnurnB+s3WIhMfgAVE7io+Nf4qqynYsbTShvVyy3 19+pw7pe uOOJ+Nctdjlxemm4798dLbtNwsmxiORWxhFg5VIIXxgMvlPxenktdmf8he+BHQnty0usUdkOQwL9g7jCwPObnjWO/6nMJ72cPrbxWpA6oKnzAhQa5qJxYtL+4RJ/LCFCmCPezg3durhmsOtc/VCM9P6ki1fHya4UMvZG42Ud4q9emRdUyzzFx9jIXhNytQByp/CUSihU48wDlf5n9LwchkCUPK5gl2/N3V4NGUCW8HkZwGgmeJZ1gOjminvEr5TnDNWS2dspXiXG0mQzzOXu0FBso/B9mJthk21xGZQvFu59173Yf368qwm2BhTg6x4gFAe0jD0yjcZ5ijmPqVCtBOcARRUcHE8yYoqmZdVNviaNwHE+O3KUn3Esvte/FdEllm16h2wdaKNMNiGyklRbBKd0nkvYhGtma7rMYgdlZ3lwh7tAY/BMRZKpg5qnkcFlUafbt0jVUhDZmvrTPzkmsH06sSfmUIYqD3UNa97Aroajn/XAXkqYabbpDO6uRactGuVy/aq346A9RaDGCbSgN8cvVgO90/z8oLXD4 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 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: 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. > This patch fixes the below crash on ppc64. > > BUG: Unable to handle kernel data access on write at 0xc00c000100400038 > Faulting instruction address: 0xc000000001269d90 > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > Modules linked in: > CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-150500.34-default+ #2 5c90a668b6bbd142599890245c2fb5de19d7d28a > Hardware name: IBM,9009-42G POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.40 (VL950_099) hv:phyp pSeries > NIP: c000000001269d90 LR: c0000000004c57d4 CTR: 0000000000000000 > REGS: c000000003632c30 TRAP: 0300 Not tainted (6.3.0-rc5-150500.34-default+) > MSR: 8000000000009033 CR: 24842228 XER: 00000000 > CFAR: c0000000004c57d0 DAR: c00c000100400038 DSISR: 42000000 IRQMASK: 0 > .... > NIP [c000000001269d90] __init_single_page.isra.74+0x14/0x4c > LR [c0000000004c57d4] __init_zone_device_page+0x44/0xd0 > Call Trace: > [c000000003632ed0] [c000000003632f60] 0xc000000003632f60 (unreliable) > [c000000003632f10] [c0000000004c5ca0] memmap_init_zone_device+0x170/0x250 > [c000000003632fe0] [c0000000005575f8] memremap_pages+0x2c8/0x7f0 > [c0000000036330c0] [c000000000557b5c] devm_memremap_pages+0x3c/0xa0 > [c000000003633100] [c000000000d458a8] dev_dax_probe+0x108/0x3e0 > [c0000000036331a0] [c000000000d41430] dax_bus_probe+0xb0/0x140 > [c0000000036331d0] [c000000000cef27c] really_probe+0x19c/0x520 > [c000000003633260] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 > [c0000000036332e0] [c000000000cef888] driver_probe_device+0x58/0x120 > [c000000003633320] [c000000000cefa6c] __device_attach_driver+0x11c/0x1e0 > [c0000000036333a0] [c000000000cebc58] bus_for_each_drv+0xa8/0x130 > [c000000003633400] [c000000000ceefcc] __device_attach+0x15c/0x250 > [c0000000036334a0] [c000000000ced458] bus_probe_device+0x108/0x110 > [c0000000036334f0] [c000000000ce92dc] device_add+0x7fc/0xa10 > [c0000000036335b0] [c000000000d447c8] devm_create_dev_dax+0x1d8/0x530 > [c000000003633640] [c000000000d46b60] __dax_pmem_probe+0x200/0x270 > [c0000000036337b0] [c000000000d46bf0] dax_pmem_probe+0x20/0x70 > [c0000000036337d0] [c000000000d2279c] nvdimm_bus_probe+0xac/0x2b0 > [c000000003633860] [c000000000cef27c] really_probe+0x19c/0x520 > [c0000000036338f0] [c000000000cef6b4] __driver_probe_device+0xb4/0x230 > [c000000003633970] [c000000000cef888] driver_probe_device+0x58/0x120 > [c0000000036339b0] [c000000000cefd08] __driver_attach+0x1d8/0x240 > [c000000003633a30] [c000000000cebb04] bus_for_each_dev+0xb4/0x130 > [c000000003633a90] [c000000000cee564] driver_attach+0x34/0x50 > [c000000003633ab0] [c000000000ced878] bus_add_driver+0x218/0x300 > [c000000003633b40] [c000000000cf1144] driver_register+0xa4/0x1b0 > [c000000003633bb0] [c000000000d21a0c] __nd_driver_register+0x5c/0x100 > [c000000003633c10] [c00000000206a2e8] dax_pmem_init+0x34/0x48 > [c000000003633c30] [c0000000000132d0] do_one_initcall+0x60/0x320 > [c000000003633d00] [c0000000020051b0] kernel_init_freeable+0x360/0x400 > [c000000003633de0] [c000000000013764] kernel_init+0x34/0x1d0 > [c000000003633e50] [c00000000000de14] ret_from_kernel_thread+0x5c/0x64 > > 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") 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. > 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); 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);