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 34D29C4332F for ; Fri, 15 Dec 2023 16:36:16 +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=ob/RZN3AKuq2orm3dLK0gG7w/86EW4BSXkf3ce0VT1g=; b=oqWgB9hlrajmZd en6DhgE2TC5Q8Rd76DorMr7k8xOvo2JgxZxM0L87UcJXUG9itfdp5QYA19sZddFdIxjyHMFmocgoY ohATVMhNwZS2UuHTdceN1WPowXTFUDCip4ZOwsy11M+X1EdEZEZQGzUVd21d7RwKS2tynnjZ//Chb egT75ReCdLG3dgIBA9/0NVMyftbZz3FTFFZapraLLfytXM6wDdIss6cQ82sYbml8w8BMEQNDt/3AL R6hW+k7d6qwSY/tXRQF/QeFGgo2Gb9Y3+ppPCFpmJHjeTyup88+aotc7x19DD7Q/emEYhgTN2MlJ7 WXDrWSbnlGMTaKgPr8tA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rEBAC-003tH5-1e; Fri, 15 Dec 2023 16:35:48 +0000 Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rEBA8-003tGS-1F for linux-arm-kernel@lists.infradead.org; Fri, 15 Dec 2023 16:35:46 +0000 Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-db3a09e96daso675951276.3 for ; Fri, 15 Dec 2023 08:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702658143; x=1703262943; darn=lists.infradead.org; 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=SPYTzxprRPq6a6Oexpdp5sY7hxU8CR4LHFMOMzNgC9E=; b=RyFy3RSiakBrWZEypAYfqSUyHCHmeu1dsnBNCRHp31u6/5nYWYrJL4Bz4WSxKiMnHs 3u1oPnT/IVUrmuUYKxJVkr+HV46GFwF1JWQUujMNb4CHSGu/sONnCFgOt0HcV/H8OcGA GdeY1oB2xdKyNFPfNUBqZjk/G7I3RncNBKRuMazyKb0P6YizGxckOiWZ7VqQeGaN9h77 qV6UKgU3fzBtnpTqi/gog1kLYraQAz/fdAW33FXrMksGdsSlwD/rNC+0RJCu8Qb7UNPj JbVNcPc9ncRXw6Ih5ZDKuX7Skl1I3WbJ6fAWDlkhNDbwJ8aQ38tg34dQWo0tyerZ7kCb S6vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702658143; x=1703262943; 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=SPYTzxprRPq6a6Oexpdp5sY7hxU8CR4LHFMOMzNgC9E=; b=qUWKo46Xw0IS3NhT/I0DTB7M/zvL1DNjo86bHWP8epcRM1NPBwsc805yajl/iL188w KtSBrhDw3l4JYX/X8nyyEphLysi2rebP5aVF09s1tCCvXyhRHMHuZH8prW/+ei/W0qfe 27RBJIb+u3R62luq6ZDhKjgvgEJFWgonOSRojMXCU1mQ6pL7CHL3RaUpIYOLS9X4Q/tZ +nf1mnlz+sqnPjC4r5vJJ77bi+wj1+f7I/3UYsp4izTmBk+FJ68tA+LJG3FwzhxgWuTa CK1kJgsTxBpPnVcidTEArMTiaEnvlxf+6KgHo4K87xlxxfwSFZ/59NCo+8lvBo4E2asT eR+Q== X-Gm-Message-State: AOJu0YwE1jl+5SIM9cDcxkWMkF92vU54waxLBj+N2EVB5ZRmsmpz462Q TE7wmf+gb7lez/e0VbLlRZ+L89gr4WU= X-Google-Smtp-Source: AGHT+IHk5kjZ6JiXVmBStFA0vpOtGbFwSGvlFJvE5y1XqTuVq3b2uH9McH3sARZDy5b+1LXYshpCdw== X-Received: by 2002:a25:ef4c:0:b0:dbc:d4c0:82ef with SMTP id w12-20020a25ef4c000000b00dbcd4c082efmr2815528ybm.92.1702658142904; Fri, 15 Dec 2023 08:35:42 -0800 (PST) Received: from localhost ([2601:344:8301:57f0:e177:373d:4717:ff6c]) by smtp.gmail.com with ESMTPSA id k15-20020a5b0a0f000000b00db54cf1383esm5504422ybq.10.2023.12.15.08.35.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 08:35:41 -0800 (PST) Date: Fri, 15 Dec 2023 08:35:40 -0800 From: Yury Norov To: Alexander Potapenko Cc: catalin.marinas@arm.com, will@kernel.org, pcc@google.com, andreyknvl@gmail.com, andriy.shevchenko@linux.intel.com, aleksander.lobakin@intel.com, linux@rasmusvillemoes.dk, alexandru.elisei@arm.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 v10-mte 4/7] arm64: mte: implement CONFIG_ARM64_MTE_COMP Message-ID: References: <20231214110639.2294687-1-glider@google.com> <20231214110639.2294687-5-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-20231215_083544_430228_C73F3920 X-CRM114-Status: GOOD ( 18.59 ) 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, Dec 15, 2023 at 04:19:27PM +0100, Alexander Potapenko wrote: > > > > That looks weird... You're casting address of a 'data' to a bitmap > > instead of 'data'. At the 1st glance it makes little sense because > > 'data' is passed as parameter. Moreover, in mte_is_compressed() > > you pass 'data', not '&data'. Can you please comment on your > > intention? > > Although `data` is a void*, it actually contains 64 bits of compressed > data, so we pass &data to mte_bitmap_read() to read its contents. > Perhaps I'd better make `data` an unsigned long to avoid confusion. Still don't understand. Let's consider this example: yury:linux$ cat tst.c #include unsigned long data[1] = {0xabc}; void foo(unsigned long *data) { printf("foo: *data\t%lx\n", (unsigned long)*data); printf("foo: data\t%lx\n", (unsigned long)data); printf("foo: &data\t%lx\n", (unsigned long)&data); } void bar(unsigned long *data) { volatile unsigned long x[100]; printf("bar: *data\t%lx\n", (unsigned long)*data); printf("bar: data\t%lx\n", (unsigned long)data); printf("bar: &data\t%lx\n", (unsigned long)&data); } int main(int argc, char *argv[]) { foo(data); bar(data); printf("main: *data\t%lx\n", (unsigned long)*data); printf("main: data\t%lx\n", (unsigned long)data); printf("main: &data\t%lx\n", (unsigned long)&data); return 0; } yury:linux$ gcc tst.c -O0 yury:linux$ ./a.out foo: *data abc foo: data 555b2cef9010 foo: &data 7fff39d6e5f8 bar: *data abc bar: data 555b2cef9010 bar: &data 7fff39d6e2c8 main: *data abc main: data 555b2cef9010 main: &data 555b2cef9010 Data and *data have their meaning across scope boundary: a pointer and a content. The &data is pretty much a random number - a pointer to somewhere on a function's stack. Isn't? > > > + max_ranges = MTE_MAX_RANGES; > > > + /* Skip the leading bit indicating the inline case. */ > > > + mte_bitmap_read(bitmap, &bit_pos, 1); > > > + largest_idx = > > > + mte_bitmap_read(bitmap, &bit_pos, MTE_BITS_PER_LARGEST_IDX); > > > > Nit: really no need to split the line - we're OK with 100-chars per > > line now. > > That's true, but I am relying on clang-format here (maybe we should > extend the limit in .clang-format?) If clang-format hurts readability, don't use it. Thanks, Yury _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel