CoreSight May 2021

coresight@lists.linaro.org

22 participants
29 discussions

Re: [PATCH v3 1/1] kernel.h: Split out panic and oops helpers

by Mathieu Poirier

On Tue, May 11, 2021 at 10:41:37AM +0300, Andy Shevchenko wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out panic and > oops helpers. > > There are several purposes of doing this: > - dropping dependency in bug.h > - dropping a loop by moving out panic_notifier.h > - unload kernel.h from something which has its own domain > > At the same time convert users tree-wide to use new headers, although > for the time being include new header back to kernel.h to avoid twisted > indirected includes for existing users. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> > Acked-by: Mike Rapoport <rppt(a)linux.ibm.com> > Acked-by: Corey Minyard <cminyard(a)mvista.com> > Acked-by: Christian Brauner <christian.brauner(a)ubuntu.com> > Acked-by: Arnd Bergmann <arnd(a)arndb.de> > Acked-by: Kees Cook <keescook(a)chromium.org> > Acked-by: Wei Liu <wei.liu(a)kernel.org> > Acked-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> > Co-developed-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Acked-by: Sebastian Reichel <sre(a)kernel.org> > Acked-by: Luis Chamberlain <mcgrof(a)kernel.org> > Acked-by: Stephen Boyd <sboyd(a)kernel.org> > Acked-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> > Acked-by: Helge Deller <deller(a)gmx.de> # parisc > --- > v3: rebased on top of v5.13-rc1, collected a few more tags > > Note WRT Andrew's SoB tag above: I have added it since part of the cases > I took from him. Andrew, feel free to amend or tell me how you want me > to do. > > arch/alpha/kernel/setup.c | 2 +- > arch/arm64/kernel/setup.c | 1 + > arch/mips/kernel/relocate.c | 1 + > arch/mips/sgi-ip22/ip22-reset.c | 1 + > arch/mips/sgi-ip32/ip32-reset.c | 1 + > arch/parisc/kernel/pdc_chassis.c | 1 + > arch/powerpc/kernel/setup-common.c | 1 + > arch/s390/kernel/ipl.c | 1 + > arch/sparc/kernel/sstate.c | 1 + > arch/um/drivers/mconsole_kern.c | 1 + > arch/um/kernel/um_arch.c | 1 + > arch/x86/include/asm/desc.h | 1 + > arch/x86/kernel/cpu/mshyperv.c | 1 + > arch/x86/kernel/setup.c | 1 + > arch/x86/purgatory/purgatory.c | 2 + > arch/x86/xen/enlighten.c | 1 + > arch/xtensa/platforms/iss/setup.c | 1 + > drivers/bus/brcmstb_gisb.c | 1 + > drivers/char/ipmi/ipmi_msghandler.c | 1 + > drivers/clk/analogbits/wrpll-cln28hpc.c | 4 + > drivers/edac/altera_edac.c | 1 + > drivers/firmware/google/gsmi.c | 1 + > drivers/hv/vmbus_drv.c | 1 + > .../hwtracing/coresight/coresight-cpu-debug.c | 1 + Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> > drivers/leds/trigger/ledtrig-activity.c | 1 + > drivers/leds/trigger/ledtrig-heartbeat.c | 1 + > drivers/leds/trigger/ledtrig-panic.c | 1 + > drivers/misc/bcm-vk/bcm_vk_dev.c | 1 + > drivers/misc/ibmasm/heartbeat.c | 1 + > drivers/misc/pvpanic/pvpanic.c | 1 + > drivers/net/ipa/ipa_smp2p.c | 1 + > drivers/parisc/power.c | 1 + > drivers/power/reset/ltc2952-poweroff.c | 1 + > drivers/remoteproc/remoteproc_core.c | 1 + Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> > drivers/s390/char/con3215.c | 1 + > drivers/s390/char/con3270.c | 1 + > drivers/s390/char/sclp.c | 1 + > drivers/s390/char/sclp_con.c | 1 + > drivers/s390/char/sclp_vt220.c | 1 + > drivers/s390/char/zcore.c | 1 + > drivers/soc/bcm/brcmstb/pm/pm-arm.c | 1 + > drivers/staging/olpc_dcon/olpc_dcon.c | 1 + > drivers/video/fbdev/hyperv_fb.c | 1 + > include/asm-generic/bug.h | 3 +- > include/linux/kernel.h | 84 +--------------- > include/linux/panic.h | 98 +++++++++++++++++++ > include/linux/panic_notifier.h | 12 +++ > kernel/hung_task.c | 1 + > kernel/kexec_core.c | 1 + > kernel/panic.c | 1 + > kernel/rcu/tree.c | 2 + > kernel/sysctl.c | 1 + > kernel/trace/trace.c | 1 + > 53 files changed, 167 insertions(+), 85 deletions(-) > create mode 100644 include/linux/panic.h > create mode 100644 include/linux/panic_notifier.h > > diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c > index 03dda3beb3bd..5d1296534682 100644 > --- a/arch/alpha/kernel/setup.c > +++ b/arch/alpha/kernel/setup.c > @@ -28,6 +28,7 @@ > #include <linux/init.h> > #include <linux/string.h> > #include <linux/ioport.h> > +#include <linux/panic_notifier.h> > #include <linux/platform_device.h> > #include <linux/memblock.h> > #include <linux/pci.h> > @@ -46,7 +47,6 @@ > #include <linux/log2.h> > #include <linux/export.h> > > -extern struct atomic_notifier_head panic_notifier_list; > static int alpha_panic_event(struct notifier_block *, unsigned long, void *); > static struct notifier_block alpha_panic_block = { > alpha_panic_event, > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 61845c0821d9..787bc0f601b3 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -23,6 +23,7 @@ > #include <linux/interrupt.h> > #include <linux/smp.h> > #include <linux/fs.h> > +#include <linux/panic_notifier.h> > #include <linux/proc_fs.h> > #include <linux/memblock.h> > #include <linux/of_fdt.h> > diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c > index 499a5357c09f..56b51de2dc51 100644 > --- a/arch/mips/kernel/relocate.c > +++ b/arch/mips/kernel/relocate.c > @@ -18,6 +18,7 @@ > #include <linux/kernel.h> > #include <linux/libfdt.h> > #include <linux/of_fdt.h> > +#include <linux/panic_notifier.h> > #include <linux/sched/task.h> > #include <linux/start_kernel.h> > #include <linux/string.h> > diff --git a/arch/mips/sgi-ip22/ip22-reset.c b/arch/mips/sgi-ip22/ip22-reset.c > index c374f3ceec38..9028dbbb45dd 100644 > --- a/arch/mips/sgi-ip22/ip22-reset.c > +++ b/arch/mips/sgi-ip22/ip22-reset.c > @@ -12,6 +12,7 @@ > #include <linux/kernel.h> > #include <linux/sched/signal.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/pm.h> > #include <linux/timer.h> > > diff --git a/arch/mips/sgi-ip32/ip32-reset.c b/arch/mips/sgi-ip32/ip32-reset.c > index 20d8637340be..18d1c115cd53 100644 > --- a/arch/mips/sgi-ip32/ip32-reset.c > +++ b/arch/mips/sgi-ip32/ip32-reset.c > @@ -12,6 +12,7 @@ > #include <linux/init.h> > #include <linux/kernel.h> > #include <linux/module.h> > +#include <linux/panic_notifier.h> > #include <linux/sched.h> > #include <linux/sched/signal.h> > #include <linux/notifier.h> > diff --git a/arch/parisc/kernel/pdc_chassis.c b/arch/parisc/kernel/pdc_chassis.c > index 75ae88d13909..da154406d368 100644 > --- a/arch/parisc/kernel/pdc_chassis.c > +++ b/arch/parisc/kernel/pdc_chassis.c > @@ -20,6 +20,7 @@ > #include <linux/init.h> > #include <linux/module.h> > #include <linux/kernel.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/notifier.h> > #include <linux/cache.h> > diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c > index 74a98fff2c2f..046fe21b5c3b 100644 > --- a/arch/powerpc/kernel/setup-common.c > +++ b/arch/powerpc/kernel/setup-common.c > @@ -9,6 +9,7 @@ > #undef DEBUG > > #include <linux/export.h> > +#include <linux/panic_notifier.h> > #include <linux/string.h> > #include <linux/sched.h> > #include <linux/init.h> > diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c > index dba04fbc37a2..36f870dc944f 100644 > --- a/arch/s390/kernel/ipl.c > +++ b/arch/s390/kernel/ipl.c > @@ -13,6 +13,7 @@ > #include <linux/init.h> > #include <linux/device.h> > #include <linux/delay.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/ctype.h> > #include <linux/fs.h> > diff --git a/arch/sparc/kernel/sstate.c b/arch/sparc/kernel/sstate.c > index ac8677c3841e..3bcc4ddc6911 100644 > --- a/arch/sparc/kernel/sstate.c > +++ b/arch/sparc/kernel/sstate.c > @@ -6,6 +6,7 @@ > > #include <linux/kernel.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/init.h> > > diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c > index 6d00af25ec6b..328b16f99b30 100644 > --- a/arch/um/drivers/mconsole_kern.c > +++ b/arch/um/drivers/mconsole_kern.c > @@ -12,6 +12,7 @@ > #include <linux/mm.h> > #include <linux/module.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/sched/debug.h> > #include <linux/proc_fs.h> > diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c > index 74e07e748a9b..9512253947d5 100644 > --- a/arch/um/kernel/um_arch.c > +++ b/arch/um/kernel/um_arch.c > @@ -7,6 +7,7 @@ > #include <linux/init.h> > #include <linux/mm.h> > #include <linux/module.h> > +#include <linux/panic_notifier.h> > #include <linux/seq_file.h> > #include <linux/string.h> > #include <linux/utsname.h> > diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h > index 476082a83d1c..ceb12683b6d1 100644 > --- a/arch/x86/include/asm/desc.h > +++ b/arch/x86/include/asm/desc.h > @@ -9,6 +9,7 @@ > #include <asm/irq_vectors.h> > #include <asm/cpu_entry_area.h> > > +#include <linux/debug_locks.h> > #include <linux/smp.h> > #include <linux/percpu.h> > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > index 22f13343b5da..9e5c6f2b044d 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -17,6 +17,7 @@ > #include <linux/irq.h> > #include <linux/kexec.h> > #include <linux/i8253.h> > +#include <linux/panic_notifier.h> > #include <linux/random.h> > #include <asm/processor.h> > #include <asm/hypervisor.h> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 72920af0b3c0..bdcdd29efea6 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -14,6 +14,7 @@ > #include <linux/initrd.h> > #include <linux/iscsi_ibft.h> > #include <linux/memblock.h> > +#include <linux/panic_notifier.h> > #include <linux/pci.h> > #include <linux/root_dev.h> > #include <linux/hugetlb.h> > diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c > index f03b64d9cb51..7558139920f8 100644 > --- a/arch/x86/purgatory/purgatory.c > +++ b/arch/x86/purgatory/purgatory.c > @@ -9,6 +9,8 @@ > */ > > #include <linux/bug.h> > +#include <linux/kernel.h> > +#include <linux/types.h> > #include <crypto/sha2.h> > #include <asm/purgatory.h> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index aa9f50fccc5d..c79bd0af2e8c 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -6,6 +6,7 @@ > #include <linux/cpu.h> > #include <linux/kexec.h> > #include <linux/slab.h> > +#include <linux/panic_notifier.h> > > #include <xen/xen.h> > #include <xen/features.h> > diff --git a/arch/xtensa/platforms/iss/setup.c b/arch/xtensa/platforms/iss/setup.c > index ed519aee0ec8..d3433e1bb94e 100644 > --- a/arch/xtensa/platforms/iss/setup.c > +++ b/arch/xtensa/platforms/iss/setup.c > @@ -14,6 +14,7 @@ > #include <linux/init.h> > #include <linux/kernel.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/printk.h> > #include <linux/string.h> > > diff --git a/drivers/bus/brcmstb_gisb.c b/drivers/bus/brcmstb_gisb.c > index 7355fa2cb439..6551286a60cc 100644 > --- a/drivers/bus/brcmstb_gisb.c > +++ b/drivers/bus/brcmstb_gisb.c > @@ -6,6 +6,7 @@ > #include <linux/init.h> > #include <linux/types.h> > #include <linux/module.h> > +#include <linux/panic_notifier.h> > #include <linux/platform_device.h> > #include <linux/interrupt.h> > #include <linux/sysfs.h> > diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c > index 8a0e97b33cae..e96cb5c4f97a 100644 > --- a/drivers/char/ipmi/ipmi_msghandler.c > +++ b/drivers/char/ipmi/ipmi_msghandler.c > @@ -16,6 +16,7 @@ > > #include <linux/module.h> > #include <linux/errno.h> > +#include <linux/panic_notifier.h> > #include <linux/poll.h> > #include <linux/sched.h> > #include <linux/seq_file.h> > diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c b/drivers/clk/analogbits/wrpll-cln28hpc.c > index 776ead319ae9..7c64ea52a8d5 100644 > --- a/drivers/clk/analogbits/wrpll-cln28hpc.c > +++ b/drivers/clk/analogbits/wrpll-cln28hpc.c > @@ -23,8 +23,12 @@ > > #include <linux/bug.h> > #include <linux/err.h> > +#include <linux/limits.h> > #include <linux/log2.h> > #include <linux/math64.h> > +#include <linux/math.h> > +#include <linux/minmax.h> > + > #include <linux/clk/analogbits-wrpll-cln28hpc.h> > > /* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */ > diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c > index 5f7fd79ec82f..61c21bd880a4 100644 > --- a/drivers/edac/altera_edac.c > +++ b/drivers/edac/altera_edac.c > @@ -20,6 +20,7 @@ > #include <linux/of_address.h> > #include <linux/of_irq.h> > #include <linux/of_platform.h> > +#include <linux/panic_notifier.h> > #include <linux/platform_device.h> > #include <linux/regmap.h> > #include <linux/types.h> > diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c > index bb6e77ee3898..adaa492c3d2d 100644 > --- a/drivers/firmware/google/gsmi.c > +++ b/drivers/firmware/google/gsmi.c > @@ -19,6 +19,7 @@ > #include <linux/dma-mapping.h> > #include <linux/fs.h> > #include <linux/slab.h> > +#include <linux/panic_notifier.h> > #include <linux/ioctl.h> > #include <linux/acpi.h> > #include <linux/io.h> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index 92cb3f7d21d9..57bbbaa4e8f7 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -25,6 +25,7 @@ > > #include <linux/delay.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/ptrace.h> > #include <linux/screen_info.h> > #include <linux/kdebug.h> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c > index 2dcf13de751f..9731d3a96073 100644 > --- a/drivers/hwtracing/coresight/coresight-cpu-debug.c > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c > @@ -17,6 +17,7 @@ > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/moduleparam.h> > +#include <linux/panic_notifier.h> > #include <linux/pm_qos.h> > #include <linux/slab.h> > #include <linux/smp.h> > diff --git a/drivers/leds/trigger/ledtrig-activity.c b/drivers/leds/trigger/ledtrig-activity.c > index 14ba7faaed9e..30bc9df03636 100644 > --- a/drivers/leds/trigger/ledtrig-activity.c > +++ b/drivers/leds/trigger/ledtrig-activity.c > @@ -11,6 +11,7 @@ > #include <linux/kernel_stat.h> > #include <linux/leds.h> > #include <linux/module.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/sched.h> > #include <linux/slab.h> > diff --git a/drivers/leds/trigger/ledtrig-heartbeat.c b/drivers/leds/trigger/ledtrig-heartbeat.c > index 36b6709afe9f..7fe0a05574d2 100644 > --- a/drivers/leds/trigger/ledtrig-heartbeat.c > +++ b/drivers/leds/trigger/ledtrig-heartbeat.c > @@ -11,6 +11,7 @@ > #include <linux/module.h> > #include <linux/kernel.h> > #include <linux/init.h> > +#include <linux/panic_notifier.h> > #include <linux/slab.h> > #include <linux/timer.h> > #include <linux/sched.h> > diff --git a/drivers/leds/trigger/ledtrig-panic.c b/drivers/leds/trigger/ledtrig-panic.c > index 5751cd032f9d..64abf2e91608 100644 > --- a/drivers/leds/trigger/ledtrig-panic.c > +++ b/drivers/leds/trigger/ledtrig-panic.c > @@ -8,6 +8,7 @@ > #include <linux/kernel.h> > #include <linux/init.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/leds.h> > #include "../leds.h" > > diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c > index 6bfea3210389..ad639ee85b2a 100644 > --- a/drivers/misc/bcm-vk/bcm_vk_dev.c > +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c > @@ -9,6 +9,7 @@ > #include <linux/fs.h> > #include <linux/idr.h> > #include <linux/interrupt.h> > +#include <linux/panic_notifier.h> > #include <linux/kref.h> > #include <linux/module.h> > #include <linux/mutex.h> > diff --git a/drivers/misc/ibmasm/heartbeat.c b/drivers/misc/ibmasm/heartbeat.c > index 4f5f3bdc814d..59c9a0d95659 100644 > --- a/drivers/misc/ibmasm/heartbeat.c > +++ b/drivers/misc/ibmasm/heartbeat.c > @@ -9,6 +9,7 @@ > */ > > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include "ibmasm.h" > #include "dot_command.h" > #include "lowlevel.h" > diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c > index 65f70a4da8c0..793ea0c01193 100644 > --- a/drivers/misc/pvpanic/pvpanic.c > +++ b/drivers/misc/pvpanic/pvpanic.c > @@ -13,6 +13,7 @@ > #include <linux/mod_devicetable.h> > #include <linux/module.h> > #include <linux/platform_device.h> > +#include <linux/panic_notifier.h> > #include <linux/types.h> > #include <linux/cdev.h> > #include <linux/list.h> > diff --git a/drivers/net/ipa/ipa_smp2p.c b/drivers/net/ipa/ipa_smp2p.c > index a5f7a79a1923..34b68dc43886 100644 > --- a/drivers/net/ipa/ipa_smp2p.c > +++ b/drivers/net/ipa/ipa_smp2p.c > @@ -8,6 +8,7 @@ > #include <linux/device.h> > #include <linux/interrupt.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/soc/qcom/smem.h> > #include <linux/soc/qcom/smem_state.h> > > diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c > index ebaf6867b457..456776bd8ee6 100644 > --- a/drivers/parisc/power.c > +++ b/drivers/parisc/power.c > @@ -38,6 +38,7 @@ > #include <linux/init.h> > #include <linux/kernel.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/sched/signal.h> > #include <linux/kthread.h> > diff --git a/drivers/power/reset/ltc2952-poweroff.c b/drivers/power/reset/ltc2952-poweroff.c > index d1495af30081..8688c8ba8894 100644 > --- a/drivers/power/reset/ltc2952-poweroff.c > +++ b/drivers/power/reset/ltc2952-poweroff.c > @@ -52,6 +52,7 @@ > #include <linux/slab.h> > #include <linux/kmod.h> > #include <linux/module.h> > +#include <linux/panic_notifier.h> > #include <linux/mod_devicetable.h> > #include <linux/gpio/consumer.h> > #include <linux/reboot.h> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 626a6b90fba2..76dd8e2b1e7e 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -20,6 +20,7 @@ > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/device.h> > +#include <linux/panic_notifier.h> > #include <linux/slab.h> > #include <linux/mutex.h> > #include <linux/dma-map-ops.h> > diff --git a/drivers/s390/char/con3215.c b/drivers/s390/char/con3215.c > index 1fd5bca9fa20..02523f4e29f4 100644 > --- a/drivers/s390/char/con3215.c > +++ b/drivers/s390/char/con3215.c > @@ -19,6 +19,7 @@ > #include <linux/console.h> > #include <linux/interrupt.h> > #include <linux/err.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/serial.h> /* ASYNC_* flags */ > #include <linux/slab.h> > diff --git a/drivers/s390/char/con3270.c b/drivers/s390/char/con3270.c > index e21962c0fd94..87cdbace1453 100644 > --- a/drivers/s390/char/con3270.c > +++ b/drivers/s390/char/con3270.c > @@ -13,6 +13,7 @@ > #include <linux/init.h> > #include <linux/interrupt.h> > #include <linux/list.h> > +#include <linux/panic_notifier.h> > #include <linux/types.h> > #include <linux/slab.h> > #include <linux/err.h> > diff --git a/drivers/s390/char/sclp.c b/drivers/s390/char/sclp.c > index 986bbbc23d0a..6627820a5eb9 100644 > --- a/drivers/s390/char/sclp.c > +++ b/drivers/s390/char/sclp.c > @@ -11,6 +11,7 @@ > #include <linux/kernel_stat.h> > #include <linux/module.h> > #include <linux/err.h> > +#include <linux/panic_notifier.h> > #include <linux/spinlock.h> > #include <linux/interrupt.h> > #include <linux/timer.h> > diff --git a/drivers/s390/char/sclp_con.c b/drivers/s390/char/sclp_con.c > index 9b852a47ccc1..cc01a7b8595d 100644 > --- a/drivers/s390/char/sclp_con.c > +++ b/drivers/s390/char/sclp_con.c > @@ -10,6 +10,7 @@ > #include <linux/kmod.h> > #include <linux/console.h> > #include <linux/init.h> > +#include <linux/panic_notifier.h> > #include <linux/timer.h> > #include <linux/jiffies.h> > #include <linux/termios.h> > diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c > index 7f4445b0f819..5b8a7b090a97 100644 > --- a/drivers/s390/char/sclp_vt220.c > +++ b/drivers/s390/char/sclp_vt220.c > @@ -9,6 +9,7 @@ > > #include <linux/module.h> > #include <linux/spinlock.h> > +#include <linux/panic_notifier.h> > #include <linux/list.h> > #include <linux/wait.h> > #include <linux/timer.h> > diff --git a/drivers/s390/char/zcore.c b/drivers/s390/char/zcore.c > index bd3c724bf695..b5b0848da93b 100644 > --- a/drivers/s390/char/zcore.c > +++ b/drivers/s390/char/zcore.c > @@ -15,6 +15,7 @@ > #include <linux/init.h> > #include <linux/slab.h> > #include <linux/debugfs.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > > #include <asm/asm-offsets.h> > diff --git a/drivers/soc/bcm/brcmstb/pm/pm-arm.c b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > index a673fdffe216..3cbb165d6e30 100644 > --- a/drivers/soc/bcm/brcmstb/pm/pm-arm.c > +++ b/drivers/soc/bcm/brcmstb/pm/pm-arm.c > @@ -28,6 +28,7 @@ > #include <linux/notifier.h> > #include <linux/of.h> > #include <linux/of_address.h> > +#include <linux/panic_notifier.h> > #include <linux/platform_device.h> > #include <linux/pm.h> > #include <linux/printk.h> > diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c b/drivers/staging/olpc_dcon/olpc_dcon.c > index 6d8e9a481786..7284cb4ac395 100644 > --- a/drivers/staging/olpc_dcon/olpc_dcon.c > +++ b/drivers/staging/olpc_dcon/olpc_dcon.c > @@ -22,6 +22,7 @@ > #include <linux/device.h> > #include <linux/uaccess.h> > #include <linux/ctype.h> > +#include <linux/panic_notifier.h> > #include <linux/reboot.h> > #include <linux/olpc-ec.h> > #include <asm/tsc.h> > diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c > index a7e6eea2c4a1..23999df52739 100644 > --- a/drivers/video/fbdev/hyperv_fb.c > +++ b/drivers/video/fbdev/hyperv_fb.c > @@ -52,6 +52,7 @@ > #include <linux/completion.h> > #include <linux/fb.h> > #include <linux/pci.h> > +#include <linux/panic_notifier.h> > #include <linux/efi.h> > #include <linux/console.h> > > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h > index b402494883b6..f152b9bb916f 100644 > --- a/include/asm-generic/bug.h > +++ b/include/asm-generic/bug.h > @@ -17,7 +17,8 @@ > #endif > > #ifndef __ASSEMBLY__ > -#include <linux/kernel.h> > +#include <linux/panic.h> > +#include <linux/printk.h> > > #ifdef CONFIG_BUG > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h > index 15d8bad3d2f2..50f4a57cf50c 100644 > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -14,6 +14,7 @@ > #include <linux/math.h> > #include <linux/minmax.h> > #include <linux/typecheck.h> > +#include <linux/panic.h> > #include <linux/printk.h> > #include <linux/build_bug.h> > #include <linux/static_call_types.h> > @@ -72,7 +73,6 @@ > #define lower_32_bits(n) ((u32)((n) & 0xffffffff)) > > struct completion; > -struct pt_regs; > struct user; > > #ifdef CONFIG_PREEMPT_VOLUNTARY > @@ -177,14 +177,6 @@ void __might_fault(const char *file, int line); > static inline void might_fault(void) { } > #endif > > -extern struct atomic_notifier_head panic_notifier_list; > -extern long (*panic_blink)(int state); > -__printf(1, 2) > -void panic(const char *fmt, ...) __noreturn __cold; > -void nmi_panic(struct pt_regs *regs, const char *msg); > -extern void oops_enter(void); > -extern void oops_exit(void); > -extern bool oops_may_print(void); > void do_exit(long error_code) __noreturn; > void complete_and_exit(struct completion *, long) __noreturn; > > @@ -370,52 +362,8 @@ extern int __kernel_text_address(unsigned long addr); > extern int kernel_text_address(unsigned long addr); > extern int func_ptr_is_kernel_text(void *ptr); > > -#ifdef CONFIG_SMP > -extern unsigned int sysctl_oops_all_cpu_backtrace; > -#else > -#define sysctl_oops_all_cpu_backtrace 0 > -#endif /* CONFIG_SMP */ > - > extern void bust_spinlocks(int yes); > -extern int panic_timeout; > -extern unsigned long panic_print; > -extern int panic_on_oops; > -extern int panic_on_unrecovered_nmi; > -extern int panic_on_io_nmi; > -extern int panic_on_warn; > -extern unsigned long panic_on_taint; > -extern bool panic_on_taint_nousertaint; > -extern int sysctl_panic_on_rcu_stall; > -extern int sysctl_max_rcu_stall_to_panic; > -extern int sysctl_panic_on_stackoverflow; > - > -extern bool crash_kexec_post_notifiers; > > -/* > - * panic_cpu is used for synchronizing panic() and crash_kexec() execution. It > - * holds a CPU number which is executing panic() currently. A value of > - * PANIC_CPU_INVALID means no CPU has entered panic() or crash_kexec(). > - */ > -extern atomic_t panic_cpu; > -#define PANIC_CPU_INVALID -1 > - > -/* > - * Only to be used by arch init code. If the user over-wrote the default > - * CONFIG_PANIC_TIMEOUT, honor it. > - */ > -static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout) > -{ > - if (panic_timeout == arch_default_timeout) > - panic_timeout = timeout; > -} > -extern const char *print_tainted(void); > -enum lockdep_ok { > - LOCKDEP_STILL_OK, > - LOCKDEP_NOW_UNRELIABLE > -}; > -extern void add_taint(unsigned flag, enum lockdep_ok); > -extern int test_taint(unsigned flag); > -extern unsigned long get_taint(void); > extern int root_mountflags; > > extern bool early_boot_irqs_disabled; > @@ -434,36 +382,6 @@ extern enum system_states { > SYSTEM_SUSPEND, > } system_state; > > -/* This cannot be an enum because some may be used in assembly source. */ > -#define TAINT_PROPRIETARY_MODULE 0 > -#define TAINT_FORCED_MODULE 1 > -#define TAINT_CPU_OUT_OF_SPEC 2 > -#define TAINT_FORCED_RMMOD 3 > -#define TAINT_MACHINE_CHECK 4 > -#define TAINT_BAD_PAGE 5 > -#define TAINT_USER 6 > -#define TAINT_DIE 7 > -#define TAINT_OVERRIDDEN_ACPI_TABLE 8 > -#define TAINT_WARN 9 > -#define TAINT_CRAP 10 > -#define TAINT_FIRMWARE_WORKAROUND 11 > -#define TAINT_OOT_MODULE 12 > -#define TAINT_UNSIGNED_MODULE 13 > -#define TAINT_SOFTLOCKUP 14 > -#define TAINT_LIVEPATCH 15 > -#define TAINT_AUX 16 > -#define TAINT_RANDSTRUCT 17 > -#define TAINT_FLAGS_COUNT 18 > -#define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1) > - > -struct taint_flag { > - char c_true; /* character printed when tainted */ > - char c_false; /* character printed when not tainted */ > - bool module; /* also show as a per-module taint flag */ > -}; > - > -extern const struct taint_flag taint_flags[TAINT_FLAGS_COUNT]; > - > extern const char hex_asc[]; > #define hex_asc_lo(x) hex_asc[((x) & 0x0f)] > #define hex_asc_hi(x) hex_asc[((x) & 0xf0) >> 4] > diff --git a/include/linux/panic.h b/include/linux/panic.h > new file mode 100644 > index 000000000000..f5844908a089 > --- /dev/null > +++ b/include/linux/panic.h > @@ -0,0 +1,98 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_PANIC_H > +#define _LINUX_PANIC_H > + > +#include <linux/compiler_attributes.h> > +#include <linux/types.h> > + > +struct pt_regs; > + > +extern long (*panic_blink)(int state); > +__printf(1, 2) > +void panic(const char *fmt, ...) __noreturn __cold; > +void nmi_panic(struct pt_regs *regs, const char *msg); > +extern void oops_enter(void); > +extern void oops_exit(void); > +extern bool oops_may_print(void); > + > +#ifdef CONFIG_SMP > +extern unsigned int sysctl_oops_all_cpu_backtrace; > +#else > +#define sysctl_oops_all_cpu_backtrace 0 > +#endif /* CONFIG_SMP */ > + > +extern int panic_timeout; > +extern unsigned long panic_print; > +extern int panic_on_oops; > +extern int panic_on_unrecovered_nmi; > +extern int panic_on_io_nmi; > +extern int panic_on_warn; > + > +extern unsigned long panic_on_taint; > +extern bool panic_on_taint_nousertaint; > + > +extern int sysctl_panic_on_rcu_stall; > +extern int sysctl_max_rcu_stall_to_panic; > +extern int sysctl_panic_on_stackoverflow; > + > +extern bool crash_kexec_post_notifiers; > + > +/* > + * panic_cpu is used for synchronizing panic() and crash_kexec() execution. It > + * holds a CPU number which is executing panic() currently. A value of > + * PANIC_CPU_INVALID means no CPU has entered panic() or crash_kexec(). > + */ > +extern atomic_t panic_cpu; > +#define PANIC_CPU_INVALID -1 > + > +/* > + * Only to be used by arch init code. If the user over-wrote the default > + * CONFIG_PANIC_TIMEOUT, honor it. > + */ > +static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout) > +{ > + if (panic_timeout == arch_default_timeout) > + panic_timeout = timeout; > +} > + > +/* This cannot be an enum because some may be used in assembly source. */ > +#define TAINT_PROPRIETARY_MODULE 0 > +#define TAINT_FORCED_MODULE 1 > +#define TAINT_CPU_OUT_OF_SPEC 2 > +#define TAINT_FORCED_RMMOD 3 > +#define TAINT_MACHINE_CHECK 4 > +#define TAINT_BAD_PAGE 5 > +#define TAINT_USER 6 > +#define TAINT_DIE 7 > +#define TAINT_OVERRIDDEN_ACPI_TABLE 8 > +#define TAINT_WARN 9 > +#define TAINT_CRAP 10 > +#define TAINT_FIRMWARE_WORKAROUND 11 > +#define TAINT_OOT_MODULE 12 > +#define TAINT_UNSIGNED_MODULE 13 > +#define TAINT_SOFTLOCKUP 14 > +#define TAINT_LIVEPATCH 15 > +#define TAINT_AUX 16 > +#define TAINT_RANDSTRUCT 17 > +#define TAINT_FLAGS_COUNT 18 > +#define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1) > + > +struct taint_flag { > + char c_true; /* character printed when tainted */ > + char c_false; /* character printed when not tainted */ > + bool module; /* also show as a per-module taint flag */ > +}; > + > +extern const struct taint_flag taint_flags[TAINT_FLAGS_COUNT]; > + > +enum lockdep_ok { > + LOCKDEP_STILL_OK, > + LOCKDEP_NOW_UNRELIABLE, > +}; > + > +extern const char *print_tainted(void); > +extern void add_taint(unsigned flag, enum lockdep_ok); > +extern int test_taint(unsigned flag); > +extern unsigned long get_taint(void); > + > +#endif /* _LINUX_PANIC_H */ > diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h > new file mode 100644 > index 000000000000..41e32483d7a7 > --- /dev/null > +++ b/include/linux/panic_notifier.h > @@ -0,0 +1,12 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_PANIC_NOTIFIERS_H > +#define _LINUX_PANIC_NOTIFIERS_H > + > +#include <linux/notifier.h> > +#include <linux/types.h> > + > +extern struct atomic_notifier_head panic_notifier_list; > + > +extern bool crash_kexec_post_notifiers; > + > +#endif /* _LINUX_PANIC_NOTIFIERS_H */ > diff --git a/kernel/hung_task.c b/kernel/hung_task.c > index bb2e3e15c84c..2871076e4d29 100644 > --- a/kernel/hung_task.c > +++ b/kernel/hung_task.c > @@ -15,6 +15,7 @@ > #include <linux/kthread.h> > #include <linux/lockdep.h> > #include <linux/export.h> > +#include <linux/panic_notifier.h> > #include <linux/sysctl.h> > #include <linux/suspend.h> > #include <linux/utsname.h> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index f099baee3578..4b34a9aa32bc 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -26,6 +26,7 @@ > #include <linux/suspend.h> > #include <linux/device.h> > #include <linux/freezer.h> > +#include <linux/panic_notifier.h> > #include <linux/pm.h> > #include <linux/cpu.h> > #include <linux/uaccess.h> > diff --git a/kernel/panic.c b/kernel/panic.c > index 332736a72a58..edad89660a2b 100644 > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -23,6 +23,7 @@ > #include <linux/reboot.h> > #include <linux/delay.h> > #include <linux/kexec.h> > +#include <linux/panic_notifier.h> > #include <linux/sched.h> > #include <linux/sysrq.h> > #include <linux/init.h> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 3a5fef9fc934..faa847ce28cd 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -32,6 +32,8 @@ > #include <linux/export.h> > #include <linux/completion.h> > #include <linux/moduleparam.h> > +#include <linux/panic.h> > +#include <linux/panic_notifier.h> > #include <linux/percpu.h> > #include <linux/notifier.h> > #include <linux/cpu.h> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c > index 6e0b77f1117c..304be14fa09b 100644 > --- a/kernel/sysctl.c > +++ b/kernel/sysctl.c > @@ -27,6 +27,7 @@ > #include <linux/sysctl.h> > #include <linux/bitmap.h> > #include <linux/signal.h> > +#include <linux/panic.h> > #include <linux/printk.h> > #include <linux/proc_fs.h> > #include <linux/security.h> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 560e4c8d3825..1c4e702133e8 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -39,6 +39,7 @@ > #include <linux/slab.h> > #include <linux/ctype.h> > #include <linux/init.h> > +#include <linux/panic_notifier.h> > #include <linux/poll.h> > #include <linux/nmi.h> > #include <linux/fs.h> > -- > 2.30.2 >

