On 7/13/20 6:43 PM, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov <grandmaster@xxxxxxxxxxxx> > --- > Continuing my work started at 93431e0607e5. > See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@xxxxxxxxxxxx>' v5.7..master > (Actually letting a shell for loop submit all this stuff for me.) > > If there are any URLs to be removed completely or at least not just HTTPSified: > Just clearly say so and I'll *undo my change*. > See also: https://lkml.org/lkml/2020/6/27/64 > > If there are any valid, but yet not changed URLs: > See: https://lkml.org/lkml/2020/6/26/837 > > If you apply the patch, please let me know. > > Sorry again to all maintainers who complained about subject lines. > Now I realized that you want an actually perfect prefixes, > not just subsystem ones. > I tried my best... > And yes, *I could* (at least half-)automate it. > Impossible is nothing! :) > > > mm/huge_memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 78c84bee7e29..9e4b78cf73ab 100644 > --- 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 > * 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). >
