linux-kernel - Re: [PATCH 06/11] x86: drop SWIOTLB and PHYS_ADDR_T

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: <d84fc2e4-ca81-42b1-ae44-292d0b32c7ed@app.fastmail.com>
Date: Wed, 04 Dec 2024 21:52:01 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Shevchenko" <andy.shevchenko@...il.com>,
 "Arnd Bergmann" <arnd@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Andy Shevchenko" <andy@...nel.org>, "Matthew Wilcox" <willy@...radead.org>,
 "Sean Christopherson" <seanjc@...gle.com>,
 "Davide Ciminaghi" <ciminaghi@...dd.com>,
 "Paolo Bonzini" <pbonzini@...hat.com>, kvm@...r.kernel.org
Subject: Re: [PATCH 06/11] x86: drop SWIOTLB and PHYS_ADDR_T_64BIT for PAE

On Wed, Dec 4, 2024, at 19:41, Andy Shevchenko wrote:
> On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@...nel.org> wrote:
>>
>> From: Arnd Bergmann <arnd@...db.de>
>>
>> Since kernels with and without CONFIG_X86_PAE are now limited
>> to the low 4GB of physical address space, there is no need to
>> use either swiotlb or 64-bit phys_addr_t any more, so stop
>> selecting these and fix up the build warnings from that.
>
> ...
>
>>         mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform);
>>         if (!uniform) {
>>                 pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n",
>> -                            __func__, addr, addr + PMD_SIZE);
>> +                            __func__, (u64)addr, (u64)addr + PMD_SIZE);
>
> Instead of castings I would rather:
> 1) have addr and size (? does above have off-by-one error?) or end;
> 2) use struct resource / range with the respective %p[Rr][a] specifier
> or use %pa.

Changed as below now. I'm still not sure whether the mtrr_type_lookup
end argument is meant to be inclusive or exclusive, so I've left
that alone, but the printed range should be correct now.

Thanks,

     Arnd

@@ -740,11 +740,12 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
 int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
 {
        u8 uniform;
+       struct resource res = DEFINE_RES_MEM(addr, PMD_SIZE);

        mtrr_type_lookup(addr, addr + PMD_SIZE, &uniform);
        if (!uniform) {
-               pr_warn_once("%s: Cannot satisfy [mem %#010llx-%#010llx] with a huge-page mapping due to MTRR override.\n",
-                            __func__, (u64)addr, (u64)addr + PMD_SIZE);
+               pr_warn_once("%s: Cannot satisfy %pR with a huge-page mapping due to MTRR override.\n",
+                            __func__, &res);
                return 0;
        }