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 B5A6AC433FE for ; Fri, 30 Sep 2022 09:25:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E2B58D0002; Fri, 30 Sep 2022 05:25:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 191FF8D0001; Fri, 30 Sep 2022 05:25:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05A488D0002; Fri, 30 Sep 2022 05:25:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EBA9B8D0001 for ; Fri, 30 Sep 2022 05:24:59 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BC0971C6F9F for ; Fri, 30 Sep 2022 09:24:59 +0000 (UTC) X-FDA: 79968217518.06.FF8BE2F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf28.hostedemail.com (Postfix) with ESMTP id CD41FC0012 for ; Fri, 30 Sep 2022 09:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664529898; 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: in-reply-to:in-reply-to:references:references; bh=L1SJANDr5slVxmH6M0J7RBmBMz9Cu2VImN3b1/69eLw=; b=jRyeuvClWb+m+jZ+gdKxy6ufW8zui6JbWPBf6GtOlXoOGacZe8y3LqErdBl/Sg/AXGsjjk slPouInHFJiHeizQ+4h1TF3zny7hTAS3UHV5sa8L4qaHX3J8l+7bJctAI9TvQfo/Zu9X5G DrJHNmhmDDrTu0+UDMUvIV70+8w+UPk= 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-581-HRAnQ8q2MTqo1Wm3tV42Tg-1; Fri, 30 Sep 2022 05:24:54 -0400 X-MC-Unique: HRAnQ8q2MTqo1Wm3tV42Tg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EAB6C804184; Fri, 30 Sep 2022 09:24:53 +0000 (UTC) Received: from localhost (ovpn-12-133.pek2.redhat.com [10.72.12.133]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ACE17492CA2; Fri, 30 Sep 2022 09:24:52 +0000 (UTC) Date: Fri, 30 Sep 2022 17:24:48 +0800 From: Baoquan He To: Mike Rapoport , Chao Ye Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, guanghuifeng@linux.alibaba.com, mark.rutland@arm.com, will@kernel.org, linux-mm@kvack.org, thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com, kexec@lists.infradead.org Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Message-ID: References: <20220828005545.94389-2-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664529899; a=rsa-sha256; cv=none; b=GnK6YLWPelecbzRUlD7QV1eBA4FVywkRngKh+bYRLb0uyYSfNH5mWMvhTngbqXyE2/PoaC U74tL2HAPXqp+7yCTEoJk82HV0NLFjFC6HSuNrk3cYms0H2XpFWQal3TmQb6GVkxDbYFLZ KBFYlgjcP2zF3+7BBXTtw1TWK9FsQuk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=jRyeuvCl; spf=pass (imf28.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664529899; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L1SJANDr5slVxmH6M0J7RBmBMz9Cu2VImN3b1/69eLw=; b=qnEc93WVj6t3rZOi8l5/FdTyZi7uQVhtptMmeH7ueJAAQJnNTVabovCFx/U086U9y4urwf M0j2dg3yYkB5rlKdCcWwQC516EuikwpwUmOSJQuQLeZkUNPGh0dyxVv6DItVRzksWCMqmR 0TihTTZJHLh5uvshVC5khpXH54g++kQ= X-Stat-Signature: qeif3uq3anoag16e3ft9b3ceth9amc7f X-Rspamd-Queue-Id: CD41FC0012 X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=jRyeuvCl; spf=pass (imf28.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam01 X-HE-Tag: 1664529898-396979 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 09/30/22 at 03:04pm, Baoquan He wrote: > Hi Mike, > > On 09/21/22 at 10:45am, Mike Rapoport wrote: > > On Tue, Sep 06, 2022 at 03:05:57PM +0200, Ard Biesheuvel wrote: > > > > > > While I appreciate the effort that has gone into solving this problem, > > > I don't think there is any consensus that an elaborate fix is required > > > to ensure that the crash kernel can be unmapped from the linear map at > > > all cost. In fact, I personally think we shouldn't bother, and IIRC, > > > Will made a remark along the same lines back when the Huawei engineers > > > were still driving this effort. > > > > > > So perhaps we could align on that before doing yet another version of this? > > > > I suggest to start with disabling crash kernel protection when its memory > > reservation is deferred and then Baoquan and kdump folks can take it from > > here. > > Thanks for the attempt, really appreciated. We all tried and all see > everybody's effort on this issue. > > If disabling protection is chosen, I would suggest disable it at all. > The system w/o having CONFIG_ZONE_DMA|32 is rarely seen, I don't think > we need do the protection for it specifically to make code inconsistent > and could confuse people. We can revert below commit and its later > change do to that. > > commit 98d2e1539b84 ("arm64: kdump: protect crash dump kernel memory") > > For RPi4, I tried to find one to test and figure out if it can do crash > dumping with buffer above 1G. However, nobody care about kdump when I > asked people around who have one at hand for testing, hobby, or > developping. Since they are not familiar with kdump setting and not so > eager to get to know, and I don't want to take up too much time, finally > I just give up. Finally, I got help from Chao who is team lead of our kernel QE. Chao has a RPi4 and he tested different cases of kdump, now we can confirm that on RPi4 the TF card and usb disk are all 30bit DMA addressing limited. Just FYI. And thanks again to Chao for his help and patience.