5 years, 4 months

Re: [PATCH v3 1/1] kernel.h: Split out panic and oops helpers

by Alex Elder

On 5/11/21 2:41 AM, Andy Shevchenko wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out panic and > oops helpers. > > There are several purposes of doing this: > - dropping dependency in bug.h > - dropping a loop by moving out panic_notifier.h > - unload kernel.h from something which has its own domain > > At the same time convert users tree-wide to use new headers, although > for the time being include new header back to kernel.h to avoid twisted > indirected includes for existing users. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> > Acked-by: Mike Rapoport <rppt(a)linux.ibm.com> > Acked-by: Corey Minyard <cminyard(a)mvista.com> > Acked-by: Christian Brauner <christian.brauner(a)ubuntu.com> > Acked-by: Arnd Bergmann <arnd(a)arndb.de> > Acked-by: Kees Cook <keescook(a)chromium.org> > Acked-by: Wei Liu <wei.liu(a)kernel.org> > Acked-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> > Co-developed-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Acked-by: Sebastian Reichel <sre(a)kernel.org> > Acked-by: Luis Chamberlain <mcgrof(a)kernel.org> > Acked-by: Stephen Boyd <sboyd(a)kernel.org> > Acked-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> > Acked-by: Helge Deller <deller(a)gmx.de> # parisc > --- > v3: rebased on top of v5.13-rc1, collected a few more tags > > Note WRT Andrew's SoB tag above: I have added it since part of the cases > I took from him. Andrew, feel free to amend or tell me how you want me > to do. > Acked-by: Alex Elder <elder(a)kernel.org> . . . > diff --git a/drivers/net/ipa/ipa_smp2p.c b/drivers/net/ipa/ipa_smp2p.c > index a5f7a79a1923..34b68dc43886 100644 > --- a/drivers/net/ipa/ipa_smp2p.c > +++ b/drivers/net/ipa/ipa_smp2p.c > @@ -8,6 +8,7 @@ > #include <linux/device.h> > #include <linux/interrupt.h> > #include <linux/notifier.h> > +#include <linux/panic_notifier.h> > #include <linux/soc/qcom/smem.h> > #include <linux/soc/qcom/smem_state.h> > . . .

