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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 05D5AC4363A for ; Thu, 29 Oct 2020 16:50:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39A9620838 for ; Thu, 29 Oct 2020 16:50:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qc8xa9Jh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39A9620838 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 58F936B0062; Thu, 29 Oct 2020 12:50:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 540386B006C; Thu, 29 Oct 2020 12:50:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42ED96B006E; Thu, 29 Oct 2020 12:50:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0048.hostedemail.com [216.40.44.48]) by kanga.kvack.org (Postfix) with ESMTP id 16E4D6B0062 for ; Thu, 29 Oct 2020 12:50:27 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A327C1EE6 for ; Thu, 29 Oct 2020 16:50:26 +0000 (UTC) X-FDA: 77425551252.26.front94_18085732728f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 8686D1804B640 for ; Thu, 29 Oct 2020 16:50:26 +0000 (UTC) X-HE-Tag: front94_18085732728f X-Filterd-Recvd-Size: 5980 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 29 Oct 2020 16:50:25 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id o3so2805089pgr.11 for ; Thu, 29 Oct 2020 09:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cv4+7kQkXt9yP5NUmOCSvou0pMNFr/3DXVTAN8b/WEM=; b=qc8xa9Jh2cxQTu85posvdCUXHcib4h8McXwY33UoEM9VfJXZHpj/WlpziCO5xhl43Y M8P4fC8eostSJrpRNf2t5gjHMBYdyJJEQE2bgP+1qYA5o7qrhHj9+vOn2JXQxMWzQN2j 1MZdzFF4jynxe0Gq3ozgtBeI/Dt6G0AjfQ3498iTUnFwSwzqDT0ngg0fdbf3zs5mfNaj v+SPH+n3zwEzjm2HCY+E1R+bPvQCYUDLmE5SbBMgF5+KsJn9QujEWnZSQOy5XEbDIGLI O0UTO74cdV1fvKKVuizRoUGGKCzLZwfN+3nJy23j70bJE5xSzPzfAkyYowGAYMslvOKH gaHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cv4+7kQkXt9yP5NUmOCSvou0pMNFr/3DXVTAN8b/WEM=; b=lmOHFu9xpGIKQvDJNiGOqeKMbZWs0ek/t261kN5MqU/m2YpjDCblrc3Q8aBS7rZFfn QtiwPuLhQBsRvtjiDHGxCS1cP9cT+Gz4erJcUnfkB5sTCu/gMJAsU5lON5utdXA5D6jn 8ZeRn22eHpB8Non9U1rokZ6A+i724LACGK37X2ZscOWD6J39goRTIsTFSADH2mtoCVCO qVKQSBRt8a5W/2X2RtOanH8DW22M+MKFEWtWUZ9GYfol+I3KQzk9TN3yBQp8HATdNpoK sLU4m2ZFyuHc5lpb8aC2MrOdCqaQoLGakL/8R/eVUeF99sYFwKvjMJJwLC0QSgZaiu2P hvKw== X-Gm-Message-State: AOAM5311i4i2rxlMNRJTfbt5yZKwScrsPaRgtG+oAflVQJzUHgSpBnjb SErPNRsujV5t0YEX2wLCyUFwyGETJ1lpTOagXVStBQ== X-Google-Smtp-Source: ABdhPJxTU/rzp1TefKplfy18pqc1JkvBEZnJsfu/L9uepwZvlwmx4AKDOFVR2PVE6mzQaGOzgOlQXDe1stDkXDsD0Uw= X-Received: by 2002:a62:7695:0:b029:152:3ddd:24a3 with SMTP id r143-20020a6276950000b02901523ddd24a3mr4914942pfc.2.1603990224897; Thu, 29 Oct 2020 09:50:24 -0700 (PDT) MIME-Version: 1.0 References: <94dfda607f7f7a28a5df9ee68703922aa9a52a1e.1602535397.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Thu, 29 Oct 2020 17:50:13 +0100 Message-ID: Subject: Re: [PATCH v5 02/40] arm64: mte: Add in-kernel MTE helpers To: Dmitry Vyukov , Catalin Marinas , Vincenzo Frascino Cc: Will Deacon , kasan-dev , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Andrew Morton , Linux ARM , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 28, 2020 at 12:28 PM Dmitry Vyukov wrote: > [...] > > +void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > +{ > > + void *ptr = addr; > > + > > + if ((!system_supports_mte()) || (size == 0)) > > + return addr; > > + > > + /* Make sure that size is MTE granule aligned. */ > > + WARN_ON(size & (MTE_GRANULE_SIZE - 1)); > > + > > + /* Make sure that the address is MTE granule aligned. */ > > + WARN_ON((u64)addr & (MTE_GRANULE_SIZE - 1)); > > + > > + tag = 0xF0 | tag; > > + ptr = (void *)__tag_set(ptr, tag); > > + > > + mte_assign_mem_tag_range(ptr, size); > > This function will be called on production hot paths. I think it makes > sense to shave off some overheads here. > > The additional debug checks may be useful, so maybe we need an > additional debug mode (debug of MTE/KASAN itself)? > > Do we ever call this when !system_supports_mte()? I think we wanted to > have static_if's higher up the stack. Having additional checks > scattered across lower-level functions is overhead for every > malloc/free. > > Looking at how this is called from KASAN code. > KASAN code already ensures addr/size are properly aligned. I think we > should either remove the duplicate alignment checks, or do them only > in the additional debugging mode. > Does KASAN also ensure proper tag value (0xF0 mask)? > > KASAN wrapper is inlined in this patch: > https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/3699 > but here we still have 2 non-inlined calls. The > mte_assign_mem_tag_range is kinda inherent since it's in .S. But then > I think this wrapper should be inlinable. > > Also, can we move mte_assign_mem_tag_range into inline asm in the > header? This would avoid register spills around the call in > malloc/free. > > The asm code seems to do the rounding of the size up at no additional > cost (checks remaining size > 0, right?). I think it makes sense to > document that as the contract and remove the additional round_up(size, > KASAN_GRANULE_SIZE) in KASAN code. These are all valid concerns. It would be great to have inline asm mte_assign_mem_tag_range() implementation. We can also call it directly from KASAN code without all these additional checks. Perhaps it makes sense to include this change into the other series that adds the production mode. And then squash if we decide to put both changes into a single one. Vincenzo, could you write a patch that adds inline asm mte_assign_mem_tag_range() implementation?