Message ID | 20231009201639.920512-3-sidhartha.kumar@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp2100783vqo; Mon, 9 Oct 2023 13:17:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFZcrvEWLuY3/fBNiPBVfLUMhJZIgwYDPlXrpYmM76i/PavOLptyWxfbIQZTZOKV1BKwjUG X-Received: by 2002:a05:6a21:3284:b0:16b:79b3:222b with SMTP id yt4-20020a056a21328400b0016b79b3222bmr13538381pzb.34.1696882670363; Mon, 09 Oct 2023 13:17:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1696882670; cv=pass; d=google.com; s=arc-20160816; b=FNWfUlX4CbPdgk0wT1FDl7EgUeJGOl9/RLS0tcf/7TIKbpg3BSygKwrga2dXewzYgk 3sqgjIsrJVKvEQY11EMsVCZrxkXnBS61Hb/DezXMrrELnv0Inri70q6D9Qo18H1aCSXe iRnwAlJYGmUZ/SFaIOyItDihXd5uCLybkbWZ0Er0KM6LeLefH9YqMcE8Co2aHxAI7Ixi Tb/LrGgawtQ22I4PD0Q+1BF58GtdNTwySV7XzaqhXGxvMpv310mhikVhSTF82YO8GI4B KzGk4OSAS8HnI8ao3E0MXscndge1dbiIskUE26mNYegWbSSlkL4aetpd53Tn0CyMbpyV tvuQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=4H5BtvqSc+0mOYg98doViY1SX0bCxITXGEXdoB6sLAM=; fh=B8hmr/q5j3tCmv46TiFW349WPKYIK+b/KkTcg+TQCdo=; b=YEIeJAT3w6AhUGTMqRFNDimbRY40kiELAbHCBedpZMp6FzteYlllVNNUy4II1D0In8 Q4z4Vl2jTuvlf3xfSba3ZAn7jdf2d2pFJZ/dg51kGtUbM264AyBAQiEGB3B3HTRv3c7Z 0dKhCXcGmconpaaOvbGJkJOpUOm5ev6yXIzDUAnD0RpCrdLX1i/2cyFns9UNO+VLNeSK puSAA1aLNdUZ2WLXB4Rco98//t4IZJ2az9n6UAS7lddtn/FvPPZxYRkQYxOunpbjAC1h NKD+fCza+3RrY4E7EIAazAm+5jCVIMk7EKOEVDKRD0V4tzH/TWC7dZu99ObatelK79B4 oi8g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=ujT23XKE; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=TdLjyEH2; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id f23-20020a63dc57000000b00588fa0def27si10047609pgj.796.2023.10.09.13.17.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 13:17:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=ujT23XKE; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=TdLjyEH2; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id ECEEA80BB223; Mon, 9 Oct 2023 13:17:47 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378591AbjJIUR0 (ORCPT <rfc822;ezelljr.billy@gmail.com> + 18 others); Mon, 9 Oct 2023 16:17:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378586AbjJIURW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Oct 2023 16:17:22 -0400 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9869B6 for <linux-kernel@vger.kernel.org>; Mon, 9 Oct 2023 13:17:19 -0700 (PDT) Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 399EXxfB014979; Mon, 9 Oct 2023 20:16:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-transfer-encoding : content-type : mime-version; s=corp-2023-03-30; bh=4H5BtvqSc+0mOYg98doViY1SX0bCxITXGEXdoB6sLAM=; b=ujT23XKEa4nsStIg2waYnxP8CJbixv4PuMHqKhSQjZ2SsHsNWevgZVFPsaLtXMvaMBrO 0DCoKZNKOGhdXMPXtsP+9G9+wCsyL7DEoYozcKx6AyiEqnnRYEdkgnegy/bQ/WvLfiP5 78KvcIm19SbtD1/oieSlenAg2q0j8+FWK2Q68DRMuuE0iC9WdD5cwKUMOMMc+2hY5xi3 Tt4KvUNsqBRLkHRYHjqC0bEgTEMdmGW0+zBWL8En+NzY1kqV3FXC3sxoCoiKxfmcZar9 1FTrlvOLC+t8b+zy61np8EklQOYxKXnpOLNxYJ0bqNf0MYftriAYoMxd+eQZwbMwV7UI lQ== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3tjx43kmbg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Oct 2023 20:16: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 399JV8q5032145; Mon, 9 Oct 2023 20:16:54 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3tmfhntnbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Oct 2023 20:16:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iH00Lwo+wX++A266L4wV3K3CXPgllYZ7hWgP6UswUMJJHt/4sQ9zDlrK2G+o5tynaYRWH+UyElx17rUS1iU7slC3+kh4qdUifcuhsfbgkV5OIb6E7KeGKCqzi4owaTo2J9FnSAqnclo2U0T3aeQOBLFlxyHWGGFIhAKeDgLvRqtfKDZvQO/0yjSt/jCIAh73pQVhdVHT0TXApFU1ZwFofUNZvmjrG/I9RP6NI1jKldgDA3VdiMBGE+j6HFjjmPZ8CohaZZ/Z6ZHiZQwGOyEFDNhxbL8UgirM+0zw/MFF6koiDPzD1MvmPuhPvctT0nrT3pxtjXvbvgNizDh1tuLNcA== 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=4H5BtvqSc+0mOYg98doViY1SX0bCxITXGEXdoB6sLAM=; b=fMD707e2ZFbunYtQmMVJVw6l5F+IuQAgOCBuDrgIpc4nD6Q0PaFu/VKWd3H5d51JhSOvopFiC+sQRqnbjmBuxdfStZz9HEu1ddt9IXmE8qtzVnlHvkEIwgPorAuJFW7pZG3NdZwfL8XcKGSumX2RcnjjI/t0xMgTVCNBFceznLUEHCThbsl0hGZPQQ88SWZ5Lum9Q5d/aO0GuHpxIXZnyZ/oeXgdvFmMWjC6BHn0qWv2m4owAZ0CruNuCOB/ZDisyXfirriy7acBpC+n/8HysgF2luJr2tVnYSnoHv63db1e8r7JRuk74Wg3QechjCcR16zU++9t2YMX7/IoMmuIpw== 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=4H5BtvqSc+0mOYg98doViY1SX0bCxITXGEXdoB6sLAM=; b=TdLjyEH2KpbTeQX+VNaECaT5c16v8t/fcjb5HqUnKpZ25qFWFliTpf/L0JsSD+9zkxNSOSdFo+sCkgHicBKNQs8LbKlc2ECL5UDg8hdKo7+57dLo88ItsjrLUqu9n7gquEnv8NTeGVifG8fComXkD7lr0uMYBz932DF7b52v5Mw= Received: from CH0PR10MB5113.namprd10.prod.outlook.com (2603:10b6:610:c9::8) by SA3PR10MB6998.namprd10.prod.outlook.com (2603:10b6:806:31c::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.35; Mon, 9 Oct 2023 20:16:52 +0000 Received: from CH0PR10MB5113.namprd10.prod.outlook.com ([fe80::e391:f2a1:a9d:967d]) by CH0PR10MB5113.namprd10.prod.outlook.com ([fe80::e391:f2a1:a9d:967d%6]) with mapi id 15.20.6863.032; Mon, 9 Oct 2023 20:16:52 +0000 From: Sidhartha Kumar <sidhartha.kumar@oracle.com> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, maple-tree@lists.infradead.org Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, zhangpeng.00@bytedance.com, Sidhartha Kumar <sidhartha.kumar@oracle.com> Subject: [PATCH 2/3] maple_tree: use preallocations in mas_store_gfp() Date: Mon, 9 Oct 2023 13:16:38 -0700 Message-ID: <20231009201639.920512-3-sidhartha.kumar@oracle.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231009201639.920512-1-sidhartha.kumar@oracle.com> References: <20231009201639.920512-1-sidhartha.kumar@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY5PR04CA0021.namprd04.prod.outlook.com (2603:10b6:a03:1d0::31) To CH0PR10MB5113.namprd10.prod.outlook.com (2603:10b6:610:c9::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH0PR10MB5113:EE_|SA3PR10MB6998:EE_ X-MS-Office365-Filtering-Correlation-Id: 2de33596-c95f-406b-19d1-08dbc904accf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M2P9cZnWrh8m/33tYCndTboE7nyH7P8HMx9DM0cVuHPui/3vpkP/a2CXGxUmsPZN/6UeHLbQjc/kRQ10q6ZbmFW1Oc578Rp9doohqUKAyIMAQATwrfkPKu6S9EHLQRYx/TPLTAlSH/YVPLfXITpGxAsffVQ039SKAz5ZvlXBSYAkyl2mYIlKLXgja1EJjRp2na2OCi8KuvdScikmysKo3CH3mcEywek4yNz00hR7f2bt8SrnQzObHjJQImkbVyYs2aQztJ988awdnsRV9nsNvqSR9wTbkL28n3yyZnimvE+fIwZGmhttJ4N4oDhK5v83SbXZy2+7rt1FK6Wv4Ut+SHD2hqwNQ9ViryQ0pioFMwnpblGuJiw/tedrkbRqw3DZMaaknyHB0lAhWNvanw3InLp2kpA8cbyrf35T8Q6Hk59f7MZzo1f402a72NL8QyQ0opLf4bQFE++oyxrTB0IMNfk3bpbtPKSPd0gXw2U1zOsydmNy3v1TElK43dq+YmRmiV5XWijIgOcNgdUYfQh1AnqTjpvHaw9HIWICmpkOsQpZdRaaxUvvwVy9Y5Gtk2CF X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR10MB5113.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(136003)(39860400002)(376002)(346002)(396003)(230922051799003)(1800799009)(451199024)(64100799003)(186009)(86362001)(38100700002)(36756003)(6486002)(6512007)(2906002)(6666004)(478600001)(8936002)(44832011)(5660300002)(41300700001)(8676002)(6506007)(4326008)(107886003)(83380400001)(2616005)(1076003)(66946007)(66556008)(66476007)(316002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CYNtsjwMFytaiHutQniWb+QtCfJ8wzdZx3US3L+9n+zOXCMB9BZxeeYhOClT8WEXudUUffy1vKcGf8R3saRqF9erdlPCJ3UAUglquNfJqFQKe1aOinrkHK72eTZVoDM129nsCKz7URJdO76oADGwMc/x7GlE/l/ByHg4gGFfh3Zm//SyL1CYnXN3RrmhmfWWoikOrVBocDi7xp5zEG9dUdluLpz/d3kRkBvlqC8drCNK3MBoDPmFONbDO1LspmS32uJv8QH9dhyTqKlh+AUltzZyNhnpjHpr5r7lHFe/hIId4foE+oqXPHAYoOWeD2LdBKja/2PPO7BVjgIOk3q+6rlfdTe2HUbfgjIoD3qck3Jgu75dT53MXkceYAskOU1NnVroxiFXfqyLXoYc2gHTeD3BkOjBLHYO9uq8A1O/Q6OFloUIjBijqnvRCdakFyfCGIL9fTS4zl5MydsDN/WCGfu/Cfz8+MKo8BZta7FXj/BDv4TbPOfqWwwbb9n7tCQ36BgqMifj50Z7Bc5fFo4UdMGrcv40LO6vp3A5imeaWU7d9y5ulyDMDsdRC8SIDl348C/klY/0CkkCXXdmTjflgxerslWzPyKs09Ub6iUBZQIx7ZrwlQ5IE5Z1hDW/YqNJyl2BvVVRfywJNyCThzNDaA7TUJnU04mCmUi+kZDWyEWVOz7svLzcWqZMXTO+YTErTlMaqZYgxCnQF5JoHj0y4mwMNQ43OvvH0+bRrEFwIDOb+SFkPimv1sm6ZMW+LJBFAxABJOKJLch938mM83ISet7F39W0QYfC76y7sMASsRsbDCYRkRhP4ajsWNS8hhd2fJCxcqnZF/hhC7zP+SqEY5Ep2gh1KySSrF/qaxIxrs2cTa08DpFoCSGwMtHlXeo/cwveH69TyfW3lnisjY3HoM/scefV0gs5WJuXERJCwNctlY22pRLrTElyy3pd1FET2tJAWMq9oLjuCDaM7obmySv/trwLSmZNkrAO1DxxOGxm5jaX+RlOlHnJaSIG9D+aoP8r5oDwrrm21GesccEzBZbvf8NkzZKh2cf2aQTE5YD4IDt+I/CFsw1tlxKqgE8QGUtyI8rBqgSRsoCP1PJl2ti1ySefvP8DIFIGV3yMCh2bCU7abspe2oOmZ2pMJMpLkrszwNKOkSqL41axZK0MF8vSMEjpfauULWOYHwSulmC3gCipJ6ywpSrDf45WtuGZlknsW/HkJ5TFeiD27fDCjM2Mb937OgPccJUhO3g2QNYa/f8hDYmX5QG64g78wnPD9Ok5rN2X1kd7J35y56wKeGGn7GbwEtkElmf9vnHv7AL9WSTuYFxwIeCjCU0boek5YAshl+hmcbZ4nccRrCrdi//lXY2mmXrYTsYsRJXypaM3hzFgUDIIFzJAy9Z8JA7MjS/hRRa7HsC+ZONxfaapJa9rJ/1MWQxFAn89QW2ilVtqgXON5MZeOHdixmFtCrptj/ua3x6r3qn2FW2vNs9315X7rgcsxXKflQAl6r6JqYrBwh3i8+Sz/iCR8q+8wYIZtQ7DMOUytOVEWrpB1VYfUmypSnr/J+6FTmIBdnpQhXQWt/VSoMBK3KxILpauoduuYncEq1ev3rkcbEQAMmP7ONL5m993mflYb0aNA/H1rcE= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: HyPEzU2lsgwdMlF983u/IDfS26yBDJmaALuor8kHa+geei2tN3v94MHV9Qcx6CApT8s2PLT0H55yRR7NKRQu7bn04SraxmjuaqRr0q+m3WubrpLm2JTfae3pUnnZZBop6BiUKzUz3moVp8S7A0jL+oGt8LNC2VFxCdxltlKUGDIRyheO9PHZhf9f6zdSJ5Iox6BGtR+ndP1l6BOCvnjsyVcCq1LmHt/AT8dqdaqKP7cyZ/fjXJMiNtOkyj24lH7tDh1/w2Q+gm1E/4PBfRKse3WKKSzWoMeLIb2DilLvPWcN7CJP+7TgRAzEvLiTx1rbxfMj+PgHVV1qaad5UjoLYB3QNuOuOJ5ZZ2dP79YWSFhzdTe6A977dX5RzAm9Cqs+wVcm7LQSBQYTAfnY8eG2WAbGTxnc7AawMLBlhg1PFmTEXYx2rxgTmLrkrvqDYRb95tA3ATH3HOcQovyY733nK3ppDEAXRLVEfqfhO78TdLqGJIoGpJNYPSJSai87rptzYvKUUG/cg38oLqlgjpQ2CDSoIj5ByEzU3fj3a41U99Nu5T8V6qsF+SfT+5dkcxY4/FV+qCjo2ZdpuUgJDMDFMeyT/QUobwJDl4Fw4x1ye2FWIIyr/Vq/JbKpQKa81zrBBpZSVa04JXDNwDp54YsovIPBzX6M3g5l43+Xbauw09F2hiVUnvGXu/PkQDfw+a8pgULvUYmtm3ZjeygrwvVME7PpBjMa+FVP047bHTsezntwKIRliR82TyiMeeoLh3RksQ/I18hbMhwXo8cveC6fimAL4qvCSaaZRzN7NG7ouA0/BZhX7kR9o2fsU/nIUJI3CAMljKeJqDHgjSjieqtJ9roj2CI+4pIvXi95SWFnAiFeMyt6Pok7tMB3GKD6hD/qLRq3Tgibw+Z8lpFhSk5uNHtYHRZ/V14DJaj7I3UDVHd9PcPx8g0+g4QKRe19U2e3FPnoF6CvJuwgNrS7AGkdRg== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2de33596-c95f-406b-19d1-08dbc904accf X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB5113.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2023 20:16:52.0423 (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: znOV2H6GjDyY0wwOtwwh6BmvzYZdzEYKiATTmdXiw/tfSZ5aS8Vtqpwu6ubu85gb/EC0XqvFLsiyGprtXvpISkf+8vcoIES60Hljveo1Ab0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR10MB6998 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-09_18,2023-10-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 adultscore=0 phishscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310090163 X-Proofpoint-ORIG-GUID: kf9SUGuqoWXaUrzWB7HsuGtKv3iwpWjE X-Proofpoint-GUID: kf9SUGuqoWXaUrzWB7HsuGtKv3iwpWjE X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 09 Oct 2023 13:17:48 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779310443010642095 X-GMAIL-MSGID: 1779310443010642095 |
Series |
align maple tree write paths
|
|
Commit Message
Sidhartha Kumar
Oct. 9, 2023, 8:16 p.m. UTC
Preallocate maple nodes before call to mas_wr_store_entry(). If a new
node is not needed, go directly to mas_wr_store_entry(), otherwise
allocate the needed nodes and set the MA_STATE_PREALLOC flag.
Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
lib/maple_tree.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
Comments
Hi, 在 2023/10/10 04:16, Sidhartha Kumar 写道: > Preallocate maple nodes before call to mas_wr_store_entry(). If a new > node is not needed, go directly to mas_wr_store_entry(), otherwise > allocate the needed nodes and set the MA_STATE_PREALLOC flag. > > Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> > --- > lib/maple_tree.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/lib/maple_tree.c b/lib/maple_tree.c > index e239197a57fc..25ae66e585f4 100644 > --- a/lib/maple_tree.c > +++ b/lib/maple_tree.c > @@ -5478,17 +5478,33 @@ int mas_prealloc_calc(struct ma_wr_state *wr_mas) > int mas_store_gfp(struct ma_state *mas, void *entry, gfp_t gfp) > { > MA_WR_STATE(wr_mas, mas, entry); > + int request; > > mas_wr_store_setup(&wr_mas); > - trace_ma_write(__func__, mas, 0, entry); > -retry: > + wr_mas.content = mas_start(mas); > + > + request = mas_prealloc_calc(&wr_mas); mas_wr_store_entry() does something similar to mas_prealloc_calc(). Now, making it do it twice would incur additional overhead. We encountered this issue while optimizing preallocation, but it hasn't been resolved yet. Previously, this problem only occurred when using mas_preallocate(). Now, this change would bring this impact to all write operations on maple tree. What do you think about it? Thanks, Peng > + if (!request) > + goto store_entry; > + > + mas_node_count_gfp(mas, request, gfp); > + if (unlikely(mas_is_err(mas))) { > + mas_set_alloc_req(mas, 0); > + mas_destroy(mas); > + mas_reset(mas); > + return xa_err(mas->node); > + } > + mas->mas_flags |= MA_STATE_PREALLOC; > + > +store_entry: > mas_wr_store_entry(&wr_mas); > if (unlikely(mas_nomem(mas, gfp))) > - goto retry; > + goto store_entry; > > if (unlikely(mas_is_err(mas))) > return xa_err(mas->node); > > + trace_ma_write(__func__, mas, 0, entry); > return 0; > } > EXPORT_SYMBOL_GPL(mas_store_gfp);
* Sidhartha Kumar <sidhartha.kumar@oracle.com> [231009 16:16]: > Preallocate maple nodes before call to mas_wr_store_entry(). If a new > node is not needed, go directly to mas_wr_store_entry(), otherwise > allocate the needed nodes and set the MA_STATE_PREALLOC flag. The way I'd like to see this working is to preallocate nodes prior to writing, but also to end in a state where we can call the store operation to continue the operation. Both of these parts need to be together in a patch set if they cannot be in the same patch. Thanks, Liam > > Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> > --- > lib/maple_tree.c | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/lib/maple_tree.c b/lib/maple_tree.c > index e239197a57fc..25ae66e585f4 100644 > --- a/lib/maple_tree.c > +++ b/lib/maple_tree.c > @@ -5478,17 +5478,33 @@ int mas_prealloc_calc(struct ma_wr_state *wr_mas) > int mas_store_gfp(struct ma_state *mas, void *entry, gfp_t gfp) > { > MA_WR_STATE(wr_mas, mas, entry); > + int request; > > mas_wr_store_setup(&wr_mas); > - trace_ma_write(__func__, mas, 0, entry); > -retry: > + wr_mas.content = mas_start(mas); > + > + request = mas_prealloc_calc(&wr_mas); > + if (!request) > + goto store_entry; > + > + mas_node_count_gfp(mas, request, gfp); > + if (unlikely(mas_is_err(mas))) { > + mas_set_alloc_req(mas, 0); > + mas_destroy(mas); > + mas_reset(mas); > + return xa_err(mas->node); > + } > + mas->mas_flags |= MA_STATE_PREALLOC; > + > +store_entry: > mas_wr_store_entry(&wr_mas); > if (unlikely(mas_nomem(mas, gfp))) > - goto retry; > + goto store_entry; > > if (unlikely(mas_is_err(mas))) > return xa_err(mas->node); > > + trace_ma_write(__func__, mas, 0, entry); > return 0; > } > EXPORT_SYMBOL_GPL(mas_store_gfp); > -- > 2.41.0 >
On 10/9/23 8:03 PM, Peng Zhang wrote: > Hi, > > 在 2023/10/10 04:16, Sidhartha Kumar 写道: >> Preallocate maple nodes before call to mas_wr_store_entry(). If a new >> node is not needed, go directly to mas_wr_store_entry(), otherwise >> allocate the needed nodes and set the MA_STATE_PREALLOC flag. >> >> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> >> --- >> lib/maple_tree.c | 22 +++++++++++++++++++--- >> 1 file changed, 19 insertions(+), 3 deletions(-) >> >> diff --git a/lib/maple_tree.c b/lib/maple_tree.c >> index e239197a57fc..25ae66e585f4 100644 >> --- a/lib/maple_tree.c >> +++ b/lib/maple_tree.c >> @@ -5478,17 +5478,33 @@ int mas_prealloc_calc(struct ma_wr_state *wr_mas) >> int mas_store_gfp(struct ma_state *mas, void *entry, gfp_t gfp) >> { >> MA_WR_STATE(wr_mas, mas, entry); >> + int request; >> mas_wr_store_setup(&wr_mas); >> - trace_ma_write(__func__, mas, 0, entry); >> -retry: >> + wr_mas.content = mas_start(mas); >> + >> + request = mas_prealloc_calc(&wr_mas); > mas_wr_store_entry() does something similar to mas_prealloc_calc(). > Now, making it do it twice would incur additional overhead. > We encountered this issue while optimizing preallocation, but it > hasn't been resolved yet. Previously, this problem only occurred > when using mas_preallocate(). Now, this change would bring this > impact to all write operations on maple tree. What do you think > about it? > After talking to Liam, I will have to implement the store type enum feature on the Maple Tree Work list so that mas_prealloc_calc() can start a partial walk and write that information to the enum. mas_wr_store_entry() can then read that enum to continue the walk that was already started rather than having to redo the whole walk. This could also be used in mas_preallocate(). Do you have any suggestions for the implementation of this enum? Thanks, Sid > Thanks, > Peng >> + if (!request) >> + goto store_entry; >> + >> + mas_node_count_gfp(mas, request, gfp); >> + if (unlikely(mas_is_err(mas))) { >> + mas_set_alloc_req(mas, 0); >> + mas_destroy(mas); >> + mas_reset(mas); >> + return xa_err(mas->node); >> + } >> + mas->mas_flags |= MA_STATE_PREALLOC; >> + >> +store_entry: >> mas_wr_store_entry(&wr_mas); >> if (unlikely(mas_nomem(mas, gfp))) >> - goto retry; >> + goto store_entry; >> if (unlikely(mas_is_err(mas))) >> return xa_err(mas->node); >> + trace_ma_write(__func__, mas, 0, entry); >> return 0; >> } >> EXPORT_SYMBOL_GPL(mas_store_gfp); >
在 2023/10/11 08:17, Sidhartha Kumar 写道: > On 10/9/23 8:03 PM, Peng Zhang wrote: >> Hi, >> >> 在 2023/10/10 04:16, Sidhartha Kumar 写道: >>> Preallocate maple nodes before call to mas_wr_store_entry(). If a new >>> node is not needed, go directly to mas_wr_store_entry(), otherwise >>> allocate the needed nodes and set the MA_STATE_PREALLOC flag. >>> >>> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> >>> --- >>> lib/maple_tree.c | 22 +++++++++++++++++++--- >>> 1 file changed, 19 insertions(+), 3 deletions(-) >>> >>> diff --git a/lib/maple_tree.c b/lib/maple_tree.c >>> index e239197a57fc..25ae66e585f4 100644 >>> --- a/lib/maple_tree.c >>> +++ b/lib/maple_tree.c >>> @@ -5478,17 +5478,33 @@ int mas_prealloc_calc(struct ma_wr_state *wr_mas) >>> int mas_store_gfp(struct ma_state *mas, void *entry, gfp_t gfp) >>> { >>> MA_WR_STATE(wr_mas, mas, entry); >>> + int request; >>> mas_wr_store_setup(&wr_mas); >>> - trace_ma_write(__func__, mas, 0, entry); >>> -retry: >>> + wr_mas.content = mas_start(mas); >>> + >>> + request = mas_prealloc_calc(&wr_mas); >> mas_wr_store_entry() does something similar to mas_prealloc_calc(). >> Now, making it do it twice would incur additional overhead. >> We encountered this issue while optimizing preallocation, but it >> hasn't been resolved yet. Previously, this problem only occurred >> when using mas_preallocate(). Now, this change would bring this >> impact to all write operations on maple tree. What do you think >> about it? >> > > After talking to Liam, I will have to implement the store type enum feature on the Maple Tree Work list so that mas_prealloc_calc() can start a partial walk and write that information to the enum. mas_wr_store_entry() can then read that enum to continue the walk that was already started rather than having to redo the whole walk. This could also be used in mas_preallocate(). Do you have any suggestions for the implementation of this enum? There is another scenario where this enum can be useful, as seen in the implementation of mas_replace_entry() in [1]. It is a faster alternative to mas_store(), but it is not safe. If we can determine through the enum while writing the maple tree that a faster write operation can be performed, it would be beneficial. Some performance improvements can also be observed in [1]. [1] https://lore.kernel.org/lkml/49f0181a-55a4-41aa-8596-877560c8b802@bytedance.com/ > > Thanks, > Sid > >> Thanks, >> Peng >>> + if (!request) >>> + goto store_entry; >>> + >>> + mas_node_count_gfp(mas, request, gfp); >>> + if (unlikely(mas_is_err(mas))) { >>> + mas_set_alloc_req(mas, 0); >>> + mas_destroy(mas); >>> + mas_reset(mas); >>> + return xa_err(mas->node); >>> + } >>> + mas->mas_flags |= MA_STATE_PREALLOC; >>> + >>> +store_entry: >>> mas_wr_store_entry(&wr_mas); >>> if (unlikely(mas_nomem(mas, gfp))) >>> - goto retry; >>> + goto store_entry; >>> if (unlikely(mas_is_err(mas))) >>> return xa_err(mas->node); >>> + trace_ma_write(__func__, mas, 0, entry); >>> return 0; >>> } >>> EXPORT_SYMBOL_GPL(mas_store_gfp); >> > >
Hello, kernel test robot noticed "BUG:sleeping_function_called_from_invalid_context_at_include/linux/sched/mm.h" on: commit: 9116baa49536116f013d691d2178c520959f46c2 ("[PATCH 2/3] maple_tree: use preallocations in mas_store_gfp()") url: https://github.com/intel-lab-lkp/linux/commits/Sidhartha-Kumar/maple_tree-introduce-mas_prealloc_calc/20231010-041859 base: https://git.kernel.org/cgit/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/all/20231009201639.920512-3-sidhartha.kumar@oracle.com/ patch subject: [PATCH 2/3] maple_tree: use preallocations in mas_store_gfp() in testcase: boot compiler: gcc-11 test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G (please refer to attached dmesg/kmsg for entire log/backtrace) +------------------------------------------------------------------------------------+------------+------------+ | | 9cbebad6db | 9116baa495 | +------------------------------------------------------------------------------------+------------+------------+ | BUG:sleeping_function_called_from_invalid_context_at_include/linux/sched/mm.h | 0 | 7 | | WARNING:suspicious_RCU_usage | 0 | 7 | | include/linux/rcupdate.h:#Illegal_context_switch_in_RCU_read-side_critical_section | 0 | 7 | +------------------------------------------------------------------------------------+------------+------------+ If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang@intel.com> | Closes: https://lore.kernel.org/oe-lkp/202310251706.6e6f6c4a-oliver.sang@intel.com [ 12.322393][ T1] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 [ 12.324008][ T1] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper [ 12.325486][ T1] preempt_count: 1, expected: 0 [ 12.326345][ T1] 1 lock held by swapper/1: [ 12.327164][ T1] #0: c2b52570 (&mt->ma_lock){+.+.}-{2:2}, at: check_root_expand+0x46/0xac0 [ 12.328850][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G T 6.6.0-rc4-00400-g9116baa49536 #1 [ 12.329034][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 12.329034][ T1] Call Trace: [ 12.329034][ T1] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) [ 12.329034][ T1] dump_stack (lib/dump_stack.c:114) [ 12.329034][ T1] __might_resched (kernel/sched/core.c:10188) [ 12.329034][ T1] __might_sleep (kernel/sched/core.c:10117 (discriminator 17)) [ 12.329034][ T1] kmem_cache_alloc (include/linux/sched/mm.h:306 mm/slab.h:705 mm/slub.c:3460 mm/slub.c:3486 mm/slub.c:3493 mm/slub.c:3502) [ 12.329034][ T1] ? mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 12.329034][ T1] mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 12.329034][ T1] mas_node_count_gfp (lib/maple_tree.c:1347) [ 12.329034][ T1] mas_store_gfp (lib/maple_tree.c:256 lib/maple_tree.c:5491) [ 12.329034][ T1] ? check_empty_area_fill+0x3d0/0x3d0 [ 12.329034][ T1] check_root_expand+0x162/0xac0 [ 12.329034][ T1] maple_tree_seed (lib/test_maple_tree.c:3577) [ 12.329034][ T1] ? check_gap_combining+0xdf8/0xdf8 [ 12.329034][ T1] do_one_initcall (init/main.c:1232) [ 12.329034][ T1] do_initcalls (init/main.c:1293 init/main.c:1310) [ 12.329034][ T1] kernel_init_freeable (init/main.c:1551) [ 12.329034][ T1] ? rest_init (init/main.c:1429) [ 12.329034][ T1] kernel_init (init/main.c:1439) [ 12.329034][ T1] ret_from_fork (arch/x86/kernel/process.c:153) [ 12.329034][ T1] ? rest_init (init/main.c:1429) [ 12.329034][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) [ 12.329034][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:944) [ 12.353802][ T1] [ 12.354345][ T1] ============================= [ 12.355188][ T1] WARNING: suspicious RCU usage [ 12.356056][ T1] 6.6.0-rc4-00400-g9116baa49536 #1 Tainted: G W T [ 12.357413][ T1] ----------------------------- [ 12.358272][ T1] include/linux/rcupdate.h:375 Illegal context switch in RCU read-side critical section! [ 12.359905][ T1] [ 12.359905][ T1] other info that might help us debug this: [ 12.359905][ T1] [ 12.361711][ T1] [ 12.361711][ T1] rcu_scheduler_active = 2, debug_locks = 1 [ 12.363058][ T1] 2 locks held by swapper/1: [ 12.363877][ T1] #0: c2ad5938 (rcu_read_lock){....}-{1:2}, at: check_mas_store_gfp+0xa9/0x1b0 [ 12.365646][ T1] #1: c3965e84 (&mt->ma_lock){+.+.}-{2:2}, at: check_mas_store_gfp+0x104/0x1b0 [ 12.367338][ T1] [ 12.367338][ T1] stack backtrace: [ 12.368430][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G W T 6.6.0-rc4-00400-g9116baa49536 #1 [ 12.369129][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 12.369129][ T1] Call Trace: [ 12.369129][ T1] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) [ 12.369129][ T1] dump_stack (lib/dump_stack.c:114) [ 12.369129][ T1] lockdep_rcu_suspicious (kernel/locking/lockdep.c:6713) [ 12.369129][ T1] __might_resched (include/linux/rcupdate.h:375 kernel/sched/core.c:10149) [ 12.369129][ T1] __might_sleep (kernel/sched/core.c:10117 (discriminator 17)) [ 12.369129][ T1] kmem_cache_alloc (include/linux/sched/mm.h:306 mm/slab.h:705 mm/slub.c:3460 mm/slub.c:3486 mm/slub.c:3493 mm/slub.c:3502) [ 12.369129][ T1] ? mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 12.369129][ T1] mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 12.369129][ T1] mas_node_count_gfp (lib/maple_tree.c:1347) [ 12.369129][ T1] mas_store_gfp (lib/maple_tree.c:256 lib/maple_tree.c:5491) [ 12.369129][ T1] check_mas_store_gfp+0x14b/0x1b0 [ 12.369129][ T1] maple_tree_seed (lib/test_maple_tree.c:3646) [ 12.369129][ T1] ? check_gap_combining+0xdf8/0xdf8 [ 12.369129][ T1] do_one_initcall (init/main.c:1232) [ 12.369129][ T1] do_initcalls (init/main.c:1293 init/main.c:1310) [ 12.369129][ T1] kernel_init_freeable (init/main.c:1551) [ 12.369129][ T1] ? rest_init (init/main.c:1429) [ 12.369129][ T1] kernel_init (init/main.c:1439) [ 12.369129][ T1] ret_from_fork (arch/x86/kernel/process.c:153) [ 12.369129][ T1] ? rest_init (init/main.c:1429) [ 12.369129][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) [ 12.369129][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:944) [ 15.220029][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 16.033920][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 17.655206][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 19.245918][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 36.522020][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 37.994914][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 38.766533][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 41.775652][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 43.236341][ T35] torture_spin_lock_write_delay: delay = 24 jiffies. [ 44.106914][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 46.776934][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 47.165604][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 49.209209][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 50.316931][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 51.511048][ T34] torture_spin_lock_write_delay: delay = 25 jiffies. [ 54.564928][ T35] torture_spin_lock_write_delay: delay = 25 jiffies. [ 59.372367][ T1] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 [ 59.374045][ T1] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper [ 59.375483][ T1] preempt_count: 1, expected: 0 [ 59.376310][ T1] 1 lock held by swapper/1: [ 59.377090][ T1] #0: c2b52570 (&mt->ma_lock){+.+.}-{2:2}, at: check_empty_area_fill+0xe5/0x3d0 [ 59.378744][ T1] CPU: 0 PID: 1 Comm: swapper Tainted: G W T 6.6.0-rc4-00400-g9116baa49536 #1 [ 59.380409][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 59.381080][ T1] Call Trace: [ 59.381080][ T1] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) [ 59.381080][ T1] dump_stack (lib/dump_stack.c:114) [ 59.381080][ T1] __might_resched (kernel/sched/core.c:10188) [ 59.381080][ T1] __might_sleep (kernel/sched/core.c:10117 (discriminator 17)) [ 59.381080][ T1] kmem_cache_alloc (include/linux/sched/mm.h:306 mm/slab.h:705 mm/slub.c:3460 mm/slub.c:3486 mm/slub.c:3493 mm/slub.c:3502) [ 59.381080][ T1] ? mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 59.381080][ T1] mas_alloc_nodes (lib/maple_tree.c:160 lib/maple_tree.c:1265) [ 59.381080][ T1] mas_node_count_gfp (lib/maple_tree.c:1347) [ 59.381080][ T1] mas_store_gfp (lib/maple_tree.c:256 lib/maple_tree.c:5491) [ 59.381080][ T1] check_empty_area_fill+0xab/0x3d0 [ 59.381080][ T1] maple_tree_seed (lib/test_maple_tree.c:3837) [ 59.381080][ T1] ? check_gap_combining+0xdf8/0xdf8 [ 59.381080][ T1] do_one_initcall (init/main.c:1232) [ 59.381080][ T1] do_initcalls (init/main.c:1293 init/main.c:1310) [ 59.381080][ T1] kernel_init_freeable (init/main.c:1551) [ 59.381080][ T1] ? rest_init (init/main.c:1429) [ 59.381080][ T1] kernel_init (init/main.c:1439) [ 59.381080][ T1] ret_from_fork (arch/x86/kernel/process.c:153) [ 59.381080][ T1] ? rest_init (init/main.c:1429) [ 59.381080][ T1] ret_from_fork_asm (arch/x86/entry/entry_32.S:741) [ 59.381080][ T1] entry_INT80_32 (arch/x86/entry/entry_32.S:944) [ 59.571154][ T1] maple_tree: 3807933 of 3807933 tests passed [ 59.572831][ T1] test_memcat_p: test passed [ 59.590510][ T1] test_meminit: all 11 tests in test_pages passed [ 59.621976][ T1] test_meminit: all 40 tests in test_kvmalloc passed [ 60.207905][ T1] test_meminit: all 70 tests in test_kmemcache passed [ 60.217750][ T1] test_meminit: all 10 tests in test_rcu_persistent passed [ 60.219088][ T1] test_meminit: all 131 tests passed! [ 60.220126][ T1] ref_tracker: reference already released. [ 60.220912][ T1] ref_tracker: allocated in: The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20231025/202310251706.6e6f6c4a-oliver.sang@intel.com
... Dropping direct Cc's in attempt to avoid even more noise. * kernel test robot <oliver.sang@intel.com> [231025 05:52]: > > > Hello, > > kernel test robot noticed "BUG:sleeping_function_called_from_invalid_context_at_include/linux/sched/mm.h" on: ... This patch set is being revised and discussed on how to make it a more complete solution. In the mean time, is there any way to stop the bot from emailing everyone and burning more power? Thank you, Liam
diff --git a/lib/maple_tree.c b/lib/maple_tree.c index e239197a57fc..25ae66e585f4 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -5478,17 +5478,33 @@ int mas_prealloc_calc(struct ma_wr_state *wr_mas) int mas_store_gfp(struct ma_state *mas, void *entry, gfp_t gfp) { MA_WR_STATE(wr_mas, mas, entry); + int request; mas_wr_store_setup(&wr_mas); - trace_ma_write(__func__, mas, 0, entry); -retry: + wr_mas.content = mas_start(mas); + + request = mas_prealloc_calc(&wr_mas); + if (!request) + goto store_entry; + + mas_node_count_gfp(mas, request, gfp); + if (unlikely(mas_is_err(mas))) { + mas_set_alloc_req(mas, 0); + mas_destroy(mas); + mas_reset(mas); + return xa_err(mas->node); + } + mas->mas_flags |= MA_STATE_PREALLOC; + +store_entry: mas_wr_store_entry(&wr_mas); if (unlikely(mas_nomem(mas, gfp))) - goto retry; + goto store_entry; if (unlikely(mas_is_err(mas))) return xa_err(mas->node); + trace_ma_write(__func__, mas, 0, entry); return 0; } EXPORT_SYMBOL_GPL(mas_store_gfp);