5 years, 4 months

[PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: avoid using UTF-8 chars

by Mauro Carvalho Chehab

While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+00a0 (' '): NO-BREAK SPACE - U+2018 ('‘'): LEFT SINGLE QUOTATION MARK - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- .../coresight/coresight-etm4x-reference.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst index b64d9a9c79df..e8ddfc144d9a 100644 --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst @@ -15,14 +15,14 @@ Root: ``/sys/bus/coresight/devices/etm<N>`` The following paragraphs explain the association between sysfs files and the ETMv4 registers that they effect. Note the register names are given without -the ‘TRC’ prefix. +the 'TRC' prefix. ---- :File: ``mode`` (rw) :Trace Registers: {CONFIGR + others} :Notes: - Bit select trace features. See ‘mode’ section below. Bits + Bit select trace features. See 'mode' section below. Bits in this will cause equivalent programming of trace config and other registers to enable the features requested. @@ -89,7 +89,7 @@ the ‘TRC’ prefix. :Notes: Pair of addresses for a range selected by addr_idx. Include / exclude according to the optional parameter, or if omitted - uses the current ‘mode’ setting. Select comparator range in + uses the current 'mode' setting. Select comparator range in control register. Error if index is odd value. :Depends: ``mode, addr_idx`` @@ -277,7 +277,7 @@ the ‘TRC’ prefix. :Trace Registers: VICTLR{23:20} :Notes: Program non-secure exception level filters. Set / clear NS - exception filter bits. Setting ‘1’ excludes trace from the + exception filter bits. Setting '1' excludes trace from the exception level. :Syntax: @@ -427,7 +427,7 @@ the ‘TRC’ prefix. :Syntax: ``echo idx > vmid_idx`` - Where idx < numvmidc + Where idx < numvmidc ---- @@ -628,7 +628,7 @@ the reset parameter:: -The ‘mode’ sysfs parameter. +The 'mode' sysfs parameter. --------------------------- This is a bitfield selection parameter that sets the overall trace mode for the @@ -696,7 +696,7 @@ Bit assignments shown below:- ETM_MODE_QELEM(val) **description:** - ‘val’ determines level of Q element support enabled if + 'val' determines level of Q element support enabled if implemented by the ETM [IDR0] @@ -780,7 +780,7 @@ Bit assignments shown below:- ---- *Note a)* On startup the ETM is programmed to trace the complete address space -using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to +using address range comparator 0. 'mode' bits 30 / 31 modify this setting to set EL exclude bits for NS state in either user space (EL0) or kernel space (EL1) in the address range comparator. (the default setting excludes all secure EL, and NS EL2) -- 2.30.2

