aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/bin/stackcollapse-record
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-02 23:59:00 +0000
set_wiphy_regd_sync+0x7f/0x90 [cfg80211] Call Trace: iwl_mvm_init_mcc+0x170/0x190 [iwlmvm] iwl_op_mode_mvm_start+0x824/0xa60 [iwlmvm] iwl_opmode_register+0xd0/0x130 [iwlwifi] init_module+0x23/0x1000 [iwlmvm] Fix this by adding the missing rtnl_lock() back to the code. Fixes: eb09ae93dabf ("iwlwifi: mvm: load regdomain at INIT stage") Link: https://lore.kernel.org/lkml/CAHk-=wjB_zBwZ+WR9LOpvgjvaQn=cqryoKigod8QnZs=iYGEhA@mail.gmail.com/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-09-01parisc: math-emu: Fix fall-through warningsHelge Deller1-3/+53 Fix lots of fallthrough warnings, e.g.: arch/parisc/math-emu/fpudispatch.c:323:33: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Helge Deller <deller@gmx.de> 2021-09-01parisc: fix crash with signals and allocaMikulas Patocka1-0/+6 I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <alloca.h> static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 <aa>: 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 <aa+0x24>,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> 2021-09-01parisc: Fix compile failure when building 64-bit kernel nativelyMasahiro Yamada3-4/+9 Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> 2021-09-01parisc: ccio-dma.c: Added tab instead of spacesShubhankar Kuranagatti1-43/+43 Single spaces has been removed and replaced with tabs. This is done to maintain code uniformity. Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Helge Deller <deller@gmx.de> 2021-09-01x86/setup: Explicitly include acpi.hNathan Chancellor1-0/+1 After commit 342f43af70db ("iscsi_ibft: fix crash due to KASLR physical memory remapping") x86_64_defconfig shows the following errors: arch/x86/kernel/setup.c: In function ‘setup_arch’: arch/x86/kernel/setup.c:916:13: error: implicit declaration of function ‘acpi_mps_check’ [-Werror=implicit-function-declaration] 916 | if (acpi_mps_check()) { | ^~~~~~~~~~~~~~ arch/x86/kernel/setup.c:1110:9: error: implicit declaration of function ‘acpi_table_upgrade’ [-Werror=implicit-function-declaration] 1110 | acpi_table_upgrade(); | ^~~~~~~~~~~~~~~~~~ [... more acpi noise ...] acpi.h was being implicitly included from iscsi_ibft.h in this configuration so the removal of that header means these functions have no definition or declaration. In most other configurations, <linux/acpi.h> continued to be included through at least <linux/tboot.h> if CONFIG_INTEL_TXT was enabled, and there were probably other implicit include paths too. Add acpi.h explicitly so there is no more error, and so that we don't continue to depend on these unreliable implicit include paths. Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Cc: Maurizio Lombardi <mlombard@redhat.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Konrad Rzeszutek Wilk <konrad@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2021-09-01fs: dlm: avoid comms shutdown delay in release_lockspaceAlexander Aring1-0/+1 When dlm_release_lockspace does active shutdown on connections to other nodes, the active shutdown will wait for any exisitng passive shutdowns to be resolved. But, the sequence of operations during dlm_release_lockspace can prevent the normal resolution of passive shutdowns (processed normally by way of lockspace recovery.) This disruption of passive shutdown handling can cause the active shutdown to wait for a full timeout period, delaying the completion of dlm_release_lockspace. To fix this, make dlm_release_lockspace resolve existing passive shutdowns (by calling dlm_clear_members earlier), before it does active shutdowns. The active shutdowns will not find any passive shutdowns to wait for, and will not be delayed. Reported-by: Chris Mackowski <cmackows@redhat.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com> 2021-09-01xen: remove stray preempt_disable() from PV AP startup codeJuergen Gross1-1/+0 In cpu_bringup() there is a call of preempt_disable() without a paired preempt_enable(). This is not needed as interrupts are off initially. Additionally this will result in early boot messages like: BUG: scheduling while atomic: swapper/1/0/0x00000002 Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210825113158.11716-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com> 2021-09-01xen/pcifront: Removed unnecessary __ref annotationSergio Miguéns Iglesias1-11/+19 An unnecessary "__ref" annotation was removed from the "drivers/pci/xen_pcifront.c" file. The function where the annotation was used was "pcifront_backend_changed()", which does not call any functions annotated as "__*init" nor "__*exit". This makes "__ref" unnecessary since this annotation is used to make the compiler ignore section miss-matches when they are not happening here in the first place. In addition to the aforementioned change, some code style issues were fixed in the same file. Signed-off-by: Sergio Miguéns Iglesias <sergio@lony.xyz> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210830175305.13370-1-sergio@lony.xyz Signed-off-by: Juergen Gross <jgross@suse.com> 2021-08-31dt-bindings: clock: samsung: fix header path in exampleKrzysztof Kozlowski1-1/+1 The proper header is exynos4.h: samsung,exynos4412-isp-clock.example.dts:19:18: fatal error: dt-bindings/clock/exynos4412.h: No such file or directory Fixes: 7ac615780926 ("dt-bindings: clock: samsung: convert Exynos4 to dtschema") Reported-by: Stephen Boyd <sboyd@kernel.org> Reported-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210831130643.83249-1-krzysztof.kozlowski@canonical.com Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> 2021-08-31mailbox: cmdq: add multi-gce clocks support for mt8195jason-jh.lin1-22/+79 For the design of GCE hardware event signal transportation, evnet rx will send the event signal to all GCE event merges after receiving the event signal from the other hardware. Because GCE event merges need to response to event rx, their clocks must be enabled at that time. To make sure all the gce clock is enabled while receiving the hardware event, each cmdq mailbox should enable or disable the others gce clk at the same time. Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> 2021-08-31mailbox: cmdq: add mediatek mailbox support for mt8195jason-jh.lin1-0/+1 Add mt8195 compatible name in the driver data of cmdq mailbox driver. Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>