linux-kernel - Re: [PATCH] mm: thp: Replace HTTP links with HTTPS ones

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] [day] [month] [year] [list]

Message-Id: <20200716165257.88776064be381ca5797983c5@linux-foundation.org>
Date:   Thu, 16 Jul 2020 16:52:57 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     "Alexander A. Klimov" <grandmaster@...klimov.de>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: thp: Replace HTTP links with HTTPS ones

On Tue, 14 Jul 2020 11:41:37 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:

> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2069,7 +2069,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> >  	 * free), userland could trigger a small page size TLB miss on the
> >  	 * small sized TLB while the hugepage TLB entry is still established in
> >  	 * the huge TLB. Some CPU doesn't like that.
> > -	 * See http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> > +	 * See https://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> >  	 * 383 on page 93. Intel should be safe but is also warns that it's
> 
> Well, it was a good opportunity to find out that the link doesn't work anyway.
> The pdf seems to be now at
> http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf
> and the erratum is on page 105

Thanks.

From: Andrew Morton <akpm@...ux-foundation.org>
Subject: mm-thp-replace-http-links-with-https-ones-fix

fix amd.com URL, per Vlastimil

Cc: "Alexander A. Klimov" <grandmaster@...klimov.de>
Cc: Vlastimil Babka <vbabka@...e.cz>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 mm/huge_memory.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/mm/huge_memory.c~mm-thp-replace-http-links-with-https-ones-fix
+++ a/mm/huge_memory.c
@@ -2065,8 +2065,8 @@ static void __split_huge_pmd_locked(stru
 	 * free), userland could trigger a small page size TLB miss on the
 	 * small sized TLB while the hugepage TLB entry is still established in
 	 * the huge TLB. Some CPU doesn't like that.
-	 * See https://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
-	 * 383 on page 93. Intel should be safe but is also warns that it's
+	 * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum
+	 * 383 on page 105. Intel should be safe but is also warns that it's
 	 * only safe if the permission and cache attributes of the two entries
 	 * loaded in the two TLB is identical (which should be the case here).
 	 * But it is generally safer to never allow small and huge TLB entries
_