5 years, 4 months

Re: [PATCH v1 2/2] dt-bindings: arm: add property for coresight component name

by taozha＠codeaurora.org

On 2021-04-16 22:47, Mike Leach wrote: > Hi > > On Fri, 16 Apr 2021 at 15:16, <taozha(a)codeaurora.org> wrote: >> >> On 2021-04-16 19:23, Alexander Shishkin wrote: >> > Tao Zhang <taozha(a)codeaurora.org> writes: >> > >> >> Add property "coresight-name" for coresight component name. This >> >> allows coresight driver to read device name from device entries. >> >> >> >> Signed-off-by: Tao Zhang <taozha(a)codeaurora.org> >> >> --- >> >> Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ >> >> 1 file changed, 2 insertions(+) >> >> >> >> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt >> >> b/Documentation/devicetree/bindings/arm/coresight.txt >> >> index d711676..0e980ce 100644 >> >> --- a/Documentation/devicetree/bindings/arm/coresight.txt >> >> +++ b/Documentation/devicetree/bindings/arm/coresight.txt >> >> @@ -103,6 +103,8 @@ its hardware characteristcs. >> >> powers down the coresight component also powers down and loses its >> >> context. This property is currently only used for the ETM 4.x >> >> driver. >> >> >> >> + * coresight-name: the name of the coresight devices. >> > >> > Which devices? Also, is it a common practice to extend device tree >> > definitions based on arbitrary driver needs, or should there be some >> > sort of a discussion first? >> > >> > Regards, >> > -- >> > Alex >> Through the device tree entries, we can define their own name for any >> coresight device. This design is mainly used to facilitate the unified >> naming of coresight devgies across targets. e.g, without this patch, >> we >> can only see from sysFS there are multiple funnels, but we cannot know >> which funnel it is based on their names from sysFS. After applying >> this >> patch, we can directly know what device it is by observing the device >> name in sysFS. And the common scripts can be developed, since applying >> this patch, the same coresight device can have the same name across >> targets. Each developer or vendor can define the name of each >> coresight >> device according to their preferences and products. >> >> Tao > > 1) I am concerned that this will break the existing protocol which > associates a fixed device type name + number with each device - i.e. > etm0, funnel1 etc. > This naming convention allows for generic common scripts to be > developed - see: > ./tools/perf/tests/shel/test_arm_coresight.sh > This relies on the device type prefixes to iterate across all devices > in a system - and uses the connections links that are present in each > of the devices to determine the topology. > Replacing these with arbitrary names will break existing scripts. > Yes, agree with you. The patch should not break the existing protocol. > 2) Using the current system it is entirely possible to determine which > specific device a given name relates to. > e.g. ls -al /sys/bus/coresight/devices/ > > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu0 -> > ../../../devices/platform/soc/858000.cti/cti_cpu0 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu1 -> > ../../../devices/platform/soc/859000.cti/cti_cpu1 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu2 -> > ../../../devices/platform/soc/85a000.cti/cti_cpu2 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu3 -> > ../../../devices/platform/soc/85b000.cti/cti_cpu3 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys0 -> > ../../../devices/platform/soc/810000.cti/cti_sys0 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys1 -> > ../../../devices/platform/soc/811000.cti/cti_sys1 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm0 -> > ../../../devices/platform/soc/85c000.etm/etm0 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm1 -> > ../../../devices/platform/soc/85d000.etm/etm1 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm2 -> > ../../../devices/platform/soc/85e000.etm/etm2 > lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm3 -> > ../../../devices/platform/soc/85f000.etm/etm3 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel0 -> > ../../../devices/platform/soc/821000.funnel/funnel0 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel1 -> > ../../../devices/platform/soc/841000.funnel/funnel1 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 replicator0 -> > ../../../devices/platform/soc/824000.replicator/replicator0 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etf0 -> > ../../../devices/platform/soc/825000.etf/tmc_etf0 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etr0 -> > ../../../devices/platform/soc/826000.etr/tmc_etr0 > lrwxrwxrwx 1 root root 0 Apr 16 14:17 tpiu0 -> > ../../../devices/platform/soc/820000.tpiu/tpiu > > Further topology can be determined using the connections sub-directory > in each device:- > > ls -al /sys/bus/coresight/devices/etm0/connections/out\:0 > lrwxrwxrwx 1 root root 0 Apr 16 14:18 > /sys/bus/coresight/devices/etm0/connections/out:0 -> > ../../../841000.funnel/funnel1 > > Using this information it is possible to iterate across the entire > topology of any coresight system. > Yes, these information can iterate across the entire topology of any coresight system. But it cannot quickly identify specific coresight devices across targets. e.g. If there are a lot of cti on one target, we need to identify the cti by its register address. The same function cti may has different register address across targets. This patch allow the same function coresight device has the same name, and it could be operated by scripts easily. > 3) If there is some scripting requirement that cannot be solved with > the information available above - then it would be better to add this > name as an alias rather than a direct replacement. > Therefore any coresight device could have an alias_name entry, that > could be interrogated by a script and used as required. This avoids > breaking any existing scripts using the established naming convention. > Agree with you. Can I use sysfs_create_link to create a kernel link between alias name and coresight device kobject? At the same time, the original coresight device naming method remains unchanged. Thus, the existing protocol will not be broken. Or is there any better suggeston on how to add alias name for coresight device? > 4) Any devicetree attribute should follow the <owner>,<attribute> > naming convention. e.g. arm,some_attribute. > I agree with Alex that it may not be normal practice to add in > attributes in these circumstances - this does not appear to relate to > a specific hardware feature or limitation. You may wish to discuss > this with the device tree maintainers. > > Thanks and Regards > > Mike Sure. I will update this according to your suggestion on patch v2. Best. Tao

