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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B16AC2B9F4 for ; Fri, 25 Jun 2021 16:23:00 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 06B246115C for ; Fri, 25 Jun 2021 16:22:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06B246115C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JRVsy3fyHJBPHa23yaXCUIiCPfOqIy9c4ioDeRO4uIw=; b=w45wRyO+l9eSXf ybXzaeT9i11wDdZFB7QGCDfYr5y/eNHyhboTmA4G9+gN8hGGj+/pUh0yAXkS2nudCH0QhNh+J7FgK s34ktTh9MNZ8A5Vm9uMOJNiYStYtF1eWHeWSFmDpxvl6+J0RtjOIS0HrJkPMxUaILxq1ELL8pv5zR 6Og2Iz4Fe3jIEuKUlJIOiQe4kUs3V2i5c2eIbqG85yJ3s/hVDFjynjiZDtZVFv0HbhPsA1mXfZ4RA XxuFVPz4QJm4ON5EkS3Nc+v2gNeqE2n4FqU25UN0W2M7rPSRBYKeFZvArjMqMqHSlKDuDZdA2Fb89 wxPcu4ifmCLg8AeS97/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwoa9-002Ha2-9N; Fri, 25 Jun 2021 16:21:29 +0000 Received: from mail-eopbgr10089.outbound.protection.outlook.com ([40.107.1.89] helo=EUR02-HE1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwoa4-002HYs-6j for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 16:21:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5sRKsBExguoNadjkKV8k/4YFiOFicH6UuTaBtGX8Izg=; b=6ex4bVDAXuKkWDYeFkZEu3TkaOlDkHsfeeqPQ13el9IXylGaXx467VSMFqx/KvmtZwPKZ8NbuI4KnoNFx0/+z9/TNympjdtSpSTzWIf9ozG0prmD/TiyqkZW6pgaizM36C4kg+kO3cHBoktAgveTKbr7hLRahJEYs3rCWHegPMY= Received: from DB6PR0301CA0028.eurprd03.prod.outlook.com (2603:10a6:4:3e::38) by DBAPR08MB5846.eurprd08.prod.outlook.com (2603:10a6:10:1b0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.20; Fri, 25 Jun 2021 16:21:18 +0000 Received: from DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:3e:cafe::b) by DB6PR0301CA0028.outlook.office365.com (2603:10a6:4:3e::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Fri, 25 Jun 2021 16:21:18 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.infradead.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.infradead.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT013.mail.protection.outlook.com (10.152.20.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Fri, 25 Jun 2021 16:21:18 +0000 Received: ("Tessian outbound 615e3db0526a:v97"); Fri, 25 Jun 2021 16:21:18 +0000 X-CR-MTA-TID: 64aa7808 Received: from cc56518e8c14.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9CC992DD-8045-452D-95A1-9C5AC70B5AE5.1; Fri, 25 Jun 2021 16:21:12 +0000 Received: from FRA01-PR2-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cc56518e8c14.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 25 Jun 2021 16:21:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I0dWIwyGAC8ByvJV7XLb5+29EbLqhIdb/DFUKYju1aEJ6CSz4AWTV91T24CresZw3PhBKDdRl7m8ENo2EJd76Gp+OQTFhYbAqpJnxzsEO9/kx6cxekJerAAyI+krDpWfDf1PHu+KRY6+q8SBUxoVRcI6cbjsoCLOGkouhD3epVw0L2aW1L8KzOn3aMYwWthnRDrLiNWbkI9Vnr6DwysfF67KDzXsYl1sV6HXDI83W2tfJxsEA+QIzcCHnATLJfqeDMbegpYNrnSRHd9TjqWnGm0OnkUOG+hpNuGcxfz58RSKfSoZAOkdd/kihlBEY/S98W6zbGyb5GcvABITSGQYtA== 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-SenderADCheck; bh=5sRKsBExguoNadjkKV8k/4YFiOFicH6UuTaBtGX8Izg=; b=fv8uRMZ9ovbMdYnhyYY+IENk0kSbQ01p3pJ5GpgWs0IFZQA1dQrgKFpAi9e18me5ygvEkY/T0b0x4dcezjh1WEamOB2Nhnrz4K3khMEfV4K/JfezwdGk30nGOJ/jLsxBgrCuiX9t+y5C1w+00UdnmCb8w2F79IFza7aESl3a+drd8MkyMborbfiu+teDsj7nHMmx7ETURarogtxbXNKKQ9BITtd93jrBF7rt14bkN6KAKkSnw4Zxyn7G1YYbFxs3EU+9RCg6CNVNEpuDdd3OMm0KQLPzeg/MwUPuxq4QVrYSmIoAUVG9i1fUi/rv7qPmng9GFZi28OdHHwpRBcT6/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5sRKsBExguoNadjkKV8k/4YFiOFicH6UuTaBtGX8Izg=; b=6ex4bVDAXuKkWDYeFkZEu3TkaOlDkHsfeeqPQ13el9IXylGaXx467VSMFqx/KvmtZwPKZ8NbuI4KnoNFx0/+z9/TNympjdtSpSTzWIf9ozG0prmD/TiyqkZW6pgaizM36C4kg+kO3cHBoktAgveTKbr7hLRahJEYs3rCWHegPMY= Received: from PR3PR08MB5692.eurprd08.prod.outlook.com (2603:10a6:102:8a::17) by PR2PR08MB4795.eurprd08.prod.outlook.com (2603:10a6:101:28::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Fri, 25 Jun 2021 16:21:10 +0000 Received: from PR3PR08MB5692.eurprd08.prod.outlook.com ([fe80::d551:45d:28a:2751]) by PR3PR08MB5692.eurprd08.prod.outlook.com ([fe80::d551:45d:28a:2751%3]) with mapi id 15.20.4242.023; Fri, 25 Jun 2021 16:21:08 +0000 From: Tejas Belagod To: Szabolcs Nagy , Will Deacon CC: Catalin Marinas , Peter Collingbourne , Vincenzo Frascino , Evgenii Stepanov , Linux ARM Subject: RE: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Thread-Topic: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Thread-Index: AQHXaA2XI/rZINtqF0GYBxmcFQ/YFqsjYoYAgAEUuICAACxZgIAACrmAgAAadACAAA2FYA== Date: Fri, 25 Jun 2021 16:21:07 +0000 Message-ID: References: <20210621123936.GB29283@willie-the-truck> <20210621151858.GC11552@arm.com> <20210621173902.GA29713@willie-the-truck> <20210621185036.GD11552@arm.com> <20210623085530.GF13058@arm.com> <20210624165228.GB25097@arm.com> <20210625092253.GJ13058@arm.com> <20210625120137.GC20835@arm.com> <20210625123959.GB3170@willie-the-truck> <20210625141438.GK13058@arm.com> In-Reply-To: <20210625141438.GK13058@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 51D6F913CBDC264C97F785035F4504AD.0 x-checkrecipientchecked: true Authentication-Results-Original: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [81.102.75.174] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 8422919b-48d9-4635-657f-08d937f54315 x-ms-traffictypediagnostic: PR2PR08MB4795:|DBAPR08MB5846: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 6tobrmpS6tGYrPOUGHj2qFcVDgiuBuR+Q7Q+Ctp1QCAYtPakbyFdidnT1A+KIJ2hCwY9N5Sbp1ehh0lCvCk16EI4I+zAtSbZCrCbA/Ou+Aah2Wjh1X2TI+USjii3GOZaJNaQhlmp1i/fKhu+SJlzy5HvtFLsZ6B8y2CFB+JB358ig1V1p6yPJsvpoTEfUKwYc1BXiXi6BP+MJvc52Iyvvg+emHgtB+xQvoaPY2uWOzp5DygArwvycY/k8/w8xwgBlJXRmLIne6WBD74wn41oZuutDC8t0oM/cmRL+VMJAqK5tst/VR5raWKfj40WtkVJIakpSkCBc3CguKzffMdbSNZl+Mioz4eSZuhsxICbZJJ5qicUvRRH98y3XaZXZcNsZwpMRQW+Yv2a1Uf9mdtuaZNXPFeySvIdaPBWyjYoFcLw1QROjS0Es7gW2pXbMywxxnzcAaIPTsQOXgzLUJfHtuHlZ+8QNppgXcbDgzYmR3KQaWxlavjCqXEblMChMQD9BlBGVBnT9O07GJSVYL0QZ+oCiSdzfy5vV2M4ttwNCFmEZQk4YFDeUFgtGa8gLGTazUY9ErlEAQHwwiFElSr6AINjEdWgeFTSJ8+0oSEvYrY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5692.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(136003)(396003)(366004)(346002)(316002)(8936002)(86362001)(478600001)(33656002)(54906003)(110136005)(8676002)(52536014)(26005)(38100700002)(186003)(122000001)(83380400001)(5660300002)(64756008)(66946007)(66446008)(66476007)(66556008)(53546011)(9686003)(4326008)(7696005)(55016002)(2906002)(71200400001)(76116006)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OThxNFNrS09qV1BXdVdRTGZqMGxWTDk4ZThzZXJhbkRGeU4rRUNYUndFZGRq?= =?utf-8?B?aVVqSVE1amJaRzNTRTBMc01LcU5CK0JMejFLVkdxZnA2TTRZWXVxZGE0MFI5?= =?utf-8?B?aFQzeURiaGtaUTZrMWp3RzNaRWtpTHlNRjZCU2x5ZmFuTFpCS3kydklZRjZu?= =?utf-8?B?TGxoNVF1eXJLVTViV3JkU1NyNmpYUDVwMGZLZ2x2YzFBa2twbXFPcUFRZFBT?= =?utf-8?B?dXc5TDNDMlVwTzhNcEFTek05bnJVSTh0M0ttYmVlS2tvQk5CWFdmU3o3SDBl?= =?utf-8?B?Nm4xbWRHK0ZqZVJVYi90aVNnK0FvRnpjTWcrd2JQSDROOFFHRkVVSnQzb0hM?= =?utf-8?B?V1cvQkVtK2NQeE1MaTM4bzMyNVUzQ29pTnBJUWJCYVJXc0xDMTNoREpuQXdj?= =?utf-8?B?YUVwbGZZaUFOcDl4akpiTlJwZUZKSHlzUlVBdXlqdjVUK3prNWFGR1daVWFm?= =?utf-8?B?Z0RpVGcyYmVValVzWTI3dVVWUzd3QWg3NFBZSEpxWHZFNWxWUEdVdDhGYVNr?= =?utf-8?B?Yk5rSjFTM3cwTjc5VXZmUW1yTUMzNnF6d2tIWDhLUFdLNk9ETzZ4NnI0TFli?= =?utf-8?B?VytXcWtuUzBZNVFYc3gwSG83ZEMxOS85WXMwQ1hZVFpEekNPQ3R1Nk83ZUxq?= =?utf-8?B?SVdseksrS2pBR3NLSDgvRmRrVTU2bFZKTllJR3JSSTdsZG5jRlFKaXd4d0kz?= =?utf-8?B?bTdleWVWMWFwZm9yd2JJckF2eHFOSXpjWERoWDI3YkQ4aWRFUlhYck8rcmlX?= =?utf-8?B?RS9BQ0tUU2lwRUhYNi94YjBMdXBsZ3hwRTVqT3grYmUzR0RDMVRUTW5UVWd1?= =?utf-8?B?b2NoUHIycnVnSzFiR1BCTFVrdVJlcXhoRHdjUnZPQVNrYTRsZ3ZRTWsyOXUy?= =?utf-8?B?RGtCcXo4bTdKbm5LaGNMaXpHN2pNZDJmaE4vcW5Ob1ArRDZIMGJmUVlhdmxD?= =?utf-8?B?RHV2SGtSdXVqMG9POGxnbWord2xyak5XZHpER1dMa1Q4cjlhVW1wcXBSQWhB?= =?utf-8?B?NjZqbzczcTRCYXdRTDZwcFJTOFBoSmtyQ2Rja1FLT212czZkMnlWQkJjdVdp?= =?utf-8?B?M0FiRDc1UEVlYXZaRU1sOEYvQmR2R0RoVUJMbnAyWTh0eTZZSUFOdGxwdDhV?= =?utf-8?B?VzNkVHF0djZyeFM3SndpWDBOdHpJMUsraW9tTG5aWlFDam5mNlIrQWVGcUJx?= =?utf-8?B?dE11c055YlFjb3JPUTB3aXpkanVqTnduUHdRTW1mc0Y2RUo0c0laZFVYTXo1?= =?utf-8?B?Ry96VHgvSkh6T1Rib2s3YVlYSFVmQVg1clhYbVRnRHM3bHlYZUh1b01BRDVP?= =?utf-8?B?d1pxelhiNDY3c1BtRFV1Qk1DOXo1OWdWK0hOa3ZSeFBRUGZQQjZ6TVcyaUx2?= =?utf-8?B?MnoremNKY0JrZGxWdXF0RTcyOEg4b2wvdUE4bXkzT3RBc1QyYVdaaXhjdUhL?= =?utf-8?B?TWRvc0hpQ3BUbWJFU3ZXUGZBa1dCV0RnV1B4SG1IRllmcUFTMkpUOWNUUXll?= =?utf-8?B?cENubmpTWCtYVnJEOGlFdVNFME1zcmZVRjd6RDR6UFlISUZCTndpUmtRQmFU?= =?utf-8?B?NnU0OGhQN24waWl0Nm5idDRhaTA3bGRFOWVQUjdGS3h0SWM2cWtlRFY0NHFY?= =?utf-8?B?dVhpSnB6VDVwZFRLdnhKWHVzRlhvbForaGZYYTIzKzE1QXN4Ni9IeVNzeXpD?= =?utf-8?B?bkJUdWR1M0QvZTNKSHpjeTM1YTloMk9qZWcxK0E1YURxTTVpUThtcURzbmdW?= =?utf-8?Q?A+GE8tXw3BeNzL4Ah1F2gfD/tSsurt0JqVq+4DG?= MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4795 Original-Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 1a8da79b-1426-489f-cf77-08d937f53dbc X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: a7N0UU1VpjpDySayqfVVevqkR4JwpP2Qwj8cDf26L4U9jmtOTNxn8K5SLv6HYwH/nuGRPc1e2Vle6fAVlZL76RxvvlpTZh74X7UILOiRI7zRHvarrF1jGB7F8bvZh8Np3IXcLmLZG1DjTJG8mTKPEf1I62BXXrzLixerhp4EcvcEc0NsZOXAlG0LeCC/cZzmn98B1DrChcevNd64qR9m6EvmwvRszfMbSR8OnFunVoVdpCHqwbkYm5JXDEX5g0aBSzVeEBEgWVoryJMIUDgXaF2lrLuFCKE8kTVYOIcs+SUpN43ZeOTX2nu1AoDeWCJ5vpKGOZKrIxj19ndOp6wn48Hv69LQZLzU3J2ik4sJP6QXajWfeYa9VzVmfZYlOoYFDJLvwQfk7fI9d7b2QSNtlUIxKSxHsJJmG6JkeNckVL8xTh9iNh3WtpO9GIzY9apPQTNAmN7oc8grOLxIPW+cy9i9RmeclHJR3ArwNmzqE1ydukrtN9IvgsVYQDtJXvtCmSM1g/e8gLacRO9fN4Z1xMMPj/3ADjRcg0Urz0p+l6lq8iatJdQbQcP1VNGn3yK75IZPG9FZFWaWikzGmj2d+RWHWQm3ADcU7pnUP2XOCXf8tXxt0SPvKqJU+6uy4F8mKhxs/lklwyLJ81PLatsg951OTah6dJZ6ZVu7pXpvkfjw9HjYdk9ibmnfGfb4Zb+IEs+4BxK0y0vMssHIgFktFw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(39850400004)(136003)(36840700001)(46966006)(52536014)(2906002)(86362001)(53546011)(6506007)(55016002)(26005)(9686003)(336012)(478600001)(186003)(316002)(70586007)(70206006)(82740400003)(110136005)(54906003)(47076005)(8676002)(4326008)(81166007)(7696005)(356005)(8936002)(82310400003)(5660300002)(36860700001)(33656002)(83380400001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2021 16:21:18.1546 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8422919b-48d9-4635-657f-08d937f54315 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5846 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210625_092124_524754_8E57E851 X-CRM114-Status: GOOD ( 30.85 ) 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 > -----Original Message----- > From: Szabolcs Nagy > Sent: Friday, June 25, 2021 3:15 PM > To: Will Deacon > Cc: Catalin Marinas ; Peter Collingbourne > ; Vincenzo Frascino ; Evgenii > Stepanov ; Linux ARM kernel@lists.infradead.org>; Tejas Belagod > Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on > a per-CPU basis > > The 06/25/2021 13:39, Will Deacon wrote: > > On Fri, Jun 25, 2021 at 01:01:37PM +0100, Catalin Marinas wrote: > > > Thanks, that's useful. I guess since the _MTAG_ENABLE tunable is not > > > ABI, the user app can't rely on what the glibc has configured. > > > Arguably, since it's driven from outside the application (env), we > > > could say the same for sysfs, though for the glibc case, the user > > > app is still be able to override it before the first thread is > > > created (or per-thread). I assume glibc only issues the prctl() once, not for > every new thread. > > note: in the end the tunable is like > > GLIBC_TUNABLES=glibc.mem.tagging=3 ./exe > > not _MTAG_ENABLE. > > and yes the setting comes from outside and glibc calls prctl once. > > > > So we can document that the mode requested by the app is an > > > indication, the system may change it to another value (and back-port > > > documentation to 5.10). If we get a request from developers to > > > honour a specific mode, we can add a new PR_MTE_TCF_EXACT bit or > > > something but it's not essential we do it now. > > > > > > So if we allow the kernel to change the user requested mode (via > > > sysfs), I think we still have two more issues to clarify: > > > > > > 1. Do we allow only "upgrade" (for some meaning of this) or sysfs can > > > downgrade to a less strict mode. I'd go for upgrade here to a > > > stricter check as in Peter's patch. > > > > > > 2. Should the sysfs upgrade the PR_MTE_TCF_NONE? _MTAG_ENABLE does > that, > > > so I'd say yes. > > > > > > Any other thoughts are welcome. > > > > As I mentioned before, I think the sysfs interface should offer: > > > > "task" : Honour whatever the task has asked for (default) > > "async" : Force async on this CPU > > "sync" : Force sync on this CPU > > > > I don't think we should upgrade PR_MTE_TCF_NONE unless we also have a > "none" > > option in here. I originally suggested that, but in hindsight it feels > > like a bad idea because a task could SIGILL on migration. So what > > we're saying is that PR_MTE_TCF_SYNC and PR_MTE_TCF_ASYNC will always > > enable MTE on success, but the reporting mode is a hint. > > > > I don't think upgrade/downgrade makes a lot of sense given that the > > sysfs controls can be changed at any point in time. It should just be an > override. > > > > This means that we can force async for CPUs where sync mode is > > horribly slow, whilst honouring the task's request on CPUs which are > > better implemented. > > i think a user should be able to ask for sync check mode for a process and get an > error if that's not possible. > > at least this is the semantics that makes sense in glibc. i think it's very confusing > if somebody explicitly asks for sync checks to debug something but then gets > useless diagnostics because somebody else tried to second guess their > performance tradeoff preferences. (if sync check is too slow on a cpu then the > user can taskset to a cpu that's not slow or just use other debugging method, > silent override sounds bad.) Sorry I'm late to the party - just catching up with this thread. I'm not a kernel/glibc expert so please correct me if I'm wrong here - I see two themes in this discussion - the usage model between user/system of the TCF mode and its implementation. From a user's perspective, they should be able to get the TCF mode they asked for and get atleast a warning if that's not possible for whatever reason(performance et al). From a system/kernel's perspective, if the system wants to use MTE, it should be able to provide the most performant(or most strict) TCF mode/per CPU as it sees fit - user's 'task' setting in sysfs/GLIBC's env will override it. Can a user-setting downgrade a system-setting TCF level is another question - probably not, so the user will need to be warned against it. So what happens if a process with TCF_NONE migrates from a CPU with TCF_NONE to TCF_ASYNC - should the kernel control process/CPU migrations according to the TCF setting? Won't this affect performance anyway by increasing contention? Implementation-wise, the sysfs interface of 'task', 'async', 'sync' seems to make sense to me as it fits in well if we use the above as a guiding principle. Thanks, Tejas. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel