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 692ABC433F5 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 3CEA560F38 for ; Mon, 11 Oct 2021 23:59:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235766AbhJLABu (ORCPT ); Mon, 11 Oct 2021 20:01:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230213AbhJLABt (ORCPT ); Mon, 11 Oct 2021 20:01:49 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81AADC061570 for ; Mon, 11 Oct 2021 16:59:48 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id c16so25202058lfb.3 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=yaimWrForwip93/Cnp3bpyb/tXTC0QRD0igi6DgTPrDUdCCYmcr9WunSM3pcWy+gFO g0nnMElzF5WvRQ0REjf3w8veZIxroTSm9CWRvXFU7mqeqTLsA30pC5fpFb3nzuNd17GC pRqH0qOki7/qxrjSdKexvKyP22NNLD+h4m9VkIJKtfPW0UhdAEy2/+HLa5YSVJHFBld8 Q3Ned9s3LhldihoC/j7pEoaLvdocpQyJhtDwkJp1oZxm+/hz21/xNitrBmOvVBFX8PoG xASL68G1A58XC3/85rhNJY6o1mUdaqxARNFAZpoj5A7CSvG48pwTJpd40dyhDwMEnMxO dTcg== X-Gm-Message-State: AOAM530G99/g4jIyFbLHoqme83OMu+tOncmMuykdB/UwdeOSQds7CSTX RqH769cFBQ+JXi2Afq5gE0pr6nQSKj5EqakR X-Google-Smtp-Source: ABdhPJzUVuLyYhRhhrCHRGUKqLho4/6nq7QxjGb11AIDoMrC6Yddg1wDs0dWzPJU44nDJC6NXDQOLg== X-Received: by 2002:a2e:a303:: with SMTP id l3mr18799740lje.242.1633996786067; Mon, 11 Oct 2021 16:59:46 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id e8sm861910lft.308.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-f49.google.com with SMTP id r19so77511482lfe.10 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-kernel@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