From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA422C433DF for ; Tue, 14 Jul 2020 09:41:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F2F820EDD for ; Tue, 14 Jul 2020 09:41:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726062AbgGNJlj (ORCPT ); Tue, 14 Jul 2020 05:41:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:40280 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725816AbgGNJli (ORCPT ); Tue, 14 Jul 2020 05:41:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B4DD7AAE8; Tue, 14 Jul 2020 09:41:39 +0000 (UTC) Subject: Re: [PATCH] mm: thp: Replace HTTP links with HTTPS ones To: "Alexander A. Klimov" , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20200713164345.36088-1-grandmaster@al2klimov.de> From: Vlastimil Babka Message-ID: <642ab4dc-d0fb-d973-0e5e-7d1bc7d90f11@suse.cz> Date: Tue, 14 Jul 2020 11:41:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200713164345.36088-1-grandmaster@al2klimov.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > Continuing my work started at 93431e0607e5. > See also: git log --oneline '--author=Alexander A. Klimov ' 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). >