Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp368084pxa; Thu, 27 Aug 2020 04:48:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCYvvy00ljc+ag9hulOpXufzwfaWe62qwKplYjIm61nu8Q2ig7ZPwTzD/Mnu6wS3RpjV+n X-Received: by 2002:a50:954d:: with SMTP id v13mr19823138eda.337.1598528886648; Thu, 27 Aug 2020 04:48:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598528886; cv=none; d=google.com; s=arc-20160816; b=dlFsoU09TEz0+5gkhoqcLIHT5n+khoT1i8+XDRMOK4//zxSmauVL2wOJgbClpAGK0X ZXTLQGJHmLEYg/8MofDjLg6TS8ZIf0BmP15mmg8K550um+sV45Ea4fQH6KY9VGD2TI+U LOGzZ0oKdKfy6MKOw0rBAxO+cCkf2OCgw86RkehYraHXoK0bu9hjh6VUUTcNYCjDHUJY bUVJg/dok7PegWMEW2ORjgDDp8YkmJXwtwVhAwjd4so84YksG/IxBa0r0lgoKM1ssFiG tSMHxG1dCUY1M6AksK/OPg8pRAPdWQ15zFy3/Ll66RdvDOUg7+XZP3KJ5y3ph4CJ2Auk np1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=eEvgxttD4L8zQsAhVcujlN+9o6rbvipRujLLwPmGsFg=; b=0w/dYvxbCOlnh1BJXUj6Y14ddFK38Y3GYNfs2lKVq0kp5inU2jIAmtKX/M+YWKUBlD u6dVVBu5VkqulMK8Mr9l33EELhoOk5/iyQFWpNdb4GxIlkExktvBTHcJ/9nEX27JqcEL vG2L0ABqx/7Y/7v3dOulYbXWuicwSgDkHvNPwdCWfWmC739N1PLVKUD05wwoRDleXdcn byimaBm7/0ggkclCLsVKoksMIEB2ixTlwSPd1A2n+1ee4bNePffIh/mKtbhRzDcvvGvL zJ5WSyWCraPC0+ezkK6Lr/rYn5GrMoLkqMmo9LFWo82W1FH8PLetErbU+9yMeAkRYCIY 8mog== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b4si1272525edr.513.2020.08.27.04.47.43; Thu, 27 Aug 2020 04:48:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728885AbgH0Lqr (ORCPT + 99 others); Thu, 27 Aug 2020 07:46:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:49446 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728533AbgH0Lf1 (ORCPT ); Thu, 27 Aug 2020 07:35:27 -0400 Received: from gaia (unknown [46.69.195.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 39DEE22BF3; Thu, 27 Aug 2020 11:10:31 +0000 (UTC) Date: Thu, 27 Aug 2020 12:10:28 +0100 From: Catalin Marinas To: Vincenzo Frascino Cc: Andrey Konovalov , Dmitry Vyukov , kasan-dev@googlegroups.com, Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Will Deacon , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers Message-ID: <20200827111027.GJ29264@gaia> References: <2cf260bdc20793419e32240d2a3e692b0adf1f80.1597425745.git.andreyknvl@google.com> <20200827093808.GB29264@gaia> <588f3812-c9d0-8dbe-fce2-1ea89f558bd2@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <588f3812-c9d0-8dbe-fce2-1ea89f558bd2@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 27, 2020 at 11:31:56AM +0100, Vincenzo Frascino wrote: > On 8/27/20 10:38 AM, Catalin Marinas wrote: > > On Fri, Aug 14, 2020 at 07:27:02PM +0200, Andrey Konovalov wrote: > >> +void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > >> +{ > >> + void *ptr = addr; > >> + > >> + if ((!system_supports_mte()) || (size == 0)) > >> + return addr; > >> + > >> + tag = 0xF0 | (tag & 0xF); > >> + ptr = (void *)__tag_set(ptr, tag); > >> + size = ALIGN(size, MTE_GRANULE_SIZE); > > > > I think aligning the size is dangerous. Can we instead turn it into a > > WARN_ON if not already aligned? At a quick look, the callers of > > kasan_{un,}poison_memory() already align the size. > > The size here is used only for tagging purposes and if we want to tag a > subgranule amount of memory we end up tagging the granule anyway. Why do you > think it can be dangerous? In principle, I don't like expanding the size unless you are an allocator. Since this code doesn't control the placement of the object it was given, a warn seems more appropriate. > >> +/* > >> + * Assign allocation tags for a region of memory based on the pointer tag > >> + * x0 - source pointer > >> + * x1 - size > >> + * > >> + * Note: size is expected to be MTE_GRANULE_SIZE aligned > >> + */ > >> +SYM_FUNC_START(mte_assign_mem_tag_range) > >> + /* if (src == NULL) return; */ > >> + cbz x0, 2f > >> + /* if (size == 0) return; */ > > > > You could skip the cbz here and just document that the size should be > > non-zero and aligned. The caller already takes care of this check. > > I would prefer to keep the check here, unless there is a valid reason, since > allocate(0) is a viable option hence tag(x, 0) should be as well. The caller > takes care of it in one place, today, but I do not know where the API will be > used in future. That's why I said just document it in the comment above the function. The check is also insufficient if the size is not aligned to an MTE granule, so it's not really consistent. This function should end with a subs followed by b.gt as cbnz will get stuck in a loop for unaligned size. -- Catalin