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 83616EB64DA for ; Fri, 14 Jul 2023 10:47:56 +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=VRoKVS31IHlWT4VYtGAEjh5hpDYJIDpZ9KcunPcrEek=; b=tPdEKZ57AAk8eN 7kVe/PIeK59yXWH1N5i7BwleLSg8bq3EvGJ4CITJuUxeuTDDcC8epLnVajXwkI9klPnL8vBTHReEv VbjTw0YMCX4xGwwyU8lZcpBkNeGZcOf0jmoDkpYYZVrJU53eaFOVY/1lEwvTE3WHgDcuoJ0eUO3Jq AOVrlw3YCk3Z+kuwWBfTxs6VB6VaTbeyhlcPqxUIWRmCRnKN9/QKTejikQNevJu5C20T8nxMnIUHQ gYCOahrEIjBF2iSRdCpPXqPYOiAZvVwJztP+uB3FHiKQBrFaG1PXkxKqBDSUW2VUaqEQlfiAT2Kqe eGTYFa7qVDc6XIN0ax9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qKGKi-005u6e-2y; Fri, 14 Jul 2023 10:47:32 +0000 Received: from mga06b.intel.com ([134.134.136.31] helo=mga06.intel.com) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qKGKg-005u0q-0f for linux-arm-kernel@lists.infradead.org; Fri, 14 Jul 2023 10:47:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689331650; x=1720867650; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tOsxOI6FQngHJON6MN20wMAy7jjyncONocREl6UC/8c=; b=ApDs+BzOVQvAIMdkQ9Ek33XA/ecO9fMsztgB8Hz1oyYv5uFIbIrk5ZYI 45K/lwURUg665IrSnfC/aPqxuLfYoaABkb4Zl0nROv75VhoAeNaLrs91q /q0GOD8aokjSpTwE20MeR5GVPPGxr4E1vqafdfKNMSt+BwoFK5Ghoh3qN i/xT1QDJNWFqvb2Tt7wh2p6MWVTv0F0ltYbprp1AHMeRzFTrT9zdpctWo bkBcSFtfXlWE2NbjSqIENDN2AdsTPsxc6lNb8loZCIdWmYR9sXaH+IQ+X Mnld2jf5hr2uq/jq79GeKG0BH3tuLHLmKPJbgb3wBx2PBYwdLPwHQJS9x Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="429210054" X-IronPort-AV: E=Sophos;i="6.01,205,1684825200"; d="scan'208";a="429210054" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 03:47:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10770"; a="835990500" X-IronPort-AV: E=Sophos;i="6.01,205,1684825200"; d="scan'208";a="835990500" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP; 14 Jul 2023 03:47:22 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qKGKX-002dBW-0w; Fri, 14 Jul 2023 13:47:21 +0300 Date: Fri, 14 Jul 2023 13:47:21 +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 Subject: Re: [v2 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20230713125706.2884502-1-glider@google.com> <20230713125706.2884502-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-20230714_034730_316312_DAE8D2C7 X-CRM114-Status: GOOD ( 32.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 Fri, Jul 14, 2023 at 11:25:41AM +0200, Alexander Potapenko wrote: ... > > Not sure why fls() / BIT() can't be used directly instead of these functions, > > but okay, they are not too ugly. > > They can't be used directly because 128 maps to 0, but I can sure > simplify them a bit. Right, that's why I'm okay with the current implementation. But if you want to rewrite, up to you. ... > > > + if (pos % 2 == 0) > > > > Would be better to keep this aligned with above? > > > > if (pos % 2) > > ... > > else > > ... > > It would, but i % 2 above didn't survive the rewrite, so I assume it > is fine to keep pos % 2 == 0 as is. Not big deal, but less characters improve the brain process, so if (pos % 2) kinda quicker to read and understand in my opinion. ... > > > +EXPORT_SYMBOL(ea0_storage_size); > > > > Btw, can we go to the namespaced export from day 1? > > Am I getting it right that I just need to change EXPORT_SYMBOL to > EXPORT_SYMBOL_NS and import the namespace in > arch/arm64/mm/test_mtecomp.c? > I.e. MODULE_IMPORT_NS is not needed in mteswap_comp.c, because it is > linked into the kernel? I think you always need to include MODULE_IMPORT_NS for the sake of robustness of the code. ... > > > + if (sizes[i] > largest) { > > > + largest = sizes[i]; > > > + largest_idx = i; > > > + } > > > > (alas max_array() can't be used here) > There's no max_array() in the kernel, am I missing something? There will be (via ASoC tree and maybe IIO tree later on) in v6.6-rc1, but as I think it can't be used anyway because you need the index of the value as well. ... > > > +void ea0_release_handle(u64 handle) > > > +{ > > > + void *storage = ea0_storage(handle); > > > + int size = ea0_storage_size(handle); > > > + struct kmem_cache *c; > > > > > + if (!handle || !storage) > > > + return; > > > > You use handle before this check. Haven't you run static analysers? > > Sparse doesn't report anything in these files, are there any > alternatives adopted in the kernel? > > Note that handle is not dereferenced above, so there's no error per se. Even if it's a simple pointer arithmetics, the storage might (theoretically?) have a dangling pointer, no? > Yet (as pointed out below) these checks are redundant, so I'll remove > some of them. ... > > > + > > > > Unneeded blank line. > > I think there's no agreement on this in the kernel code, but my > version is more popular: > > $ git grep -B2 '^module_init(' | grep '\-}' -A2 | grep module_init | wc > 2688 2707 164023 > $ git grep -B2 '^module_init(' | grep '\-}' -A1 | grep module_init | wc > 505 523 30989 Even though, there is no need for this blank line. And note, for better argument, compare this for the new code added let's say for the past 2 years. I believe numbers will tend to my variant. I.o.w. you need to count on trends and not only on frequencies. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel