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 22870C001DE for ; Thu, 13 Jul 2023 19:27:54 +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=xVIcTloQwIQN4shJ8nQVnd78S6uUqLE32LvipQw5/dA=; b=daeGbKtdvvStpz YkXUuwj3h/hIBd8dTGm1wehGeVQlw6V1Yof+LsWdsxQi2+qczzDEfrDTVYX2dNOR+aIfOX51bltHI yrWqIRZlApyqJ7HTtbj6Dv2RXR+e0+qa3qLwy2QlpRsDMXKEksf0TGvwyfXElJE0fuXen3VfIdVVV 0qA3oVwYSdqtqiD80wKBVxTigz8xXf6RH3tue550LGZCkwdI9fnCsS+gMSpyltyUmxAZDEuCq+dM2 MRkCm/NSXvKebwZf8LdRs5luvazDR8W7/9gKwsvZzRRaJm9nxHWvoziC28dFEWytM2Mjshk8MlQFu 1E7y1vK7nl5JP87QtJTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qK1yF-004E9c-1X; Thu, 13 Jul 2023 19:27:23 +0000 Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qK1yB-004E8k-2K for linux-arm-kernel@lists.infradead.org; Thu, 13 Jul 2023 19:27:21 +0000 Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-53482b44007so735315a12.2 for ; Thu, 13 Jul 2023 12:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689276438; x=1691868438; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PMBXi7c6FE7ClrpCTx65QR6NnLayYlC4d8VJ2B2i1Y4=; b=OR6scnI6d1gId2kANm6EChHSLrcJhjxR8gzThM3xvkGjmF8tMvgtMpdIIvRlMOh6lx oZbs7JoWRaiyy13+MgXxdQJH8M86jySGMJ+Bnpr6YC9RnFe97HKB47HswSjmdoOi7uiO GDsIP1C+QTAYn+COe3S8XM5/Y7GS9l0TbKPniKThBNa1heqUYAzjz0XQQqX/8PMdv0Ex pDUiyqjoaq3VfIMDnV1FYOB4FdihaPLsx6Ugh6RZfPKFFByCpUv0TWNaUkDSkcNGrTqn Yca9Qts7LcXdrmeb/hTfaF56PrsRotX5U6b67/rjQNaXDdueCBcVBK2JnaeLX90O8eoI cmsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689276438; x=1691868438; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PMBXi7c6FE7ClrpCTx65QR6NnLayYlC4d8VJ2B2i1Y4=; b=MbnKkplyAQfqo32DiZ1Wlfy05XCXr9FPVx9PZJ9KL2euV/kPJWHRlTDlOG3pjKIRXV ch/oUZ4bYSkEP4NPpjxR/8Gil3KMI3+wr0gZRWOVxGF4+Dxd5titvUVHzPFCVjnEh5su Iz2Pd7/yz2HXrT/rnnqFfaAfQW59QhvSX62xYhI0ggfY0XdvLFZudDq6WbDkfI7/YcX+ L+3yQlZlIS2tlOCiG2qQxHlknzCyWPfsi84qS2KDJFmmLPGhzuhcBCNSefzu5eMWdF4g eVfVT+OsbyWGPkyhB+49SxnrYvboWJIc6Yn1mUPskzu1TPBXlRFi+Ggo/J5lIc76IMXX bJzw== X-Gm-Message-State: ABy/qLbv8OHdXhKwioCR0iHg73OddKzlyXPy9PYOTW+KOdOzPEJVMn+0 bl3ua7Z3YbBHipfUE2eHHXFL0U7dhd6flQ== X-Google-Smtp-Source: APBJJlGdjoTOFysniZVkEhzi/MdZNUz4HCYELkeAVVSlVvLoDjn1esz9d3WONIhaXdww0n96cuz82g== X-Received: by 2002:a17:90a:5997:b0:263:f75b:c33f with SMTP id l23-20020a17090a599700b00263f75bc33fmr1659208pji.45.1689276437836; Thu, 13 Jul 2023 12:27:17 -0700 (PDT) Received: from localhost ([216.228.127.131]) by smtp.gmail.com with ESMTPSA id 20-20020a17090a199400b002639c4f81cesm13264023pji.3.2023.07.13.12.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jul 2023 12:27:17 -0700 (PDT) Date: Thu, 13 Jul 2023 12:27:15 -0700 From: Yury Norov To: Andy Shevchenko Cc: Alexander Potapenko , catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, linux@rasmusvillemoes.dk, 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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230713_122719_788882_5CDFF0CA X-CRM114-Status: GOOD ( 13.36 ) 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 > > + bitmap_set_value_unaligned((unsigned long *)buf, largest_idx, > > + bit_pos, 4); > > > + bitmap_set_value_unaligned((unsigned long *)buf, largest_idx, > > + bit_pos, 6); > > > + bitmap_set_value_unaligned((unsigned long *)buf, tags[i], > > + bit_pos, 4); > > > + bitmap_set_value_unaligned((unsigned long *)buf, 0, bit_pos, 4); > > > + bitmap_set_value_unaligned((unsigned long *)buf, sizes[i], > > + bit_pos, 7); > > > + largest_idx = bitmap_get_value_unaligned((unsigned long *)buf, bit_pos, > > + l_bits); > > > + r_tags[i] = bitmap_get_value_unaligned((unsigned long *)buf, > > + bit_pos, 4); > > > + r_sizes[i] = bitmap_get_value_unaligned((unsigned long *)buf, > > + bit_pos, 7); > > These castings is a red flag. bitmap API shouldn't be used like this. Something > is not okay here. Big-endian arches are not OK. Out-of-boundary access is not OK when the buf is not exactly a multiple of words. > > +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? This approach is called 'defensive programming' as I learned from previous iteration. Another interesting thing is that the only caller of the function in patch #5 explicitly checks the handle for NULL, so we're surely double-defensed here. +void _mte_free_saved_tags(void *storage) +{ + unsigned long handle = xa_to_value(storage); + int size; + + if (!handle) + return; + size = ea0_storage_size(handle); + ea0_release_handle(handle); +} _mte_free_saved_tags() calculates size, but doesn't use it in any form, just to calculate it again in callee... Thanks, Yury _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel