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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 092BCCA5507 for ; Wed, 13 Sep 2023 08:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:CC:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8+oy9mavCwDqAx5xDrzUA68DZOz0hClvKtoQ2X3Pd+o=; b=KkqH+ktI+V3fxL eVO6TUZsw7V2Fk5pgJWqTZYypOWpW5sFBeef11Xw/NwMOPNuQH8aHUro8nKIfUJ99JmXcyKDwv38u snT7ZmDOaQBXtenzrgMGliLXyV1GR3Btu1lG0PzInybjwXiD0GDQZCvPVa3Nd8U53O8FGAsu7xfGY rswo13BaDioOIUaxBYCWzs1pzaxOaZh+MSYfiLo6I4hGW+QzLCeY7/ikl2gwPggtRuvE2UfyY5FRp nPPWaioQT2eUYAKkaGv7RFPuHl93+I/bOwwCY2sjmHbPrV3rqQAhFEmVSMD7/T+zxMJ5FAM3jclTG dTIP8Foz02h2KXR9ghrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qgL8s-00552q-35; Wed, 13 Sep 2023 08:22:34 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qgL8p-00551c-1P for linux-arm-kernel@lists.infradead.org; Wed, 13 Sep 2023 08:22:33 +0000 X-UUID: aa36b1fe520e11ee9b7791016c24628a-20230913 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=MIME-Version:Content-Transfer-Encoding:Content-ID:Content-Type:In-Reply-To:References:Message-ID:Date:Subject:CC:To:From; bh=KyAlndDdQsH3o8yBJHabq0a6JQTQPBqiRF5daf34N78=; b=NZPviTL8WOnfKYOhEo5dsy3aDMwoxsJvvzI3wRXKxDxBFRNhTDAvkuXHPpsr0uSWcIVecXWdkR1tBJnNvkwFniY4j6WSoQPj9LU92OQIwKCHkCI7CM9R6S+hcrUga/IzDYtiT313yrm3l7NBrAlE6WKEssPoPEROSQoGhmm8vC4=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.31,REQID:25954800-36d7-4b09-8810-11d1a98ee389,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:0ad78a4,CLOUDID:9087f9c2-1e57-4345-9d31-31ad9818b39f,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:11|1,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1,SPR: NO,DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR,TF_CID_SPAM_ULN X-UUID: aa36b1fe520e11ee9b7791016c24628a-20230913 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 118783708; Wed, 13 Sep 2023 01:22:23 -0700 Received: from mtkmbs10n1.mediatek.inc (172.21.101.34) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Wed, 13 Sep 2023 16:11:45 +0800 Received: from APC01-PSA-obe.outbound.protection.outlook.com (172.21.101.237) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Wed, 13 Sep 2023 16:11:45 +0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZAoT7WEotCWWr5xmBylzhKWsQYpWg3XVyOIOrIPg/1AwoO0G6PhMGInsi6TOiEsYu+rU2hse4l3x842UzRHDFLw51udAU0amDCFGO2XxXFJEzobvldrs/yVU//ZAm+mcCRxX/sghOZp68dR8UA+oQge8vAz4Srr1SQlj1Totb+yPSdmuZjyuCcXbZV0NyW3rPRyuv2W1abWkEbDvSkHpP1chLlGX53zUCr6fc6EsG/xklHQNXrR22YPW6atfS4qmL3I/J51lT7zy4BoqVSbEe2DyJPfpS/YrRaaQDaqGhUTm8ElyN+3mGBPXZZYrKbHOX4/cfuHFJb8OMNSSpBADIA== 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=KyAlndDdQsH3o8yBJHabq0a6JQTQPBqiRF5daf34N78=; b=hzuE5sHFWPsXnBSeg4tvvm3isrwCyA9Erv3deeNAgR2ASRZT2WU2pjvojlmCf3tTl/fWNlQkRWBKkoMkAzY28x2aJmDn+8YrBT/fVbMTKWP+co5/7Y4wBs+zQpW5EIzeTqsZa99oZOsMwxUKNRI5dO4lD1b1AoF/cfZ3TpULzOXorTdsNZahZDLSpL8KmfAf5tP/HwWFXZhY8rAmw7X3zyxfrBod7rlXZ6SWg+KC5XsbMpvFU0uJyczZlgw2BThRlzkN4TuzyllN90TVhFYw7vf/sHMksYZ8vhzieiHuaxCGgsWz5bD4nltzDkW1mrSTZcuwVm5w2S8t11OvMa+ORg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mediatek.com; dmarc=pass action=none header.from=mediatek.com; dkim=pass header.d=mediatek.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mediateko365.onmicrosoft.com; s=selector2-mediateko365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KyAlndDdQsH3o8yBJHabq0a6JQTQPBqiRF5daf34N78=; b=r7IbrbEysOOvd4duANxLezDrgVOc43RxO2lm3WHOeQahmVhg7uguYeqNbS/auRnt9hIxuWEro4p1Ymv9W1ll+hZqc/sja8Nch/qx5d816vK7BNoJLBtHCL33mnB1U36UiaU30bD12zlABcne3o5DnOZJOht1cV0xb4ZiyupeL9k= Received: from PUZPR03MB5964.apcprd03.prod.outlook.com (2603:1096:301:b4::11) by TYSPR03MB8084.apcprd03.prod.outlook.com (2603:1096:400:473::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.35; Wed, 13 Sep 2023 08:11:40 +0000 Received: from PUZPR03MB5964.apcprd03.prod.outlook.com ([fe80::4731:7196:588d:ba27]) by PUZPR03MB5964.apcprd03.prod.outlook.com ([fe80::4731:7196:588d:ba27%3]) with mapi id 15.20.6768.029; Wed, 13 Sep 2023 08:11:40 +0000 From: =?utf-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= To: "dietmar.eggemann@arm.com" , "hughd@google.com" , "peterz@infradead.org" , "maz@kernel.org" , "rostedt@goodmis.org" , "rppt@kernel.org" , "yuzenghui@huawei.com" , "james.morse@arm.com" , "vschneid@redhat.com" , "bristot@redhat.com" , "juri.lelli@redhat.com" , "alexandru.elisei@arm.com" , "suzuki.poulose@arm.com" , "catalin.marinas@arm.com" , "mingo@redhat.com" , "akpm@linux-foundation.org" , "mhiramat@kernel.org" , "bsegall@google.com" , "mgorman@suse.de" , "arnd@arndb.de" , "oliver.upton@linux.dev" , "vincent.guittot@linaro.org" , "will@kernel.org" CC: "linux-kernel@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , =?utf-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= , "linux-mm@kvack.org" , "hyesoo.yu@samsung.com" , "kcc@google.com" , "kvmarm@lists.linux.dev" , "david@redhat.com" , =?utf-8?B?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= , "steven.price@arm.com" , =?utf-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , =?utf-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , "eugenis@google.com" , "linux-arm-kernel@lists.infradead.org" , "pcc@google.com" , "vincenzo.frascino@arm.com" , "linux-arch@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "anshuman.khandual@arm.com" Subject: Re: [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse Thread-Topic: [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse Thread-Index: AQHZ5hQIdDLoncUf6kWsooEIME0SPbAYZ6+A Date: Wed, 13 Sep 2023 08:11:40 +0000 Message-ID: <0dc2afaf8a976ef8eb9af711fd941f1bbfd71321.camel@mediatek.com> References: <20230823131350.114942-1-alexandru.elisei@arm.com> In-Reply-To: <20230823131350.114942-1-alexandru.elisei@arm.com> Accept-Language: zh-TW, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mediatek.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PUZPR03MB5964:EE_|TYSPR03MB8084:EE_ x-ms-office365-filtering-correlation-id: c9cf2b7c-2248-46b4-4b65-08dbb4310f6e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lbA7wCGpGAgpW2WU3p8RZcXrBu79jgk/oysvpm4Ga6tQ73YinlIVV8EtsvO4H/lhW8YpwrYo0tUbH1ZbxkY7v8B+/kKfFW+789ntdt+ZmAxsFSwu8B6PIGAJXZ3mLI8e6oxSRlAKPjD1qjHCVBucWezvgh89KVBsy8exBud/W/84v41UrzzwFLLxZqJnbcFEXnC7Whiv9Pt3ovImFLP0g1OTAoHt4OrlHNMmceGezrJ4OrmdG8pcErs3Q5dOfR3gY6bxrnNKwV9cwFuFl+Y5ghgZN5Dx7YY03gYK/lT4YoGNH8cdUZD3FwlO39mgvtylZy0+JWsLLZrG2icZcHjcpAAJmTLlLSIpaA+FnXus0OFDaixvm5Z1/TtBxBD4eciQzmcdoJra+wHDa/KKi4aFyCKbH9Yxpq49uU0Az5qVV//Q7R+TPRj3MrlYlKO26bI7G9SZpiUetsoNfXR5YYFdUM56pTitJLF0WcqHjEuWqsL2cYimr5mJYg28r/U+idbuKuPPAtAKtmdlczHEAGpNQJy1Suxf3tf0yph90sfqOUnspl/E7jQixF9pDvPner7e1D2qnsRg+QlICLJJrd2AwySNjGgo3lVJXKmKQePEHNr+ZopXas6JdRmaOTs9kV1rzu7k78/zJ6tAiZbD3zSiRh5a7M+LhwaJZEB8p+O0prrE8QVJRKRrh9NEei1YGxVoY6rp1VATWJIXesnfgs4KmQjSEKM2ocLXky7j9P5SvBg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PUZPR03MB5964.apcprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39860400002)(136003)(346002)(376002)(366004)(396003)(1800799009)(451199024)(186009)(85182001)(36756003)(478600001)(66476007)(30864003)(2906002)(54906003)(91956017)(66946007)(66556008)(76116006)(64756008)(2616005)(921005)(38100700002)(38070700005)(86362001)(122000001)(7406005)(66446008)(7416002)(4326008)(8676002)(8936002)(41300700001)(5660300002)(316002)(83380400001)(26005)(6506007)(6486002)(110136005)(71200400001)(6512007)(966005)(99106002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cFdHK2IySFI2b2dVNXV2VkpreHBndjA3QWNPS1FGU2NHcHlMVnd4NkRBbk1L?= =?utf-8?B?NnJHWE4zMmU1cGswckxHdS9DeFJ3WXBOMGN1RHN2VnNWUDJ0c29Tb3RMMFhG?= =?utf-8?B?SHRrVlRnVWo2dm1IeVBabk0rNE84NU15TWdxS1pzV1BBcVpmek5jUWdCOERl?= =?utf-8?B?YUhseFhBeDRqVGtzeStLdEgycjZrZlhhSUNNRCtSVWl2NUJWZVN1K280b2M0?= =?utf-8?B?UTM2d2NzajhoM082dEhvcGs5VytmTUhKTjRNSk44MVhXdk5tTXJGei9vcFZs?= =?utf-8?B?Y1JteDRNMFpySTBiTStDU0NDUVVJL1o4R3hsZzVJUlVmSzB0TVc0eGlKYy84?= =?utf-8?B?OVZQZmhpU3BtQW4vZ0VZdDNsVVNTL1h3SGx2RG5RRjB4aVBJbFpwZlRKalBq?= =?utf-8?B?S2VzWm95Z3h5MXF5MjB4VkNXMDhhdm9PZWtETnRzSjB2R3djNTNFb1ZlYnVw?= =?utf-8?B?cVVJTWxBZnB3aUUzcWY3UDc1OThscnFNaHB2cGttY0Q2ODZtcnB2dHp1c05J?= =?utf-8?B?c2ZKWEx6K3ZSSFU0Z1lkTUdNeE4rQXc0SjhFeHVIZnEvdmtDRmI2M0d4anln?= =?utf-8?B?Q1pleDdCSGliUnF4V1I1aFlRS3p4L0JGUEsxZ2ZYb3RhcDh1cjRlSVlnOGZO?= =?utf-8?B?UTQ0TnVYTDNhK1pjSytTRjRGeXp6Uk5XQnVkQjhCczNxT1EwcktlUXViaGNq?= =?utf-8?B?c3hXZk91SW1MWUNPUFZsQzJ3TGlUMDUvc2RnR3pPeERucTNaTEhWSXF1OWsy?= =?utf-8?B?cUhXanlWd3ZiSXZkUmhTNGFTMUd0MDJVb0Vycklpdy9rQU80ZXlDMXlqZVpr?= =?utf-8?B?Y005VXBsaDhUeFR2bGhldDI5cXpGdnFoUnBidWxKeXJZZC9SSFhLcU9wYStW?= =?utf-8?B?VnZMSXdDemVXREhRUmVsby81RjJwMm9JWStQcVVhaUdsZ0xxUzhMNUV1Q2x4?= =?utf-8?B?aXA4R01tMmllRVJ6VXpKekJxYWErRitWazZ4aVNpbnMwNVI1dHNwVEp1eXVY?= =?utf-8?B?bDB4TGV3VG5LbmU5cXAydmQ5YlZQcGI0cVp1cjZ2TkdRREVtU1BUZzJtOG40?= =?utf-8?B?aXdZNXZJYW9Bc29DQWJuc0VGVTF2ZFFiVEp4cFV0L05ySEtwMXlGZHlxT0pk?= =?utf-8?B?akF2ZTRmZDQwV0t1WW9ZU1BteUFWUUtEaW5hTGh4d3ZGWlhMNWdMcW1ITldL?= =?utf-8?B?Qks4bk1wZFI3SjRIT3NqVVQybUdUVURJMlNpZlhwaENxYklKbVk3WVJOWHEr?= =?utf-8?B?cW9DeU1iQi9qUEp5R08vWXFMam1FQ0JlMkcySnl4enoydHV0QzNIck16S2lV?= =?utf-8?B?bnFHdFpkWG9YVzhwcERZZUZGVVJReGY4ayt2WnJ4Zm45R1Q1RFl4aFRCaVFM?= =?utf-8?B?NUV1czFkeTAwcmZaNFFOVStZdEJySXc0clJGWFpBeUl4emR0RW92Y3k3azZ4?= =?utf-8?B?bjViN3dXbjBqbEE4bXBHUjQ1eC9ML2tlSFV4SGM0V0lRamNWcXA3YUdIekha?= =?utf-8?B?ajRWTGphU3U3d2FBUHluMURRVEoyTG0zK1JHemhmK3ZRMEhoa3cxM3JQV3Za?= =?utf-8?B?MFZlcUNteVhMRHQ5NjJ4Z2JzNEFDQi85RHcxbkxaZkFBcWMyZlNYZ3NxZ2Fj?= =?utf-8?B?c2xXMWplMlNYWVRreXY0ajV3MHNtOWNsRlgrS25UaHhmZXRKTVNQQ2xDN3NB?= =?utf-8?B?ZkZQOXBjOWNJQ0lDaFpoK21JZ0ZJWVg1SFhLSUNtRXlJb1QvYlFLdDdvSDJw?= =?utf-8?B?dDJDalhHR3BzenprbjQyYW1iNEo3aVJlVnVrYXpXcHkrdDVSbTQyTFg1TGNJ?= =?utf-8?B?YzE2dGNsWTJld293VlVkcXJob254dTByS0c5YlBYTm5yaytyRHhJUWhqL2lk?= =?utf-8?B?ZDhsNzVaWlo2RU16WEkrNDhiNkFCQVNPZFFNeG1DeXlraWZWYjliWGZaZ2lY?= =?utf-8?B?UHhveUczdmVZcGI5R1VkVDBESUxYNWZCcGVvbG93YW5kamNXV0ViWGNVL3Fh?= =?utf-8?B?YU9sMHhnRWxzVHVXRDZBS1ZqR2NBS1JwRENDK3l5bzlhZnZLM2tqNjczZFI0?= =?utf-8?B?WDRuUkpEODFORS93QU02QUhJNDJQR1BaQXg2VUxyYlgydUZ3YnR1SERoZWM3?= =?utf-8?B?d1dqeFhCMEk0QlB0QS80L1FybDN4RUplTkplY2xuN1I1SW5tODh4TlpKYWJs?= =?utf-8?B?WVE9PQ==?= Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PUZPR03MB5964.apcprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9cf2b7c-2248-46b4-4b65-08dbb4310f6e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2023 08:11:40.7980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7687ede-7a6b-4ef6-bace-642f677fbe31 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0EkUMCpl4gHaKm7A8l6wM3n81r/TmAhDgr1D2iUEbcHYtdVoS4qd6D1b0yIpPnM5ZJCtch65xoEpHalNWOBxAb25wLh4qhTXRBdfQgCFplo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYSPR03MB8084 X-TM-AS-Product-Ver: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-AS-Result: No-10--28.437500-8.000000 X-TMASE-MatchedRID: SncuatAvtBfUL3YCMmnG4ia1MaKuob8PC/ExpXrHizwWnuSeJfGi86ay 8WuchSY5+m2IKGMplMBwoI7ADD6NSMuQAtnkyqZZws9cphnKwlErHkgIan9a0dtYrdTBJLQ3E/H ycyv3xP0MMxzlIWOkR1j/1GLnHinisaYKl6IqtEGpFX54L8f9xbLiLKO9VZOiGNAPebYwJ/vWo8 YegoeVBQSJ12JXGqp0BkQrR0pCNf5dbsV/qG94cZ1U1lojafr/MApqy5cfknUuaIC/E9/9wdKmy J56Qa3Egnz0LU2mdHEqWdHo/PSCyrh6yGDarE85uIwLnB3Aqp0zc8FC0MEwT1BNZpqw0l9/qM8P YJGuHYqcHepQtiMfOLHn/HPzhGPjrRlLslggfyrtMsi+dai/0VDbjkq6XySP5VavBrAV4wWP0WP 5G0rZ4PGxJyOoqney/ip3JFJxIHx5OFLKjahJ2f9WgQ5yFeIpMC4zO7d4kaMs7eP5cPCWQ4MD9b HFpPzhC96AWDFf8+t4YW8J1JEHCZIOhgOZiPMs9fdTUM4Rka9Owvf3uvRKNwZbeEWcL03VrW41+ BBqq+/GfIV+lx4m/OhYrXMDjRUpP+M4Y9nUpYEMH4SsGvRsA7n7V+KB+3cul2j8d+K0VSjnEMZ5 GA4+K0Cv/d/fQFKz3NBToeqBqO7GWQHDiYaPQLSw7varainhQrO4XR6BRQOna6U74e0+qJdAax/ AUFGFj3LSL6XI3mOEhap2q5omymuwlVr0S63TM5vhCMb51Y/8d3gJRYhL8Rb3td/MpM62ghXbgK 5iPnSjBbva5jafBQHM8svLP4MRGClvwc20fT6eAiCmPx4NwMFrpUbb72MU1B0Hk1Q1KyLUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--28.437500-8.000000 X-TMASE-Version: SMEX-14.0.0.3152-9.1.1006-23728.005 X-TM-SNTS-SMTP: F0733B9F0281989FF6C8D314A1A145C7A9B7166B9B10D03FD4AFFE2AF9E4E37D2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230913_012231_492971_AFDDF666 X-CRM114-Status: GOOD ( 18.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 2023-08-23 at 14:13 +0100, Alexandru Elisei wrote: > Introduction > ============ > > Arm has implemented memory coloring in hardware, and the feature is > called > Memory Tagging Extensions (MTE). It works by embedding a 4 bit tag in > bits > 59..56 of a pointer, and storing this tag to a reserved memory > location. > When the pointer is dereferenced, the hardware compares the tag > embedded in > the pointer (logical tag) with the tag stored in memory (allocation > tag). > > The relation between memory and where the tag for that memory is > stored is > static. > > The memory where the tags are stored have been so far unaccessible to > Linux. > This series aims to change that, by adding support for using the tag > storage > memory only as data memory; tag storage memory cannot be itself > tagged. > > > Implementation > ============== > > The series is based on v6.5-rc3 with these two patches cherry picked: > > - mm: Call arch_swap_restore() from unuse_pte(): > > > https://lore.kernel.org/all/20230523004312.1807357-3-pcc@google.com/ > > - arm64: mte: Simplify swap tag restoration logic: > > > https://lore.kernel.org/all/20230523004312.1807357-4-pcc@google.com/ > > The above two patches are queued for the v6.6 merge window: > > > https://lore.kernel.org/all/20230702123821.04e64ea2c04dd0fdc947bda3@linux-foundation.org/ > > The entire series, including the above patches, can be cloned with: > > $ git clone https://gitlab.arm.com/linux-arm/linux-ae.git \ > -b arm-mte-dynamic-carveout-rfc-v1 > > On the arm64 architecture side, an extension is being worked on that > will > clarify how MTE tag storage reuse should behave. The extension will > be > made public soon. > > On the Linux side, MTE tag storage reuse is accomplished with the > following changes: > > 1. The tag storage memory is exposed to the memory allocator as a new > migratetype, MIGRATE_METADATA. It behaves similarly to MIGRATE_CMA, > with > the restriction that it cannot be used to allocate tagged memory (tag > storage memory cannot be tagged). On tagged page allocation, the > corresponding tag storage is reserved via alloc_contig_range(). > > 2. mprotect(PROT_MTE) is implemented by changing the pte prot to > PAGE_METADATA_NONE. When the page is next accessed, a fault is taken > and > the corresponding tag storage is reserved. > > 3. When the code tries to copy tags to a page which doesn't have the > tag > storage reserved, the tags are copied to an xarray and restored in > set_pte_at(), when the page is eventually mapped with the tag storage > reserved. > > KVM support has not been implemented yet, that because a non-MTE > enabled VMA > can back the memory of an MTE-enabled VM. After there is a consensus > on the > right approach on the memory management support, I will add it. > > Explanations for the last two changes follow. The gist of it is that > they > were added mostly because of races, and it my intention to make the > code > more robust. > > PAGE_METADATA_NONE was introduced to avoid races with > mprotect(PROT_MTE). > For example, migration can race with mprotect(PROT_MTE): > - thread 0 initiates migration for a page in a non-MTE enabled VMA > and a > destination page is allocated without tag storage. > - thread 1 handles an mprotect(PROT_MTE), the VMA becomes tagged, and > an > access turns the source page that is in the process of being > migrated > into a tagged page. > - thread 0 finishes migration and the destination page is mapped as > tagged, > but without tag storage reserved. > More details and examples can be found in the patches. > > This race is also related to how tag restoring is handled when tag > storage > is missing: when a tagged page is swapped out, the tags are saved in > an > xarray indexed by swp_entry.val. When a page is swapped back in, if > there > are tags corresponding to the swp_entry that the page will replace, > the > tags are unconditionally restored, even if the page will be mapped as > untagged. Because the page will be mapped as untagged, tag storage > was > not reserved when the page was allocated to replace the swp_entry > which has > tags associated with it. > > To get around this, save the tags in a new xarray, this time indexed > by > pfn, and restore them when the same page is mapped as tagged. > > This also solves another race, this time with copy_highpage. In the > scenario where migration races with mprotect(PROT_MTE), before the > page is > mapped, the contents of the source page is copied to the destination. > And > this includes tags, which will be copied to a page with missing tag > storage, which can to data corruption if the missing tag storage is > in use > for data. So copy_highpage() has received a similar treatment to the > swap > code, and the source tags are copied in the xarray indexed by the > destination page pfn. > > > Overview of the patches > ======================= > > Patches 1-3 do some preparatory work by renaming a few functions and > a gfp > flag. > > Patches 4-12 are arch independent and introduce MIGRATE_METADATA to > the > page allocator. > > Patches 13-18 are arm64 specific and add support for detecting the > tag > storage region and onlining it with the MIGRATE_METADATA migratetype. > > Patches 19-24 are arch independent and modify the page allocator to > callback into arch dependant functions to reserve metadata storage > for an > allocation which requires metadata. > > Patches 25-28 are mostly arm64 specific and implement the reservation > and > freeing of tag storage on tagged page allocation. Patch #28 ("mm: > sched: > Introduce PF_MEMALLOC_ISOLATE") adds a current flag, > PF_MEMALLOC_ISOLATE, > which ignores page isolation limits; this is used by arm64 when > reserving > tag storage in the same patch. > > Patches 29-30 add arch independent support for doing > mprotect(PROT_MTE) > when metadata storage is enabled. > > Patches 31-37 are mostly arm64 specific and handle the restoring of > tags > when tag storage is missing. The exceptions are patches 32 (adds the > arch_swap_prepare_to_restore() function) and 35 (add > PAGE_METADATA_NONE > support for THPs). > > Testing > ======= > > To enable MTE dynamic tag storage: > > - CONFIG_ARM64_MTE_TAG_STORAGE=y > - system_supports_mte() returns true > - kasan_hw_tags_enabled() returns false > - correct DTB node (for the specification, see commit "arm64: mte: > Reserve tag > storage memory") > > Check dmesg for the message "MTE tag storage enabled" or grep for > metadata > in /proc/vmstat. > > I've tested the series using FVP with MTE enabled, but without > support for > dynamic tag storage reuse. To simulate it, I've added two fake tag > storage > regions in the DTB by splitting a 2GB region roughly into 33 slices > of size > 0x3e0_0000, and using 32 of them for tagged memory and one slice for > tag > storage: > > diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts > b/arch/arm64/boot/dts/arm/fvp-base-revc.dts > index 60472d65a355..bd050373d6cf 100644 > --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts > +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts > @@ -165,10 +165,28 @@ C1_L2: l2-cache1 { > }; > }; > > - memory@80000000 { > + memory0: memory@80000000 { > device_type = "memory"; > - reg = <0x00000000 0x80000000 0 0x80000000>, > - <0x00000008 0x80000000 0 0x80000000>; > + reg = <0x00 0x80000000 0x00 0x7c000000>; > + }; > + > + metadata0: metadata@c0000000 { > + compatible = "arm,mte-tag-storage"; > + reg = <0x00 0xfc000000 0x00 0x3e00000>; > + block-size = <0x1000>; > + memory = <&memory0>; > + }; > + > + memory1: memory@880000000 { > + device_type = "memory"; > + reg = <0x08 0x80000000 0x00 0x7c000000>; > + }; > + > + metadata1: metadata@8c0000000 { > + compatible = "arm,mte-tag-storage"; > + reg = <0x08 0xfc000000 0x00 0x3e00000>; > + block-size = <0x1000>; > + memory = <&memory1>; > }; > Hi Alexandru, AFAIK, the above memory configuration means that there are two region of dram(0x80000000-0xfc000000 and 0x8_80000000-0x8_fc0000000) and this is called PDD memory map. Document[1] said there are some constraints of tag memory as below. | The following constraints apply to the tag regions in DRAM: | 1. The tag region cannot be interleaved with the data region. | The tag region must also be above the data region within DRAM. | | 2.The tag region in the physical address space cannot straddle | multiple regions of a memory map. | | PDD memory map is not allowed to have part of the tag region between | 2GB-4GB and another part between 34GB-64GB. I'm not sure if we can separate tag memory with the above configuration. Or do I miss something? [1] https://developer.arm.com/documentation/101569/0300/?lang=en (Section 5.4.6.1) Thanks, Kuan-Ying Lee > reserved-memory { > > > Alexandru Elisei (37): > mm: page_alloc: Rename gfp_to_alloc_flags_cma -> > gfp_to_alloc_flags_fast > arm64: mte: Rework naming for tag manipulation functions > arm64: mte: Rename __GFP_ZEROTAGS to __GFP_TAGGED > mm: Add MIGRATE_METADATA allocation policy > mm: Add memory statistics for the MIGRATE_METADATA allocation > policy > mm: page_alloc: Allocate from movable pcp lists only if > ALLOC_FROM_METADATA > mm: page_alloc: Bypass pcp when freeing MIGRATE_METADATA pages > mm: compaction: Account for free metadata pages in > __compact_finished() > mm: compaction: Handle metadata pages as source for direct > compaction > mm: compaction: Do not use MIGRATE_METADATA to replace pages with > metadata > mm: migrate/mempolicy: Allocate metadata-enabled destination page > mm: gup: Don't allow longterm pinning of MIGRATE_METADATA pages > arm64: mte: Reserve tag storage memory > arm64: mte: Expose tag storage pages to the MIGRATE_METADATA > freelist > arm64: mte: Make tag storage depend on ARCH_KEEP_MEMBLOCK > arm64: mte: Move tag storage to MIGRATE_MOVABLE when MTE is > disabled > arm64: mte: Disable dynamic tag storage management if HW KASAN is > enabled > arm64: mte: Check that tag storage blocks are in the same zone > mm: page_alloc: Manage metadata storage on page allocation > mm: compaction: Reserve metadata storage in compaction_alloc() > mm: khugepaged: Handle metadata-enabled VMAs > mm: shmem: Allocate metadata storage for in-memory filesystems > mm: Teach vma_alloc_folio() about metadata-enabled VMAs > mm: page_alloc: Teach alloc_contig_range() about MIGRATE_METADATA > arm64: mte: Manage tag storage on page allocation > arm64: mte: Perform CMOs for tag blocks on tagged page > allocation/free > arm64: mte: Reserve tag block for the zero page > mm: sched: Introduce PF_MEMALLOC_ISOLATE > mm: arm64: Define the PAGE_METADATA_NONE page protection > mm: mprotect: arm64: Set PAGE_METADATA_NONE for mprotect(PROT_MTE) > mm: arm64: Set PAGE_METADATA_NONE in set_pte_at() if missing > metadata > storage > mm: Call arch_swap_prepare_to_restore() before arch_swap_restore() > arm64: mte: swap/copypage: Handle tag restoring when missing tag > storage > arm64: mte: Handle fatal signal in reserve_metadata_storage() > mm: hugepage: Handle PAGE_METADATA_NONE faults for huge pages > KVM: arm64: Disable MTE is tag storage is enabled > arm64: mte: Enable tag storage management > > arch/arm64/Kconfig | 13 + > arch/arm64/include/asm/assembler.h | 10 + > arch/arm64/include/asm/memory_metadata.h | 49 ++ > arch/arm64/include/asm/mte-def.h | 16 +- > arch/arm64/include/asm/mte.h | 40 +- > arch/arm64/include/asm/mte_tag_storage.h | 36 ++ > arch/arm64/include/asm/page.h | 5 +- > arch/arm64/include/asm/pgtable-prot.h | 2 + > arch/arm64/include/asm/pgtable.h | 33 +- > arch/arm64/kernel/Makefile | 1 + > arch/arm64/kernel/elfcore.c | 14 +- > arch/arm64/kernel/hibernate.c | 46 +- > arch/arm64/kernel/mte.c | 31 +- > arch/arm64/kernel/mte_tag_storage.c | 667 > +++++++++++++++++++++++ > arch/arm64/kernel/setup.c | 7 + > arch/arm64/kvm/arm.c | 6 +- > arch/arm64/lib/mte.S | 30 +- > arch/arm64/mm/copypage.c | 26 + > arch/arm64/mm/fault.c | 35 +- > arch/arm64/mm/mteswap.c | 113 +++- > fs/proc/meminfo.c | 8 + > fs/proc/page.c | 1 + > include/asm-generic/Kbuild | 1 + > include/asm-generic/memory_metadata.h | 50 ++ > include/linux/gfp.h | 10 + > include/linux/gfp_types.h | 14 +- > include/linux/huge_mm.h | 6 + > include/linux/kernel-page-flags.h | 1 + > include/linux/migrate_mode.h | 1 + > include/linux/mm.h | 12 +- > include/linux/mmzone.h | 26 +- > include/linux/page-flags.h | 1 + > include/linux/pgtable.h | 19 + > include/linux/sched.h | 2 +- > include/linux/sched/mm.h | 13 + > include/linux/vm_event_item.h | 5 + > include/linux/vmstat.h | 2 + > include/trace/events/mmflags.h | 5 +- > mm/Kconfig | 5 + > mm/compaction.c | 52 +- > mm/huge_memory.c | 109 ++++ > mm/internal.h | 7 + > mm/khugepaged.c | 7 + > mm/memory.c | 180 +++++- > mm/mempolicy.c | 7 + > mm/migrate.c | 6 + > mm/mm_init.c | 23 +- > mm/mprotect.c | 46 ++ > mm/page_alloc.c | 136 ++++- > mm/page_isolation.c | 19 +- > mm/page_owner.c | 3 +- > mm/shmem.c | 14 +- > mm/show_mem.c | 4 + > mm/swapfile.c | 4 + > mm/vmscan.c | 3 + > mm/vmstat.c | 13 +- > 56 files changed, 1834 insertions(+), 161 deletions(-) > create mode 100644 arch/arm64/include/asm/memory_metadata.h > create mode 100644 arch/arm64/include/asm/mte_tag_storage.h > create mode 100644 arch/arm64/kernel/mte_tag_storage.c > create mode 100644 include/asm-generic/memory_metadata.h > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel