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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 AE200C433E4 for ; Fri, 24 Jul 2020 08:14:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 908F52074A for ; Fri, 24 Jul 2020 08:14:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726769AbgGXIOq (ORCPT ); Fri, 24 Jul 2020 04:14:46 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:44661 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726437AbgGXIOp (ORCPT ); Fri, 24 Jul 2020 04:14:45 -0400 Received: from mail-qt1-f174.google.com ([209.85.160.174]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M42zo-1jysqq0f9k-0003bn for ; Fri, 24 Jul 2020 10:14:44 +0200 Received: by mail-qt1-f174.google.com with SMTP id o22so6090206qtt.13 for ; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) X-Gm-Message-State: AOAM531Eitt9lseBhkip8q7TGf2XPd5Lf3vC7Pepj5YwLUX/XLVtF7H0 Z4jgR8Y5tofbNeOaia/key/ASzQCQ8F9yPDY3ZU= X-Google-Smtp-Source: ABdhPJygisjtG0/T5RZOpGU5w2vxR1Ybi3XIk/oHG1gnkzduo22/qOY0PE84/zvIhSqmrnDmSiaO0gHwgOoBfMX/5hA= X-Received: by 2002:ac8:7587:: with SMTP id s7mr8295990qtq.304.1595578483047; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) MIME-Version: 1.0 References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> In-Reply-To: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> From: Arnd Bergmann Date: Fri, 24 Jul 2020 10:14:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt Cc: Alex Ghiti , Palmer Dabbelt , Albert Ou , Linux-MM , Michael Ellerman , Anup Patel , "linux-kernel@vger.kernel.org" , Atish Patra , Paul Mackerras , Zong Li , Paul Walmsley , linux-riscv , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:HDwZL9icJfxyMmpxtY3DvBs7U9uzzEZ0jHaAzBBDsJ2so8pPZPS /wu/uOwXTpyPAdvrdgc4tnVagGr+uPCi76sAKJu6/QBK/4wi+QMt9bYLK9z+5BAXlPfQC8L lNVgPy1/NlmfVW0LriHqIpzdJCRzPS0ouPnnOVWdZBWTfn7nIfjdAyE726HqyxyPwG2JIug P1+JDJ5B6Vxw4iUncm3qA== X-UI-Out-Filterresults: notjunk:1;V03:K0:3PfhPQFARng=:lZ2ZWn6Ajn53EoqwHCDtHX UrEtsq7ay2AIwwoaVqYR1sv9V4WgUpUsOkgzWchvn2cUt95RxwJW5ZeF2dLGZRyXbOYD6YYLA 96V3YbIoN9M4k9KtVyJ7h3N4/rCeOA5iyrwEY5H6SjQXXYIhDZBsbTuhJYrotVp9hrwCqYwKE 0A4knKgLbl/daJmCATmq8BASlWR0xmMfjOAV1t/nYQsUB/rG1w9lngehZNluY6K6mPzhfNEzZ IdKvuscX69ZwcpM9jJTdRGCjtVS2xf8S5JTQH7JkXTanqF8SRZrmjL2Pac93vR934TL9zl3xx 4Z0zBhFKV+axcFsCC6ciZT5q3cWBVeplIzbD3QofoCDTHnpTsNSqfzTAbP9A6Vj4ATBU2CamC iaSanrrvDxYBsvcDZLRWoauYgpIBPzLxzH8OxAaToxp+C9EjNZUIfOybSmZTAjfLlA/ATLW+J LQGmTQokI5jxyjDB9DeXNcrdaw/HwWGNQnisBK4eDz3jfjzW2fpR/IJNEsT8GLkn4qWEywve2 /cPTPCKk1/VYlw14VK0e6ruFH/6Ii6gZUE9Y46PzKFLXA2rqoLUooRPlPztoch3E9dqqCIbO5 pWmXmemJXA1EuaBsqViGldVKFIOYzJo72lnkzviYIvykms52QT9WFTiOVZwLRbQ4miCL/2bUW IxOkm4LhdFM5Dbre/mgNQe/f8Z8JhHOG5hKSUF5CMumvGrYZvOXSMHL8TSBP6KlENyHb17ilG MAhgGIlgAOnnR/d0emkx/JpidMkSa8oCyPjDd00xtUBY0KtLtEZUaEYNnZepZlg9osHqxebj7 UTxzWF/T3hqkXY7WkwtWZzNe+dpRXozJn6Fr4SRZXRCCtoczwPqlvJm9uEI04SokT9Kht0tM6 JxYgrWjfiLIkda034QKfWEC7nzKhXOc9/piHRTKbNdOlxdeGMmGRjxLCI51p/TLVuhiS1VVuK lByu/L20B+iqWcBpeePZ0ms4XblV+OAI2Mn1tL797sTaAMvol/sWY Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt wrote: > On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > > works fine with huge pages, what is your problem there ? You rely on > > > punching small-page size holes in there ? > > > > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > > mapping in the direct mapping as it sets different permissions to > > different part of the kernel (data, text..etc). > > Ah ok, that can be solved in a couple of ways... > > One is to use the linker script to ensure those sections are linked > HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One > is to selectively degrade just those huge pages. > > I'm not familiar with the RiscV MMU (I should probably go have a look) > but if it's a classic radix tree with huge pages at PUD/PMD level, then > you could just degrade the one(s) that cross those boundaries. That would work, but if the system can otherwise use 1GB-sized pages, that might mean degrading the first gigabyte into a mix of 2MB pages and 4KB pages. If the kernel is in vmalloc space and vmap is able to use 2MB pages for contiguous chunks of the mapping, you get a somewhat better TLB usage. However, this also means that a writable mapping exists in the linear mapping for any executable part of the kernel (.text in both vmlinux and modules). Do we have that on other architectures as well, or is this something that ought to be prevented with STRICT_KERNEL_RWX/STRICT_MODULE_RWX? Arnd 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 6DE27C433DF for ; Fri, 24 Jul 2020 08:15:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 322A320748 for ; Fri, 24 Jul 2020 08:15:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MmLDLkX8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 322A320748 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EfL1JtKH6bG7Ze9aw2ih7wqC414HyTW6ImkwGRThGVk=; b=MmLDLkX8JFqwpirsHJZTFHDux BkRHJsJ2O3N2DvvL/0E6NjGVTSz+chE9gr9FZkfv5OD5a47E4s+xeRoWHh9NvMpxj2IXQLX5COLfJ uEVfygqhXiqbgvTnhvfuhbbqARS+k7PrwbXfZmyilP/ucrOcn15ilMRVeUzNkYoMcVpGOnjwD5pCL rf9PkPcaI9IpIMktFE2EJcRRYohuS4j1BxSg7/Wj7ODyTf/a+u0DiuTZ6Q0unYH3tNEd36ghICiIT +ktKnsIor5EoXkTP1M9KNJhPlzph/lFnwd5P/fkAjQ2YvcF8kOhCsAqQswMy2nz78NXUrBtzjJdEI LnQQ1dOaQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jysqy-00057Y-RK; Fri, 24 Jul 2020 08:14:52 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jysqw-00056I-4s for linux-riscv@lists.infradead.org; Fri, 24 Jul 2020 08:14:51 +0000 Received: from mail-qt1-f173.google.com ([209.85.160.173]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MnaY1-1ki9sx1MDl-00jXa1 for ; Fri, 24 Jul 2020 10:14:46 +0200 Received: by mail-qt1-f173.google.com with SMTP id d27so6332330qtg.4 for ; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) X-Gm-Message-State: AOAM533UpgZ2QW68xAHaacf2kkkV7vYoFhIYiuKlNvSkgDM0mEXu+xwe pFUqfnbyRAOCFAcr8FyPexTcko9zgqLuUDaZTuM= X-Google-Smtp-Source: ABdhPJygisjtG0/T5RZOpGU5w2vxR1Ybi3XIk/oHG1gnkzduo22/qOY0PE84/zvIhSqmrnDmSiaO0gHwgOoBfMX/5hA= X-Received: by 2002:ac8:7587:: with SMTP id s7mr8295990qtq.304.1595578483047; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) MIME-Version: 1.0 References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> In-Reply-To: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> From: Arnd Bergmann Date: Fri, 24 Jul 2020 10:14:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt X-Provags-ID: V03:K1:GUrsHSmy5FSOW7iMQiEtqQZY0KkqCXUiq8uRbQI7VJs1bIkZ1Oa s12T0G4t+qyEW9ueWjugSxXvdYWxGmaHqAOp2e5nWjC6hvLwH6THgyWThVl59VTGTU0yb4P x+1Nq+tqUuZEBQbFXPI7nheLTxklvNOS2UE7+aNBTgmd6gvoqaQ4pVoIxoqXoQgbPXdQlYl JpHnqtdBrSf0HQriwQPuw== X-UI-Out-Filterresults: notjunk:1;V03:K0:yRzaeGobxfA=:qxw2/9UbNRMCvdpUel/+za lpp/jNPM/lW+HyAFiwoshGnBSy4/nLN6LmX7vp+ujrxwzpRRz1o0ffRS0IOHFXVuOnSaqnuU1 p4oohx/738a+mERqPu9jzyJ8BKDKyUr4PtmCO9jZkbS7YgURCNt1wlniM+9EPALYK9YqXk5H1 vys9jLqB/Kw71goLQR2JDquR8UocMJHTeC9321iMo/F1xgqRvmgBO2nSPtQavGJMFNEeyiTN1 nviAVWzYg+ZDhccve2BhsHWT6oTsrWq2KoG+gSyEPqZaGm2pcjXAq0vGw2WEitPRgIkuWPzo/ ffCkCfFkK2bYjHmZmMB7FkPxvIJ/XRUErh5yv7BkfOOaoFoqTsFwRy3VdxZ/S71Cc+7kAM3uC 89aAEV3gBYETvbwTQZEzMn9v5f/sh5EFIUXlrGMxIdMEe6n6+v3l+bZ0evg8g4VJKzVGnhNUw /8cQstHus+GXOOeGqtOgQHu/Yfd0u6ZOyWdvpNvqKLon2P8FwBlvyVllGxmnlhKQ1VHlWzEwP 5QrFsZbbRjOALM38ucjVHJUQE0mOK0VfC0lebP5+ADzlza3a+K9WA6qN9PsilblZVSmZuuGrh yEc6w2T8Utzhub7GoEt9eANE+QxWNPFU9H3W98lwpA9CvIyWainB9jmI3vvMBW9vtDbK81GAa MLUVfEZoF3EERzO/3sXgMVZ0eACorCNRoPQ0uttg+G3egYHnHgmD6N1LR5hnxu+UnTG6aKoDH SGQgPfPm5xAbzxWJTe8EK/5gFsueIAiCOAUqRTc6so2Gv4Z9ux5iZJ8rm6VlSFXp0OAQ5nfMc DFCrchhPII+Fj4AxHjaP7duSMPHVM2Nes/3oSaJM88yKtJHi+aKYI/IJcBJMqS8x3a2U2rojD WKNF6S8oc5x5WOj2K4sroc5I9R6dxlIzvnmIuiPrNucw+ATMyNqgkUNDvY1MidzZPYtsyA3Qz pezXUpsYz+dqSfQja9K4TMHV+48n4ySYjsGzDqdkFUASiOSCO+qvB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200724_041450_428280_CA825788 X-CRM114-Status: GOOD ( 18.38 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Albert Ou , Alex Ghiti , Atish Patra , Michael Ellerman , Anup Patel , "linux-kernel@vger.kernel.org" , Linux-MM , Palmer Dabbelt , Zong Li , Paul Walmsley , Paul Mackerras , linux-riscv , linuxppc-dev Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt wrote: > On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > > works fine with huge pages, what is your problem there ? You rely on > > > punching small-page size holes in there ? > > > > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > > mapping in the direct mapping as it sets different permissions to > > different part of the kernel (data, text..etc). > > Ah ok, that can be solved in a couple of ways... > > One is to use the linker script to ensure those sections are linked > HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One > is to selectively degrade just those huge pages. > > I'm not familiar with the RiscV MMU (I should probably go have a look) > but if it's a classic radix tree with huge pages at PUD/PMD level, then > you could just degrade the one(s) that cross those boundaries. That would work, but if the system can otherwise use 1GB-sized pages, that might mean degrading the first gigabyte into a mix of 2MB pages and 4KB pages. If the kernel is in vmalloc space and vmap is able to use 2MB pages for contiguous chunks of the mapping, you get a somewhat better TLB usage. However, this also means that a writable mapping exists in the linear mapping for any executable part of the kernel (.text in both vmlinux and modules). Do we have that on other architectures as well, or is this something that ought to be prevented with STRICT_KERNEL_RWX/STRICT_MODULE_RWX? Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 CECABC433E5 for ; Fri, 24 Jul 2020 08:14:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7DA3820748 for ; Fri, 24 Jul 2020 08:14:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DA3820748 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A4B6B8D002B; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FAAA8D0027; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EA448D002B; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 7A0A08D0027 for ; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E5810180397BE for ; Fri, 24 Jul 2020 08:14:46 +0000 (UTC) X-FDA: 77072258172.05.kick62_480764326f45 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id B856C1811E9C9 for ; Fri, 24 Jul 2020 08:14:46 +0000 (UTC) X-HE-Tag: kick62_480764326f45 X-Filterd-Recvd-Size: 5304 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jul 2020 08:14:45 +0000 (UTC) Received: from mail-qt1-f171.google.com ([209.85.160.171]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MTRdK-1kOHSC1sEu-00TlnM for ; Fri, 24 Jul 2020 10:14:44 +0200 Received: by mail-qt1-f171.google.com with SMTP id k18so6309744qtm.10 for ; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) X-Gm-Message-State: AOAM533kTokKgT088+hnAlEEi7DseFnqINXVomBhnmwhMuDKVcm/8r4b x7NM5W4uS4uyiGisottirIR23Mj45Pz1EvxgX3I= X-Google-Smtp-Source: ABdhPJygisjtG0/T5RZOpGU5w2vxR1Ybi3XIk/oHG1gnkzduo22/qOY0PE84/zvIhSqmrnDmSiaO0gHwgOoBfMX/5hA= X-Received: by 2002:ac8:7587:: with SMTP id s7mr8295990qtq.304.1595578483047; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) MIME-Version: 1.0 References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> In-Reply-To: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> From: Arnd Bergmann Date: Fri, 24 Jul 2020 10:14:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt Cc: Alex Ghiti , Palmer Dabbelt , Albert Ou , Linux-MM , Michael Ellerman , Anup Patel , "linux-kernel@vger.kernel.org" , Atish Patra , Paul Mackerras , Zong Li , Paul Walmsley , linux-riscv , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:ah0NcL+ATEYgZ0AAHAueqRr2v/CvmpDm88b3hIuvT6ouFmeL3/2 0NkxeSnYgPQeoKh9mlJEnc7zFA9KrOCtZIh3i4k5LTT7K8+m1kfyalOw/UfX4xI5hYRz7Fg XIb9xgXJFzaEwLLlhPRS2qFYHCH8dio0DFqGzbZk2Jr6h1lVIsWxqRmLOG+wBduCn07oMgC 5JrrnHh5485Hu7Eob2nbg== X-UI-Out-Filterresults: notjunk:1;V03:K0:17bBDCa767U=:n3PwViPQKW8aJFM52GXLAc mf/r48Ne9AUSygLXDCs58qtO/F6VR+YR+veIseA8/U0MMrcv/8Zp4a7wUVqr9jZLCV1Ji8ZEk g8darHv45kta3liN1WTadx5QTUGCp8puZlrRpbFmnCUeawl+pSwzcS7N2/DmNExfgEfHtgUGN Ay5mPsuFP/Vx7HLdBiZdYeYWSiYdG/cpJShkhfXL4QeogeVMFBZ73dv58kIW4Lg98KSHOjuVw xBW+MN8eE8PFKBQ/kWF431BhEPRjV7J/m4p/GHqYQZkNlzlC5jgdLEPZE0UHPwpy1xpetmXL8 OBHgtQuPzpHxcjhsRt4U9ZjPjd5iuSlUYdikZpjPZGi4xA4mTeigElMuN83jB63EKRSdaqniC +LImRFP6ogBOahdq50VhoPgGBWETbBI1roE4pWYAw70w8VTdOIqXPiYDJKHojCfC9zs59IZZh J56cTgArAgIPZ4sUIlt724AX/hOsQvuHuj/F6a6gentsY9EQ9aDzIkOMbfxMeUWFaeIFwzfFb ESJFT7d/aDMd1524/orDxTm+qAqj2ZOVm/C6E1M4rnbCjDzlzy56iuw94AclMdFF9ofw4iOlz 3eNlarCc1o1y4v5UFhxjmb6hDtt5ClJe1G8BmGjGSY9nsXpD6EaNCGsekNLdmSU0G+GlHnR6k FXasPYE0TInc/c+cVFx5MG3reag3ELHaLmKODs3tMgJU7s96Xo22/tpOzAKXZxrvTFrLVSmTM sLU0pz8C9iSH4wxmk0ei4jAmXCVxCFZkXrVp6ehM/getFt2d/GDnS0xhElODgkb97x047kIfB SVaLXOlb1pXu/5rPE9UVkTGIINY96LWHdbNha3AciaO+7Pjj8Yt9KuIK3NuQFiP1u89G/669W jYcYqMxQMbNERe5UVbBESc0TbgsOQgyPhwN9KpLy71u+ZsTWIFatRNcSzx0qEV+ifNoxCdETT /+jsEMi8T9SqISC062pLP+LdarbYhFS1B13xuW/3LAFgDj4kB4wox X-Rspamd-Queue-Id: B856C1811E9C9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt wrote: > On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > > works fine with huge pages, what is your problem there ? You rely on > > > punching small-page size holes in there ? > > > > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > > mapping in the direct mapping as it sets different permissions to > > different part of the kernel (data, text..etc). > > Ah ok, that can be solved in a couple of ways... > > One is to use the linker script to ensure those sections are linked > HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One > is to selectively degrade just those huge pages. > > I'm not familiar with the RiscV MMU (I should probably go have a look) > but if it's a classic radix tree with huge pages at PUD/PMD level, then > you could just degrade the one(s) that cross those boundaries. That would work, but if the system can otherwise use 1GB-sized pages, that might mean degrading the first gigabyte into a mix of 2MB pages and 4KB pages. If the kernel is in vmalloc space and vmap is able to use 2MB pages for contiguous chunks of the mapping, you get a somewhat better TLB usage. However, this also means that a writable mapping exists in the linear mapping for any executable part of the kernel (.text in both vmlinux and modules). Do we have that on other architectures as well, or is this something that ought to be prevented with STRICT_KERNEL_RWX/STRICT_MODULE_RWX? Arnd 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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 7C7EEC433DF for ; Fri, 24 Jul 2020 08:16:51 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F338520674 for ; Fri, 24 Jul 2020 08:16:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F338520674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BChr06g9QzF07s for ; Fri, 24 Jul 2020 18:16:48 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.126.135; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BChnk5gT9zDrNk for ; Fri, 24 Jul 2020 18:14:49 +1000 (AEST) Received: from mail-qt1-f180.google.com ([209.85.160.180]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Myb8P-1kkMnZ2z89-00z1Qh for ; Fri, 24 Jul 2020 10:14:44 +0200 Received: by mail-qt1-f180.google.com with SMTP id b25so6346921qto.2 for ; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) X-Gm-Message-State: AOAM530nWv4+7N7Ybb2BebDl56JQgpBFk2HvuMYD5Fw+2Sr18gTjLmLB EYb8kkXExd0LJFVy1n7voDGqQOLQMuZ1PXNJ50g= X-Google-Smtp-Source: ABdhPJygisjtG0/T5RZOpGU5w2vxR1Ybi3XIk/oHG1gnkzduo22/qOY0PE84/zvIhSqmrnDmSiaO0gHwgOoBfMX/5hA= X-Received: by 2002:ac8:7587:: with SMTP id s7mr8295990qtq.304.1595578483047; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) MIME-Version: 1.0 References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> In-Reply-To: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> From: Arnd Bergmann Date: Fri, 24 Jul 2020 10:14:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:+9wITevh3p85GTzMrKSyaZtkHw69m24SfgiKosKWUfF3EumwWV0 SehbEf029mXlyuBSqX4++EHdVn3jP2g+WPwD0bDSdgNVvidPEbO2GSfLVJ6v7S32jzrdZvy YbLWXyXEoSbumB111E7zQk6sC7ZRnszViujVHHivvg8GPKctoU+aT7SlCFRNVuqagLA6Zh3 InOJuJuXKYc5xQTeoQcwQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:8K48o2VU+5U=:DfR00JXyieYiVSxZ29VzR5 uiM+Ez4jkLw5yN0rguzQj2X1NUg2Ijo3eNM6bB4VkRSG7qj9FtCw01gIa1HxfeeoyYLA/IXeG Dluhnepy1bEgvkTQJgsmFnCwJsBPCjwrErTq4GfeZoHBHP2ms+0MzSnL1kfjMu0hOoa2Ywp7F YIUp6c5NTVfoYTME+MtwFV7EKPWWGzAFiqFarVheZDIB3rLoeGsgJtzsxVupRQIAZG/hhn8ko eBrJu9TVkyKhnKqUvsbzF8dmGdaUMpsZ6zmbskBbTZmKhoqtK+/KlEzkVhk0W+i3wMRBp3EPc arh0CvnK1lFKZpEY7Tw8H9GQzNBdhxJb85laUSJYGzLve7IOAMM0H4HZGxXiiMLYkvF+Cyghn tqgjQcXY25SCIElNsw1pekwlftZixN3ubCDh8zhRw2WMIO7iTWABSBNp2yWPP5w6sIOPlUDRe NQ3K9YYz26QGWVNJQEGLLHroXOYKk5nCDdfwNoFJ1gFhKnmDPqfmnPjODANUu2dNxsmf+1KTw 2IwD+ZQq4VKOk7jnJP1dFuqVKokwCInCkMAljfIYV9I8JE0JLaiYStjlboB/1mtUu6iiiJhVZ wJQl9E0kTLh/IvFiGL0NUWHrypAeTTjPPumqimeZE+mmhE6y0RU+FTMXsjBLpOqEoVeHBQQmT GpAutoihLYLFp3Ejt4yw/GqtKW03vC1u9prtDojfLXYmUOsPNA+2sSGSBg/KqcMKOqnN7AMPU CT5XVE2xpxrnltffUq6Cba25C2j9dRXQtRPGIx8oQRp55D7SaIC2lfEM7wEDzqYcq74NoSAml Z8gf36q0FRsEYA/e6IVQvRSdbPM+XO98i0I+ilVG5eOUrOiw1gEPc4+K+oTHNrH93dn2Wy4OU 5SF0W23r8GiYVadRtKrFSIlzO+toE1mTIPBEFEj0/OIhGq3VgUop/NRcON7lS9dulmBU2Fvbe YhyBhGT4OXhiLr6w7+w99ZG07KKB8o8Sa4MxpV++jgAIbYiH0QtF6 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Albert Ou , Alex Ghiti , Atish Patra , Anup Patel , "linux-kernel@vger.kernel.org" , Linux-MM , Palmer Dabbelt , Zong Li , Paul Walmsley , Paul Mackerras , linux-riscv , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt wrote: > On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > > works fine with huge pages, what is your problem there ? You rely on > > > punching small-page size holes in there ? > > > > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > > mapping in the direct mapping as it sets different permissions to > > different part of the kernel (data, text..etc). > > Ah ok, that can be solved in a couple of ways... > > One is to use the linker script to ensure those sections are linked > HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One > is to selectively degrade just those huge pages. > > I'm not familiar with the RiscV MMU (I should probably go have a look) > but if it's a classic radix tree with huge pages at PUD/PMD level, then > you could just degrade the one(s) that cross those boundaries. That would work, but if the system can otherwise use 1GB-sized pages, that might mean degrading the first gigabyte into a mix of 2MB pages and 4KB pages. If the kernel is in vmalloc space and vmap is able to use 2MB pages for contiguous chunks of the mapping, you get a somewhat better TLB usage. However, this also means that a writable mapping exists in the linear mapping for any executable part of the kernel (.text in both vmlinux and modules). Do we have that on other architectures as well, or is this something that ought to be prevented with STRICT_KERNEL_RWX/STRICT_MODULE_RWX? Arnd