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 333CFC43334 for ; Tue, 5 Jul 2022 08:35:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81E586B0071; Tue, 5 Jul 2022 04:35:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F4D26B0073; Tue, 5 Jul 2022 04:35:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E5FE6B0074; Tue, 5 Jul 2022 04:35:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 609066B0071 for ; Tue, 5 Jul 2022 04:35:37 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 10D03350EB for ; Tue, 5 Jul 2022 08:35:37 +0000 (UTC) X-FDA: 79652387514.10.A5D9AEB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id B0BCA40011 for ; Tue, 5 Jul 2022 08:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657010135; h=from:from: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; bh=0z2UhLA9zTx8MYx+v6FOVFe00lHXS/rANJnQv0UrSL8=; b=cG4nakGBx28Ndc3BPGvSn3AafrR0NIezlzGmkdd4SF0SL3KCjflwps4tas26zK/agnCyDe fQy0XfpXJwRZGO9Yl4nuCH9fA8gwwaa1mc+KhDQB5XRayVPhaXL11uFMxZtj9sfa3saZks c+oz01r9BKBCcgPvWo8nk0FjQKRixoU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-146-uU9BWdGCPfue2BuqLtC7dg-1; Tue, 05 Jul 2022 04:35:24 -0400 X-MC-Unique: uU9BWdGCPfue2BuqLtC7dg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C311C85A581; Tue, 5 Jul 2022 08:35:23 +0000 (UTC) Received: from localhost (ovpn-13-74.pek2.redhat.com [10.72.13.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 393584010D28; Tue, 5 Jul 2022 08:35:22 +0000 (UTC) Date: Tue, 5 Jul 2022 16:35:18 +0800 From: Baoquan He To: Ard Biesheuvel Cc: Will Deacon , kexec@lists.infradead.org, "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 Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation Message-ID: References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657010136; 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=0z2UhLA9zTx8MYx+v6FOVFe00lHXS/rANJnQv0UrSL8=; b=qMEmC9GqGE7CY6wzCSZNNrEKtUNWX5EA1KsVlgpvyLhShUkavE2SGOgzfOS3wUAzKTOpV6 Rfk6ZgrXyyQ3RcIOCszbt6wq6HO8BzUrMKhhec3OBjvHVKEdSeqi7eEBteZ22DqVoumO79 srx2teCXZSfz01VY7SeM6cmU45nLEwo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=cG4nakGB; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of bhe@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657010136; a=rsa-sha256; cv=none; b=7JRdeCZ0WvTRqcbE5VndRPi45hxPVvSoGnxoFFmgI7IY5uyduaMMVXkOJNCHj9x841gx42 NHqsn3fL/UBHbZQqczaSviw1ef950pdr/e+fmZLQIbiAuHaQ/I53ga8GwcCpBQQyliM8Bl Kq+y6H9NeAd3qah6EDcK7QGwoJw3oek= X-Rspam-User: X-Rspamd-Queue-Id: B0BCA40011 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=cG4nakGB; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf07.hostedemail.com: domain of bhe@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=bhe@redhat.com X-Stat-Signature: cyfyuk4fpsmjzj7c6jskfzpj5u96argf X-Rspamd-Server: rspam08 X-HE-Tag: 1657010135-296351 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 07/04/22 at 07:09pm, Ard Biesheuvel wrote: > 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. > > > > > > 在 2022/7/4 22:23, Will Deacon 写道: > > > > 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 to 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 rd/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 which > > > 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 preventing > > writes to memory which should not be writable, then you should use > > rodata=full. > > > > 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 != 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? Kernel text and rodata are remapped r/o in linear map, whereas module code and rodata are left writable, it's different concept than crashkernel region being mapped r/o. If it's doable in technology to remap module code and rodata r/o, and stamping into those regions will corrupt the entire system, we should do it too. However, kdump is a system error diagonosing mechanism which is very important and helpful on server, or some application scenarios, e.g cloud. Stamping into crashkernel region will make it useless. I am not against removing the arch_kexec_[un]protect_crashkres on arm64. It is a balance: Protecting the crashkernel region, causeing severe performance degradation. This is always felt since we usually don't specify rodata and enable kfence. Taking off the protecting of crashkernel region, performance improved very much, while wrong code may stamp into crashkernel region and fail kdump. That could happen one in a million. Once happen, it's a nightmare of kernel dev.