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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 46CE6C2B9F4 for ; Fri, 25 Jun 2021 16:54:05 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 077C861969 for ; Fri, 25 Jun 2021 16:54:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 077C861969 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc: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=sfe3Fyj+brb4E4jISRuOqnVs0LVwMXkxZ8hij4ThlVI=; b=ZA5+PNeyNINoLg Ys5theyBt6HY6utoHhTHWvcBubygvsFx+/dZ3PrLpXLxxJyFUs8HDqp8qB52QEEeP84gif+2qfOj0 VyzeDlXrGM1advJ/GKxmzuql3TUQUHZCZp3kua0tthWSRHZuwh5Nve49miLPoW2py+7zHMHgDGZ5C DlWUMnUQWH67fUQXl2+t5o5NnvG/M8Ub+VzZLuhPwuloTv5ohAJpBp5BnPF+wr4k5P/+p1K4L37iq FB3uTvXmWpVT6LmN8CtWgwXgqWvjrP3aCy+h8z6fchIEUVt5scUNShGYT/k93oGrjI6ZbO4crjB5x MxnX2Jg3Si/H+tIpcTpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwp4Q-002MmR-QV; Fri, 25 Jun 2021 16:52:46 +0000 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwp4L-002Mlr-Ac for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 16:52:44 +0000 Received: by mail-il1-x131.google.com with SMTP id i17so10251902ilj.11 for ; Fri, 25 Jun 2021 09:52:39 -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=N/UUU9wBefPzEVM58PT9NL43+h0nuVqaWkiVTHNvFk0=; b=LrLoLCjpvzVnepd4ka+TqIUqhuucIq1wdesPHdYaTZhAea9d0Us46oyZooeO2sSJeC fsW1gMSoJY1sKdpI+60JJRDOjLnSm0GFh/8hiJ5+r21z5WAl+JdaFPydb4WDBdFG9U0v UfwDojXHYLTqq/XDfkQGmgl6E15+19i0NwFoMXixtxxHxm6qPWBwaY+hdY6/n+cxwPU1 mBmO/wGpjGDh8e8+FOSpVv93rOTopJx9cochjJH1To7PK3G3aen6Ds0f5l3Nu27Szz0J 8TcbHO+ze1kLWw91nlz+c8ZHilEI/RqNFkVU2qv32spaUkwHcucUDt1SQA4vp/ZbOFZJ bjOw== 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=N/UUU9wBefPzEVM58PT9NL43+h0nuVqaWkiVTHNvFk0=; b=R865IRY/EnN4SsT1r00n93CU6FAt8G/ldRA7Ry27k8Ldric0qxR1JNNsMktXPzudUV 9QIFv42bb1ROOPxLX+zdBtvV6BQEwlTR4CSo1lyRba67BvJvGQG32/DTOBLcRbFUYWS4 iJvuClF/gCm8adM78rDYQNqSFSpOMZoNCnwEYAArX9o2UPNLCAbiwf8YWMHae03OukR8 6fghCb43zZJ9zNMasUlCuuCtUkOxleG5Isi1Dy6QmciK1uOOtS4rxW75h3VeTJoyNyEv /DdYh83nd/udinqhrtA/MgL8e+yiV8PiN+WDJIBP+K+RghmcIop/6emuGUo2z/6oHXVo jQGg== X-Gm-Message-State: AOAM5300HuOsBX7PLkVZBpQy6mTKmMuXvzhuwodh1Bkz2r+uSBUBZR98 JZY2hE2HIlXZu9elPewaVaSjALSBdrKQlJSXtQ22uQ== X-Google-Smtp-Source: ABdhPJyQFiDmx9y8rfrfAjIWinElx3L7btM0ONoH23UlRGC/2AvZ2VD3f6X4qkmEnbuQIzgOA0RnymYDJzOqWIOS3G0= X-Received: by 2002:a92:874a:: with SMTP id d10mr7705769ilm.145.1624639959159; Fri, 25 Jun 2021 09:52:39 -0700 (PDT) MIME-Version: 1.0 References: <20210617215829.GD25403@willie-the-truck> <20210618150953.GH16116@arm.com> <20210621123936.GB29283@willie-the-truck> <20210621151858.GC11552@arm.com> <20210621173902.GA29713@willie-the-truck> <20210621185036.GD11552@arm.com> <20210623085530.GF13058@arm.com> <20210624165228.GB25097@arm.com> <20210625092253.GJ13058@arm.com> <20210625120137.GC20835@arm.com> In-Reply-To: <20210625120137.GC20835@arm.com> From: Peter Collingbourne Date: Fri, 25 Jun 2021 09:52:27 -0700 Message-ID: Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis To: Catalin Marinas Cc: Szabolcs Nagy , Will Deacon , Vincenzo Frascino , Evgenii Stepanov , Linux ARM , Tejas Belagod X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210625_095243_360121_F8A54CAF X-CRM114-Status: GOOD ( 40.04 ) 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, Jun 25, 2021 at 5:01 AM Catalin Marinas wrote: > > On Fri, Jun 25, 2021 at 10:22:53AM +0100, Szabolcs Nagy wrote: > > The 06/24/2021 17:52, Catalin Marinas wrote: > > > Thanks. Is there any MTE support in mainline glibc? If not, we may have > > > another chance of adjusting the ABI. > > > > glibc exposed heap tagging via an env var mechanism that can change > > between glibc releases, i.e. not abi stable, and we have no real > > contract about how the prctl can be used on top of glibc (see e.g. the > > multi-thread issue). > > > > we don't expect the async mode to be very useful on glibc based linux > > systems. > > > > changing async mode is unlikely to affect anything in userspace at > > this point. > > Thanks, that's useful. I guess since the _MTAG_ENABLE tunable is not > ABI, the user app can't rely on what the glibc has configured. Arguably, > since it's driven from outside the application (env), we could say the > same for sysfs, though for the glibc case, the user app is still be able > to override it before the first thread is created (or per-thread). I > assume glibc only issues the prctl() once, not for every new thread. > > > > The proposed interface is sysfs. I think that's not relevant to the user > > > application since it wouldn't have control over it anyway. What's > > > visible is that it cannot rely on the mode it requested, not even for > > > the lifetime of a thread (as it may migrate between CPUs). Do you see > > > any issues with this? For Android, it's probably fine but if other > > > programs cannot cope (or need the specific mode requested), we'd need a > > > new control (for opt-in or opt-out). > > > > i don't see any issues with changing async mode. > > > > i assume the prctl get operation would return whatever was the prctl > > setting for the thread and not try to expose the per cpu architectural > > state. > > Yes. > > > i assume async vs sync fault can be distinguished via the > > SEGV_MTE{A,S}ERR si_code. > > Indeed. > > So we can document that the mode requested by the app is an indication, > the system may change it to another value (and back-port documentation > to 5.10). If we get a request from developers to honour a specific mode, > we can add a new PR_MTE_TCF_EXACT bit or something but it's not > essential we do it now. > > So if we allow the kernel to change the user requested mode (via sysfs), > I think we still have two more issues to clarify: > > 1. Do we allow only "upgrade" (for some meaning of this) or sysfs can > downgrade to a less strict mode. I'd go for upgrade here to a > stricter check as in Peter's patch. Agreed, for the reasons that I and Szabolcs have mentioned. > 2. Should the sysfs upgrade the PR_MTE_TCF_NONE? _MTAG_ENABLE does that, > so I'd say yes. This would be a problem for Android. Currently when disabling MTE in a process which has previously had MTE enabled we set TCF to NONE via prctl and then proceed mostly as if MTE was never enabled. This means e.g. that tags in existing PROT_MTE pages are not updated. If TCF is set to something other than NONE as a result of the prctl we would randomly hit tag check faults as a result of accessing allocations with non-updated tags. It would not be sufficient to disable tag checks via TCO because TCO is disabled in signal handlers. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel