linux-kernel - Re: [BUG] x86/mm: regression after 4a02ed8e1cc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <920DC212-880C-4688-A577-2589CABEED75@gmail.com>
Date: Wed, 3 Sep 2025 17:18:29 +0300
From: Nadav Amit <nadav.amit@...il.com>
To: Jann Horn <jannh@...gle.com>
Cc: Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
 Rik van Riel <riel@...riel.com>,
 the arch/x86 maintainers <x86@...nel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Borislav Petkov <bp@...en8.de>,
 peterz@...radead.org,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 zhengqi.arch@...edance.com,
 thomas.lendacky@....com,
 kernel-team@...a.com,
 "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 jackmanb@...gle.com,
 mhklinux@...look.com,
 andrew.cooper3@...rix.com,
 Manali.Shukla@....com,
 Ingo Molnar <mingo@...nel.org>,
 Dave Hansen <dave.hansen@...el.com>,
 baolu.lu@...el.com,
 david.guckian@...el.com,
 damian.muszynski@...el.com
Subject: Re: [BUG] x86/mm: regression after 4a02ed8e1cc3

I just noticed few things need clarification

> On 2 Sep 2025, at 19:05, Jann Horn <jannh@...gle.com> wrote:
> 
> On Tue, Sep 2, 2025 at 5:44 PM Giovanni Cabiddu
> <giovanni.cabiddu@...el.com> wrote:
>> 

[snip]

>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index 39f80111e6f1..e66c7662c254 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -1459,7 +1459,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
>> 
>>        put_flush_tlb_info();
>>        put_cpu();
>> -       mmu_notifier_arch_invalidate_secondary_tlbs(mm, start, end);
>> +       mmu_notifier_arch_invalidate_secondary_tlbs(mm, info->start, info->end);
>> }
> 
> I don't see why the IOMMU flush should be broadened just because the
> CPU flush got broadened.

Agreed (as Rik also indicated now)

> 
> On x86, IOMMU flushes happen from arch_tlbbatch_add_pending() and
> flush_tlb_mm_range(); the IOMMU folks might know better, but as far as
> I know, there is nothing that elides IOMMU flushes depending on the
> state of X86-internal flush generation tracking or such.
> 
> To me this looks like a change that is correct but makes it easier to
> hit IOMMU flushing issues in other places.

This change is not correct. Do not reference info after calling
put_flush_tlb_info().

> 
> Are you encountering these issues on an Intel system or an AMD system?

I would note that on AMD IOMMUs there is some masking functionality
that allows to make large yet selective flushes.

This means both that we should not force IOMMU flush range to be large
just because we decided to do so for the CPU (as you correctly said)
and that there might be an unrelated bug, like in the mask computation.