5 years, 4 months

[PATCH 0/7] Split Coresight decode by aux records

by James Clark

Hi All, Since my previous RFC, I've fixed --per-thread mode and solved most of the open questions. I've also changed --dump-raw-trace to use the same code path so it's also working now. I think the only open questions are: * General approach * If aux records need to be saved, or if they can be pulled from elsewhere. I've also tested perf inject which is now working with troublesome files. Thanks James James Clark (7): perf cs-etm: Split up etm queue setup function perf cs-etm: Only search timestamp in current sample's queue. perf cs-etm: Save aux records in each etm queue perf cs-etm: don't process queues until cs_etm__flush_events perf cs-etm: split decode by aux records. perf cs-etm: Use existing decode code path for --dump-raw-trace perf cs-etm: Suppress printing when resetting decoder .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 +- tools/perf/util/cs-etm.c | 300 ++++++++++-------- 2 files changed, 168 insertions(+), 142 deletions(-) -- 2.28.0

5 years, 4 months

Re: Help sought on which approach to take for tracing with CoreSight

by Mike Leach

Hi, Please ensure you reply to the list as well - this gives you a better chance of getting a timely response & my find people who know more about CSAL. On Wed, 21 Apr 2021 at 20:36, Dominik Huber <dominik.huber(a)fau.de> wrote: > > Hello, > Thanks for all the help. Especially the explanation of the trace was > very insightful. > For now, I am going to try implementing the sysfs tracing, since it > seemed easier at first glance. I found the documentation for the .ini > files within the snapshots, and am now trying to create my own version > of them. But I'm struggling to get the addresses for all the devices, > e.g. within cpu_0.ini. I've read in the discovery.md from CSAL that they > can be extracted by reading the ROM table of my Cortex-A53, but I'm > doing/understanding something wrong. > I cross-compiled the CSAL library and the csinfo-folder (which btw > only compiled after inserting "MODULE_LICENSE("");" into the csinfo.c > file). > Then I copied the resulting csinfo.ko to my Hikey620 where I tried > "sudo make" and it returned: > Load CoreSight reporting module... expect "Resource temporarily unavailable" > insmod csinfo.ko > insmod: ERROR: could not insert module csinfo.ko: Resource temporarily > unavailable > Makefile:17: recipe for target 'load' failed > make: *** [load] Error 1 > If I understood correctly, that is intended, but should also give me the > base address of the ROM-table afterward. But there was no other output. > I do have CONFIG_DEVMEM enabled. I tried "sudo insmod csinfo.ko". > directly as well, with the same result. Looking at the code it appears that the output is printk(KERN_INFO ... ) Check the printk level is correct on your system. > I could neither find the physical base address for the Cortex-A53 nor a > way to read the "CBAR_EL1" register, which apparently contains that > information. At least not without a debugger. > Since I don't know the correct address, i just tried "sudo ./csscan.py > 0x0", and this was the result: > @0x0 0x000 0x000 r0.0 unexpected CIDR: 0x000000f8 > class:0 > What does this output mean? > As far as I can tell to get valid output from this tool, you need to give it a valid input address / range of addresses. CIDR is the component ID register - this is used by the tool to match to known component values. If it says unexpected then it means just that - the value found is not a recognised CIDR for the tool. See the Coresight Spoecification for how CIDR and other IDR values are useda nd waht is expected. Regards Mike > For the address 0xE011000 I got: > @0xe011000 0x200 0x000 r0.7 unexpected CIDR: 0x00001a3f > ROM table > Does this help me? Unfortunately, this is not persistent information, > since after a reboot it showed something different. > How can I find out the addresses, that I need for the .ini files? > > Regards, > > Dominik > > On 12/04/2021 11:44, Mike Leach wrote: > > HI, > > > > On Sat, 10 Apr 2021 at 13:59, Dominik Huber <dominik.huber(a)fau.de> wrote: > >> > >> Am 09.04.2021 um 17:01 schrieb Mike Leach: > >>> Hi Dominik > >>> > >>> On Fri, 9 Apr 2021 at 15:22, Dominik Huber<dominik.huber(a)fau.de> wrote: > >>>> Hello, > >>>> I want to gather trace data of closed source binaries using CoreSight > >>>> ETMv4 on a Hikey620. I want to know the source and destination address > >>>> for all taken jumps of the traced program, like in the output of "perf > >>>> script". It would be great if I could get feedback on how to achieve this. > >>>> I'm not sure where to turn to with such a broad CoreSight problem, so > >>>> I'm sorry if you are not the right ones to turn to, but I'd be happy for > >>>> any help or advice you might have. > >>>> > >>> This is exactly the right place to ask for help on this! > >> I'm glad to hear that! > >>>> My main problem is, that I don't know which approaches are promising to > >>>> try. Below I describe two Ideas that I tried but where I got stuck after > >>>> a while. Are they any good for my use case? If yes, then how can I solve > >>>> the respective problems that have come up, or where can I look to solve > >>>> them? If not, are there maybe better ways to approach this, which I've > >>>> overlooked until now? > >>>> > >>>> After hearing a presentation from Mathieu Poirier, I thought sysFS was > >>>> the (only) way to go. However, the decoded trace seems to show only the > >>>> jump address, instead of both the source and destination addresses, and > >>>> I did not find a register to change that. > >>> What do you mean by decoded trace here & what are you using to decode the trace? > >>> If you look at the ETM spec / OpenCSD documentation you will see that > >>> to fully decode trace there is a two step process. > >>> 1) convert the trace byte stream into trace packets. This will > >>> require some minimal information regarding the configuration of the > >>> ETM > >>> 2) convert the trace packets into the fully decoded execution trace. > >>> This requires access to the binary images executed during the trace > >>> session. > >>> The reason for this is that trace packets are highly compressed, and > >>> contain the minimum of address information. Decode requires that the > >>> decoder will walk the binary images to deduce which branches are taken > >>> and not taken. > >>> Only were address information cannot be deduced from this code is > >>> included in the trace packets - and this is only ever target address > >>> information - the source address can always be deduced from the code > >>> walk. > >> I used ptm2human for decoding. I also tried the c_api_pkt_print_test.c > >> from OpenCSD, which decodes a single packet. However, depending on how I > >> collected the trace data, it does not always produce decoded data. > > ptm2human performs the 1st stage of decode - byte stream to trace > > packets. The output from this is the same as the packet only decode > > from the OpenCSD library / trc_pkt_lister app. This will print out the > > trace packets - but be aware that in both cases the addresses that you > > see in the trace are not all the branch addresses used in the executed > > application. > > > > > >> Once > >> I have a working proof-of-concept, I intended to write myself an OpenCSD > >> decoder. Because of that, and because the decoding often just seemed "to > >> work", I postponed any thoughts about the packet processing. > >> What are these "binary images"? Until now, I got only a cstrace.bin from > >> /dev/[sink], which I used as only Input for any decoding. How can I get > >> them? Can I, by using them, obtain the destination addresses of branch > >> instructions? > >> > > cstrace.bin is the binary trace data. The binary images I refer to are > > the memory images of the executed code - the decoder walks this memory > > image to deduce the path of the executed trace based on the opcodes > > encountered. > > These are either the binary files of your application and any loaded > > .so files, or may be a memory dump of the locations these were loaded > > during the trace session. Either will do to decode. > > > > See https://github.com/Linaro/OpenCSD/blob/master/decoder/docs/prog_guide/prog_… > > > > So to successfully decode a trace session to obtain the source and > > target branch addresses you want, you will need the following:- > > > > 1) The captured binary trace data. > > 2) The configuration registers of the ETM > > 3) The program binaries for all applications and .so libraries active > > during the trace session and their load addresses. > > Be aware that ETM will trace everything running on a core - so you it > > may be necessary for any analysis of a particular program to filter > > out anything unrelated. > > > > > >>>> Also, the trace gathered seems to lose some of the branch addresses. > >>>> Inserting a sleep instruction after each regular instruction into my > >>>> test program, fixed that. But since it should also work for closed > >>>> source binaries and has to be fast this is probably not an option. > >>>> > >>>> Then I tried to copy the way "perf record" is tracing, and extract the > >>>> relevant code parts. But then I realized, that perf record doesn't use > >>>> sysFS, apart from enabling the sink in "util/cs-etm.c" (which apparently > >>>> is not used, and not even deactivated afterward). > >>> perf uses the driver in the a similar way to sysfs. It does in fact > >>> activate and de-activate the sources and sinks as the perf events are > >>> run on any CPU. > >>> perf also records the binaries used during the trace session - so that > >>> full trace decode is possible. With sysfs you can get raw trace data - > >>> but relating this to the binaries being executed is far more > >>> difficult. > >> So is it your recommendation to use large parts of the perf source code > >> for my project because it already makes use of these "binary images"? > > I was not recommending re-use of perf source code - I was recommending > > using perf to capture and analyse trace. If this is not sufficient - > > or you want to write your own application, then perf serves as an > > example of the information you need to collect during a trace session > > to successfully decode the trace. perf does two tasks - capture - > > using perf record, and analysis using perf report. These are very > > separate elements - the first happens in kernel space, the second, > > often offline as a separate perf program, in user space. > > > >> Up until now, I only thought about using a few hundred lines, because I > >> believe perf has a lot of overhead (both in performance and code length) > >> just to get branch instructions from an executed binary. > >> > >> The most important factors for me are that > >> 1) the trace includes all branches (including the jump destination), and > >> 2) it is fast (faster than using hardware emulation and extracting the > >> addresses from there) > >> > >> What about the approaches to use the CoreSight driver directly or to use > >> CSAL for trace collection? Would they maybe be better suited? > >> > > The best method used for capturing trace is really an assessment for > > you to decide based on your requirements. CSAL / direct driver access > > / sysfs are all options - though I am not aware of anyone actually > > using a direct driver access method so could not really advise here. > > > > Remember that whatever method you choose, in order to get the data > > that you require you will need to collect the additional information I > > describe above. > > Once you have this data you can then pass it to the OpenCSD library > > for full decode. This will output the executed trace ranges. You are > > then free to analyse these ranges to synthesise source / target data > > for branches. > > > > Below is a short example of the trace output from the library - I have > > annotated this '***' to explain what is happening. This was generated > > using trc_pkt_lister test program from OpenCSD, running on one of the > > supplied test captures. > > > > The I_ packets are the trace packets - as would be output from > > ptm2human, the OCSD_GEN_TRC packets are the output of the library - > > fully decoded trace ranges. > > > > Idx:356; ID:12; [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > > 0x00 0x80 ]; I_ASYNC : Alignment Synchronisation. > > *** start of trace - align the decoder to the incoming byte stream for > > the ETM programmed with trace ID 0x12 > > > > Idx:369; ID:12; [0x01 0x01 0x00 ]; I_TRACE_INFO : Trace Info.; > > INFO=0x0 { CC.0 } > > *** Some setup information regarding trace configuration - used > > internally by the decoder. > > > > Idx:372; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E > > *** atom packet - skipped - cannot decode until we get an address / > > context packet > > > > Idx:373; ID:12; [0x85 0x22 0x12 0x4d 0x00 0x00 0x00 0x00 0x00 0x30 ]; > > I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; > > Addr=0x00000000004D2488; Ctxt: AArch64,EL0, NS; > > *** address and context packet - this gives the trace start address > > for the decoder + EL and ISA context. > > > > Idx:384; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E > > *** Atom packet. This indicates that the program executed a number of > > instructions until it encountered a P0 element instruction (a P0 > > element instruction - previously referred to as waypoints in PTM, are > > instructions that change the address flow of the program. These are > > primarily branch instructions but the full range of P0 instruction > > types is defined by the ETM4 protocol). This instruction was executed. > > > > Idx:373; ID:12; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A64) EL0N; 64-bit; ) > > *** OpenCSD library outputs the context information for the client > > application. Where traced context also includes the Context ID > > register which may contain the PID of the program running on the CPU > > under dertain kernel configurations. > > > > Idx:384; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > > range=0x4d2488:[0x4d2494] num_i(3) last_sz(4) (ISA=A64) E iBR A64:ret > > ) > > *** OpenCSD outputs the executed instruction trace range three > > instructions from addresses 0x4d2488 - 0x4d2493. This is output in > > response to the atom packet. > > This range was calculated by starting @ address 0x4d2488, walking > > through the program image from that address, examining opcodes until > > it found a P0 element (branch instruction) which it associates with > > the atom packet. > > This was an indirect branch (iBR A64:ret ) and also an aarch64 return > > instruction. This branch was taken (E). At this point we do not know > > the destination of the branch - so we are waiting for a target address > > packet in the input stream. > > > > Idx:385; ID:12; [0x9d 0x48 0x5f 0x4d 0x00 0x00 0x00 0x00 0x00 ]; > > I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000000004DBF20; > > *** Address packet - this updates the decoder with the target of the > > prior indirect branch - which can now continue decoding > > > > Idx:394; ID:12; [0xde ]; I_ATOM_F4 : Atom format 4.; NENE > > *** 4 atom packets - representing 4 waypoint instructions that were > > taken (E) or not taken (N). You will note that this single packet will > > decode into 4 separate executed instruction ranges - with no further > > address packets visible in the trace. > > > > Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > > range=0x4dbf20:[0x4dbf24] num_i(1) last_sz(4) (ISA=A64) N BR <cond>) > > *** OpenCSD executed instruction range - 1 instruction - was a not > > taken branch. This range started @ 0x04DBF20 - taken from the address > > packet above. > > At this point the client program using the library can deduce the most > > recent taken branch information - as 0x4d2490=>0x4dbf20 > > > > Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > > range=0x4dbf24:[0x4dbf2c] num_i(2) last_sz(4) (ISA=A64) E BR b+link ) > > *** OpenCSD executed instruction range - 2 instruction - last > > instruction was a taken branch + link - in this case the decoder can > > calculate the target address from the instruction opcode - so no > > address data needs to appear in the trace. > > > > Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > > range=0x4d1d88:[0x4d1db4] num_i(11) last_sz(4) (ISA=A64) N BR > > <cond>) > > *** OpenCSD executed instruction range - 11 instrucitons, starting at > > the address calculated from the previous range. So the start of the > > range was the result of a branch 0x4dbf28=>0x4d1d88 > > Ends in a not taken branch. > > > > Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec > > range=0x4d1db4:[0x4d1dbc] num_i(2) last_sz(4) (ISA=A64) E BR <cond>) > > *** OpenCSD executed instruction range - 2 instructions, last is a > > direct branch which will allow us to calculate the target address. > > > > Throughout this process the decoder maintains a current trace address > > from the incoming address packets, and by walking through the executed > > opcodes - calculating branch targets where possible. This is why the > > program and library binaries (or a memeory dump or their load > > locations ) is required for full trace decode and obtaining the > > information you require. > > > > Again, I would recommend reading the ETM protocol spec and the OpenCSD > > libarary documentation to get a full understanding of the protocols > > and how decoding works. > > > > Regards > > > > > > > > Mike > > > >>> If you are interested in tracing a particular binary & this is a > >>> userspace program then you may wish to try:- > >>> perf record -e cs_etm//u --per-thread <program-to-trace> > >>> to ensure that any trace collected is related to the program you are > >>> interested in. You can then use the facilites of perf report / perf > >>> script to examine the trace. > >> Thanks, but I luckily already knew about that one. > >>> Regards > >>> > >>> Mike > >>> > >>> > >>> > >>>> So there is another way to gather trace, maybe by interacting with the > >>>> CoreSight driver directly. But looking into the "perf report" source > >>>> code I couldn't find it yet. > >>>> > >>>> Thanks and regards, > >>>> > >>>> Dominik > >>>> > >>>> _______________________________________________ > >>>> CoreSight mailing list > >>>> CoreSight(a)lists.linaro.org > >>>> https://lists.linaro.org/mailman/listinfo/coresight > >>> -- > >>> Mike Leach > >>> Principal Engineer, ARM Ltd. > >>> Manchester Design Centre. UK > > > > > > -- > > Mike Leach > > Principal Engineer, ARM Ltd. > > Manchester Design Centre. UK -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

