From: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
akpm@linux-foundation.org, joe@perches.com, dyoung@redhat.com
Subject: Re: [PATCH] kexec: fix the unexpected kexec_dprintk() macro
Date: Thu, 14 Mar 2024 21:02:54 +0800 [thread overview]
Message-ID: <ZfL1fvlfcziCVBsP@MiWiFi-R3L-srv> (raw)
In-Reply-To: <5d10552a-1c73-4f35-84be-ce6c1dcd800b@kernel.org>
On 03/14/24 at 12:54pm, Jiri Slaby wrote:
> On 14. 03. 24, 11:39, Baoquan He wrote:
> > Jiri reported that the current kexec_dprintk() always prints out
> > debugging message whenever kexec/kdmmp loading is triggered. That is
> > not wanted. The debugging message is supposed to be printed out when
> > 'kexec -s -d' is specified for kexec/kdump loading.
> >
> > After investigating, the reason is the current kexec_dprintk() takes
> > printk(KERN_INFO) or printk(KERN_DEBUG) depending on whether '-d' is
> > specified. However, distros usually have defaulg log level like below:
> >
> > [~]# cat /proc/sys/kernel/printk
> > 7 4 1 7
> >
> > So, even though '-d' is not specified, printk(KERN_DEBUG) also always
> > prints out. I thought printk(KERN_DEBUG) is equal to pr_debug(), it's
> > not.
> >
> > Fix it by changing to use pr_info() and pr_debug() instead which are
> > expected to work.
>
> Hi,
>
> sow, you'd need both -d, and dyndbg updates. Hence, again my question:
> ===
> Actually what was wrong on the pr_debug()s? Can you simply turn them on from
> the kernel when -d is passed to kexec instead of all this?
I checked code, it's because some codes are shared by both kexec_load and
kexec_file_load, e.g below function on arm64:
arch/arm64/kernel/machine_kexec.c:machine_kexec_post_load()
"kexec -c -l -d" is for kexec_load debugging message printing, it's all
done in user space kexec-tools utility. The pr_debug() have been there
for arm64 developer's debugging if they want to. I don't want to change
that.
If 'kexec -s -l -d', pr_info() is called to print out. If 'kexec -s -l'
w/o '-d', or 'kexec -c -l', it's still pr_debug just as before.
> ===
>
> And yet, it is still missing a prefix :).
It looks like this now, seems no need to add prefix.
[ 102.609784] kexec_file: kernel: 0000000081fc03e0 kernel_size: 0xccb200
[ 102.617084] PEFILE: Unsigned PE binary
[ 102.753174] ima: kexec measurement buffer for the loaded kernel at 0x71435000.
[ 102.761335] kexec-bzImage64: Loaded purgatory at 0x71430000
[ 102.767571] kexec-bzImage64: Loaded boot_param, command line and misc at 0x7142c000 bufsz=0x1320 memsz=0x2000
[ 102.778650] kexec-bzImage64: Loaded 64bit kernel at 0x6d000000 bufsz=0xcc6200 memsz=0x3c4c000
[ 102.788251] kexec-bzImage64: Loaded initrd at 0x6ac0f000 bufsz=0x23f0175 memsz=0x23f0175
[ 102.797283] kexec-bzImage64: Final command line is: root=/dev/mapper/fedora_lenovo--electron--sr850--01-root ro rd.lvm.lv=fedora_lenovo-electron-sr850-01/root console=ttyS0,115200n81
[ 102.815435] kexec-bzImage64: E820 memmap:
[ 102.819912] kexec-bzImage64: 0000000000000000-000000000003dfff (1)
[ 102.826817] kexec-bzImage64: 000000000003e000-000000000003ffff (2)
[ 103.021435] kexec-bzImage64: 00000000ff000000-00000000ffffffff (2)
......snip
[ 103.028336] kexec-bzImage64: 0000000100000000-000000403fffffff (1)
[ 103.269194] kexec_file: nr_segments = 5
[ 103.273484] kexec_file: segment[0]: buf=0x00000000898981dd bufsz=0x59e mem=0x71435000 memsz=0x1000
[ 103.283616] kexec_file: segment[1]: buf=0x000000003d8dd363 bufsz=0x4000 mem=0x71430000 memsz=0x5000
[ 103.293748] kexec_file: segment[2]: buf=0x00000000ba27c5ef bufsz=0x1320 mem=0x7142c000 memsz=0x2000
[ 103.303865] kexec_file: segment[3]: buf=0x0000000026acdcf4 bufsz=0xcc6200 mem=0x6d000000 memsz=0x3c4c000
[ 103.333455] kexec_file: segment[4]: buf=0x000000001a7dac7f bufsz=0x23f0175 mem=0x6ac0f000 memsz=0x23f1000
[ 103.356698] kexec_file: kexec_file_load: type:0, start:0x714301a0 head:0x1222da002 flags:0x8
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2024-03-14 13:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 10:39 [PATCH] kexec: fix the unexpected kexec_dprintk() macro Baoquan He
2024-03-14 11:54 ` Jiri Slaby
2024-03-14 13:02 ` Baoquan He [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZfL1fvlfcziCVBsP@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=jirislaby@kernel.org \
--cc=joe@perches.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).