Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp5071130rdb; Tue, 12 Dec 2023 19:23:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IEU2gY3DMAXLmL0a4oG+YrGH51hP8T6cl0vWy0eO6oMJh//+8T8Jpr+k+DkSMFzqx1Johxh X-Received: by 2002:a17:902:988e:b0:1d0:6ffe:a2c with SMTP id s14-20020a170902988e00b001d06ffe0a2cmr6135400plp.138.1702437819786; Tue, 12 Dec 2023 19:23:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702437819; cv=none; d=google.com; s=arc-20160816; b=lAaRrEvUGaUhYhnAGL9Ny8gfA+KsREr81pXE0UuDQ7LpP/odUteZZxYe5u8W27g2Rp dM8WiFhA0eT/xWbyDW7fQQaBEAMGaLbKOH6cN2di0SLOKdAMic+0bJcFNKFZQd2GEthz NP0xNjnngOUKDrXzZbV2ZYpAok1JQr04csarGS24RWYVQH7QDU0LFKvSxx8jkttUXQlN YEW4F/MQw4moepLdym0LLr0tPMEiwzWzkK/GalM/sFEL8jd6UKy1Rg34yh1gjuoJGq3e 2W1FsVauVZkWoFVDd9vCr+Tu7GtfDYnVQ3pcfvQ0cN8JDIOIJfSWU0NPDEi1xYoRpsOr W9BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kJBrP/wuvom17BSUXW0NG0A84o2uJgCWtjNkzp2u12s=; fh=ImyC61zYI7gDfmTihtgDjuSAQVUJSVxutmyN63p1YlE=; b=n4Kj+imWMvGvIENMKb7tGlnwUgziSgbfy7+ImU844dkrncHfkmVid4yPJQzjOUxzEO uvvpkIOUu7RltbgZa0nMQCPYvoInjR6UTeDCQV4xIqveOMUVFCiyt+jDka/8fDLIti2P e3uieTr2XJXSFXJfZCod+QNPyYw2g4DNtZrbN40AIRMKSKEshrRfgA+s0QgH/56LVoHZ CPs9NqL50DlIXbPuBImaqge1lnWqL2qITfkjnlR77Bga9eulvZ0KBfxH1yhwQ67jt1rE dmFB2u8h8wYQFGDmsNIp74LoKUafsiWVQFkV9uf5PaaBzdbnwKARBYGg6grGj8dCFHxe 5RHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MAe19yBn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id c12-20020a170902b68c00b001cf69ac4c14si8670298pls.444.2023.12.12.19.23.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 19:23:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MAe19yBn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 462B680B8E79; Tue, 12 Dec 2023 19:23:34 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378450AbjLMDXI (ORCPT + 99 others); Tue, 12 Dec 2023 22:23:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378437AbjLMDXH (ORCPT ); Tue, 12 Dec 2023 22:23:07 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6E22B0 for ; Tue, 12 Dec 2023 19:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702437792; 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=kJBrP/wuvom17BSUXW0NG0A84o2uJgCWtjNkzp2u12s=; b=MAe19yBnRO5GyuRmqM1t4/s+KJkZcSh2Kk9FGL1kqbPOvqDuyq7wwUQ0Gdbm1seYkff/ek 9gpHPS+518waLJslhlpEtbkotmvtU2bJxrqJkKo5f65qM7D8hO+dfuuz9TQ0wwNnpxB1T2 GcCkrOIrMn9m0hjf3jgwgVn+mLEvaAk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-656-qho-sWqZPYqtExHysk5vCA-1; Tue, 12 Dec 2023 22:23:11 -0500 X-MC-Unique: qho-sWqZPYqtExHysk5vCA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F9A43C29A62; Wed, 13 Dec 2023 03:23:10 +0000 (UTC) Received: from localhost (unknown [10.72.116.83]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 519BB2026D66; Wed, 13 Dec 2023 03:23:09 +0000 (UTC) Date: Wed, 13 Dec 2023 11:23:06 +0800 From: Baoquan He To: Conor Dooley Cc: Conor Dooley , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-parisc@vger.kernel.org, akpm@linux-foundation.org, joe@perches.com, nathan@kernel.org Subject: Re: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required Message-ID: References: <20231130023955.5257-1-bhe@redhat.com> <20231130023955.5257-6-bhe@redhat.com> <20231201-blog-blasphemy-985d2665903c@wendy> <20231204-liftoff-enclosure-d3e3daf0ab6e@spud> <20231206-pasta-embassy-c7250740b16c@spud> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 12 Dec 2023 19:23:34 -0800 (PST) On 12/07/23 at 07:22am, Baoquan He wrote: > On 12/06/23 at 04:54pm, Conor Dooley wrote: > > On Wed, Dec 06, 2023 at 11:37:52PM +0800, Baoquan He wrote: > > > On 12/04/23 at 04:14pm, Conor Dooley wrote: > > > > On Mon, Dec 04, 2023 at 11:38:05PM +0800, Baoquan He wrote: > > > > > On 12/01/23 at 10:38am, Conor Dooley wrote: > > > > > > On Thu, Nov 30, 2023 at 10:39:53AM +0800, Baoquan He wrote: > > > > > > > > > > > > $subject has a typo in the arch bit :) > > > > > > > > > > Indeed, will fix if need report. Thanks for careful checking. > > > > > > > > > > > > > > > > > > Replace pr_debug() with the newly added kexec_dprintk() in kexec_file > > > > > > > loading related codes. > > > > > > > > > > > > Commit messages should be understandable in isolation, but this only > > > > > > explains (part of) what is obvious in the diff. Why is this change > > > > > > being made? > > > > > > > > > > The purpose has been detailedly described in cover letter and patch 1 > > > > > log. Andrew has picked these patches into his tree and grabbed the cover > > > > > letter log into the relevant commit for people's later checking. All > > > > > these seven patches will be present in mainline together. This is common > > > > > way when posting patch series? Please let me know if I misunderstand > > > > > anything. > > > > > > > > Each patch having a commit message that explains why a change is being > > > > made is the expectation. It is especially useful to explain the why > > > > here, since it is not just a mechanical conversion of pr_debug()s as the > > > > commit message suggests. > > > > > > Sounds reasonable. I rephrase the patch 3 log as below, do you think > > > it's OK to you? > > > > Yes, but with one comment. > > > > > > > > I will also adjust patch logs on other ARCH once this one is done. > > > Thanks. > > > > > > ============================= > > > Subject: [PATCH v3 5/7] kexec_file, ricv: print out debugging message if required > > > > > > Then when specifying '-d' for kexec_file_load interface, loaded > > > locations of kernel/initrd/cmdline etc can be printed out to help debug. > > > > > > Here replace pr_debug() with the newly added kexec_dprintk() in kexec_file > > > loading related codes. > > > > > > > > And also replace pr_notice() with kexec_dprintk() in elf_kexec_load() > > > because it's make sense to always print out loaded location of purgatory > ~ > > > and device tree even though users don't expect the message. > > Fixed typo: > ========== > > And also replace pr_notice() with kexec_dprintk() in elf_kexec_load() > because it doesn't make sense to always print out loaded location of > purgatory and device tree even though users don't expect the message. I will post v4 to include these suggested changes, please add comments if there's any concern. Thanks for reviewing. > > > > > This seems to contradict what you said in your earlier mail, about > > moving these from notice to debug. I think you missed a negation in your > > new version of the commit message. What you said in response to me seems > > like a more complete explanation anyway: > > Ah, I made mistake when typing, these printing is only for debugging, > so always printing out them is not suggested. > > > always printing out the loaded location of purgatory and > > device tree doesn't make sense. It will be confusing when users > > see these even when they do normal kexec/kdump loading. > > > > Thanks, > > Conor. > > > > > And also remove kexec_image_info() because the content has been printed > > > out in generic code. > > > > > > ============================ > > > > > > > > > > > > > > > > > > > > > > > > > > > And also remove kexec_image_info() because the content has been printed > > > > > > > out in generic code. > > > > > > > > > > > > > > Signed-off-by: Baoquan He > > > > > > > --- > > > > > > > arch/riscv/kernel/elf_kexec.c | 11 ++++++----- > > > > > > > arch/riscv/kernel/machine_kexec.c | 26 -------------------------- > > > > > > > 2 files changed, 6 insertions(+), 31 deletions(-) > > > > > > > > > > > > > > diff --git a/arch/riscv/kernel/elf_kexec.c b/arch/riscv/kernel/elf_kexec.c > > > > > > > index e60fbd8660c4..5bd1ec3341fe 100644 > > > > > > > --- a/arch/riscv/kernel/elf_kexec.c > > > > > > > +++ b/arch/riscv/kernel/elf_kexec.c > > > > > > > @@ -216,7 +216,6 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf, > > > > > > > if (ret) > > > > > > > goto out; > > > > > > > kernel_start = image->start; > > > > > > > - pr_notice("The entry point of kernel at 0x%lx\n", image->start); > > > > > > > > > > > > > > /* Add the kernel binary to the image */ > > > > > > > ret = riscv_kexec_elf_load(image, &ehdr, &elf_info, > > > > > > > @@ -252,8 +251,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf, > > > > > > > image->elf_load_addr = kbuf.mem; > > > > > > > image->elf_headers_sz = headers_sz; > > > > > > > > > > > > > > - pr_debug("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n", > > > > > > > - image->elf_load_addr, kbuf.bufsz, kbuf.memsz); > > > > > > > + kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n", > > > > > > > + image->elf_load_addr, kbuf.bufsz, kbuf.memsz); > > > > > > > > > > > > > > /* Setup cmdline for kdump kernel case */ > > > > > > > modified_cmdline = setup_kdump_cmdline(image, cmdline, > > > > > > > @@ -275,6 +274,8 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf, > > > > > > > pr_err("Error loading purgatory ret=%d\n", ret); > > > > > > > goto out; > > > > > > > } > > > > > > > + kexec_dprintk("Loaded purgatory at 0x%lx\n", kbuf.mem); > > > > > > > + > > > > > > > ret = kexec_purgatory_get_set_symbol(image, "riscv_kernel_entry", > > > > > > > &kernel_start, > > > > > > > sizeof(kernel_start), 0); > > > > > > > @@ -293,7 +294,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf, > > > > > > > if (ret) > > > > > > > goto out; > > > > > > > initrd_pbase = kbuf.mem; > > > > > > > > > > > > > - pr_notice("Loaded initrd at 0x%lx\n", initrd_pbase); > > > > > > > + kexec_dprintk("Loaded initrd at 0x%lx\n", initrd_pbase); > > > > > > > > > > > > This is not a pr_debug(). > > > > > > > > > > > > > } > > > > > > > > > > > > > > /* Add the DTB to the image */ > > > > > > > @@ -318,7 +319,7 @@ static void *elf_kexec_load(struct kimage *image, char *kernel_buf, > > > > > > > } > > > > > > > /* Cache the fdt buffer address for memory cleanup */ > > > > > > > image->arch.fdt = fdt; > > > > > > > > > > > > > - pr_notice("Loaded device tree at 0x%lx\n", kbuf.mem); > > > > > > > + kexec_dprintk("Loaded device tree at 0x%lx\n", kbuf.mem); > > > > > > > > > > > > Neither is this. Why are they being moved from pr_notice()? > > > > > > > > > > You are right. > > > > > > > > > > While always printing out the loaded location of purgatory and > > > > > device tree doesn't make sense. It will be confusing when users > > > > > see these even when they do normal kexec/kdump loading. It should be > > > > > changed to pr_debug(). > > > > > > > > > > Which way do you suggest? > > > > > 1) change it back to pr_debug(), fix it in another patch; > > > > > 2) keep it as is in the patch; > > > > > > > > Personally I think it is fine to change them all in one patch, but the > > > > rationale for converting pr_notice() to your new debug infrastructure > > > > needs to be in the commit message. > > > > > > Sure, sounds good to me. I have changed the patch log to reflect this as > > > you suggested, please help check. Thanks again. > > > > >