summaryrefslogtreecommitdiffstats
path: root/Documentation/ABI/testing/sysfs-class-net-queues
diff options
context:
space:
mode:
authorJinke Han <jinkehan@didiglobal.com>2026-09-08 15:37:42 +0800
committerIngo Molnar <mingo@kernel.org>2026-09-17 09:48:42 +0200
commita5f7a5bb3b7f28ba7e4fa246775b29a0e5537255 (patch)
tree73fef824f9a846cf935869d0dbc5070ef6e2f741 /Documentation/ABI/testing/sysfs-class-net-queues
downloadlinux-stable-a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255.tar.gz
linux-stable-a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255.zip
x86/kprobes: Fix crash when probing CS CALL instructionsgrafted
When using eBPF to probe CS CALL instructions within a function, a crash can be triggered. The eBPF tool probes offset 257 of the __hrtimer_run_queues() function: <__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1) <__hrtimer_run_queues+254>: mov %r14,%rdi <__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>: mov %eax,%r12d <__hrtimer_run_queues+266>: xchg %ax,%ax <__hrtimer_run_queues+268>: mov %r13,%rdi Which triggers this crash: BUG: unable to handle page fault for address: 00000000000f41c9 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P RIP: 0010:__hrtimer_run_queues+0x106/0x230 Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction. The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation. During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash. Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro. [ mingo: Refined the changelog ] Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Jinke Han <jinkehan@didiglobal.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Yafang Shao <laoar.shao@gmail.com> Acked-by: Borislav Petkov <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000
Diffstat (limited to 'Documentation/ABI/testing/sysfs-class-net-queues')
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-queues121
1 files changed, 121 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues
new file mode 100644
index 000000000..84aa25e0d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-queues
@@ -0,0 +1,121 @@
+What: /sys/class/net/<iface>/queues/rx-<queue>/rps_cpus
+Date: March 2010
+KernelVersion: 2.6.35
+Contact: netdev@vger.kernel.org
+Description:
+ Mask of the CPU(s) currently enabled to participate into the
+ Receive Packet Steering packet processing flow for this
+ network device queue. Possible values depend on the number
+ of available CPU(s) in the system.
+
+What: /sys/class/net/<iface>/queues/rx-<queue>/rps_flow_cnt
+Date: April 2010
+KernelVersion: 2.6.35
+Contact: netdev@vger.kernel.org
+Description:
+ Number of Receive Packet Steering flows being currently
+ processed by this particular network device receive queue.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/tx_timeout
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the number of transmit timeout events seen by this
+ network interface transmit queue.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/tx_maxrate
+Date: March 2015
+KernelVersion: 4.1
+Contact: netdev@vger.kernel.org
+Description:
+ A Mbps max-rate set for the queue, a value of zero means disabled,
+ default is disabled.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/xps_cpus
+Date: November 2010
+KernelVersion: 2.6.38
+Contact: netdev@vger.kernel.org
+Description:
+ Mask of the CPU(s) currently enabled to participate into the
+ Transmit Packet Steering packet processing flow for this
+ network device transmit queue. Possible values depend on the
+ number of available CPU(s) in the system.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/xps_rxqs
+Date: June 2018
+KernelVersion: 4.18.0
+Contact: netdev@vger.kernel.org
+Description:
+ Mask of the receive queue(s) currently enabled to participate
+ into the Transmit Packet Steering packet processing flow for this
+ network device transmit queue. Possible values depend on the
+ number of available receive queue(s) in the network device.
+ Default is disabled.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the hold time in milliseconds to measure the slack
+ of this particular network device transmit queue.
+ Default value is 1000.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the number of bytes (objects) in flight on this
+ network device transmit queue.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the current limit of bytes allowed to be queued
+ on this network device transmit queue. This value is clamped
+ to be within the bounds defined by limit_max and limit_min.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the absolute maximum limit of bytes allowed to be
+ queued on this network device transmit queue. See
+ include/linux/dynamic_queue_limits.h for the default value.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
+Date: November 2011
+KernelVersion: 3.3
+Contact: netdev@vger.kernel.org
+Description:
+ Indicates the absolute minimum limit of bytes allowed to be
+ queued on this network device transmit queue. Default value is
+ 0.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_thrs
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Tx completion stall detection threshold in ms. Kernel will
+ guarantee to detect all stalls longer than this threshold but
+ may also detect stalls longer than half of the threshold.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_cnt
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Number of detected Tx completion stalls.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_max
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Longest detected Tx completion stall. Write 0 to clear.