summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/libxed.py
diff options
context:
space:
mode:
authorSteven Rostedt <rostedt@goodmis.org>2026-01-05 20:31:41 -0500
committerSteven Rostedt (Google) <rostedt@goodmis.org>2026-01-07 14:52:22 -0500
commit5f1ef0dfcb5b7f4a91a9b0e0ba533efd9f7e2cdb (patch)
tree7ca2e2fbc9bca44bd243dc8eac56c02e43c78579 /tools/perf/scripts/python/libxed.py
parent5232196ff49be08350b27f1ba8e1fad87afc9cdf (diff)
downloadkernel-5f1ef0dfcb5b7f4a91a9b0e0ba533efd9f7e2cdb.tar.gz
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again. Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI). Have the stack trace code use the interrupt context to protect against recursion. Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately. Link: https://lore.kernel.org/all/20260102122807.7025fc87@gandalf.local.home/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105203141.515cd49f@gandalf.local.home Reported-by: Yao Kai <yaokai34@huawei.com> Tested-by: Yao Kai <yaokai34@huawei.com> Fixes: 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Diffstat (limited to 'tools/perf/scripts/python/libxed.py')
0 files changed, 0 insertions, 0 deletions
.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 2013-12-15PCI: pciehp: Make various functions void since they can't failBjorn Helgaas These functions: pcie_enable_notification() pciehp_power_off_slot() pciehp_get_power_status() pciehp_get_attention_status() pciehp_set_attention_status() pciehp_get_latch_status() pciehp_get_adapter_status() pcie_write_cmd() now always return success, so this patch makes them void and drops the error-checking code in their callers. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 2013-07-25PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV deviceYinghai Lu Hot-removing a device with SR-IOV enabled causes a null pointer dereference in v3.9 and v3.10. This is a regression caused by ba518e3c17 ("PCI: pciehp: Iterate over all devices in slot, not functions 0-7"). When we iterate over the bus->devices list, we first remove the PF, which also removes all the VFs from the list. Then the list iterator blows up because more than just the current entry was removed from the list. ac205b7bb7 ("PCI: make sriov work with hotplug remove") works around a similar problem in pci_stop_bus_devices() by iterating over the list in reverse, so the VFs are stopped and removed from the list first, before the PF. This patch changes pciehp_unconfigure_device() to iterate over the list in reverse, too. [bhelgaas: bugzilla, changelog] Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60604 Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yijing Wang <wangyijing@huawei.com> CC: stable@vger.kernel.org # v3.9+ 2013-01-25PCI: pciehp: Iterate over all devices in slot, not functions 0-7Yijing Wang Currently, we enumerate devices in a slot with pci_scan_slot(), then iterate through all the devices we found by looking for functions 0-7. But that's wrong for ARI devices, which may have function numbers up to 255. This means that when we hot-add an ARI device, pciehp only initializes functions 0-7, and other functions don't work correctly. Additionally, if we hot-remove the device, pciehp only removes functions 0-7, leaving stale pci_dev structures for any other functions. This patch fixes the problem by iterating over devices in a slot by using the upstream bridge's "bus->devices" list instead. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 2012-06-13PCI: pciehp: use generic pci_hp_add_bridge()Yinghai Lu Use the new generic pci_hp_add_bridge() interface. [bhelgaas: split "add generic pci_hp_add_bridge()" into a separate patch] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 2012-06-13PCI: replace struct pci_bus secondary/subordinate with busn_resYinghai Lu Replace the struct pci_bus secondary/subordinate members with the struct resource busn_res. Later we'll build a resource tree of these bus numbers. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>