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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F3DAC433EF for ; Mon, 4 Jul 2022 17:09:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C3CF6B0072; Mon, 4 Jul 2022 13:09:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4713E6B0073; Mon, 4 Jul 2022 13:09:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33AEC6B0074; Mon, 4 Jul 2022 13:09:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2473B6B0072 for ; Mon, 4 Jul 2022 13:09:39 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D9C25763 for ; Mon, 4 Jul 2022 17:09:38 +0000 (UTC) X-FDA: 79650054036.16.3105340 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id CB1F940005 for ; Mon, 4 Jul 2022 17:09:37 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E3EBE6151D for ; Mon, 4 Jul 2022 17:09:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B869DC341CF for ; Mon, 4 Jul 2022 17:09:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656954575; bh=Um74VEI3JxHcz8FDRGAiWVUNuyk2Y2i4GBLAq54v5s0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vH1ACDnAOIBP7LSR5Gway+gxOl7zbLOA2muLRdWKyn21uxTJs0bGcytHe0Ob6CQW/ MTRyzW6y8i7r4iWDGKJaWYHa2WIN4USUPc5IOp9mNItt7dU0Our6h3zXsTDaysKn7Q 1bCSHKvWh4dDURhYEW+BYKGwh1ky35dTZiUJDG1pzv9htFkbqRH2kHB94tXcUFOPsc GNIHuvB1o7A0vJfKZWZ+QJlgRQcuVGlLuxTDWmli5tOBpiwyibpePsn4DaQXhq78Gf gEPTWVtyqNfuMsGn7ifi6nb9qgx31IqTVl8m+YVj5LcC9APk+DYLsBvcjYGUlPTK41 NGK+Sz5DnQ+qw== Received: by mail-oi1-f178.google.com with SMTP id t189so13518953oie.8 for ; Mon, 04 Jul 2022 10:09:35 -0700 (PDT) X-Gm-Message-State: AJIora/oxYtRZuNKUsG8XUagVQ0JMSAUDpTA/3eFUL/jLrcPoqFT9bnt PFzyxZDl9MwwMqkAK8HLxAt9D6KNoJfiLDC0vwM= X-Google-Smtp-Source: AGRyM1sahgoRXg4Rzbf0/gmHR3RNP37cUxpO88Ud1QW1I/Znw7jgxtkIkBfkP6ZcjDK/UZIkdHCwZeqw3SVjKPNYBPU= X-Received: by 2002:a05:6808:18a1:b0:337:5:30cf with SMTP id bi33-20020a05680818a100b00337000530cfmr11082396oib.228.1656954574851; Mon, 04 Jul 2022 10:09:34 -0700 (PDT) MIME-Version: 1.0 References: <1656777473-73887-1-git-send-email-guanghuifeng@linux.alibaba.com> <20220704103523.GC31437@willie-the-truck> <73f0c53b-fd17-c5e9-3773-1d71e564eb50@linux.alibaba.com> <20220704111402.GA31553@willie-the-truck> <4accaeda-572f-f72d-5067-2d0999e4d00a@linux.alibaba.com> <20220704131516.GC31684@willie-the-truck> <2ae1cae0-ee26-aa59-7ed9-231d67194dce@linux.alibaba.com> <20220704142313.GE31684@willie-the-truck> <6977c692-78ca-5a67-773e-0389c85f2650@linux.alibaba.com> <20220704163815.GA32177@willie-the-truck> In-Reply-To: <20220704163815.GA32177@willie-the-truck> From: Ard Biesheuvel Date: Mon, 4 Jul 2022 19:09:23 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation To: Will Deacon Cc: "guanghui.fgh" , baolin.wang@linux.alibaba.com, catalin.marinas@arm.com, akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com, james.morse@arm.com, quic_qiancai@quicinc.com, christophe.leroy@csgroup.eu, jonathan@marek.ca, mark.rutland@arm.com, thunder.leizhen@huawei.com, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rppt@kernel.org, geert+renesas@glider.be, linux-mm@kvack.org, yaohongbo@linux.alibaba.com, alikernel-developer@linux.alibaba.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656954578; a=rsa-sha256; cv=none; b=REwFyDbC/1Xn6kA1ELeDg2W/U0DPee/dJrL/hLhvH1GtHSTOunRHO6SC3iyR5lcBHQh7GK QBfIuQscnMf+BQc8OPn87Ll8iCgCcRD1ETZqKXaLx+KLl0e6W1QXgzyfxKL1VFz8f1PUrZ N2RubMq0Ixrbg9MPUXlVv0y6gn5SFK0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vH1ACDnA; spf=pass (imf01.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656954578; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Um74VEI3JxHcz8FDRGAiWVUNuyk2Y2i4GBLAq54v5s0=; b=J3UA8PTwQXlHGHgx7+g2m2Svesx/Li+sK6RwfdH2cIF0ZyiuIPOmIwba/ehm6qyfrTioJt hRLxlNAWHNH/Rw2OndXJJG8b9hC5SURBzdjGy7PVRnQk9B1tNafkQkSVtZwpzd+Tmdg/ik kTwWBt2/kyzlmFBjXj+OUEf2BSyeyis= X-Stat-Signature: fbcpxujwpzog8xcdq5pygzgohp1bj1z9 X-Rspamd-Queue-Id: CB1F940005 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vH1ACDnA; spf=pass (imf01.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1656954577-608896 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 Mon, 4 Jul 2022 at 18:38, Will Deacon wrote: > > On Mon, Jul 04, 2022 at 10:34:07PM +0800, guanghui.fgh wrote: > > Thanks. > > > > =E5=9C=A8 2022/7/4 22:23, Will Deacon =E5=86=99=E9=81=93: > > > On Mon, Jul 04, 2022 at 10:11:27PM +0800, guanghui.fgh wrote: ... > > > > Namely, it's need to use non block/section mapping for crashkernel = mem > > > > before shringking. > > > > > > Well, yes, but we can change arch_kexec_[un]protect_crashkres() not t= o do > > > that if we're leaving the thing mapped, no? > > > > > I think we should use arch_kexec_[un]protect_crashkres for crashkernel = mem. > > > > Because when invalid crashkernel mem pagetable, there is no chance to r= d/wr > > the crashkernel mem by mistake. > > > > If we don't use arch_kexec_[un]protect_crashkres to invalid crashkernel= mem > > pagetable, there maybe some write operations to these mem by mistake wh= ich > > may cause crashkernel boot error and vmcore saving error. > > I don't really buy this line of reasoning. The entire main kernel is > writable, so why do we care about protecting the crashkernel so much? The > _code_ to launch the crash kernel is writable! If you care about preventi= ng > writes to memory which should not be writable, then you should use > rodata=3Dfull. > This is not entirely true - the core kernel text and rodata are remapped r/o in the linear map, whereas all module code and rodata are left writable when rodata !=3D full. But the conclusion is the same, imo: if you can't be bothered to protect a good chunk of the code and rodata that the kernel relies on, why should the crashkernel be treated any differently?