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 2B201EB64DA for ; Wed, 19 Jul 2023 05:08:05 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5DznPhqv8q3NPYOZjwST3nHxjNGzLzoh3fU7nP4RkpQ=; b=wRlBts+426ESn+ zglyncfzCWOqhux+Azs/g0Y5GLlo2UXm95X5cIlb5Xbr6p/sHSngbOHk4oYTsq7v3nzRcjaWR31Bo r21FDrRr5Lfz7rldUOd/aNv+w+N46A81GqY4r/bsiKrHGE7cAl6gwAjaCfShw8BoW/6TFrwpt1Jm1 V3rsfhGIF1rJM6xJu+2N8CgbKieyzQvFhTbr+aATwQQSXlJqikEz7Y7HGuly3ae/k1wXRED+8/w5E 5HimospLvxww2Vqym/NWNeUH5GaS1oFdUrJQoQ3Ym+rT624W+gvKeBe5U9A3hdP3agtYU5iqLa2sV hRcJMo8EGcpEZ6r/uaIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qLzPf-0059fH-2A; Wed, 19 Jul 2023 05:07:47 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qLzPc-0059do-1L for linux-arm-kernel@bombadil.infradead.org; Wed, 19 Jul 2023 05:07:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=jNeAvRLmB6hWcSjcUwyUFWttbNMumnwUyq4u1uyi2uM=; b=gD1MJBB39oLDyLPHVBLCRs438w pbWrOwFgIiWA6m7ObLuc+XRDkz1srHRw0EK6ZAnMjMuiMcnmj9xyT5sMhn/Fm3EvXTawqrOEsGDAP qWAKeC1P0GEzoS4SZpjvqXOrDYGhdIRDy87mD7IJSH2nPabsjpEBGRQy1Xv+nBZa6gXL66XEXs9sw I2UHVZ1NfJjQ0l9lFmsaAb4DBFY9CVF5EQRtblJ8OYldGMwYnhD97C2usykdK+iSZM6ZVLqC/AE8Z GUrIMcjaWl6jugtX/IXfpOX7zx+routj1Gd1GJopck6Bmw9mB7Goy4Pi8akv+yaMUMrPZznuZ1SWz r/mzbZUw==; Received: from mga06b.intel.com ([134.134.136.31] helo=mga06.intel.com) by desiato.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qLoLn-00BoTW-2n for linux-arm-kernel@lists.infradead.org; Tue, 18 Jul 2023 17:19:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689700743; x=1721236743; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=DEWWKPhD3bMLHl0K23L9B74wls/fgC1L701Hhpw8vVA=; b=Jo8HQ/axtDf+4VyIxQDeXYrz/s3oH6E3N7aJG/00w3gqSBPmDPqFztI8 PeiBxvT2BwjLWpzGRo3luMQHA1CGZBTBqa9b+ByIwvsaHpzi6yQwzvB+m BBDow/3B+Hdfg91olMfWLLwpHNPXATb2+2hci0brr8AcypZ5FGyR2TH7t vxq4akaUDomvPyxefRdebQAHCNkvPakDOxb+II6alysGDSZ/3KHbSQQT4 o6vgVrGskVRO5LnEo9BrOMUWC4mcZTVyTEtsIIH2IdJRBu9LN6aEy/ZZF R9QIbP7rwIyUqc9Hna735J6b8cjsDjuqordgywK/jVvjh4qI+/J3M8kPF A==; X-IronPort-AV: E=McAfee;i="6600,9927,10775"; a="430028061" X-IronPort-AV: E=Sophos;i="6.01,214,1684825200"; d="scan'208";a="430028061" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2023 10:17:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10775"; a="717676698" X-IronPort-AV: E=Sophos;i="6.01,214,1684825200"; d="scan'208";a="717676698" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 18 Jul 2023 10:17:53 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qLoKd-005QHc-2q; Tue, 18 Jul 2023 20:17:51 +0300 Date: Tue, 18 Jul 2023 20:17:51 +0300 From: Andy Shevchenko To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, linux@rasmusvillemoes.dk, yury.norov@gmail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eugenis@google.com, syednwaris@gmail.com, william.gray@linaro.org Subject: Re: [PATCH v3 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20230717113709.328671-1-glider@google.com> <20230717113709.328671-4-glider@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230718_181905_400846_F5D74FA5 X-CRM114-Status: GOOD ( 42.10 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gVHVlLCBKdWwgMTgsIDIwMjMgYXQgMDU6MzM6MzdQTSArMDIwMCwgQWxleGFuZGVyIFBvdGFw ZW5rbyB3cm90ZToKPiBPbiBNb24sIEp1bCAxNywgMjAyMyBhdCAzOjQ54oCvUE0gQW5keSBTaGV2 Y2hlbmtvCj4gPGFuZHJpeS5zaGV2Y2hlbmtvQGxpbnV4LmludGVsLmNvbT4gd3JvdGU6Cj4gPiBP biBNb24sIEp1bCAxNywgMjAyMyBhdCAwMTozNzowNlBNICswMjAwLCBBbGV4YW5kZXIgUG90YXBl bmtvIHdyb3RlOgoKLi4uCgo+IEhvd2V2ZXIgaXQgZG9lc24ndCBzZWVtIHRvIGJlIHZlcnkgcGlj a3kuCj4gCj4gICAkIHNjcmlwdHMva2VybmVsLWRvYyAtdiAgLW5vbmUgYXJjaC9hcm02NC9pbmNs dWRlL2FzbS9tdGVjb21wLmgKPiAKPiB3YXJucyBhYm91dCBlLmcuIHBhcmFtZXRlciBuYW1lIG1p c21hdGNoLCBidXQgZG9lcyBub3QgY2FyZSBhYm91dCB0aGUKPiBtaXNzaW5nIHJldHVybiBzZWN0 aW9uLgoKLVdyZXR1cm4gaXMgbWlzc2luZwoKLi4uCgo+ID4gQWxzbwo+ID4gd2h5IHlvdSBwdXQg dGhlIGRlc2NyaXB0aW9ucyBpbiB0byB0aGUgaGVhZGVyIGZpbGU/IEl0J3MgYSBiaXQgdW51c3Vh bCBmb3IgdGhlCj4gPiBleHBvcnRlZCBvbmVzLgo+IAo+IGh0dHBzOi8vZG9jcy5rZXJuZWwub3Jn L2RvYy1ndWlkZS9rZXJuZWwtZG9jLmh0bWwgd2FzIG5vdCBzcGVjaWZpYyBvbgo+IHRoaXMsIGFu ZCBJIHRob3VnaHQgYW55b25lIHdhbnRpbmcgdG8gdW5kZXJzdGFuZCBob3cgYW4gaW50ZXJmYWNl Cj4gd29ya3Mgd291bGQgcHJlZmVyIHJlYWRpbmcgdGhlIGhlYWRlciByYXRoZXIgdGhhbiB0aGUg aW1wbGVtZW50YXRpb24uCj4gSSBjYW4gbW92ZSB0aGUgY29tbWVudHMgdG8gYXJjaC9hcm02NC9t bS9tdGVjb21wLmMgaWYgeW91IHRoaW5rIGl0J3MgYQo+IGJldHRlciBwbGFjZSBmb3IgdGhlbS4K CldpdGggdGhlIGtlcm5lbCBkb2MgaW4gdGhlIEMgZmlsZSB5b3UgbWF5IGFsc28gY29tbWVudCB0 aGUgaW50ZXJuYWwgb25lcyBhbmQKZ2VuZXJhdGUgZG9jdW1lbnRhdGlvbiBvbmx5IGZvciBleHBv cnRlZCBvbmVzLiBUaGlzIGlzIG5vdCBwb3NzaWJsZSB3aXRoIGguCgouLi4KCj4gPiA+ICt2b2lk IGVhMF9yYW5nZXNfdG9fdGFncyh1OCAqcl90YWdzLCBzaG9ydCAqcl9zaXplcywgaW50IHJfbGVu LCB1OCAqdGFncyk7Cj4gPiBJbiBib3RoIGNhc2VzIHNpZ25lZCBpbnRlZ2VyIG1heSBiZSBwcm9t b3RlZCB3aXRoIGEgc2lnbi4gSXMgaXQgYSBwcm9ibGVtIGhlcmU/Cj4gTm90IHN1cmUgaWYgeW91 IG1lYW4gcl9sZW4gb3Igcl9zaXplcywKCk1vc3RseSBhYm91dCB0aGUgbGF0dGVyLgoKPiBidXQg YWxsIHRob3NlIHZhbHVlcyBhcmUgPj0gMAo+IGFuZCA8PSAyNTYsIHNvIHRoZXJlIHNob3VsZCBi ZSBubyBwcm9ibGVtcy4KPiAoc2hvcnRzIGNvdWxkIGhhdmUgYmVlbiBpbnRzIGFzIHdlbGwsIHdl IGFyZSBqdXN0IHNhdmluZyBzb21lIHN0YWNrCj4gc3BhY2UgaW4gZWEwX2NvbXByZXNzKCkvZWEw X2RlY29tcHJlc3MoKSkuCgpUaGVuIHdoeSB0aGV5IGFyZSBzaWduZWQ/IFBsZWFzZSwganVzdGlm eSB0aGF0LgpTaWduZG5lc3MgcHJvbmUgdG8gc3VidGxlIGFuZCBoYXJkIHRvIGh1bnQgZXJyb3Jz IGR1ZSB0byBpbnRlZ2VyIHByb21vdGlvbnMuCgouLi4KCj4gPiA+ICsjaW5jbHVkZSA8bGludXgv Yml0cy5oPgo+ID4gPiArI2luY2x1ZGUgPGxpbnV4L2JpdG1hcC5oPgo+ID4KPiA+IGJpdG1hcCBn dWFyYW50ZWVzIHRoYXQgYml0cy5oIHdpbGwgYmUgaW5jbHVkZWQuCj4gCj4gSSBhbSBmb2xsb3dp bmcgdGhlIElXWVUgcHJpbmNpcGxlIGhlcmUsIGFuZCBJIGJlbGlldmUgaXQncyBhIGdvb2QgdGhp bmcgdG8gZG8uCj4gSSd2ZSBzZWVuIGNhc2VzIHdoZXJlIHRoZXNlIHRyYW5zaXRpdmUgZGVwZW5k ZW5jaWVzIHJvdHRlZCBhZnRlciBzb21lCj4gcmVmYWN0b3JpbmcsIGJ1dCB0aGUgZmFjdCB3YXMg b25seSBub3RpY2VkIGluIGNlcnRhaW4gY29uZmlndXJhdGlvbnMuCj4gQWxzbywgdGhlcmUncyBh biBvbmdvaW5nIHdvcmsgYnkgSW5nbyBNb2xuYXIgdG8gc3BlZWQgdXAga2VybmVsIGJ1aWxkcwo+ IGJ5IG9wdGltaXppbmcgaGVhZGVycwo+IChodHRwczovL2x3bi5uZXQvbWwvbGludXgta2VybmVs L1lkSWZ6K0xNZXdldFNhRUJAZ21haWwuY29tLyksIGFuZCBpdAo+IHJlbGllcyBvbiBleHBsaWNp dCBkZXBlbmRlbmNpZXMgd2hpY2ggYXJlIGVhc2llciB0byB1bnRhbmdsZS4KClllcywgYnV0IHdl IGhhdmUgc29tZSBndWFyYW50ZWVzLiBFLmcuLCB3ZSBkb24ndCBpbmNsdWRlIGNvbXBpbGVyKi5o CndoZW4gdHlwZXMuaCBpcyBpbmNsdWRlZCwgYmVjYXVzZSBvZiB0aGUgZ3VhcmFudGVlcy4KCk90 aGVyd2lzZSB5b3VyIGNvZGUgbWlzc2VzIF9hIGxvdF8gb2YgaGVhZGVycy4KCi4uLgoKPiA+IENh biB5b3UgbWFrZSBpdCB1bnNpZ25lZCBhbmQgc3RhcnQgZnJvbSAwPwo+IAo+IENoYW5nZWQgdG8g c3RhcnQgd2l0aCAwLCBidXQgSSBhbSBhIGJpdCBoZXNpdGFudCBhYm91dCBtYWtpbmcgaXQKPiB1 bnNpZ25lZDogaXQgaXMgbm93IG5vIG1vcmUgc3BlY2lhbCB0aGFuIGEgbG9vcCB2YXJpYWJsZS4K ClNpZ25kbmVzcyBpcyBhIGJlYXN0IGluIEMsIG5lZWRzIGFsd2F5cyBhbiBhZGRpdGlvbmFsIGp1 c3RpZmljYXRpb24uCgouLi4KCj4gPiA+ICsgICAgIGludCBpLCBqLCBwb3MgPSAwOwo+ID4KPiA+ IFdvdWxkbid0IGJlIG1vcmUgY29ycmVjdCB0byBoYXZlIHRoaXMgYXNzaWdubWVudCBpbnNpZGUg dGhlIGZpcnN0IGZvci1sb29wPwo+IAo+IERvIHlvdSBtZWFuIHNldHRpbmcgaXQgYmFjayB0byAw IG9uIGV2ZXJ5IGl0ZXJhdGlvbiBvZiB0aGUgb3V0ZXIgbG9vcD8KClllcy4KCj4gV2Ugc3VyZSBk b24ndCB3YW50IHRoYXQsIHNpbmNlIHBvcyBpcyB0aGUgbG9jYXRpb24gaW4gdGhlIHRhZ3NbXSBh cnJheQo+IHdoZXJlIHRoZSBuZXh0IHRhZyBpcyB3cml0dGVuLgoKT0shCgouLi4KCj4gPiA+ICsj ZGVmaW5lIFJBTkdFU19JTkxJTkUgZWEwX3NpemVfdG9fcmFuZ2VzKDgpCj4gPgo+ID4gRG9uJ3Qg Zm9yZ2V0IHRvIHVuZGVmIGl0IHdoZW4gbm90IG5lZWRlZC4KPiAKPiBPaywgd2lsbCBkby4KCj4g U2hhbGwgSSB1bmRlZiB0aGUgY29uc3RhbnRzIGFib3ZlIGFzIHdlbGwgKGUuZy4gQklUU19QRVJf VEFHKT8KPiBUaGUgaW50dWl0aXZlIGFuc3dlciBpcyAibm8iLAoKQ29ycmVjdC4KCj4gYnV0IHRo ZW4gdGhlcmUgc2hvdWxkIGJlIHNvbWUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRob3NlIGFuZCBSQU5H RVNfSU5MSU5FPwoKWWVzLCBvbmUgaXMgd2lkZWx5IHVzZWQgY29uc3RhbnQgYW5kIG9uZSBpcyBh IF9sb2NhbGl6ZWRfIGhlbHBlci4KCi4uLgoKPiA+ID4gK3N0YXRpYyB2b2lkIGJpdG1hcF93cml0 ZSh1bnNpZ25lZCBsb25nICpiaXRtYXAsIHVuc2lnbmVkIGxvbmcgdmFsdWUsCj4gPiA+ICsgICAg ICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyAqcG9zLCB1bnNpZ25lZCBsb25nIGJpdHMp Cj4gPgo+ID4gUGxlYXNlLCBkb24ndCB1c2UgcmVzZXJ2ZWQgbmFtZXNwYWNlLiBZb3VycyBpcyBl YTAsIHVzZSBpdDoKPiA+IGVhMF9iaXRtYXBfd3JpdGUoKSEgU2FtZSB0byBvdGhlciBzaW1pbGFy bHkgbmFtZWQgZnVuY3Rpb25zLgo+IAo+IERvbmUuCj4gSG93ZXZlciB0aGVyZSBhcmUgdHdvIHBh cmFsbGVsIG5hbWVzcGFjZXMgbm93OiAiZWEwIiBmb3IgdGhlCj4gY29tcHJlc3Npb24gYWxnb3Jp dGhtLCBhbmQgIm1lbWNvbXAiIGZvciB0aGUgbW9kdWxlIGluaXRpYWxpemF0aW9uIGFuZAo+IGRh dGEgc3RydWN0dXJlcy4KPiBEdW5ubyBpZiBpdCBtYWtlcyBzZW5zZSB0byBtZXJnZSB0aGVtIChh bmQgcmVuYW1lIHRoZSAuYyBmaWxlIGFjY29yZGluZ2x5KS4KCllvdXIgY2hvaWNlLiBNdSBwb2lu dCwganVzdCBkbyBwcmVmaXggaXQgd2l0aCBzb21ldGhpbmcgbWVhbmluZ2Z1bC4KCi4uLgoKPiA+ ID4gKyAgICAgdTggcl90YWdzWzI1Nl07Cj4gPiA+ICsgICAgIGludCByX2xlbiA9IEFSUkFZX1NJ WkUocl90YWdzKTsKPiA+Cj4gTm8sIGl0IGlzIHRoZSBsZW5ndGggb2YgdGhlIGFycmF5cyAoYm90 aCByX3RhZ3MgYW5kIHJfc2l6ZXMpLgo+IEJlbG93IHlvdSBtYWtlIGEgZ29vZCBwb2ludCBpdCB3 aWxsIHNwYXJlIHVzIGEga2VybmVsLmggZGVwZW5kZW5jeSwKPiBidXQgZm9yIHRoZSBzYWtlIG9m IGtlZXBpbmcgdGhlIGNvZGUgZXJyb3ItcHJvbmUgd2UgcHJvYmFibHkgc2hvdWxkbid0Cj4gYXNz dW1lIHJfdGFncyBpcyBhIGJ5dGUgYXJyYXkuCgpJdCdzIGEgY29tbW9uIHByYWN0aWNlIGV2ZW4g b3V0c2lkZSBvZiBMaW51eCBrZXJuZWwgdG8gdXNlIHNpemVvZigpIGFnYWluc3QKY2hhciBhcnJh eXMuIEkgZG9uJ3Qgc2VlIHRoZSBwb2ludCB0byBoYXZlIHRoZSBBUlJBWV9TSVpFKCkgY29tcGxp Y2F0aW9uIGhlcmUuCgouLi4KCj4gPiA+ICsgICAgICAgICAgICAgc25wcmludGYobmFtZSwgQVJS QVlfU0laRShuYW1lKSwgIm10ZS10YWdzLSVkIiwgc2l6ZSk7CgpZb3Ugc2VlLCBpZiB5b3UgZ3Jl cCBmb3Igc2ltaWxhciBjYWxscyBJJ20gcHJldHR5IHN1cmUgdGhlIG9yZGVyIG9mIDIgb2YgcG93 ZXIKb2YgMTAgd2lsbCBiZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHNpemVvZigpL0FSUkFZX1NJ WkUoKSBpZiB0aGUgbGF0dGVyIGV2ZW4Kb2NjdXJzIGF0IGxlYXN0IG9uY2UuCgoKLS0gCldpdGgg QmVzdCBSZWdhcmRzLApBbmR5IFNoZXZjaGVua28KCgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGlu dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66DDBEB64DC for ; Tue, 18 Jul 2023 17:18:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232517AbjGRRSQ (ORCPT ); Tue, 18 Jul 2023 13:18:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232942AbjGRRR6 (ORCPT ); Tue, 18 Jul 2023 13:17:58 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74B39170B for ; Tue, 18 Jul 2023 10:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689700677; x=1721236677; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=DEWWKPhD3bMLHl0K23L9B74wls/fgC1L701Hhpw8vVA=; b=COwxpX2u2PXovbwfq7MQXi4kUGhsK47KL0xhSg0t9k8BDifn4NhsnKiP FIkYRlBoF5CVRmbiOGI0GNbAU+M5S/KCVpSx5u8hftP+ek3mnaGxBDVkm 0TT24QWV/3IDuXwYn7qXPHxpRp4PVsL/J12MB5vEv3PEMhT12YsIG3UEA oEVdYgdH7UJWszZ73thf8+famdeM0Qd273h3QNoQ0dS0iPL6oehOQeBFw vzCLGupv3/Dj4yakwgTI0VNkTvzTkMfXdgyFyjXvXHaXqJPSX2lFTjIY9 jAKSDDm9oOprrIfm9ySHbk+D7KVa+8+lgz+zw2R7BB5F6x08ZrHYxH2Co w==; X-IronPort-AV: E=McAfee;i="6600,9927,10775"; a="430028058" X-IronPort-AV: E=Sophos;i="6.01,214,1684825200"; d="scan'208";a="430028058" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2023 10:17:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10775"; a="717676698" X-IronPort-AV: E=Sophos;i="6.01,214,1684825200"; d="scan'208";a="717676698" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 18 Jul 2023 10:17:53 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qLoKd-005QHc-2q; Tue, 18 Jul 2023 20:17:51 +0300 Date: Tue, 18 Jul 2023 20:17:51 +0300 From: Andy Shevchenko To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, linux@rasmusvillemoes.dk, yury.norov@gmail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eugenis@google.com, syednwaris@gmail.com, william.gray@linaro.org Subject: Re: [PATCH v3 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20230717113709.328671-1-glider@google.com> <20230717113709.328671-4-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 18, 2023 at 05:33:37PM +0200, Alexander Potapenko wrote: > On Mon, Jul 17, 2023 at 3:49 PM Andy Shevchenko > wrote: > > On Mon, Jul 17, 2023 at 01:37:06PM +0200, Alexander Potapenko wrote: ... > However it doesn't seem to be very picky. > > $ scripts/kernel-doc -v -none arch/arm64/include/asm/mtecomp.h > > warns about e.g. parameter name mismatch, but does not care about the > missing return section. -Wreturn is missing ... > > Also > > why you put the descriptions in to the header file? It's a bit unusual for the > > exported ones. > > https://docs.kernel.org/doc-guide/kernel-doc.html was not specific on > this, and I thought anyone wanting to understand how an interface > works would prefer reading the header rather than the implementation. > I can move the comments to arch/arm64/mm/mtecomp.c if you think it's a > better place for them. With the kernel doc in the C file you may also comment the internal ones and generate documentation only for exported ones. This is not possible with h. ... > > > +void ea0_ranges_to_tags(u8 *r_tags, short *r_sizes, int r_len, u8 *tags); > > In both cases signed integer may be promoted with a sign. Is it a problem here? > Not sure if you mean r_len or r_sizes, Mostly about the latter. > but all those values are >= 0 > and <= 256, so there should be no problems. > (shorts could have been ints as well, we are just saving some stack > space in ea0_compress()/ea0_decompress()). Then why they are signed? Please, justify that. Signdness prone to subtle and hard to hunt errors due to integer promotions. ... > > > +#include > > > +#include > > > > bitmap guarantees that bits.h will be included. > > I am following the IWYU principle here, and I believe it's a good thing to do. > I've seen cases where these transitive dependencies rotted after some > refactoring, but the fact was only noticed in certain configurations. > Also, there's an ongoing work by Ingo Molnar to speed up kernel builds > by optimizing headers > (https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/), and it > relies on explicit dependencies which are easier to untangle. Yes, but we have some guarantees. E.g., we don't include compiler*.h when types.h is included, because of the guarantees. Otherwise your code misses _a lot_ of headers. ... > > Can you make it unsigned and start from 0? > > Changed to start with 0, but I am a bit hesitant about making it > unsigned: it is now no more special than a loop variable. Signdness is a beast in C, needs always an additional justification. ... > > > + int i, j, pos = 0; > > > > Wouldn't be more correct to have this assignment inside the first for-loop? > > Do you mean setting it back to 0 on every iteration of the outer loop? Yes. > We sure don't want that, since pos is the location in the tags[] array > where the next tag is written. OK! ... > > > +#define RANGES_INLINE ea0_size_to_ranges(8) > > > > Don't forget to undef it when not needed. > > Ok, will do. > Shall I undef the constants above as well (e.g. BITS_PER_TAG)? > The intuitive answer is "no", Correct. > but then there should be some difference between those and RANGES_INLINE? Yes, one is widely used constant and one is a _localized_ helper. ... > > > +static void bitmap_write(unsigned long *bitmap, unsigned long value, > > > + unsigned long *pos, unsigned long bits) > > > > Please, don't use reserved namespace. Yours is ea0, use it: > > ea0_bitmap_write()! Same to other similarly named functions. > > Done. > However there are two parallel namespaces now: "ea0" for the > compression algorithm, and "memcomp" for the module initialization and > data structures. > Dunno if it makes sense to merge them (and rename the .c file accordingly). Your choice. Mu point, just do prefix it with something meaningful. ... > > > + u8 r_tags[256]; > > > + int r_len = ARRAY_SIZE(r_tags); > > > No, it is the length of the arrays (both r_tags and r_sizes). > Below you make a good point it will spare us a kernel.h dependency, > but for the sake of keeping the code error-prone we probably shouldn't > assume r_tags is a byte array. It's a common practice even outside of Linux kernel to use sizeof() against char arrays. I don't see the point to have the ARRAY_SIZE() complication here. ... > > > + snprintf(name, ARRAY_SIZE(name), "mte-tags-%d", size); You see, if you grep for similar calls I'm pretty sure the order of 2 of power of 10 will be the difference between sizeof()/ARRAY_SIZE() if the latter even occurs at least once. -- With Best Regards, Andy Shevchenko