5 years, 4 months

[PATCH AUTOSEL 5.10 36/85] coresight: Do not scan for graph if none is present

by Sasha Levin

From: Suzuki K Poulose <suzuki.poulose(a)arm.com> [ Upstream commit 2b921b671a8d29c2adb255a86409aad1e3267309 ] If a graph node is not found for a given node, of_get_next_endpoint() will emit the following error message : OF: graph: no port node found in /<node_name> If the given component doesn't have any explicit connections (e.g, ETE) we could simply ignore the graph parsing. As for any legacy component where this is mandatory, the device will not be usable as before this patch. Updating the DT bindings to Yaml and enabling the schema checks can detect such issues with the DT. Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Link: https://lore.kernel.org/r/20210405164307.1720226-11-suzuki.poulose@arm.com Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hwtracing/coresight/coresight-platform.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c index 3629b7885aca..c594f45319fc 100644 --- a/drivers/hwtracing/coresight/coresight-platform.c +++ b/drivers/hwtracing/coresight/coresight-platform.c @@ -90,6 +90,12 @@ static void of_coresight_get_ports_legacy(const struct device_node *node, struct of_endpoint endpoint; int in = 0, out = 0; + /* + * Avoid warnings in of_graph_get_next_endpoint() + * if the device doesn't have any graph connections + */ + if (!of_graph_is_present(node)) + return; do { ep = of_graph_get_next_endpoint(node, ep); if (!ep) -- 2.30.2

5 years, 4 months

[PATCH AUTOSEL 5.11 044/104] coresight: Do not scan for graph if none is present

by Sasha Levin

5 years, 4 months

[PATCH AUTOSEL 5.12 047/116] coresight: Do not scan for graph if none is present

by Sasha Levin

5 years, 4 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight May 2021