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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52D0AC433EF for ; Mon, 11 Oct 2021 23:59:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 296E760F11 for ; Mon, 11 Oct 2021 23:59:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235752AbhJLABu (ORCPT ); Mon, 11 Oct 2021 20:01:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231361AbhJLABt (ORCPT ); Mon, 11 Oct 2021 20:01:49 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7FE1C06161C for ; Mon, 11 Oct 2021 16:59:48 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id r19so77511762lfe.10 for ; Mon, 11 Oct 2021 16:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OgVSO9l8+qaj3s+luNrigHMuS+kRVTnezRpRHPjbW94=; b=DKTICZkUM6+mQG0DkILdTYZfNfrDqAhQovODFervf5Lp8oEVb8SilHueb0cyn8u/xv XjaotArwSiIRg2V2JD0UdseT1WBdQdkROwO52I5s0Do4CGlHHCCiAQXRoQiTuYhiPvbW Ui91qkKHYi4ttDBdjPrMIDhbomocs37Ov8yPk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OgVSO9l8+qaj3s+luNrigHMuS+kRVTnezRpRHPjbW94=; b=YtXYXx0wqWrg+AgVR+Bb8nAwUdVOxGdhRjImWUlWGsc3F6hJ1/RlE3hX8mSylTxZKr Zs/vTTKVaWRSJEru5w/Wwdgz/wYMi6FHJrK6aVFSLF8piqMtMhGQpv5BOyJ27+KvSpAL 7BbijuHw+mVN9Dm1q3f6+CQUtzgAgGFMelBsONEKP68KZsMNRT/LjM9RH2w4z3g7/Dg2 rdI8gBv6An9HaAEMPQfGrAc6WxxgBKz2xGnMWbUfjK00oNOmLPZVxXbVU0cGYm+hifSW oOsvavoU/4O8bYeFCuqx5E3M8aj7Wk1nTD1z72Q0Dhb28lB0Pvq20gQky+wOqyGFRLqT trEw== X-Gm-Message-State: AOAM533yTyVJISKVrxKdXwxfVu73i6sT7RCIXpgY9KwyvGbU5mr7D4mP bu/g9HBi1DVRLXPNY47ESnMMmX4phkKeStll X-Google-Smtp-Source: ABdhPJwfB8v1ruTczagtNUcBGB/PcaesIVYDHAMkv1ToAXs7EOeabeQG/kxw+CXS0E/Th7uLLlF7NA== X-Received: by 2002:a05:651c:a05:: with SMTP id k5mr5668466ljq.288.1633996786422; Mon, 11 Oct 2021 16:59:46 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id i12sm862318lfb.234.2021.10.11.16.59.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 16:59:44 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id j5so80271261lfg.8 for ; Mon, 11 Oct 2021 16:59:44 -0700 (PDT) X-Received: by 2002:a05:6512:139b:: with SMTP id p27mr30802647lfa.173.1633996784057; Mon, 11 Oct 2021 16:59:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 11 Oct 2021 16:59:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][arm64] possible infinite loop in btrfs search_ioctl() To: Catalin Marinas Cc: Al Viro , Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , "ocfs2-devel@oss.oracle.com" , Josef Bacik , Will Deacon Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Oct 11, 2021 at 2:08 PM Catalin Marinas wrote: > > +#ifdef CONFIG_ARM64_MTE > +#define FAULT_GRANULE_SIZE (16) > +#define FAULT_GRANULE_MASK (~(FAULT_GRANULE_SIZE-1)) [...] > If this looks in the right direction, I'll do some proper patches > tomorrow. Looks fine to me. It's going to be quite expensive and bad for caches, though. That said, fault_in_writable() is _supposed_ to all be for the slow path when things go south and the normal path didn't work out, so I think it's fine. I do wonder how the sub-page granularity works. Is it sufficient to just read from it? Because then a _slightly_ better option might be to do one write per page (to catch page table writability) and then one read per "granule" (to catch pointer coloring or cache poisoning issues)? That said, since this is all preparatory to us wanting to write to it eventually anyway, maybe marking it all dirty in the caches is only good. Linus