print.rs: Allow printing in the kernel crate #223
Conversation
|
Looks like a maintainer needs to kick off the CI. |
|
Also the above comments look like spam, but I don't see the "Report content" options. Maybe that also needs to be done by a maintainer? |
adamrk
force-pushed
the
print-in-kernel-crate
branch
from
3a3dd93 to
ab632d5
Compare
|
Ah nevermind. That required an unstable feature to add attributes to statements. |
adamrk
force-pushed
the
print-in-kernel-crate
branch
from
ab632d5 to
9be9b9b
Compare
Yeah, it is a new "feature" of GitHub to prevent abuse. Their blog says it should only apply to first-time contributors, but it seems they are populating that table from scratch... I have also invited you to the organization (sorry, I thought you were already there), in case that helps. https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/ |
The `pr_*` print macros previously didn't compile when used from the `kernel` crate because they refer to the path `kernel` instead of using the `$crate` variable and require a `const __MODULE_NAME` to be defined in any crate in which they are used. This fixes both issues and changes the `__MODULE_NAME` to `__LOG_PREFIX` to reflect the fact that the print macro may be called from a module or a kernel library. Signed-off-by: Adam Bratschi-Kaye <[email protected]>
adamrk
force-pushed
the
print-in-kernel-crate
branch
from
9be9b9b to
e156312
Compare
Thanks! Seems like being a member of the org still isn't enough to run the CI, though. It's no rush anyway. |
|
You can always ping me if you need an approval! |
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much extra space will be needed in the device tree for some memory related properties. That logic uses the size of RAM divided by drmem_lmb_size() to do the estimation. However drmem_lmb_size() can be zero if the machine has no hotpluggable memory configured, which is the case when booting with qemu and no maxmem=x parameter is passed (the default). The division by zero is reported by UBSAN, and can also lead to an overflow and a warning from kvmalloc, and kdump kernel loading fails: WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160 Modules linked in: CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 #223 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,git-dd0dca pSeries NIP: c00000000041ff4c LR: c00000000041fe58 CTR: 0000000000000000 REGS: c0000000096ef750 TRAP: 0700 Not tainted (6.2.0-rc5-03455-g07358bd97810) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24248242 XER: 2004011e CFAR: c00000000041fed0 IRQMASK: 0 ... NIP kvmalloc_node+0x15c/0x160 LR kvmalloc_node+0x68/0x160 Call Trace: kvmalloc_node+0x68/0x160 (unreliable) of_kexec_alloc_and_setup_fdt+0xb8/0x7d0 elf64_load+0x25c/0x4a0 kexec_image_load_default+0x58/0x80 sys_kexec_file_load+0x5c0/0x920 system_call_exception+0x128/0x330 system_call_vectored_common+0x15c/0x2ec To fix it, skip the calculation if drmem_lmb_size() is zero. Fixes: 2377c92 ("powerpc/kexec_file: fix FDT size estimation for kdump kernel") Cc: [email protected] # v5.12+ Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
The
pr_*print macros previously didn't compile when used from thekernelcrate because they refer to the pathkernelinstead ofusing the
$cratevariable and require aconst __MODULE_NAMEto bedefined in any crate in which they are used.
This fixes both issues and changes the
__MODULE_NAMEto__LOG_PREFIXto reflect the fact that the print macro may be called from a module or
a kernel library.
Signed-off-by: Adam Bratschi-Kaye [email protected]