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 X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D712C433E1 for ; Thu, 27 Aug 2020 11:24:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DE3A922CBB for ; Thu, 27 Aug 2020 11:24:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lnsiBkUd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE3A922CBB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IJmi/wA3y8xHk4bGws2W4evb+AJs0TsSUrpuwJWpKjc=; b=lnsiBkUdKY5OA2478gJzp5wmq SLC+T6+3l7FhIJEeaVfNWhWc4lU/vsaz0cP6UcJggEd2oJbbxWPSnTuqwq4jamY+YBFARU5jdTzYw qHwAMMgSOlZnM7GEAmX1jsew5hM40oggIxb3NLaiKK5fLMhxNdTBLiSNBJaQI4MPImpww6SJM8gi/ vhEnIpyp4u6Lnzd2RojUEvFtHMh+zOkNoaUo6LfgCl4F2v6WZfpR7TaaMysKwgwA43sBizHxUHtKa JgnU7nJ0IVoiGwPZynZPWDvG/faWNeo5PEJ9KEwLYFGenyferT+AcDlG2VkN2CJ5/DOhmUUJIsvsC 8Cfs9qlkg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBFzX-0005Wn-OL; Thu, 27 Aug 2020 11:22:51 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kBFzU-0005Vy-QM for linux-arm-kernel@lists.infradead.org; Thu, 27 Aug 2020 11:22:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9DFD211B3; Thu, 27 Aug 2020 04:22:47 -0700 (PDT) Received: from [192.168.1.190] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 84D723F68F; Thu, 27 Aug 2020 04:22:45 -0700 (PDT) Subject: Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers To: Catalin Marinas References: <2cf260bdc20793419e32240d2a3e692b0adf1f80.1597425745.git.andreyknvl@google.com> <20200827093808.GB29264@gaia> <588f3812-c9d0-8dbe-fce2-1ea89f558bd2@arm.com> <20200827111027.GJ29264@gaia> From: Vincenzo Frascino Message-ID: <921c4ed0-b5b5-bc01-5418-c52d80f1af59@arm.com> Date: Thu, 27 Aug 2020 12:24:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200827111027.GJ29264@gaia> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200827_072248_949390_0D33199C X-CRM114-Status: GOOD ( 27.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, Marco Elver , Elena Petrova , Andrey Konovalov , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Potapenko , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Dmitry Vyukov 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 8/27/20 12:10 PM, Catalin Marinas wrote: > 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. > That's a good point. Ok, we can change this in a warning. >>>> +/* >>>> + * 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. > That's correct. Thanks for pointing this out. I currently used it only in places where the caller took care to align the size. But in future we cannot know hence we should harden the function with what you are suggesting. -- Regards, Vincenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel