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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 0CADDC433E0 for ; Tue, 2 Feb 2021 18:08:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3F1F64F99 for ; Tue, 2 Feb 2021 18:08:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238051AbhBBSH4 (ORCPT ); Tue, 2 Feb 2021 13:07:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238015AbhBBSFb (ORCPT ); Tue, 2 Feb 2021 13:05:31 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9F40C06174A for ; Tue, 2 Feb 2021 10:04:50 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id e9so2905779pjj.0 for ; Tue, 02 Feb 2021 10:04:50 -0800 (PST) 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=bmHbrW4wHvIdfjHfeZ3EaQjyVR5RRbKrvsyfN94JInNi9Cn/Ji526G1EpUl55uf6bH m13PPwd6OvYcUlrgA/4HEDMO743f3REGWb/rhRNZx0Aufi7rf6VXi+aZ5OuZiITpO1L9 7lT7EPS+7AOGkhtIhtsHxq98UcXFLblKenrLQqqrlr1B45IRYPlDXDDJTwOVMJa/BGKP yBbfOe7hVFgzgcoQsCfXkRDgtuvOBds9FsxJP+7V6ungIy4DVbkpiRQsI3TRPgliGdW1 DaaAKLFjlCfHCv7Q4+Qh5yw17ptKBNaw6Pl8Q50l3Y1UPSOqxUiL72dpSLziTfMOEIlk 6U5Q== 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=D60wiNEaQHL7en/rJnKgouwXHxuUCFYBTilfrniXKaGPwNaUbmhH3V4j+c18YDh+aB 3hVBTloNRwvx9t7d6KYWnrq5r9IHRnrM1tSojsRWW36eQ30WTiV2XJ4QL2cC3F75bJoD 7MnrqXAtrVPH68Mcox1wc5blVk2dL+BagTjCvqLzJ9BTKJYYpuu9uWuEyECOnz8Daj78 EIPbYl9q01Z0OnZu0DYiD+0VE9GSpT7zigjyglHBzfA4fXJBbgqJPlZqS9J1Ww3s4Bzt 60QlO7bbBS1d539Tx3oXHIlegWSsKpYM/F9wEDgFCnKKd8HEFqYTSswSBuZuF7heP3SJ +ZPA== X-Gm-Message-State: AOAM531Hs2jYR9P3Sj+5XKaHm5D2yTX8Kz3jbe3ytOlmizcBzyNLjsJG FTTpD5rW+1EigLyj9vf7JFSobAlPxOJft8y1VlfBew== X-Google-Smtp-Source: ABdhPJzk53kiwjHoUAN5T37N7cq5l6z6TqzmjhMRUYbQYZsukvhrqYwA9meKTYnDVYMved0hS9LJFa4X1pkaHapfvQc= X-Received: by 2002:a17:90b:30d4:: with SMTP id hi20mr5325944pjb.41.1612289090058; Tue, 02 Feb 2021 10:04:50 -0800 (PST) MIME-Version: 1.0 References: <17d6bef698d193f5fe0d8baee0e232a351e23a32.1612208222.git.andreyknvl@google.com> <20210202154200.GC26895@gaia> In-Reply-To: <20210202154200.GC26895@gaia> From: Andrey Konovalov Date: Tue, 2 Feb 2021 19:04:38 +0100 Message-ID: Subject: Re: [PATCH 10/12] arm64: kasan: simplify and inline MTE functions To: Catalin Marinas Cc: Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Marco Elver , Andrew Morton , Will Deacon , Andrey Ryabinin , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , kasan-dev , Linux ARM , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2021 at 4:42 PM Catalin Marinas wrote: > > On Mon, Feb 01, 2021 at 08:43:34PM +0100, Andrey Konovalov wrote: > > +/* > > + * Assign allocation tags for a region of memory based on the pointer tag. > > + * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and > > + * size must be non-zero and MTE_GRANULE_SIZE aligned. > > + */ > > OK, so we rely on the caller to sanity-check the range. Fine by me but I > can see (un)poison_range() only doing this for the size. Do we guarantee > that the start address is aligned? See the previous patch in the series. kasan_poison() checks and warns on both unaligned addr and size. kasan_unpoison() checks addr and rounds up size. > > +static __always_inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > +{ > > + u64 curr, end; > > + > > + if (!size) > > + return; > > + > > + curr = (u64)__tag_set(addr, tag); > > + end = curr + size; > > + > > + do { > > + /* > > + * 'asm volatile' is required to prevent the compiler to move > > + * the statement outside of the loop. > > + */ > > + asm volatile(__MTE_PREAMBLE "stg %0, [%0]" > > + : > > + : "r" (curr) > > + : "memory"); > > + > > + curr += MTE_GRANULE_SIZE; > > + } while (curr != end); > > +} > > > > void mte_enable_kernel_sync(void); > > void mte_enable_kernel_async(void); > > @@ -47,10 +95,12 @@ static inline u8 mte_get_mem_tag(void *addr) > > { > > return 0xFF; > > } > > + > > static inline u8 mte_get_random_tag(void) > > { > > return 0xFF; > > } > > + > > static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > This function used to return a pointer and that's what the dummy static > inline does here. However, the new mte_set_mem_tag_range() doesn't > return anything. We should have consistency between the two (the new > static void definition is fine by me). Right, forgot to update the empty function definition. Will do in v2. > > Otherwise the patch looks fine. > > Reviewed-by: Catalin Marinas Thanks! 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=-23.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 B804DC433E0 for ; Tue, 2 Feb 2021 18:04:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C21E64F96 for ; Tue, 2 Feb 2021 18:04:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C21E64F96 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 C5BF76B0071; Tue, 2 Feb 2021 13:04:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE5116B0072; Tue, 2 Feb 2021 13:04:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD3AA6B0073; Tue, 2 Feb 2021 13:04:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 92E2B6B0071 for ; Tue, 2 Feb 2021 13:04:52 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4DF82180AD804 for ; Tue, 2 Feb 2021 18:04:52 +0000 (UTC) X-FDA: 77774103624.12.nose08_320d9fa275cc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 90FC91801EDCA for ; Tue, 2 Feb 2021 18:04:51 +0000 (UTC) X-HE-Tag: nose08_320d9fa275cc X-Filterd-Recvd-Size: 5563 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 18:04:51 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id d2so2888089pjs.4 for ; Tue, 02 Feb 2021 10:04:51 -0800 (PST) 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=bmHbrW4wHvIdfjHfeZ3EaQjyVR5RRbKrvsyfN94JInNi9Cn/Ji526G1EpUl55uf6bH m13PPwd6OvYcUlrgA/4HEDMO743f3REGWb/rhRNZx0Aufi7rf6VXi+aZ5OuZiITpO1L9 7lT7EPS+7AOGkhtIhtsHxq98UcXFLblKenrLQqqrlr1B45IRYPlDXDDJTwOVMJa/BGKP yBbfOe7hVFgzgcoQsCfXkRDgtuvOBds9FsxJP+7V6ungIy4DVbkpiRQsI3TRPgliGdW1 DaaAKLFjlCfHCv7Q4+Qh5yw17ptKBNaw6Pl8Q50l3Y1UPSOqxUiL72dpSLziTfMOEIlk 6U5Q== 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=d9xQtIQSobckL9UoJsczTS0hrBPczS7vjYwRvw9/YltQUf8SbHkhI89cCa9ppwvAJG lg2ONpZi4Hx0CjbjDWtU4w35LMflSQdb3WS9AREojwAh8kI5i1INIV1VzG8ae5cstHEA bTWSV4SF5xB127ILfy+Rp1YqmVauqkCdBVflN+UlRELcNejhlQyQPYIPkCcEeHw+U7oy eP746ip3aXEeGcs0+Xge4gh3eMnD2QkEAXbntCKnRdJyjIMiYx6h3LBjZnmlJwmDCECW m3kp8eOhHyhw1kncrfTKzEY++JwcjxkrSSmHs/YYh8YpVLgYDdyQxrLC3X/MLtfZxqM7 RGnw== X-Gm-Message-State: AOAM531xIVIP7QQQwAye7F0d1z8PPDLISSwMxzwv5RFiZ0QxznmPSFgb eqVkXL10UwO2NwUYsJ+QhrBlXUoJKn7NwRfjUN2uQQ== X-Google-Smtp-Source: ABdhPJzk53kiwjHoUAN5T37N7cq5l6z6TqzmjhMRUYbQYZsukvhrqYwA9meKTYnDVYMved0hS9LJFa4X1pkaHapfvQc= X-Received: by 2002:a17:90b:30d4:: with SMTP id hi20mr5325944pjb.41.1612289090058; Tue, 02 Feb 2021 10:04:50 -0800 (PST) MIME-Version: 1.0 References: <17d6bef698d193f5fe0d8baee0e232a351e23a32.1612208222.git.andreyknvl@google.com> <20210202154200.GC26895@gaia> In-Reply-To: <20210202154200.GC26895@gaia> From: Andrey Konovalov Date: Tue, 2 Feb 2021 19:04:38 +0100 Message-ID: Subject: Re: [PATCH 10/12] arm64: kasan: simplify and inline MTE functions To: Catalin Marinas Cc: Vincenzo Frascino , Dmitry Vyukov , Alexander Potapenko , Marco Elver , Andrew Morton , Will Deacon , Andrey Ryabinin , Peter Collingbourne , Evgenii Stepanov , Branislav Rankov , Kevin Brodsky , kasan-dev , Linux ARM , Linux Memory Management List , 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 Tue, Feb 2, 2021 at 4:42 PM Catalin Marinas wrote: > > On Mon, Feb 01, 2021 at 08:43:34PM +0100, Andrey Konovalov wrote: > > +/* > > + * Assign allocation tags for a region of memory based on the pointer tag. > > + * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and > > + * size must be non-zero and MTE_GRANULE_SIZE aligned. > > + */ > > OK, so we rely on the caller to sanity-check the range. Fine by me but I > can see (un)poison_range() only doing this for the size. Do we guarantee > that the start address is aligned? See the previous patch in the series. kasan_poison() checks and warns on both unaligned addr and size. kasan_unpoison() checks addr and rounds up size. > > +static __always_inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > +{ > > + u64 curr, end; > > + > > + if (!size) > > + return; > > + > > + curr = (u64)__tag_set(addr, tag); > > + end = curr + size; > > + > > + do { > > + /* > > + * 'asm volatile' is required to prevent the compiler to move > > + * the statement outside of the loop. > > + */ > > + asm volatile(__MTE_PREAMBLE "stg %0, [%0]" > > + : > > + : "r" (curr) > > + : "memory"); > > + > > + curr += MTE_GRANULE_SIZE; > > + } while (curr != end); > > +} > > > > void mte_enable_kernel_sync(void); > > void mte_enable_kernel_async(void); > > @@ -47,10 +95,12 @@ static inline u8 mte_get_mem_tag(void *addr) > > { > > return 0xFF; > > } > > + > > static inline u8 mte_get_random_tag(void) > > { > > return 0xFF; > > } > > + > > static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > This function used to return a pointer and that's what the dummy static > inline does here. However, the new mte_set_mem_tag_range() doesn't > return anything. We should have consistency between the two (the new > static void definition is fine by me). Right, forgot to update the empty function definition. Will do in v2. > > Otherwise the patch looks fine. > > Reviewed-by: Catalin Marinas Thanks! 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=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 15228C433DB for ; Tue, 2 Feb 2021 18:06:03 +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 CF1A864F97 for ; Tue, 2 Feb 2021 18:06:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF1A864F97 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z6V43kXPtVajt5zei5JTavt/fYMCCKaxP1dD23MxUSg=; b=1W81o3t5q9deLfJc7ARkeTxoZ gcXfOj+JVAwCt7S/3idhnKECAVdcWVGzMBzH2zlFwhUwZ6v+0JkmrQUYeJtd1nQ9vzFAnbn+OHIh1 4YIRe+3QHDdGwR/Kx1NJK6+3SiYBZAom8BXp9UcjqnGQ6i9M4Mo7sO7kOrg2p0HzozhGYSK7mVlxj 2M9DXlr98UeFOBjlC2TnwKVCQ2pBzQA3acLNaNo3mtUEZqhvayJgRAdUbv+8Frk3qqQJyb9dsJKzX LORBJEUmd9sOcWQgdU8bPOC2iYwFBxl3aksmbCUGj8PhvZS/lmwwl6BAJGV6yVM92/akeHR5SI29T 8D29Y+86A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l702p-0002aJ-Hb; Tue, 02 Feb 2021 18:04:55 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l702m-0002ZJ-On for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 18:04:54 +0000 Received: by mail-pl1-x62e.google.com with SMTP id a16so1299861plh.8 for ; Tue, 02 Feb 2021 10:04:51 -0800 (PST) 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=bmHbrW4wHvIdfjHfeZ3EaQjyVR5RRbKrvsyfN94JInNi9Cn/Ji526G1EpUl55uf6bH m13PPwd6OvYcUlrgA/4HEDMO743f3REGWb/rhRNZx0Aufi7rf6VXi+aZ5OuZiITpO1L9 7lT7EPS+7AOGkhtIhtsHxq98UcXFLblKenrLQqqrlr1B45IRYPlDXDDJTwOVMJa/BGKP yBbfOe7hVFgzgcoQsCfXkRDgtuvOBds9FsxJP+7V6ungIy4DVbkpiRQsI3TRPgliGdW1 DaaAKLFjlCfHCv7Q4+Qh5yw17ptKBNaw6Pl8Q50l3Y1UPSOqxUiL72dpSLziTfMOEIlk 6U5Q== 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=bkJ396ovGQTUsRhCdFoZILK6dCLPexHJ2EGZdWor+hw=; b=kV9mhm3gBVsfi2R62CxyyA3iDQ8zeYRTZ/LYreZ/EWXfI5mXeLxRexIGnk0dfQV8L8 iMqKOIsrkJkUnh4XuxpsX3Zjmlvpw4OoG1R6bcwmMGoeJ5fx0rDqEL383+SpI/0GIDYX v9KYo6mtzi/KNBK/bTmAYugr/ND/yVCA/q2s+s7O3Uoory3aN3rFTtSwJTOu1WUV4djm UVCadkMnUM8Qo//s4pkAPzbnIr+GmS0mQsRS+19FXS2c41O/VQJro8wBxhCzBaKM98Uf OGHAnv1UcME2yiIZIMj4spdZk2EmNnmLWhbGXzao4eJyNEw2EaMiPgrqwfMQaV804O7y cMPA== X-Gm-Message-State: AOAM532pfuegz3aWnx43//yETJHiWFvlD7m6hxXwIunsPDAO8YaFfffY 1rOjBDxH6sOLTf6+xZIdE/rLpRoX/OfAKa5AaIX+wA== X-Google-Smtp-Source: ABdhPJzk53kiwjHoUAN5T37N7cq5l6z6TqzmjhMRUYbQYZsukvhrqYwA9meKTYnDVYMved0hS9LJFa4X1pkaHapfvQc= X-Received: by 2002:a17:90b:30d4:: with SMTP id hi20mr5325944pjb.41.1612289090058; Tue, 02 Feb 2021 10:04:50 -0800 (PST) MIME-Version: 1.0 References: <17d6bef698d193f5fe0d8baee0e232a351e23a32.1612208222.git.andreyknvl@google.com> <20210202154200.GC26895@gaia> In-Reply-To: <20210202154200.GC26895@gaia> From: Andrey Konovalov Date: Tue, 2 Feb 2021 19:04:38 +0100 Message-ID: Subject: Re: [PATCH 10/12] arm64: kasan: simplify and inline MTE functions To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_130452_840747_34764596 X-CRM114-Status: GOOD ( 23.33 ) 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 , Marco Elver , Kevin Brodsky , Will Deacon , Branislav Rankov , kasan-dev , LKML , Linux Memory Management List , Alexander Potapenko , Evgenii Stepanov , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Peter Collingbourne , 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 Tue, Feb 2, 2021 at 4:42 PM Catalin Marinas wrote: > > On Mon, Feb 01, 2021 at 08:43:34PM +0100, Andrey Konovalov wrote: > > +/* > > + * Assign allocation tags for a region of memory based on the pointer tag. > > + * Note: The address must be non-NULL and MTE_GRANULE_SIZE aligned and > > + * size must be non-zero and MTE_GRANULE_SIZE aligned. > > + */ > > OK, so we rely on the caller to sanity-check the range. Fine by me but I > can see (un)poison_range() only doing this for the size. Do we guarantee > that the start address is aligned? See the previous patch in the series. kasan_poison() checks and warns on both unaligned addr and size. kasan_unpoison() checks addr and rounds up size. > > +static __always_inline void mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > +{ > > + u64 curr, end; > > + > > + if (!size) > > + return; > > + > > + curr = (u64)__tag_set(addr, tag); > > + end = curr + size; > > + > > + do { > > + /* > > + * 'asm volatile' is required to prevent the compiler to move > > + * the statement outside of the loop. > > + */ > > + asm volatile(__MTE_PREAMBLE "stg %0, [%0]" > > + : > > + : "r" (curr) > > + : "memory"); > > + > > + curr += MTE_GRANULE_SIZE; > > + } while (curr != end); > > +} > > > > void mte_enable_kernel_sync(void); > > void mte_enable_kernel_async(void); > > @@ -47,10 +95,12 @@ static inline u8 mte_get_mem_tag(void *addr) > > { > > return 0xFF; > > } > > + > > static inline u8 mte_get_random_tag(void) > > { > > return 0xFF; > > } > > + > > static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag) > > This function used to return a pointer and that's what the dummy static > inline does here. However, the new mte_set_mem_tag_range() doesn't > return anything. We should have consistency between the two (the new > static void definition is fine by me). Right, forgot to update the empty function definition. Will do in v2. > > Otherwise the patch looks fine. > > Reviewed-by: Catalin Marinas Thanks! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel