From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 18B3B35C1A6 for ; Tue, 27 Jan 2026 14:47:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769525230; cv=none; b=mhcpqpcHxtqi9s8z97qrrH99eOfnE7Nve04JSG1q4Ck0sswW42QBk+iaEvYUu+DvRm01OCKT9Nh55CA+xEr4KCYinSrxOL3U15mTJvY8w2mRNpxMzzLtFegaNSAM2j3b3puEzKTqRJytk3wc2KYYsyA4VB8odfxsrwarMoLTgJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769525230; c=relaxed/simple; bh=LpQbDqH5V/q3+43Pxgle0PMfv3EL/1+Mec1psxoDuUc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QhnBdt4POACwvpMAE9Dm/Szq1Usw9+8IwUkkokn5t0nmEbjXdvPGL+D4kXvxbssK+VUR4NuImvyWZrqX5JfFZN4OrksUc1i2UBZoxXa+2eov+8vAjZZ/idXh7QDVLvGqdqb/8+tXDZS4WkXKbH6UVBEIaMGZVwXg1/Ab1qQ6Y24= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DBF611595; Tue, 27 Jan 2026 06:47:01 -0800 (PST) Received: from [10.1.37.210] (XHFQ2J9959.cambridge.arm.com [10.1.37.210]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7397B3F73F; Tue, 27 Jan 2026 06:47:06 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 14:47:04 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/13] arm64: mm: More flags for __flush_tlb_range() Content-Language: en-GB To: Jonathan Cameron Cc: Will Deacon , Ard Biesheuvel , Catalin Marinas , Mark Rutland , Linus Torvalds , Oliver Upton , Marc Zyngier , Dev Jain , Linu Cherian , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260119172202.1681510-1-ryan.roberts@arm.com> <20260119172202.1681510-12-ryan.roberts@arm.com> <20260127124533.0000302e@huawei.com> <20260127141137.00004dd4@huawei.com> <20260127141412.00005d7a@huawei.com> From: Ryan Roberts In-Reply-To: <20260127141412.00005d7a@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27/01/2026 14:14, Jonathan Cameron wrote: > On Tue, 27 Jan 2026 14:11:37 +0000 > Jonathan Cameron wrote: > >> On Tue, 27 Jan 2026 13:50:06 +0000 >> Ryan Roberts wrote: >> >>> On 27/01/2026 12:45, Jonathan Cameron wrote: >>>> On Mon, 19 Jan 2026 17:21:58 +0000 >>>> Ryan Roberts wrote: >>>> >>>>> Refactor function variants with "_nosync", "_local" and "_nonotify" into >>>>> a single __always_inline implementation that takes flags and rely on >>>>> constant folding to select the parts that are actually needed at any >>>>> given callsite, based on the provided flags. >>>>> >>>>> Flags all live in the tlbf_t (TLB flags) type; TLBF_NONE (0) continues >>>>> to provide the strongest semantics (i.e. evict from walk cache, >>>>> broadcast, synchronise and notify). Each flag reduces the strength in >>>>> some way; TLBF_NONOTIFY, TLBF_NOSYNC and TLBF_NOBROADCAST are added to >>>>> complement the existing TLBF_NOWALKCACHE. >>>> >>>> Unless I'm missing something the case of TLBF_NOBROADCAST but not >>>> TLBF_NOWALKCACHE isn't currently used. >>> >>> Currect but the next couple of patches start using TLBF_NOBROADCAST without >>> TLBF_NOWALKCACHE. TLBF_NOWALKCACHE is used without TLBF_NOBROADCAST in this patch. >>> >>>> >>>> I wonder if bringing that in with a user will make it easier to see what >>>> is going on. >>> >>> I'm not sure I understand the suggestion. This patch is using both flags so I >>> can't really defer introducing one of them. It's just that (for this patch only) >>> it never uses TLBF_NOBROADCAST without TLBF_NOWALKCACHE. >> >> Would be a case of lobbing in a build_bug_on() or similar, but this was >> mainly that I hadn't read the later patches at this point (or at least >> not such that they were still in my memory). >> >> Perhaps a breadcrumb just to say that new combination is added, but >> not used until later patches. > > Now I'm going crazy. Is it used used in this series? After you pointed out > the addition of TLBF_NOWALKCACHE in the flush page stuff I'm failing to spot > that. Or do you mean in a follow up series? Yeah, you're right; sorry about that. ___flush_tlb_range() (3 underscores) never sees TLBF_NOBROADCAST without TLBF_NOWALKCACHE. (I also failed to see the tweek in __flush_tlb_page() when I first responded to this. There is no follow up series). I'll replace the vae1 option with a BUILD_BUG() and remove the vae1()/rvae1() helpers in the next version. Thanks for the review! Thanks, Ryan