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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2024-03-14 13:03 UTC|newest]
Thread overview: 6+ 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 10:39 ` Baoquan He
2024-03-14 11:54 ` Jiri Slaby
2024-03-14 11:54 ` Jiri Slaby
2024-03-14 13:02 ` Baoquan He [this message]
2024-03-14 13:02 ` Baoquan He
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.