| 0/0 |
2026/08/08 22:05 |
flow |
assessment-security |
45m
Results: map[DenialOfService:true Explanation:**Bug Analysis & Root Cause:**
The bug is a CPU soft lockup occurring in the `gate_timer_func` of the
`act_gate` Traffic Control (TC) action.
The `act_gate` action uses an `hrtimer` to enforce a time-based schedule for
network traffic. Users can configure a list of schedule entries, each with a
specific `interval` (duration). The timer function `gate_timer_func()` advances
the schedule and reprograms the `hrtimer` to fire after the current entry's
`interval` has elapsed.
The root cause of the soft lockup is the lack of a minimum bound check on the
`interval` value. The configuration parsing function `fill_gate_entry()` only
rejects `interval == 0`, meaning a user can successfully configure an interval
of `1` nanosecond.
If an interval is set to 1 ns, the `hrtimer` will be programmed to fire every 1
nanosecond. Because executing the timer callback and the associated softirq
overhead takes significantly longer than 1 ns, the timer will immediately expire
again upon re-enqueuing. This creates an interrupt storm where the CPU gets
stuck in an infinite loop processing the `hrtimer` softirq, ultimately
triggering the kernel's soft lockup watchdog.
Additionally, there is a logical flaw in `gate_timer_func()` where
`gact->current_close_time` is not properly updated to the recalculated
`close_time` when the timer falls behind (`ktime_after(now, close_time)` is
true). This causes the timer to continuously think it is lagging behind, further
exacerbating the tight loop if the cycle time is small.
**Security Impact:**
* **Exploitable:** No. This is a pure CPU exhaustion/infinite loop issue. It
does not involve memory corruption, use-after-free, or out-of-bounds accesses,
so it cannot be exploited for privilege escalation or information leaks.
* **Denial Of Service:** Yes. Triggering this bug causes a hard CPU stall (soft
lockup), which degrades system performance and can lead to a kernel panic if
`softlockup_panic` is enabled, resulting in a complete Denial of Service.
* **Accessible From Unprivileged Processes:** No. Configuring TC actions
requires the `CAP_NET_ADMIN` capability in the network namespace. A standard
unprivileged process cannot reach this code.
* **Accessible From User Namespaces:** Yes. An unprivileged user can create a
new user namespace and a new network namespace (`CLONE_NEWUSER | CLONE_NEWNET`).
Within this isolated namespace, the user gains `CAP_NET_ADMIN` and can freely
configure TC actions, including `act_gate`, to trigger the soft lockup on the
host CPU.
* **Network / Remote / Peripheral Triggers:** No. The bug is triggered purely by
the local configuration of the TC action via netlink messages, not by processing
malicious network packets, remote traffic, or peripheral devices. Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:false UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 1/1 |
2026/08/08 22:05 |
action |
syz-repro-to-c-repro |
0m
Results:
|
| 2/1 |
2026/08/08 22:05 |
action |
kernel-checkouter |
1m
Results: map[KernelSrc:/app/workdir/cache/src/eb616ad39216846ce17f213811dd9f9d62d09fec]
|
| 3/1 |
2026/08/08 22:06 |
action |
kernel-builder |
12m
Results: map[KernelObj:/app/workdir/cache/build/f0c37cf0c2ffb367511b645d8e4ac19737508da4]
|
| 4/1 |
2026/08/08 22:18 |
action |
codesearch-prepare |
9m
Results: map[Index:codesearch-index]
|
| 5/1 |
2026/08/08 22:27 |
agent |
expert |
22m
Model:
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:false UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Instruction: You are an experienced Linux kernel security engineer. Your task is to analyze given kernel bug report
and determine its security impact based on the following dimensions.
Use the provided tools to examine the source code, check for capability checks (e.g., capable(), ns_capable()),
and understand the nature of the bug. Analyze the given kernel build and configuration.
You can check the kernel config by grepping ".config" file; you can check kernel cmdline by grepping
".config" file for "CONFIG_CMDLINE=". Assume sysctl parameters have default values.
But analyze for the corresponding production build w/o debugging tools enabled (like KASAN, KMSAN, UBSAN).
Try different strategies when analyzing the bug:
- think of ways in which the vulnerable code is unreachable
- or the other way around: try to come up with different ideas of how an unprivileged user can reach the bug
If still unsure err on the side of the bug being non-exploitable/not-accessible.
In the final reply, provide a reasoning for your assessment.
Analysis dimensions:
* Exploitable:
Determine if the bug can result in memory corruption, elevated privileges, or an information leak.
Memory safety issues are almost always exploitable (KASAN or UBSAN reports for use-after-free, out-of-bounds;
refcounting issues, corrupted lists, etc). When kernel is crashing on a completely wild pointer access
(e.g. user-space address, or non-canonical address, but not on NULL or address corresponding to KASAN shadow
for NULL address), including both data accesses and control transfers, that also usually implies possibility
of exploitation. Such reports usually say "unable to handle kernel paging request".
Uses of uninitialized values detected by KMSAN may be exploitable b/c attacker frequently can affect uninit
values with spraying techniques. However, for these exploitability depends on how exactly the uninit value
is used in the code, and what it affects.
Information leaks are exploitable on their own and should be classified as such. A bug that copies kernel
memory contents to userspace (e.g. an out-of-bounds read whose result is returned to the caller, or
uninitialized stack/heap bytes written to a user buffer) is exploitable: it can reveal kernel pointer
values and defeat KASLR, expose sensitive data such as cryptographic keys or other processes' memory, and
serves as a necessary building block in most modern kernel privilege-escalation exploit chains. Do not classify
an information leak as non-exploitable solely because it does not directly cause a memory write or control-flow
hijack; the leak itself is the exploit primitive.
Think of what happens after the bug is triggered. Some bugs cause kernel panic and halt execution,
they are harder to exploit. For example, BUG reports halts the kernel. However, WARNING reports don't halt
execution in production builds. Debug bug detection tools (like KASAN, KMSAN, KCSAN, UBSAN) are also not enabled
in production builds, so attacker can freely exploit these bugs w/o being detected by these tools.
If you see an integer overflow, think how the overflowed value used later (if it's used as allocation size,
or an array index). If you see an out-of-bounds read, think if it's followed by an out-of-bounds write as well.
Some KCSAN data-races may be exploitable by skilled attackers as well. Think what data structures got corrupted
as the result of data races and how. However, note that kernel has lots of "benign" data races that don't lead
to any runtime misbehavior at all.
* Denial Of Service:
Determine if the bug can result in denial-of-service. Most bugs can, since they cause system crash,
hangs, deadlocks, or resource leaks. This is mostly applicable to WARNING bugs that won't cause system crash
in production. For these think what will be consequences of the violation of the kernel assumptions flagged
by the WARNING. In some cases the unexpected condition is also properly handled by the normal control flow
(e.g. with "if (WARN_ON(...))"), these won't cause denial-of-service. If the condition is not handled,
then it may or may not cause denial-of-service.
* Accessible From Unprivileged Processes:
Determine if the bug can be reached from a typical (non-root) user process that does NOT have any special capabilities
(like CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON) or access to device nodes restricted to root.
Assume that unprivileged_bpf_disabled=1, that is eBPF loading is not accessible. However, cBPF (classical BPF)
is still accessible to non-root processes.
Assume that user namespaces are not accessible, that is, the process cannot get the mentioned capabilities even
within a new user namespace (checked by ns_capable() function in the kernel sources).
* Accessible From User Namespaces:
Determine if the bug can be reached within a user-namespace where the process has all capabilities
(including CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON). Such capabilities are checked with ns_capable()
function in the kernel sources.
* VM Guest Trigger:
Determine if the bug can be triggered from the context of a typical KVM guest (e.g., set up by a QEMU VMM).
Consider accesses to standard Linux host paravirtualized features (virtio-blk, virtio-net, etc.),
and handling of VM exits in the KVM code.
* VM Host Trigger in The Confidential Computing Context:
Determine if the bug can be triggered in a confidential computing guest kernel from the context of a KVM host.
Consider access to standard Linux guest paravirtualized features (virtio-blk, virtio-net, etc.).
* Ethernet Network Trigger:
Determine if the bug can be triggered by processing ingress network Ethernet traffic, either directly (network stack)
or via drivers exposed to network data.
* Other Remote Trigger:
Determine if the bug can be triggered by processing remote traffic other than Ethernet (Wifi, Bluetooth, NFC, etc).
* Peripheral Trigger:
Determine if the bug can be triggered via an untrusted peripheral device that can be physically plugged
into a system, such as a USB device or a niche hardware driver handling external hardware inputs.
This is particularly important for mobile and desktop environments where users can plug in unknown devices.
* Malicious Filesystem Trigger:
Determine if the bug can be triggered by the kernel mounting and parsing a malicious filesystem image.
This is highly critical for Desktop and Mobile environments where external media or downloaded images
might be auto-mounted.
Don't make assumptions about the kernel source code (it may be different from what you assume it is).
Extensively use the provided code access tools (codesearch-*, git-*, grepper, etc)
to examine the actual source code, and confirm any assumptions.
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt:
The kernel bug report is:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [syz.4.1491:10102]
Modules linked in:
irq event stamp: 33885853
hardirqs last enabled at (33885852): [<ffff800080559824>] seqcount_lockdep_reader_access+0x7c/0xf8 include/linux/seqlock.h:75
hardirqs last disabled at (33885853): [<ffff8000868e627c>] __el1_irq arch/arm64/kernel/entry-common.c:506 [inline]
hardirqs last disabled at (33885853): [<ffff8000868e627c>] el1_interrupt+0x28/0x60 arch/arm64/kernel/entry-common.c:522
softirqs last enabled at (49606): [<ffff800084c14ca8>] __alloc_skb+0x1c0/0x610 net/core/skbuff.c:698
softirqs last disabled at (49607): [<ffff8000800204c0>] __do_softirq+0x14/0x20 kernel/softirq.c:656
CPU: 0 UID: 0 PID: 10102 Comm: syz.4.1491 Tainted: G L syzkaller #0 PREEMPT
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/02/2026
pstate: 43400005 (nZcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : seqcount_lockdep_reader_access+0xd8/0xf8 include/linux/seqlock.h:76
lr : seqcount_lockdep_reader_access+0xd4/0xf8 include/linux/seqlock.h:75
sp : ffff80008eb27ce0
x29: ffff80008eb27ce0 x28: 1fffe00035bc5c3a x27: ffff80008e80e110
x26: dfff800000000000 x25: ffff0000cdab8f80 x24: 1fffe0001bac7226
x23: dfff800000000000 x22: ffff0000cdab8fb0 x21: 0000000000000000
x20: ffff800080559c88 x19: 00000000000000c0 x18: 00000000ffffffff
x17: ffff80008a791000 x16: 0000000000000005 x15: ffff80008a31ada0
x14: 000000008030f608 x13: 0000000000000001 x12: ffff0000c7011d40
x11: ffff80008a590e28 x10: 0000000000000003 x9 : 0000000000000102
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000008 x3 : ffff800080559874
x2 : 0000000000000080 x1 : ffff0000c7011d40 x0 : 0000000000000000
Call trace:
__daif_local_irq_restore arch/arm64/include/asm/irqflags.h:175 [inline] (P)
arch_local_irq_restore arch/arm64/include/asm/irqflags.h:195 [inline] (P)
seqcount_lockdep_reader_access+0xd8/0xf8 include/linux/seqlock.h:75 (P)
ktime_get+0x68/0x218 kernel/time/timekeeping.c:971
gate_get_time+0x1c/0xa4 net/sched/act_gate.c:23
gate_timer_func+0x1a8/0x390 net/sched/act_gate.c:101
__run_hrtimer kernel/time/hrtimer.c:2032 [inline]
__hrtimer_run_queues+0x314/0xbe0 kernel/time/hrtimer.c:2096
hrtimer_run_softirq+0x15c/0x21c kernel/time/hrtimer.c:2113
handle_softirqs+0x2ec/0xd98 kernel/softirq.c:622
__do_softirq+0x14/0x20 kernel/softirq.c:656
____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:78
call_on_irq_stack+0x30/0x48 arch/arm64/kernel/entry.S:889
do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:83
do_softirq+0x90/0xf8 kernel/softirq.c:523
__local_bh_enable_ip+0x240/0x35c kernel/softirq.c:450
local_bh_enable include/linux/bottom_half.h:33 [inline]
__alloc_skb+0x1c8/0x610 net/core/skbuff.c:699
alloc_skb include/linux/skbuff.h:1384 [inline]
alloc_skb_with_frags+0xb8/0x690 net/core/skbuff.c:6769
sock_alloc_send_pskb+0x740/0x850 net/core/sock.c:3013
unix_dgram_sendmsg+0x434/0x1078 net/unix/af_unix.c:2136
sock_sendmsg_nosec net/socket.c:775 [inline]
__sock_sendmsg+0xc8/0x17c net/socket.c:790
____sys_sendmsg+0x3f8/0x6c8 net/socket.c:2684
___sys_sendmsg+0x198/0x224 net/socket.c:2738
__sys_sendmmsg+0x204/0x580 net/socket.c:2827
__do_sys_sendmmsg net/socket.c:2854 [inline]
__se_sys_sendmmsg net/socket.c:2851 [inline]
__arm64_sys_sendmmsg+0xac/0xc8 net/socket.c:2851
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:736
el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:755
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:594
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 4696 Comm: syz-executor Tainted: G L syzkaller #0 PREEMPT
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/02/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:-1 [inline]
pc : arch_local_irq_enable arch/arm64/include/asm/irqflags.h:48 [inline]
pc : handle_softirqs+0x1cc/0xd98 kernel/softirq.c:606
lr : handle_softirqs+0x1c8/0xd98 kernel/softirq.c:606
sp : ffff80008eb37ef0
x29: ffff80008eb37f80 x28: ffff0000d2fa3a88 x27: ffff0000d2fa3a90
x26: dfff800000000000 x25: 0000000000000008 x24: dfff800000000000
x23: ffff0001ade63640 x22: ffff0000d2fa3a80 x21: 000000000000000a
x20: ffff800088ac5640 x19: ffff0001ade63640 x18: 1fffe00035bc9e28
x17: ffff80012539e000 x16: ffff80008eb30000 x15: 0000000000000000
x14: 00000000ffff8000 x13: 0000000000000001 x12: 0000000000000000
x11: ffff800080157100 x10: 0000000000000003 x9 : 0000000000000000
x8 : 0000000000164b8c x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000008 x3 : ffff8000801571a8
x2 : 0000000000000000 x1 : ffff0000d2fa3a80 x0 : ffff80012539e000
Call trace:
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:26 [inline] (P)
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:48 [inline] (P)
handle_softirqs+0x1cc/0xd98 kernel/softirq.c:606 (P)
__do_softirq+0x14/0x20 kernel/softirq.c:656
____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:78
call_on_irq_stack+0x30/0x48 arch/arm64/kernel/entry.S:889
do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:83
invoke_softirq kernel/softirq.c:503 [inline]
__irq_exit_rcu+0x1ac/0x428 kernel/softirq.c:735
irq_exit_rcu+0x14/0x84 kernel/softirq.c:752
__el1_irq arch/arm64/kernel/entry-common.c:510 [inline]
el1_interrupt+0x40/0x60 arch/arm64/kernel/entry-common.c:522
el1h_64_irq_handler+0x18/0x24 arch/arm64/kernel/entry-common.c:527
el1h_64_irq+0x6c/0x70 arch/arm64/kernel/entry.S:590
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:26 [inline] (P)
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:48 [inline] (P)
__raw_write_unlock_irq include/linux/rwlock_api_smp.h:301 [inline] (P)
_raw_write_unlock_irq+0x34/0x80 kernel/locking/spinlock.c:362 (P)
exit_notify kernel/exit.c:806 [inline]
do_exit+0x1044/0x1a74 kernel/exit.c:1021
do_group_exit+0x198/0x238 kernel/exit.c:1152
__do_sys_exit_group kernel/exit.c:1163 [inline]
__se_sys_exit_group kernel/exit.c:1161 [inline]
pid_child_should_wake+0x0/0x104 kernel/exit.c:1161
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:736
el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:755
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:594
Reply: **Bug Analysis & Root Cause:**
The bug is a CPU soft lockup occurring in the `gate_timer_func` of the `act_gate` Traffic Control (TC) action.
The `act_gate` action uses an `hrtimer` to enforce a time-based schedule for network traffic. Users can configure a list of schedule entries, each with a specific `interval` (duration). The timer function `gate_timer_func()` advances the schedule and reprograms the `hrtimer` to fire after the current entry's `interval` has elapsed.
The root cause of the soft lockup is the lack of a minimum bound check on the `interval` value. The configuration parsing function `fill_gate_entry()` only rejects `interval == 0`, meaning a user can successfully configure an interval of `1` nanosecond.
If an interval is set to 1 ns, the `hrtimer` will be programmed to fire every 1 nanosecond. Because executing the timer callback and the associated softirq overhead takes significantly longer than 1 ns, the timer will immediately expire again upon re-enqueuing. This creates an interrupt storm where the CPU gets stuck in an infinite loop processing the `hrtimer` softirq, ultimately triggering the kernel's soft lockup watchdog.
Additionally, there is a logical flaw in `gate_timer_func()` where `gact->current_close_time` is not properly updated to the recalculated `close_time` when the timer falls behind (`ktime_after(now, close_time)` is true). This causes the timer to continuously think it is lagging behind, further exacerbating the tight loop if the cycle time is small.
**Security Impact:**
* **Exploitable:** No. This is a pure CPU exhaustion/infinite loop issue. It does not involve memory corruption, use-after-free, or out-of-bounds accesses, so it cannot be exploited for privilege escalation or information leaks.
* **Denial Of Service:** Yes. Triggering this bug causes a hard CPU stall (soft lockup), which degrades system performance and can lead to a kernel panic if `softlockup_panic` is enabled, resulting in a complete Denial of Service.
* **Accessible From Unprivileged Processes:** No. Configuring TC actions requires the `CAP_NET_ADMIN` capability in the network namespace. A standard unprivileged process cannot reach this code.
* **Accessible From User Namespaces:** Yes. An unprivileged user can create a new user namespace and a new network namespace (`CLONE_NEWUSER | CLONE_NEWNET`). Within this isolated namespace, the user gains `CAP_NET_ADMIN` and can freely configure TC actions, including `act_gate`, to trigger the soft lockup on the host CPU.
* **Network / Remote / Peripheral Triggers:** No. The bug is triggered purely by the local configuration of the TC action via netlink messages, not by processing malicious network packets, remote traffic, or peripheral devices.
|
| 6/2 |
2026/08/08 22:27 |
llm |
expert |
0m
Model:
Tokens:
input: 9727
output: 36
thoughts: 1277
Thoughts: **Analyzing a Soft Lockup on CPU#0**
Okay, so I've got a soft lockup situation on CPU#0, and the stack trace is pointing towards a potential issue with the `gate_timer_func` within the networking scheduler, specifically in `net/sched/act_gate.c`. I see a `seqcount_lockdep_reader_access` call, then `ktime_get` and then right into `gate_get_time`, and then `gate_timer_func`. The presence of `seqcount_lockdep_reader_access` is notable; it suggests there's a problem with concurrent access to a sequence counter, likely related to timing or a scheduling aspect of the gate's operation. The `seqcount` lock is a read-write lock that, depending on the implementation and context, can lead to contention if not carefully managed. It looks like the timer function is getting stuck, likely waiting on a resource held by another process or interrupt, perhaps related to timekeeping, given the call to `ktime_get`. The softirq handling is involved, which means this is a low-level interrupt-related issue. It's traversing the softirq path, hinting at a potential interrupt latency or an issue within the softirq processing itself, which has to be examined carefully. It then calls `__alloc_skb` which allocates a skb. and `sock_alloc_send_pskb`, and then unix domain socket code. The `unix_dgram_sendmsg` function being involved further suggests that there is a problem with the unix domain socket that is somehow related to the network scheduler, timer function, and the softirq. It's a chain of events that needs to be understood.
Comparing the stack trace on CPU#1, it shows something happening within the same context, but it's exiting rather than being locked up. The softirq path is traversed, similar to the first CPU, but CPU#1 appears to be finishing the softirq. It then goes to an irq_exit, and then ultimately does a `do_exit`. CPU #1 calls `do_exit`, meaning it is exiting, and perhaps related to the same resource. This suggests a potential resource contention or a deadlock scenario, or some sort of starvation where one CPU has the resource and the other waits. This also has to be investigated.
My focus should be on `gate_timer_func` and how it interacts with timekeeping, sequence locks and the softirq processing. I'll need to scrutinize the locking within `act_gate.c` and how it interacts with the hrtimer system, and in the interaction with the unix domain sockets. The stack trace on CPU#1, the exiting CPU, is also a critical piece of the puzzle, since it may be the CPU that "gives" up the resource for CPU#0 to acquire.
|
| 7/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:80 LineCount:50]
Results: map[Contents: 80:
81: p = rcu_dereference_protected(gact->param,
82: lockdep_is_held(&gact->tcf_lock));
83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
90: gact->current_close_time = ktime_add_ns(gact->current_close_time,
91: next->interval);
92:
93: close_time = gact->current_close_time;
94:
95: if (list_is_last(&next->list, &p->entries))
96: next = list_first_entry(&p->entries,
97: struct tcfg_gate_entry, list);
98: else
99: next = list_next_entry(next, list);
100:
101: now = gate_get_time(gact);
102:
103: if (ktime_after(now, close_time)) {
104: ktime_t cycle, base;
105: u64 n;
106:
107: cycle = p->tcfg_cycletime;
108: base = ns_to_ktime(p->tcfg_basetime);
109: n = div64_u64(ktime_sub_ns(now, base), cycle);
110: close_time = ktime_add_ns(base, (n + 1) * cycle);
111: }
112:
113: gact->next_entry = next;
114:
115: hrtimer_set_expires(&gact->hitimer, close_time);
116:
117: spin_unlock(&gact->tcf_lock);
118:
119: return HRTIMER_RESTART;
120: }
121:
122: TC_INDIRECT_SCOPE int tcf_gate_act(struct sk_buff *skb,
123: const struct tc_action *a,
124: struct tcf_result *res)
125: {
126: struct tcf_gate *gact = to_gate(a);
127: int action = READ_ONCE(gact->tcf_action);
128:
129: tcf_lastuse_update(&gact->tcf_tm);
]
|
| 8/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 12451
output: 36
thoughts: 76
Thoughts: **Analyzing a Potential Soft Lockup in the Gate Timer Function**
Okay, so I've got a soft lockup to troubleshoot, and it looks like the culprit is residing within `gate_timer_func`. My initial concern is the return value of `HRTIMER_RESTART` from this function. A "restart" implies the timer is supposed to fire again, but I need to investigate the circumstances more closely.
Specifically, I'm thinking about the implications if `close_time`, the key time value in this operation, is either already in the past, or extremely close to the current time, `now`. That condition would mean the timer might immediately try to restart and fire again, which is probably what's causing the lockup. It's a classic race condition scenario and I have to be extremely meticulous in checking it.
So, the next step is clear. I need to dive deep into `gate_timer_func` itself and thoroughly understand its execution path, especially how it handles `close_time` relative to the current time, and exactly how the timer restart mechanism is implemented. I need to be sure all the potential execution paths are accounted for.
|
| 9/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:60 LineCount:30]
Results: map[Contents: 60: ktime_t expires;
61:
62: expires = hrtimer_get_expires(&gact->hitimer);
63: if (expires == 0)
64: expires = KTIME_MAX;
65:
66: start = min_t(ktime_t, start, expires);
67:
68: hrtimer_start(&gact->hitimer, start, HRTIMER_MODE_ABS_SOFT);
69: }
70:
71: static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
72: {
73: struct tcf_gate *gact = container_of(timer, struct tcf_gate,
74: hitimer);
75: struct tcfg_gate_entry *next;
76: struct tcf_gate_params *p;
77: ktime_t close_time, now;
78:
79: spin_lock(&gact->tcf_lock);
80:
81: p = rcu_dereference_protected(gact->param,
82: lockdep_is_held(&gact->tcf_lock));
83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
]
|
| 10/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 13269
output: 37
thoughts: 783
Thoughts: **Analyzing a Potential Soft Lockup in the HRTimer Subsystem**
Okay, so I'm looking at this code and I've got a potential soft lockup issue flagged. The core problem, as I understand it, is that if `close_time` somehow ends up being less than or equal to `now`, then `hrtimer_set_expires` will effectively set the timer to expire immediately, leading to an immediate re-queue and a soft lockup because of the `HRTIMER_RESTART` return. My immediate thought is, let's trace where this `close_time` comes from.
Right, so `close_time` is calculated initially using `ktime_add_ns` with the `current_close_time` and the `next->interval`. But this is only an initial calculation. I've got to follow the `if` statement to really figure out the value. The condition that interests me is, `if (ktime_after(now, close_time))`. If that's true, we recalculate `close_time`. Now, the recalculation is where the interesting logic is: `close_time = ktime_add_ns(base, (n + 1) * cycle);`.
My mind immediately flags a potential issue: what if `cycle` is zero? A division by zero is definitely something I want to avoid. However, I note that we don't directly divide by `cycle` but use `div64_u64`. I guess there is no direct check for a zero value. But maybe it's checked earlier. Even so, the question that is relevant in this context, is, what happens if `close_time` is still less than or equal to `now` *after* this recalculation? I want to look at the formula itself to explore this.
Let's dissect this further. If we evaluate the line `n = div64_u64(ktime_sub_ns(now, base), cycle);` with respect to the inequality `now > base`, we will get a positive value of `n`. Then `(n + 1) * cycle` is larger than `(now - base)` which will be the result of a positive value of `n` multiplied by cycle. Then `close_time` will therefore be greater than `now`. So that's safe, and the first condition is not met.
But what if `now < base`? Ah, that's where things get interesting. In this case, `ktime_sub_ns(now, base)` is negative, and `div64_u64` is taking a `u64`. So that negative number becomes this *huge* positive `u64`. Then, `n` gets huge. This means that `(n + 1) * cycle` is either going to overflow or it's going to be very, very large. Could this cause `close_time` to still be less than or equal to `now`? The fact that `ktime_after(now, close_time)` could still be true, regardless of our calculation, is concerning.
Okay, so `base` comes from `p->tcfg_basetime`. Let me just refresh and review the `gate_setup_timer` function to see if that gives me any more clues. I need to understand the initial setup of these time values and whether this edge case is even *possible*. I need to know under what circumstances `now < base` is even true. I've got to check where `base` is initialized.
|
| 11/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:120 LineCount:50]
Results: map[Contents: 120: }
121:
122: TC_INDIRECT_SCOPE int tcf_gate_act(struct sk_buff *skb,
123: const struct tc_action *a,
124: struct tcf_result *res)
125: {
126: struct tcf_gate *gact = to_gate(a);
127: int action = READ_ONCE(gact->tcf_action);
128:
129: tcf_lastuse_update(&gact->tcf_tm);
130: tcf_action_update_bstats(&gact->common, skb);
131:
132: spin_lock(&gact->tcf_lock);
133: if (unlikely(gact->current_gate_status & GATE_ACT_PENDING)) {
134: spin_unlock(&gact->tcf_lock);
135: return action;
136: }
137:
138: if (!(gact->current_gate_status & GATE_ACT_GATE_OPEN)) {
139: spin_unlock(&gact->tcf_lock);
140: goto drop;
141: }
142:
143: if (gact->current_max_octets >= 0) {
144: gact->current_entry_octets += qdisc_pkt_len(skb);
145: if (gact->current_entry_octets > gact->current_max_octets) {
146: spin_unlock(&gact->tcf_lock);
147: goto overlimit;
148: }
149: }
150: spin_unlock(&gact->tcf_lock);
151:
152: return action;
153:
154: overlimit:
155: tcf_action_inc_overlimit_qstats(&gact->common);
156: drop:
157: tcf_action_inc_drop_qstats(&gact->common);
158: return TC_ACT_SHOT;
159: }
160:
161: static const struct nla_policy entry_policy[TCA_GATE_ENTRY_MAX + 1] = {
162: [TCA_GATE_ENTRY_INDEX] = { .type = NLA_U32 },
163: [TCA_GATE_ENTRY_GATE] = { .type = NLA_FLAG },
164: [TCA_GATE_ENTRY_INTERVAL] = { .type = NLA_U32 },
165: [TCA_GATE_ENTRY_IPV] = { .type = NLA_S32 },
166: [TCA_GATE_ENTRY_MAX_OCTETS] = { .type = NLA_S32 },
167: };
168:
169: static const struct nla_policy gate_policy[TCA_GATE_MAX + 1] = {
]
|
| 12/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 15714
output: 19
thoughts: 22
Thoughts: Here's my thought process, focusing on how `close_time` is initialized, as I understand it:
**Investigating the Initialization of `close_time`**
Alright, I need to get to the bottom of how this `close_time` variable is initially set. The most logical place to start digging is the `gate_setup_timer` function. It seems like the obvious candidate since it sounds like a setup or initialization routine, and I need to figure out how `close_time` gets its first value. Let's trace it back and make sure it is what I think it is.
|
| 13/2 |
2026/08/08 22:28 |
tool |
grepper |
0m
Args: map[Expression:gate_setup_timer]
Results: map[Output:net/sched/act_gate.c=317=static int gate_clock_resolve(s32 clockid, enum tk_offsets *tko,
--
net/sched/act_gate.c-338-
net/sched/act_gate.c:339:static void gate_setup_timer(struct tcf_gate *gact, s32 clockid,
net/sched/act_gate.c-340- enum tk_offsets tko)
--
net/sched/act_gate.c=347=static int tcf_gate_init(struct net *net, struct nlattr *nla,
--
net/sched/act_gate.c-507- if (need_cancel || ret == ACT_P_CREATED)
net/sched/act_gate.c:508: gate_setup_timer(gact, timer_clockid, tko);
net/sched/act_gate.c-509- p->tcfg_priority = prio;
--
net/sched/act_gate.c-548- if (ret == ACT_P_CREATED)
net/sched/act_gate.c:549: gate_setup_timer(gact, timer_clockid, tko);
net/sched/act_gate.c-550-
]
|
| 14/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 16216
output: 37
thoughts: 11
Thoughts: Okay, let's dive into this. Here's my take on those thoughts, as if they're my own:
**Analyzing the Function `gate_setup_timer`**
Alright, time to get into this `gate_setup_timer` function. I need to understand its role within the broader system. I'm immediately trying to connect it to the bigger picture β what are the dependencies, the inputs, the expected outputs, and the context in which this timer is being set up? Is this related to a hardware interrupt, a software watchdog, or something else entirely? I'm already mentally running through potential pitfalls β are there any race conditions I should be looking out for? What's the impact of this timer on the overall timing of the system? I need to analyze how this function interacts with the timer's registers and hardware. I'm going to start by looking for any comments or documentation associated with this function. Then, I'll identify the control flow and data dependencies to begin piecing together a proper understanding.
|
| 15/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:339 LineCount:50]
Results: map[Contents: 339: static void gate_setup_timer(struct tcf_gate *gact, s32 clockid,
340: enum tk_offsets tko)
341: {
342: WRITE_ONCE(gact->tk_offset, tko);
343: hrtimer_setup(&gact->hitimer, gate_timer_func, clockid,
344: HRTIMER_MODE_ABS_SOFT);
345: }
346:
347: static int tcf_gate_init(struct net *net, struct nlattr *nla,
348: struct nlattr *est, struct tc_action **a,
349: struct tcf_proto *tp, u32 flags,
350: struct netlink_ext_ack *extack)
351: {
352: struct tc_action_net *tn = net_generic(net, act_gate_ops.net_id);
353: u64 cycletime = 0, basetime = 0, cycletime_ext = 0;
354: struct tcf_gate_params *p = NULL, *old_p = NULL;
355: enum tk_offsets old_tk_offset = TK_OFFS_TAI;
356: const struct tcf_gate_params *cur_p = NULL;
357: bool bind = flags & TCA_ACT_FLAGS_BIND;
358: struct nlattr *tb[TCA_GATE_MAX + 1];
359: enum tk_offsets tko = TK_OFFS_TAI;
360: struct tcf_chain *goto_ch = NULL;
361: s32 timer_clockid = CLOCK_TAI;
362: bool use_old_entries = false;
363: s32 old_clockid = CLOCK_TAI;
364: bool need_cancel = false;
365: s32 clockid = CLOCK_TAI;
366: struct tcf_gate *gact;
367: struct tc_gate *parm;
368: u64 old_basetime = 0;
369: int ret = 0, err;
370: u32 gflags = 0;
371: s32 prio = -1;
372: ktime_t start;
373: u32 index;
374:
375: if (!nla)
376: return -EINVAL;
377:
378: err = nla_parse_nested(tb, TCA_GATE_MAX, nla, gate_policy, extack);
379: if (err < 0)
380: return err;
381:
382: if (!tb[TCA_GATE_PARMS])
383: return -EINVAL;
384:
385: if (tb[TCA_GATE_CLOCKID])
386: clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
387:
388: parm = nla_data(tb[TCA_GATE_PARMS]);
]
|
| 16/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 17377
output: 37
thoughts: 14
Thoughts: Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to an expert:
**Diving Deeper into `tcf_gate_init`**
Alright, let's take a closer look at `tcf_gate_init`. I need to understand its role within the broader context. What's it initializing, exactly? Is this a critical starting point for a key process, or is it more of a setup function? I'm already thinking about potential error scenarios I should anticipate. I want to identify any dependencies it has, any assumptions it's making about the environment, and if there are any obvious opportunities for optimization or potential pitfalls that could lead to problems down the line. I know the devil is in the details, so I'm paying close attention to every line. This initial exploration is crucial to building a proper understanding of the codebase.
|
| 17/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:389 LineCount:50]
Results: map[Contents: 389: index = parm->index;
390:
391: err = tcf_idr_check_alloc(tn, &index, a, bind);
392: if (err < 0)
393: return err;
394:
395: if (err && bind)
396: return ACT_P_BOUND;
397:
398: if (!err) {
399: ret = tcf_idr_create_from_flags(tn, index, est, a,
400: &act_gate_ops, bind, flags);
401: if (ret) {
402: tcf_idr_cleanup(tn, index);
403: return ret;
404: }
405:
406: ret = ACT_P_CREATED;
407: } else if (!(flags & TCA_ACT_FLAGS_REPLACE)) {
408: tcf_idr_release(*a, bind);
409: return -EEXIST;
410: }
411:
412: gact = to_gate(*a);
413:
414: err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
415: if (err < 0)
416: goto release_idr;
417:
418: p = kzalloc(sizeof(*p), GFP_KERNEL);
419: if (!p) {
420: err = -ENOMEM;
421: goto chain_put;
422: }
423: INIT_LIST_HEAD(&p->entries);
424:
425: use_old_entries = !tb[TCA_GATE_ENTRY_LIST];
426: if (!use_old_entries) {
427: err = parse_gate_list(tb[TCA_GATE_ENTRY_LIST], p, extack);
428: if (err < 0)
429: goto err_free;
430: use_old_entries = !err;
431: }
432:
433: if (ret == ACT_P_CREATED && use_old_entries) {
434: NL_SET_ERR_MSG(extack, "The entry list is empty");
435: err = -EINVAL;
436: goto err_free;
437: }
438:
]
|
| 18/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 18339
output: 37
thoughts: 6
Thoughts: Okay, I'm ready. Let's see what we're working with.
***
**Diving In: Initial Assessment and Framing**
Alright, let's get into it. My initial thought process is to see what the text is about. I need to quickly identify the core themes, any key methodologies, and the overall objectives. As an expert, I'm already sifting for any novel concepts or perhaps areas that are underdeveloped within my current knowledge base. I'm actively looking for the 'so what?' β the significance and implications. Where does this fit in the existing discourse? What gaps does it address, or does it try to create? I'm essentially starting with a critical, but also an inquisitive, mindset. It's like I'm already formulating questions as I read, and determining how much further I have to delve.
|
| 19/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:439 LineCount:50]
Results: map[Contents: 439: if (ret != ACT_P_CREATED) {
440: rcu_read_lock();
441: cur_p = rcu_dereference(gact->param);
442:
443: old_basetime = cur_p->tcfg_basetime;
444: old_clockid = cur_p->tcfg_clockid;
445: old_tk_offset = READ_ONCE(gact->tk_offset);
446:
447: basetime = old_basetime;
448: cycletime_ext = cur_p->tcfg_cycletime_ext;
449: prio = cur_p->tcfg_priority;
450: gflags = cur_p->tcfg_flags;
451:
452: if (!tb[TCA_GATE_CLOCKID])
453: clockid = old_clockid;
454:
455: err = 0;
456: if (use_old_entries) {
457: err = tcf_gate_copy_entries(p, cur_p, extack);
458: if (!err && !tb[TCA_GATE_CYCLE_TIME])
459: cycletime = cur_p->tcfg_cycletime;
460: }
461: rcu_read_unlock();
462: if (err)
463: goto err_free;
464: }
465:
466: if (tb[TCA_GATE_PRIORITY])
467: prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
468:
469: if (tb[TCA_GATE_BASE_TIME])
470: basetime = nla_get_u64(tb[TCA_GATE_BASE_TIME]);
471:
472: if (tb[TCA_GATE_FLAGS])
473: gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
474:
475: if (tb[TCA_GATE_CYCLE_TIME])
476: cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
477:
478: if (tb[TCA_GATE_CYCLE_TIME_EXT])
479: cycletime_ext = nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
480:
481: err = gate_clock_resolve(clockid, &tko, extack);
482: if (err)
483: goto err_free;
484: timer_clockid = clockid;
485:
486: need_cancel = ret != ACT_P_CREATED &&
487: gate_timer_needs_cancel(basetime, old_basetime,
488: tko, old_tk_offset,
]
|
| 20/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 19426
output: 37
thoughts: 6
Thoughts: Okay, I'm ready. Let's see what we've got. Here's a summary from my perspective:
**Initial Assessment and Anticipation**
Right, let's dive into this. I'm going to read further and analyze. I'll need to keep an open mind and be ready to delve into the details. I'm looking forward to the challenge of analyzing and summarizing the concepts at hand.
|
| 21/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:489 LineCount:50]
Results: map[Contents: 489: timer_clockid, old_clockid);
490:
491: if (need_cancel)
492: hrtimer_cancel(&gact->hitimer);
493:
494: spin_lock_bh(&gact->tcf_lock);
495:
496: if (!cycletime) {
497: struct tcfg_gate_entry *entry;
498: ktime_t cycle = 0;
499:
500: list_for_each_entry(entry, &p->entries, list)
501: cycle = ktime_add_ns(cycle, entry->interval);
502: cycletime = cycle;
503: }
504: p->tcfg_cycletime = cycletime;
505: p->tcfg_cycletime_ext = cycletime_ext;
506:
507: if (need_cancel || ret == ACT_P_CREATED)
508: gate_setup_timer(gact, timer_clockid, tko);
509: p->tcfg_priority = prio;
510: p->tcfg_flags = gflags;
511: p->tcfg_basetime = basetime;
512: p->tcfg_clockid = timer_clockid;
513: gate_get_start_time(gact, p, &start);
514:
515: old_p = rcu_replace_pointer(gact->param, p,
516: lockdep_is_held(&gact->tcf_lock));
517:
518: gact->current_close_time = start;
519: gact->current_gate_status = GATE_ACT_GATE_OPEN | GATE_ACT_PENDING;
520:
521: gact->next_entry = list_first_entry(&p->entries,
522: struct tcfg_gate_entry, list);
523:
524: goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
525:
526: gate_start_timer(gact, start);
527:
528: spin_unlock_bh(&gact->tcf_lock);
529:
530: if (goto_ch)
531: tcf_chain_put_by_act(goto_ch);
532:
533: if (old_p)
534: call_rcu(&old_p->rcu, tcf_gate_params_free_rcu);
535:
536: return ret;
537:
538: err_free:
]
|
| 22/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 20361
output: 37
thoughts: 48
Thoughts: Okay, let me think this through.
**Analyzing the `cycletime` Calculation**
Right, so I'm looking at how `cycletime` is determined. The logic seems to be: it's the sum of `entry->interval`. Seems straightforward enough, but my expert eye immediately spots a potential edge case. What happens if an `entry->interval` is actually zero? Does the code handle that gracefully? It's a fundamental question of how the system perceives intervals of no time, and if it could generate incorrect calculations.
I'm thinking I should take a look at `parse_gate_list` to see if that function has any influence on the state of `entry->interval`. Understanding its behavior will be necessary to ensure the calculation is robust and accurate, particularly when dealing with potentially null or zero intervals. We must consider every scenario, and examine the code with that in mind.
|
| 23/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:250 LineCount:50]
Results: map[Contents: 250: new->gate_state = entry->gate_state;
251: new->interval = entry->interval;
252: new->ipv = entry->ipv;
253: new->maxoctets = entry->maxoctets;
254: list_add_tail(&new->list, &dst->entries);
255: i++;
256: }
257:
258: dst->num_entries = i;
259: return 0;
260: }
261:
262: static int parse_gate_list(struct nlattr *list_attr,
263: struct tcf_gate_params *sched,
264: struct netlink_ext_ack *extack)
265: {
266: struct tcfg_gate_entry *entry;
267: struct nlattr *n;
268: int err, rem;
269: int i = 0;
270:
271: if (!list_attr)
272: return -EINVAL;
273:
274: nla_for_each_nested(n, list_attr, rem) {
275: if (nla_type(n) != TCA_GATE_ONE_ENTRY) {
276: NL_SET_ERR_MSG(extack, "Attribute isn't type 'entry'");
277: continue;
278: }
279:
280: entry = kzalloc_obj(*entry, GFP_ATOMIC);
281: if (!entry) {
282: NL_SET_ERR_MSG(extack, "Not enough memory for entry");
283: err = -ENOMEM;
284: goto release_list;
285: }
286:
287: err = parse_gate_entry(n, entry, i, extack);
288: if (err < 0) {
289: kfree(entry);
290: goto release_list;
291: }
292:
293: list_add_tail(&entry->list, &sched->entries);
294: i++;
295: }
296:
297: sched->num_entries = i;
298:
299: return i;
]
|
| 24/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 21327
output: 37
thoughts: 11
Thoughts: Okay, here's my attempt at summarizing the thought process, tailored for an expert audience, and written in the first person:
**Analyzing `parse_gate_entry`**
Alright, let's dive into this `parse_gate_entry` function. My initial thought is to quickly assess its purpose and expected input. *Is it reading from a file, a network stream, or a user input? What's the expected format β delimited text, binary data, something else entirely?* I'm mentally parsing the potential complexity here. The name suggests it deals with gate entry data, so I need to immediately consider potential issues related to security, data validation, and error handling. *What specific checks are performed? Are there sanity checks on data types and ranges? Are there any obvious injection vulnerabilities?* I need to see how robust this code is. Ultimately, the question is, *can I trust this function to correctly and safely handle a variety of input scenarios, including edge cases and potentially malicious data?* I'm looking for potential vulnerabilities and areas for optimization.
|
| 25/2 |
2026/08/08 22:28 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:180 LineCount:50]
Results: map[Contents: 180:
181: static int fill_gate_entry(struct nlattr **tb, struct tcfg_gate_entry *entry,
182: struct netlink_ext_ack *extack)
183: {
184: u32 interval = 0;
185:
186: entry->gate_state = nla_get_flag(tb[TCA_GATE_ENTRY_GATE]);
187:
188: if (tb[TCA_GATE_ENTRY_INTERVAL])
189: interval = nla_get_u32(tb[TCA_GATE_ENTRY_INTERVAL]);
190:
191: if (interval == 0) {
192: NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
193: return -EINVAL;
194: }
195:
196: entry->interval = interval;
197:
198: entry->ipv = nla_get_s32_default(tb[TCA_GATE_ENTRY_IPV], -1);
199:
200: entry->maxoctets = nla_get_s32_default(tb[TCA_GATE_ENTRY_MAX_OCTETS],
201: -1);
202:
203: return 0;
204: }
205:
206: static int parse_gate_entry(struct nlattr *n, struct tcfg_gate_entry *entry,
207: int index, struct netlink_ext_ack *extack)
208: {
209: struct nlattr *tb[TCA_GATE_ENTRY_MAX + 1] = { };
210: int err;
211:
212: err = nla_parse_nested(tb, TCA_GATE_ENTRY_MAX, n, entry_policy, extack);
213: if (err < 0) {
214: NL_SET_ERR_MSG(extack, "Could not parse nested entry");
215: return -EINVAL;
216: }
217:
218: entry->index = index;
219:
220: return fill_gate_entry(tb, entry, extack);
221: }
222:
223: static void release_entry_list(struct list_head *entries)
224: {
225: struct tcfg_gate_entry *entry, *e;
226:
227: list_for_each_entry_safe(entry, e, entries, list) {
228: list_del(&entry->list);
229: kfree(entry);
]
|
| 26/2 |
2026/08/08 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 22378
output: 291
thoughts: 1447
Thoughts: **Analyzing Potential Soft Lockup in Gate Timer Function**
Okay, so I'm digging into this `gate_timer_func` and trying to understand a potential soft lockup issue. The initial thought is that the `interval` can't be zero, and because `cycletime` is derived from a sum of `interval`s, it also cannot be zero. But wait, `cycletime` *can* be provided via `TCA_GATE_CYCLE_TIME`. If it's *not* provided or set to zero, it is recalculated as a sum of all `interval`s, and so will be greater than zero.
Now, looking at the core logic within `gate_timer_func`, there's this `ktime_after(now, close_time)` check. If `now` is after `close_time`, we recalculate `close_time`. The recalculation is where it gets interesting: `n = div64_u64(ktime_sub_ns(now, base), cycle);` and then `close_time = ktime_add_ns(base, (n + 1) * cycle);`.
If `now < base`, `ktime_sub_ns(now, base)` yields a negative value. Since `div64_u64` takes an *unsigned* 64-bit integer, this negative result gets converted to a *huge* positive number. The crucial point is that this 'n' could become a massive positive number. Then `(n + 1) * cycle` might overflow a 64-bit signed integer (`ktime_t`), potentially making `close_time` a negative number. This means `hrtimer_set_expires` could set the timer to a time in the past, causing it to fire immediately, which would be a problem.
The key observation is that `gact->current_close_time` isn't updated if `ktime_after(now, close_time)` is true. That means the `gact->current_close_time` continues to increment by `next->interval`, but the `close_time` in the `hrtimer_set_expires` can jump into the past (due to the underflow on the `div64_u64`). So the overflow keeps the clock far behind the current time.
I realized this can happen because `base` (the base time for the cycle calculations) is provided by the user via `TCA_GATE_BASE_TIME`. The user can set `base` to a time *far* in the future relative to `now`. That way `now < base` would always be true, and underflow would be triggered. So this means the user could trigger the soft lockup by providing a suitable `base` value. I'll verify this now.
|
| 27/2 |
2026/08/08 22:29 |
tool |
codeexpert |
2m
Args: map[Question:In net/sched/act_gate.c, gate_timer_func() has the following code:
```c
if (ktime_after(now, close_time)) {
ktime_t cycle, base;
u64 n;
cycle = p->tcfg_cycletime;
base = ns_to_ktime(p->tcfg_basetime);
n = div64_u64(ktime_sub_ns(now, base), cycle);
close_time = ktime_add_ns(base, (n + 1) * cycle);
}
```
If `now < base` (which is possible since `basetime` is user-controlled), `ktime_sub_ns(now, base)` is negative.
Since `div64_u64` takes a `u64` dividend, it will be treated as a huge positive number.
Will this cause `close_time` to be calculated as a value in the past (e.g. due to overflow), leading to an infinite hrtimer loop (soft lockup)?
Also, is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?]
Results: map[Answer:### Part 1: Will `now < base` cause `close_time` to be in the past and lead to an infinite hrtimer loop (soft lockup)?
#### 1. Is `now < base` possible when `ktime_after(now, close_time)` is true?
**No.** Under normal conditions, `now < base` is mathematically impossible when the `if (ktime_after(now, close_time))` block is entered.
**Proof:**
* `gact->current_close_time` is initialized to `start`, which is calculated by `gate_get_start_time()`.
* If `base > now`, `start` is set to `base`. If `base <= now`, `start` is set to `base + (n + 1) * cycle > base`. Thus, `gact->current_close_time` is always initialized to a value greater than or equal to `base`.
* In `gate_timer_func()`, `gact->current_close_time` is only updated by adding `next->interval` (which is strictly positive). Thus, `gact->current_close_time` is always `>= base`.
* `close_time` is set to `gact->current_close_time`. Since `next->interval > 0`, `close_time` is always strictly greater than `base` (`close_time > base`).
* If `ktime_after(now, close_time)` is true, then `now > close_time`.
* By transitivity, since `now > close_time` and `close_time > base`, we must have `now > base`.
* Therefore, `now < base` is impossible when the `if (ktime_after(now, close_time))` block is entered.
#### 2. What if `now < base` hypothetically happens (e.g., due to clock jumps or other anomalies)?
Even if `now < base` hypothetically happens, the unsigned division math in `div64_u64` will **not** cause `close_time` to be in the past, nor will it cause an infinite hrtimer loop (soft lockup).
**Mathematical Proof:**
* Let $W = 2^{64}$. All 64-bit integer arithmetic is performed modulo $W$.
* Since `now < base`, `ktime_sub_ns(now, base)` is negative, which as a `u64` is represented as $D = W + \text{now} - \text{base}$.
* Let $cycle = C$.
* `n = div64_u64(D, C)` performs integer division: $D = n \cdot C + R$, where $R = D \pmod C$ and $0 \le R < C$.
* Thus, $(n + 1) \cdot C = n \cdot C + C = D - R + C = W + \text{now} - \text{base} - R + C$.
* `close_time` is calculated as:
$$\text{close\_time} = \text{base} + (n + 1) \cdot C \pmod W$$
$$\text{close\_time} = \text{base} + (W + \text{now} - \text{base} - R + C) \pmod W$$
$$\text{close\_time} = \text{now} - R + C \pmod W$$
* Since $0 \le R < C$, we have $0 < C - R \le C$.
* Therefore, $\text{close\_time}$ is in the range $[\text{now} + 1, \text{now} + C]$.
* Since `now` is the current time (a valid positive `s64` value far from `S64_MAX`) and $C$ is relatively small, `close_time` will be a valid positive `s64` value strictly in the future relative to `now`.
* Since `close_time` is in the future, the hrtimer will be scheduled for a future time and will **not** cause an infinite loop or a soft lockup.
---
### Part 2: Is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?
**No, it is not intentional; it is a significant logical bug.**
#### Consequences of not updating `gact->current_close_time`:
1. If the timer falls behind (e.g., due to temporary system delay, CPU starvation, or clock adjustments), `ktime_after(now, close_time)` becomes true.
2. `close_time` is recalculated to the next cycle boundary in the future, but `gact->current_close_time` is left unchanged (lagging far in the past).
3. In the next timer expiration, `gact->current_close_time` is incremented by `next->interval`. However, because it was lagging behind, it remains far in the past compared to the new `now`.
4. As a result, `ktime_after(now, close_time)` will evaluate to true on **every subsequent timer expiration**.
5. The timer will continually recalculate `close_time` to the next cycle boundary and reschedule itself.
6. Consequently, the timer will **only fire at cycle boundaries** (skipping all intermediate schedule entries/intervals). Each entry in the schedule will effectively run for a full cycle time instead of its specified interval, completely breaking the gate action's schedule.
#### How it should be fixed:
When `ktime_after(now, close_time)` is true, `gact->current_close_time` should be updated to the recalculated `close_time` (the start of the next cycle), and `next` should be reset to the first entry of the schedule (`list_first_entry(&p->entries, struct tcfg_gate_entry, list)`). This aligns the schedule perfectly with the next cycle boundary.]
|
| 28/3 |
2026/08/08 22:29 |
agent |
codeexpert |
2m
Model:
Results: map[Answer:### Part 1: Will `now < base` cause `close_time` to be in the past and lead to an infinite hrtimer loop (soft lockup)?
#### 1. Is `now < base` possible when `ktime_after(now, close_time)` is true?
**No.** Under normal conditions, `now < base` is mathematically impossible when the `if (ktime_after(now, close_time))` block is entered.
**Proof:**
* `gact->current_close_time` is initialized to `start`, which is calculated by `gate_get_start_time()`.
* If `base > now`, `start` is set to `base`. If `base <= now`, `start` is set to `base + (n + 1) * cycle > base`. Thus, `gact->current_close_time` is always initialized to a value greater than or equal to `base`.
* In `gate_timer_func()`, `gact->current_close_time` is only updated by adding `next->interval` (which is strictly positive). Thus, `gact->current_close_time` is always `>= base`.
* `close_time` is set to `gact->current_close_time`. Since `next->interval > 0`, `close_time` is always strictly greater than `base` (`close_time > base`).
* If `ktime_after(now, close_time)` is true, then `now > close_time`.
* By transitivity, since `now > close_time` and `close_time > base`, we must have `now > base`.
* Therefore, `now < base` is impossible when the `if (ktime_after(now, close_time))` block is entered.
#### 2. What if `now < base` hypothetically happens (e.g., due to clock jumps or other anomalies)?
Even if `now < base` hypothetically happens, the unsigned division math in `div64_u64` will **not** cause `close_time` to be in the past, nor will it cause an infinite hrtimer loop (soft lockup).
**Mathematical Proof:**
* Let $W = 2^{64}$. All 64-bit integer arithmetic is performed modulo $W$.
* Since `now < base`, `ktime_sub_ns(now, base)` is negative, which as a `u64` is represented as $D = W + \text{now} - \text{base}$.
* Let $cycle = C$.
* `n = div64_u64(D, C)` performs integer division: $D = n \cdot C + R$, where $R = D \pmod C$ and $0 \le R < C$.
* Thus, $(n + 1) \cdot C = n \cdot C + C = D - R + C = W + \text{now} - \text{base} - R + C$.
* `close_time` is calculated as:
$$\text{close\_time} = \text{base} + (n + 1) \cdot C \pmod W$$
$$\text{close\_time} = \text{base} + (W + \text{now} - \text{base} - R + C) \pmod W$$
$$\text{close\_time} = \text{now} - R + C \pmod W$$
* Since $0 \le R < C$, we have $0 < C - R \le C$.
* Therefore, $\text{close\_time}$ is in the range $[\text{now} + 1, \text{now} + C]$.
* Since `now` is the current time (a valid positive `s64` value far from `S64_MAX`) and $C$ is relatively small, `close_time` will be a valid positive `s64` value strictly in the future relative to `now`.
* Since `close_time` is in the future, the hrtimer will be scheduled for a future time and will **not** cause an infinite loop or a soft lockup.
---
### Part 2: Is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?
**No, it is not intentional; it is a significant logical bug.**
#### Consequences of not updating `gact->current_close_time`:
1. If the timer falls behind (e.g., due to temporary system delay, CPU starvation, or clock adjustments), `ktime_after(now, close_time)` becomes true.
2. `close_time` is recalculated to the next cycle boundary in the future, but `gact->current_close_time` is left unchanged (lagging far in the past).
3. In the next timer expiration, `gact->current_close_time` is incremented by `next->interval`. However, because it was lagging behind, it remains far in the past compared to the new `now`.
4. As a result, `ktime_after(now, close_time)` will evaluate to true on **every subsequent timer expiration**.
5. The timer will continually recalculate `close_time` to the next cycle boundary and reschedule itself.
6. Consequently, the timer will **only fire at cycle boundaries** (skipping all intermediate schedule entries/intervals). Each entry in the schedule will effectively run for a full cycle time instead of its specified interval, completely breaking the gate action's schedule.
#### How it should be fixed:
When `ktime_after(now, close_time)` is true, `gact->current_close_time` should be updated to the recalculated `close_time` (the start of the next cycle), and `next` should be reset to the first entry of the schedule (`list_first_entry(&p->entries, struct tcfg_gate_entry, list)`). This aligns the schedule perfectly with the next cycle boundary.]
Instruction:
You are a capable Linux kernel developer tasked with researching complex questions
about kernel source code. You will be given a concrete question, and need to provide
a concrete answer.
Use tools extensively while researching the question. Don't make assumptions,
or rely on your previous knowledge about the kernel source code, use available tools
to access the actual source code.
Use all available sources of information:
- kernel source code
- documentation in the Documentation dir in the source tree
- git commits descriptions, git blame
Do not guess file names or file paths and attempt to read them without
verifying their existence first using content search or directory listing tools.
If a file, symbol, or directory is not found via content search (grepper) or
directory listing (codesearch-dir-index), treat it as completely absent.
Do not attempt to guess alternative names, extensions, or directories.
Tool Selection Guidelines:
1. For C functions, structs, and variables: Prefer codesearch-definition-source
or codesearch-struct-layout FIRST to retrieve clean, exact definitions
without line-number guessing.
2. If symbol lookup fails (e.g., preprocessor macros, macro-generated code, or
disabled #ifdef branches), fall back to read-file or grepper.
3. For file headers, #include directives, preprocessor macro definitions, and
non-C files (Kconfig, Makefiles, docs): Use read-file or grepper directly.
Do NOT use git-log to search for the presence or existence of files in the
repository. git-log is only for tracing commit history of files that are
already present in the current checkout. If a file does not exist in the
current checkout, it cannot be used for reproduction.
Avoid running broad git-log queries (such as searches on the entire repo)
without a specific 'PathPrefix' to restrict the scope, as these are very
expensive and will time out.
If a git-log tool call times out, do not retry the query with the same broad
scope. You must specify a tighter, narrower 'PathPrefix' for subsequent queries.
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: In net/sched/act_gate.c, gate_timer_func() has the following code:
```c
if (ktime_after(now, close_time)) {
ktime_t cycle, base;
u64 n;
cycle = p->tcfg_cycletime;
base = ns_to_ktime(p->tcfg_basetime);
n = div64_u64(ktime_sub_ns(now, base), cycle);
close_time = ktime_add_ns(base, (n + 1) * cycle);
}
```
If `now < base` (which is possible since `basetime` is user-controlled), `ktime_sub_ns(now, base)` is negative.
Since `div64_u64` takes a `u64` dividend, it will be treated as a huge positive number.
Will this cause `close_time` to be calculated as a value in the past (e.g. due to overflow), leading to an infinite hrtimer loop (soft lockup)?
Also, is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?
|
| 29/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 4144
output: 38
thoughts: 246
Thoughts: **Analyzing the Act_Gate Timer Function**
Okay, let's break down this user's questions about `net/sched/act_gate.c` and specifically the `gate_timer_func()`. Their concerns are valid, and it's essential to ensure the timer's logic is sound, especially with user-controlled `basetime`.
The first question is spot on. If `now < base`, the subtraction results in a negative value. That negative value, when converted to an unsigned 64-bit integer for `div64_u64`, becomes a massive positive number. My experience tells me that this could absolutely cause `close_time` to be calculated as a value in the past due to potential overflow or, more accurately, underflow in this specific scenario. The result could then lead to a soft lockup due to an infinite hrtimer loop. That's definitely something we need to investigate more closely.
The second part of the question is just as important. They're asking why `gact->current_close_time` isn't being updated with the potentially recalculated `close_time`. Is this an intentional design decision, or is it a potential bug? We need to verify if the timer is intended to function like this, and if it is, the justification behind it.
Alright, let's get the source code for `net/sched/act_gate.c`. We can use `codesearch-definition-source`, `read-file`, or even `grepper`. I'll start with `codesearch-definition-source` to get a quick definition of `gate_timer_func`. Now that I have the source code, I can analyze the calculations and confirm their suspicions about the behavior of the timer. I need to understand this logic in detail.
|
| 30/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:gate_timer_func]
Results: map[SourceCode: 71: static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
72: {
73: struct tcf_gate *gact = container_of(timer, struct tcf_gate,
74: hitimer);
75: struct tcfg_gate_entry *next;
76: struct tcf_gate_params *p;
77: ktime_t close_time, now;
78:
79: spin_lock(&gact->tcf_lock);
80:
81: p = rcu_dereference_protected(gact->param,
82: lockdep_is_held(&gact->tcf_lock));
83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
90: gact->current_close_time = ktime_add_ns(gact->current_close_time,
91: next->interval);
92:
93: close_time = gact->current_close_time;
94:
95: if (list_is_last(&next->list, &p->entries))
96: next = list_first_entry(&p->entries,
97: struct tcfg_gate_entry, list);
98: else
99: next = list_next_entry(next, list);
100:
101: now = gate_get_time(gact);
102:
103: if (ktime_after(now, close_time)) {
104: ktime_t cycle, base;
105: u64 n;
106:
107: cycle = p->tcfg_cycletime;
108: base = ns_to_ktime(p->tcfg_basetime);
109: n = div64_u64(ktime_sub_ns(now, base), cycle);
110: close_time = ktime_add_ns(base, (n + 1) * cycle);
111: }
112:
113: gact->next_entry = next;
114:
115: hrtimer_set_expires(&gact->hitimer, close_time);
116:
117: spin_unlock(&gact->tcf_lock);
118:
119: return HRTIMER_RESTART;
120: }
SourceFile:net/sched/act_gate.c]
|
| 31/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 5612
output: 35
thoughts: 46
Thoughts: Okay, let's dive into this. Here's my thought process on the matter:
**Delving Deeper into `net/sched/act_gate.c`**
I need to understand the surrounding logic of this section, so I'm going to take a look at `net/sched/act_gate.c` for some context. Jumping into the file at the top and reviewing the initial lines will give me an immediate sense of the purpose and structure. Let's start with lines 1 through 70, to quickly gain an understanding.
|
| 32/4 |
2026/08/08 22:29 |
tool |
read-file |
0m
Args: map[File:net/sched/act_gate.c FirstLine:1 LineCount:70]
Results: map[Contents: 1: // SPDX-License-Identifier: GPL-2.0-or-later
2: /* Copyright 2020 NXP */
3:
4: #include <linux/module.h>
5: #include <linux/types.h>
6: #include <linux/kernel.h>
7: #include <linux/string.h>
8: #include <linux/errno.h>
9: #include <linux/skbuff.h>
10: #include <linux/rtnetlink.h>
11: #include <linux/init.h>
12: #include <linux/slab.h>
13: #include <net/act_api.h>
14: #include <net/netlink.h>
15: #include <net/pkt_cls.h>
16: #include <net/tc_act/tc_gate.h>
17: #include <net/tc_wrapper.h>
18:
19: static struct tc_action_ops act_gate_ops;
20:
21: static ktime_t gate_get_time(struct tcf_gate *gact)
22: {
23: ktime_t mono = ktime_get();
24:
25: switch (gact->tk_offset) {
26: case TK_OFFS_MAX:
27: return mono;
28: default:
29: return ktime_mono_to_any(mono, gact->tk_offset);
30: }
31:
32: return KTIME_MAX;
33: }
34:
35: static void tcf_gate_params_free_rcu(struct rcu_head *head);
36:
37: static void gate_get_start_time(struct tcf_gate *gact,
38: const struct tcf_gate_params *param,
39: ktime_t *start)
40: {
41: ktime_t now, base, cycle;
42: u64 n;
43:
44: base = ns_to_ktime(param->tcfg_basetime);
45: now = gate_get_time(gact);
46:
47: if (ktime_after(base, now)) {
48: *start = base;
49: return;
50: }
51:
52: cycle = param->tcfg_cycletime;
53:
54: n = div64_u64(ktime_sub_ns(now, base), cycle);
55: *start = ktime_add_ns(base, (n + 1) * cycle);
56: }
57:
58: static void gate_start_timer(struct tcf_gate *gact, ktime_t start)
59: {
60: ktime_t expires;
61:
62: expires = hrtimer_get_expires(&gact->hitimer);
63: if (expires == 0)
64: expires = KTIME_MAX;
65:
66: start = min_t(ktime_t, start, expires);
67:
68: hrtimer_start(&gact->hitimer, start, HRTIMER_MODE_ABS_SOFT);
69: }
70:
]
|
| 33/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 6777
output: 50
thoughts: 59
Thoughts: **Analyzing the Gate Timer and Closing Time**
Okay, let's dive into this `act_gate` code. My immediate focus is on understanding the lifecycle of `gate_timer_func` and how `gact->current_close_time` is set up, used, and modified. We need to trace the initialization and subsequent manipulation of that `current_close_time` variable within this context. I'll need to pinpoint precisely when and how the timer function is invoked within the gate action framework.
My next step will be to meticulously comb through `net/sched/act_gate.c`. I will be searching every instance of `current_close_time` within that file. This should help me construct a coherent picture of how that variable drives the gate's behavior and ensures it's performing as expected. I need to be sure I've identified all the read and write locations to ensure I have full context.
|
| 34/4 |
2026/08/08 22:29 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:net/sched/act_gate.c IncludeSnippetLines:10 Name:tcf_gate::current_close_time]
Results: map[References:[map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:gate_timer_func SourceFile:net/sched/act_gate.c SourceLine:90 SourceSnippet: 80:
81: p = rcu_dereference_protected(gact->param,
82: lockdep_is_held(&gact->tcf_lock));
83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
90: gact->current_close_time = ktime_add_ns(gact->current_close_time,
91: next->interval);
92:
93: close_time = gact->current_close_time;
94:
95: if (list_is_last(&next->list, &p->entries))
96: next = list_first_entry(&p->entries,
97: struct tcfg_gate_entry, list);
98: else
99: next = list_next_entry(next, list);
100:
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:gate_timer_func SourceFile:net/sched/act_gate.c SourceLine:90 SourceSnippet: 80:
81: p = rcu_dereference_protected(gact->param,
82: lockdep_is_held(&gact->tcf_lock));
83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
90: gact->current_close_time = ktime_add_ns(gact->current_close_time,
91: next->interval);
92:
93: close_time = gact->current_close_time;
94:
95: if (list_is_last(&next->list, &p->entries))
96: next = list_first_entry(&p->entries,
97: struct tcfg_gate_entry, list);
98: else
99: next = list_next_entry(next, list);
100:
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:gate_timer_func SourceFile:net/sched/act_gate.c SourceLine:93 SourceSnippet: 83: next = gact->next_entry;
84:
85: /* cycle start, clear pending bit, clear total octets */
86: gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
87: gact->current_entry_octets = 0;
88: gact->current_max_octets = next->maxoctets;
89:
90: gact->current_close_time = ktime_add_ns(gact->current_close_time,
91: next->interval);
92:
93: close_time = gact->current_close_time;
94:
95: if (list_is_last(&next->list, &p->entries))
96: next = list_first_entry(&p->entries,
97: struct tcfg_gate_entry, list);
98: else
99: next = list_next_entry(next, list);
100:
101: now = gate_get_time(gact);
102:
103: if (ktime_after(now, close_time)) {
] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:tcf_gate_init SourceFile:net/sched/act_gate.c SourceLine:518 SourceSnippet: 508: gate_setup_timer(gact, timer_clockid, tko);
509: p->tcfg_priority = prio;
510: p->tcfg_flags = gflags;
511: p->tcfg_basetime = basetime;
512: p->tcfg_clockid = timer_clockid;
513: gate_get_start_time(gact, p, &start);
514:
515: old_p = rcu_replace_pointer(gact->param, p,
516: lockdep_is_held(&gact->tcf_lock));
517:
518: gact->current_close_time = start;
519: gact->current_gate_status = GATE_ACT_GATE_OPEN | GATE_ACT_PENDING;
520:
521: gact->next_entry = list_first_entry(&p->entries,
522: struct tcfg_gate_entry, list);
523:
524: goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
525:
526: gate_start_timer(gact, start);
527:
528: spin_unlock_bh(&gact->tcf_lock);
]] TruncatedOutput:false]
|
| 35/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 8682
output: 39
thoughts: 55
Thoughts: Here's my take on the thought process, as if it were my own:
**Diving into TCF Gate Initialization**
Okay, so I need to understand the relationship between `start` and `current_close_time` within the `tcf_gate` context. Let's see how the `start` value is actually calculated, and also how `current_close_time` gets its initial value during the `tcf_gate_init` process. I'll need to trace the initialization logic to get a clear picture.
Right, time to go get the source code. Let's use `codesearch-definition-source` to fetch the definition of `tcf_gate_init`. This should provide the necessary context to uncover the secrets of how these two variables are set up. From there, I'll be able to work backward and see how the surrounding code interacts with them.
|
| 36/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:tcf_gate_init]
Results: map[SourceCode: 347: static int tcf_gate_init(struct net *net, struct nlattr *nla,
348: struct nlattr *est, struct tc_action **a,
349: struct tcf_proto *tp, u32 flags,
350: struct netlink_ext_ack *extack)
351: {
352: struct tc_action_net *tn = net_generic(net, act_gate_ops.net_id);
353: u64 cycletime = 0, basetime = 0, cycletime_ext = 0;
354: struct tcf_gate_params *p = NULL, *old_p = NULL;
355: enum tk_offsets old_tk_offset = TK_OFFS_TAI;
356: const struct tcf_gate_params *cur_p = NULL;
357: bool bind = flags & TCA_ACT_FLAGS_BIND;
358: struct nlattr *tb[TCA_GATE_MAX + 1];
359: enum tk_offsets tko = TK_OFFS_TAI;
360: struct tcf_chain *goto_ch = NULL;
361: s32 timer_clockid = CLOCK_TAI;
362: bool use_old_entries = false;
363: s32 old_clockid = CLOCK_TAI;
364: bool need_cancel = false;
365: s32 clockid = CLOCK_TAI;
366: struct tcf_gate *gact;
367: struct tc_gate *parm;
368: u64 old_basetime = 0;
369: int ret = 0, err;
370: u32 gflags = 0;
371: s32 prio = -1;
372: ktime_t start;
373: u32 index;
374:
375: if (!nla)
376: return -EINVAL;
377:
378: err = nla_parse_nested(tb, TCA_GATE_MAX, nla, gate_policy, extack);
379: if (err < 0)
380: return err;
381:
382: if (!tb[TCA_GATE_PARMS])
383: return -EINVAL;
384:
385: if (tb[TCA_GATE_CLOCKID])
386: clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
387:
388: parm = nla_data(tb[TCA_GATE_PARMS]);
389: index = parm->index;
390:
391: err = tcf_idr_check_alloc(tn, &index, a, bind);
392: if (err < 0)
393: return err;
394:
395: if (err && bind)
396: return ACT_P_BOUND;
397:
398: if (!err) {
399: ret = tcf_idr_create_from_flags(tn, index, est, a,
400: &act_gate_ops, bind, flags);
401: if (ret) {
402: tcf_idr_cleanup(tn, index);
403: return ret;
404: }
405:
406: ret = ACT_P_CREATED;
407: } else if (!(flags & TCA_ACT_FLAGS_REPLACE)) {
408: tcf_idr_release(*a, bind);
409: return -EEXIST;
410: }
411:
412: gact = to_gate(*a);
413:
414: err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
415: if (err < 0)
416: goto release_idr;
417:
418: p = kzalloc(sizeof(*p), GFP_KERNEL);
419: if (!p) {
420: err = -ENOMEM;
421: goto chain_put;
422: }
423: INIT_LIST_HEAD(&p->entries);
424:
425: use_old_entries = !tb[TCA_GATE_ENTRY_LIST];
426: if (!use_old_entries) {
427: err = parse_gate_list(tb[TCA_GATE_ENTRY_LIST], p, extack);
428: if (err < 0)
429: goto err_free;
430: use_old_entries = !err;
431: }
432:
433: if (ret == ACT_P_CREATED && use_old_entries) {
434: NL_SET_ERR_MSG(extack, "The entry list is empty");
435: err = -EINVAL;
436: goto err_free;
437: }
438:
439: if (ret != ACT_P_CREATED) {
440: rcu_read_lock();
441: cur_p = rcu_dereference(gact->param);
442:
443: old_basetime = cur_p->tcfg_basetime;
444: old_clockid = cur_p->tcfg_clockid;
445: old_tk_offset = READ_ONCE(gact->tk_offset);
446:
447: basetime = old_basetime;
448: cycletime_ext = cur_p->tcfg_cycletime_ext;
449: prio = cur_p->tcfg_priority;
450: gflags = cur_p->tcfg_flags;
451:
452: if (!tb[TCA_GATE_CLOCKID])
453: clockid = old_clockid;
454:
455: err = 0;
456: if (use_old_entries) {
457: err = tcf_gate_copy_entries(p, cur_p, extack);
458: if (!err && !tb[TCA_GATE_CYCLE_TIME])
459: cycletime = cur_p->tcfg_cycletime;
460: }
461: rcu_read_unlock();
462: if (err)
463: goto err_free;
464: }
465:
466: if (tb[TCA_GATE_PRIORITY])
467: prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
468:
469: if (tb[TCA_GATE_BASE_TIME])
470: basetime = nla_get_u64(tb[TCA_GATE_BASE_TIME]);
471:
472: if (tb[TCA_GATE_FLAGS])
473: gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
474:
475: if (tb[TCA_GATE_CYCLE_TIME])
476: cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
477:
478: if (tb[TCA_GATE_CYCLE_TIME_EXT])
479: cycletime_ext = nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
480:
481: err = gate_clock_resolve(clockid, &tko, extack);
482: if (err)
483: goto err_free;
484: timer_clockid = clockid;
485:
486: need_cancel = ret != ACT_P_CREATED &&
487: gate_timer_needs_cancel(basetime, old_basetime,
488: tko, old_tk_offset,
489: timer_clockid, old_clockid);
490:
491: if (need_cancel)
492: hrtimer_cancel(&gact->hitimer);
493:
494: spin_lock_bh(&gact->tcf_lock);
495:
496: if (!cycletime) {
497: struct tcfg_gate_entry *entry;
498: ktime_t cycle = 0;
499:
500: list_for_each_entry(entry, &p->entries, list)
501: cycle = ktime_add_ns(cycle, entry->interval);
502: cycletime = cycle;
503: }
504: p->tcfg_cycletime = cycletime;
505: p->tcfg_cycletime_ext = cycletime_ext;
506:
507: if (need_cancel || ret == ACT_P_CREATED)
508: gate_setup_timer(gact, timer_clockid, tko);
509: p->tcfg_priority = prio;
510: p->tcfg_flags = gflags;
511: p->tcfg_basetime = basetime;
512: p->tcfg_clockid = timer_clockid;
513: gate_get_start_time(gact, p, &start);
514:
515: old_p = rcu_replace_pointer(gact->param, p,
516: lockdep_is_held(&gact->tcf_lock));
517:
518: gact->current_close_time = start;
519: gact->current_gate_status = GATE_ACT_GATE_OPEN | GATE_ACT_PENDING;
520:
521: gact->next_entry = list_first_entry(&p->entries,
522: struct tcfg_gate_entry, list);
523:
524: goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
525:
526: gate_start_timer(gact, start);
527:
528: spin_unlock_bh(&gact->tcf_lock);
529:
530: if (goto_ch)
531: tcf_chain_put_by_act(goto_ch);
532:
533: if (old_p)
534: call_rcu(&old_p->rcu, tcf_gate_params_free_rcu);
535:
536: return ret;
537:
538: err_free:
539: release_entry_list(&p->entries);
540: kfree(p);
541: chain_put:
542: if (goto_ch)
543: tcf_chain_put_by_act(goto_ch);
544: release_idr:
545: /* action is not inserted in any list: it's safe to init hitimer
546: * without taking tcf_lock.
547: */
548: if (ret == ACT_P_CREATED)
549: gate_setup_timer(gact, timer_clockid, tko);
550:
551: tcf_idr_release(*a, bind);
552: return err;
553: }
SourceFile:net/sched/act_gate.c]
|
| 37/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 12321
output: 40
thoughts: 1248
Thoughts: **Analyzing Potential Issues with the Gate Timer Implementation**
Okay, let's break this down. The initial question regarding potential issues in the gate timer implementation has got me thinking. The core of the problem seems to be the potential for `now` being less than `base`, given that `base` is user-controlled. The concern is that if `now < base`, `ktime_sub_ns(now, base)` will result in a negative value, which, when treated as an unsigned 64-bit integer by `div64_u64`, will become a very large positive number. This could lead to a `close_time` calculation that results in a value in the past due to overflow. A past `close_time` would lead to an infinite timer loop, effectively a soft lockup.
I need to dive deeper into the code to trace how `close_time` and `base` relate. Let's look at `gate_get_start_time`. Here, if `base` is greater than `now`, `start` is set to `base`, and `gact->current_close_time` is initialized to this `base`. The timer is started with this `base` value.
Then, when the timer expires, `gate_timer_func` is called. At the start of `gate_timer_func`, `gact->current_close_time` is incremented by `next->interval`, and `close_time` is set to this updated value. The critical point is whether `now` (from `gate_get_time(gact)`) can actually be less than `base` when the timer function runs. The timer should expire at or after `base`. Thus, under normal conditions, `now` should be greater than or equal to `base`.
But wait, can `now` somehow be less than `base`? Hrtimers *shouldn't* fire before their set time. However, what if the system time is changed? If the user changes the system clock (like `CLOCK_REALTIME` or `CLOCK_TAI` clock types), `gate_get_time(gact)` can indeed return a time that's *before* `base` if the clock is jumped backwards.
Furthermore, consider `gact->tk_offset` which can be `TK_OFFS_TAI` β that's TAI, which can be adjusted. This is the real potential for `now < base` to occur. Even with a monotonic clock, a future `base` setting and a subsequent clock change could make `now < base`.
Now, what if `base` is set to a future time, and the system clock is then adjusted backwards, or what if `base` is set to a *very* large value in the future? If `base` is in the future, the timer is scheduled to expire at `base`. A user parameter update could then lead to a recalculation of the timer, potentially cancelling it.
Now, let's look at `tcf_gate_init`. If the action is replaced. `gate_timer_needs_cancel` is called. It looks like I need to analyze `gate_timer_needs_cancel` to understand the conditions when this happens. I must go search for it.
|
| 38/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:gate_timer_needs_cancel]
Results: map[SourceCode: 307: static bool gate_timer_needs_cancel(u64 basetime, u64 old_basetime,
308: enum tk_offsets tko,
309: enum tk_offsets old_tko,
310: s32 clockid, s32 old_clockid)
311: {
312: return basetime != old_basetime ||
313: clockid != old_clockid ||
314: tko != old_tko;
315: }
SourceFile:net/sched/act_gate.c]
|
| 39/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 14490
output: 38
thoughts: 2658
Thoughts: **Analyzing Time Calculations with `ktime_t` and `u64`**
Okay, so I'm digging into this timer logic. The key seems to be how we handle time calculations when `basetime` changes or when the current time (`now`) is *before* `base`. If `basetime` changes, we cancel and restart the timer, but the interesting case is when other parameters change, and `basetime` *doesn't* change, because the calculations are more complex. Let's trace it through.
I'm starting by looking at the behavior of `div64_u64(ktime_sub_ns(now, base), cycle)` when `now < base`. This is where the signed-to-unsigned conversion comes into play, and I want to make sure I understand the consequences. `ktime_sub_ns(now, base)` is going to give me a *negative* `s64` value because `ktime_t` is a signed 64-bit integer. That value is then passed into `div64_u64`. Because the function expects *unsigned* `u64` operands, the negative `s64` is implicitly cast to `u64`. That means the negative value gets converted to a *huge* positive `u64` value β essentially, `2^64` minus the absolute value of the original negative number. Let's call this huge number `D = 2^64 - |now - base|`.
Now, we have `n = D / cycle` where D is a huge number. Since D is huge, the resulting `n` is, naturally, also going to be huge. Then we calculate the close time as `close_time = ktime_add_ns(base, (n + 1) * cycle);`. I need to pay close attention to this. I'm seeing that we add `(n + 1) * cycle` to `base` to obtain the *close_time*. Let me see if I can simplify that.
Let's expand the `(n + 1) * cycle` part: since `n = D / cycle`, then `n * cycle = D - (D % cycle)`. This means that `(n + 1) * cycle = D - (D % cycle) + cycle`. Substituting this into the equation for `close_time` yields `close_time = base + (2^64 - |now - base| - (D % cycle) + cycle)`. Because we're dealing with 64-bit arithmetic, adding `2^64` is effectively a no-op, it just wraps around. Hence, we can simplify this expression to `close_time = base - |now - base| - (D % cycle) + cycle`. But `base - |now - base|` turns out to be equal to `now`. So, it simplifies to `close_time = now - (D % cycle) + cycle`.
I'm seeing that with these steps, the calculation will always result in a `close_time` in the future relative to `now`. I can double-check with a concrete example. I can choose a scenario with small numbers to help me track. Let's test `cycle = 100`, `base = 1000`, and `now = 950`.
* Then `now - base = -50`.
* Which as a `u64` is `2^64 - 50`
* `D = 2^64 - 50`.
* `D % 100 = (2^64 - 50) % 100 = (16 - 50) % 100 = -34 % 100 = 66`.
* Then `n = (2^64 - 50 - 66) / 100 = (2^64 - 116) / 100`.
* Then `(n + 1) * cycle = (n + 1) * 100 = 2^64 - 116 + 100 = 2^64 - 16`.
* Then `close_time = 1000 + 2^64 - 16 = 984`, modulo `2^64`.
It looks good: 984 is greater than 950. Let's try another example. `now = 910`:
* Then `now - base = -90`.
* As a `u64` is
|
| 40/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Error:
Args: map[ContextFile:include/linux/ktime.h Name:ktime_add_ns]
Results: map[SourceCode: SourceFile:]
|
| 41/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 18232
output: 26
thoughts: 35
Thoughts: Okay, here's my attempt at summarizing that thought process, tailored for an expert audience:
**Kernel Time Investigation**
Right, let me see... I'm pretty sure `ktime_add_ns` is defined somewhere in the kernel's timekeeping headers. My initial guess, given its name, is that it's in `include/linux/ktime.h`. Now, to confirm and locate the definitive declaration, I'll need to run a quick search. Time to fire up `grepper` and see if my hunch is correct. I should be able to track it down in a snap.
|
| 42/4 |
2026/08/08 22:29 |
tool |
grepper |
0m
Error:
Args: map[Expression:static inline ktime_t ktime_add_ns]
Results:
|
| 43/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 18437
output: 30
thoughts: 23
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it were my own internal monologue:
**Refining the Search Strategy**
Alright, I'm thinking I need to find the definition or usage of `ktime_add_ns`. It's a kernel function, so I'll use `grepper` β that's the tool for the job. But, "ktime_add_ns" directly might be too specific at first. I suspect there might be variations or related functions in the codebase. Let's simplify the search query to something a little broader to see if we can get a better initial overview. Perhaps a more basic expression will yield more relevant results initially, letting me home in on precisely what I'm after, and how it is used.
|
| 44/4 |
2026/08/08 22:29 |
tool |
grepper |
0m
Args: map[Expression:ktime_add_ns PathPrefix:include/linux/]
Results: map[Output:include/linux/hrtimer.h=103=static inline void hrtimer_add_expires_ns(struct hrtimer *timer, u64 ns)
include/linux/hrtimer.h-104-{
include/linux/hrtimer.h:105: timer->node.expires = ktime_add_ns(timer->node.expires, ns);
include/linux/hrtimer.h:106: timer->_softexpires = ktime_add_ns(timer->_softexpires, ns);
include/linux/hrtimer.h-107-}
--
include/linux/ktime.h=36=static inline ktime_t ktime_set(const s64 secs, const unsigned long nsecs)
--
include/linux/ktime.h-59- */
include/linux/ktime.h:60:#define ktime_add_ns(kt, nsval) ((kt) + (nsval))
include/linux/ktime.h-61-
--
include/linux/ktime.h=177=static inline ktime_t ktime_add_us(const ktime_t kt, const u64 usec)
include/linux/ktime.h-178-{
include/linux/ktime.h:179: return ktime_add_ns(kt, usec * NSEC_PER_USEC);
include/linux/ktime.h-180-}
--
include/linux/ktime.h=182=static inline ktime_t ktime_add_ms(const ktime_t kt, const u64 msec)
include/linux/ktime.h-183-{
include/linux/ktime.h:184: return ktime_add_ns(kt, msec * NSEC_PER_MSEC);
include/linux/ktime.h-185-}
]
|
| 45/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 19129
output: 38
thoughts: 965
Thoughts: **Analyzing the Time Calculation in the Kernel Code**
Okay, so I'm looking at this `ktime_add_ns` macro and how it's used. Right, it's just a simple addition: `((kt) + (nsval))`. And `ktime_t` is an `s64`. So the code is effectively doing `base + ((n + 1) * cycle)`. `base` is an `s64`, and `(n + 1) * cycle` is a `u64`. C's usual arithmetic conversions mean the `s64` gets cast to a `u64`, the addition happens as `u64`, and then the result is assigned back to `close_time`, which is an `s64`. Essentially, it does a modulo `2^64` addition. That means the result is `base + (n + 1) * cycle` modulo `2^64`.
We showed mathematically that that's the same as `now - R + cycle` where `R = (2^64 + now - base) % cycle`. Since `0 <= R < cycle`, we're guaranteed that `0 < cycle - R <= cycle`. Thus `close_time` is in the range `[now + 1, now + cycle]`. That means it's always strictly *after* `now`.
But, wait... are there any edge cases? What if `now` is really huge, or if `now - R + cycle` overflows the signed `s64`? Okay, `now` is `gate_get_time(gact)`. This means it's the current time, and a valid `ktime_t`. In normal operation, it's going to be a positive value, far from `S64_MAX` (292 years from the epoch). So it won't overflow the positive `s64`. `cycle` is also positive, and relatively small (milliseconds or seconds, usually). So the arithmetic won't exceed `S64_MAX`. Therefore, `close_time` will be a valid, positive `s64` and strictly greater than `now`.
Hold on... let's double-check for other possible issues. Hmm, what if `cycle` is zero? Can that happen? I'll look into that.
Okay, let's see how `cycle` is determined. In `tcf_gate_init`, if `cycletime` is initially zero, the code iterates through a list of entries and sums up their intervals:
```c
if (!cycletime) {
struct tcfg_gate_entry *entry;
ktime_t cycle = 0;
list_for_each_entry(entry, &p->entries, list)
cycle = ktime_add_ns(cycle, entry->interval);
cycletime = cycle;
}
```
Wait, if `cycletime` is zero *or* the list is empty? If the entry list is empty, then the function *returns* `-EINVAL` and sets an error message, which is good.
```c
if (ret == ACT_P_CREATED && use_old_entries) {
NL_SET_ERR_MSG(extack, "The entry list is empty");
err = -EINVAL;
goto err_free;
}
```
Okay, so the code handles the case where the list is empty. Each entry's `interval` must also be positive. Let's make sure `parse_gate_list` does proper input validation. I will verify that `interval` is positive by checking `parse_gate_list` with `codesearch-definition-source`.
|
| 46/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:parse_gate_list]
Results: map[SourceCode: 262: static int parse_gate_list(struct nlattr *list_attr,
263: struct tcf_gate_params *sched,
264: struct netlink_ext_ack *extack)
265: {
266: struct tcfg_gate_entry *entry;
267: struct nlattr *n;
268: int err, rem;
269: int i = 0;
270:
271: if (!list_attr)
272: return -EINVAL;
273:
274: nla_for_each_nested(n, list_attr, rem) {
275: if (nla_type(n) != TCA_GATE_ONE_ENTRY) {
276: NL_SET_ERR_MSG(extack, "Attribute isn't type 'entry'");
277: continue;
278: }
279:
280: entry = kzalloc_obj(*entry, GFP_ATOMIC);
281: if (!entry) {
282: NL_SET_ERR_MSG(extack, "Not enough memory for entry");
283: err = -ENOMEM;
284: goto release_list;
285: }
286:
287: err = parse_gate_entry(n, entry, i, extack);
288: if (err < 0) {
289: kfree(entry);
290: goto release_list;
291: }
292:
293: list_add_tail(&entry->list, &sched->entries);
294: i++;
295: }
296:
297: sched->num_entries = i;
298:
299: return i;
300:
301: release_list:
302: release_entry_list(&sched->entries);
303:
304: return err;
305: }
SourceFile:net/sched/act_gate.c]
|
| 47/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 21571
output: 38
thoughts: 20
Thoughts: Here's my thought process, as requested:
**Navigating the Codebase**
Okay, I need to pinpoint the definition of `parse_gate_entry`. My initial instinct is to use the `codesearch-definition-source` tool. It's usually the quickest way to jump directly to where a function is declared, especially in a codebase this size. I'm hoping it's a straightforward search and I can quickly get the file path and context. I'll execute the command and see what it returns. Hopefully, the results are accurate and I can begin analyzing the function's implementation immediately.
|
| 48/4 |
2026/08/08 22:29 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:parse_gate_entry]
Results: map[SourceCode: 206: static int parse_gate_entry(struct nlattr *n, struct tcfg_gate_entry *entry,
207: int index, struct netlink_ext_ack *extack)
208: {
209: struct nlattr *tb[TCA_GATE_ENTRY_MAX + 1] = { };
210: int err;
211:
212: err = nla_parse_nested(tb, TCA_GATE_ENTRY_MAX, n, entry_policy, extack);
213: if (err < 0) {
214: NL_SET_ERR_MSG(extack, "Could not parse nested entry");
215: return -EINVAL;
216: }
217:
218: entry->index = index;
219:
220: return fill_gate_entry(tb, entry, extack);
221: }
SourceFile:net/sched/act_gate.c]
|
| 49/4 |
2026/08/08 22:29 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 22047
output: 38
thoughts: 20
Thoughts: Here's my thought process, as if I were thinking it:
**Finding the `fill_gate_entry` Function**
Okay, so I need to track down the definition of the `fill_gate_entry` function. Itβs important, I know that much. Let's see... a quick `codesearch-definition-source` search should get me where I need to be. Given my experience, I'm expecting this to either be in some core library related to gate management, or perhaps a more specialized module within the codebase. Iβll be looking for header files, certainly. I'm hoping I don't have to wade through too much macro magic before I get to the actual implementation. I anticipate it will be relatively straightforward, assuming it is properly documented. Let's see what we find!
|
| 50/4 |
2026/08/08 22:30 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/act_gate.c Name:fill_gate_entry]
Results: map[SourceCode: 181: static int fill_gate_entry(struct nlattr **tb, struct tcfg_gate_entry *entry,
182: struct netlink_ext_ack *extack)
183: {
184: u32 interval = 0;
185:
186: entry->gate_state = nla_get_flag(tb[TCA_GATE_ENTRY_GATE]);
187:
188: if (tb[TCA_GATE_ENTRY_INTERVAL])
189: interval = nla_get_u32(tb[TCA_GATE_ENTRY_INTERVAL]);
190:
191: if (interval == 0) {
192: NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
193: return -EINVAL;
194: }
195:
196: entry->interval = interval;
197:
198: entry->ipv = nla_get_s32_default(tb[TCA_GATE_ENTRY_IPV], -1);
199:
200: entry->maxoctets = nla_get_s32_default(tb[TCA_GATE_ENTRY_MAX_OCTETS],
201: -1);
202:
203: return 0;
204: }
SourceFile:net/sched/act_gate.c]
|
| 51/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 22689
output: 53
thoughts: 345
Thoughts: **Analyzing the Gate Action's Cycle Time Logic**
Okay, so I'm digging into this `act_gate` code and I've hit a point where the behavior around the `cycletime` parameter is key. Initially, I realized that the `interval` value, crucial for the gate's operation, *has* to be positive. That's a fundamental constraint. Now, the `cycletime` itself is either user-defined or derived from the sum of the individual intervals. The question that popped up immediately: Can a user *intentionally* supply a `cycletime` value of zero?
Let me dive into `tcf_gate_init` to verify how it's handled:
```c
if (tb[TCA_GATE_CYCLE_TIME])
cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
```
The code directly pulls the `cycletime` from the user-provided data. But, wait... does it *validate* it? I don't see any explicit check for a zero value here.
Digging further, I observe:
```c
if (!cycletime) {
struct tcfg_gate_entry *entry;
ktime_t cycle = 0;
list_for_each_entry(entry, &p->entries, list)
cycle = ktime_add_ns(cycle, entry->interval);
cycletime = cycle;
}
```
Aha! If the user *does* specify a zero `cycletime`, this block kicks in. It calculates the `cycletime` by summing up all the intervals from the gate entries. Since each entry *requires* a positive interval, this effectively guarantees that `cycletime` will always be positive. Even if the user *tries* to break it with a 0 value. It will be overwritten with a valid one.
Just to be thorough, I'm going to search the rest of the `net/sched/act_gate.c` file for any other validation of `cycletime`, just to make sure there's nothing I'm missing. Looking for `tcfg_cycletime`.
|
| 52/4 |
2026/08/08 22:30 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:net/sched/act_gate.c IncludeSnippetLines:5 Name:tcf_gate_params::tcfg_cycletime]
Results: map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:gate_get_start_time SourceFile:net/sched/act_gate.c SourceLine:52 SourceSnippet: 47: if (ktime_after(base, now)) {
48: *start = base;
49: return;
50: }
51:
52: cycle = param->tcfg_cycletime;
53:
54: n = div64_u64(ktime_sub_ns(now, base), cycle);
55: *start = ktime_add_ns(base, (n + 1) * cycle);
56: }
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:gate_timer_func SourceFile:net/sched/act_gate.c SourceLine:107 SourceSnippet: 102:
103: if (ktime_after(now, close_time)) {
104: ktime_t cycle, base;
105: u64 n;
106:
107: cycle = p->tcfg_cycletime;
108: base = ns_to_ktime(p->tcfg_basetime);
109: n = div64_u64(ktime_sub_ns(now, base), cycle);
110: close_time = ktime_add_ns(base, (n + 1) * cycle);
111: }
112:
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:tcf_gate_cycletime SourceFile:include/net/tc_act/tc_gate.h SourceLine:91 SourceSnippet: 86: {
87: struct tcf_gate_params *p;
88: u64 tcfg_cycletime;
89:
90: p = tcf_gate_params_locked(a);
91: tcfg_cycletime = p->tcfg_cycletime;
92:
93: return tcfg_cycletime;
94: }
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:tcf_gate_dump SourceFile:net/sched/act_gate.c SourceLine:632 SourceSnippet: 627: if (nla_put_u64_64bit(skb, TCA_GATE_BASE_TIME,
628: p->tcfg_basetime, TCA_GATE_PAD))
629: goto nla_put_failure;
630:
631: if (nla_put_u64_64bit(skb, TCA_GATE_CYCLE_TIME,
632: p->tcfg_cycletime, TCA_GATE_PAD))
633: goto nla_put_failure;
634:
635: if (nla_put_u64_64bit(skb, TCA_GATE_CYCLE_TIME_EXT,
636: p->tcfg_cycletime_ext, TCA_GATE_PAD))
637: goto nla_put_failure;
] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:tcf_gate_init SourceFile:net/sched/act_gate.c SourceLine:459 SourceSnippet: 454:
455: err = 0;
456: if (use_old_entries) {
457: err = tcf_gate_copy_entries(p, cur_p, extack);
458: if (!err && !tb[TCA_GATE_CYCLE_TIME])
459: cycletime = cur_p->tcfg_cycletime;
460: }
461: rcu_read_unlock();
462: if (err)
463: goto err_free;
464: }
] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:tcf_gate_init SourceFile:net/sched/act_gate.c SourceLine:504 SourceSnippet: 499:
500: list_for_each_entry(entry, &p->entries, list)
501: cycle = ktime_add_ns(cycle, entry->interval);
502: cycletime = cycle;
503: }
504: p->tcfg_cycletime = cycletime;
505: p->tcfg_cycletime_ext = cycletime_ext;
506:
507: if (need_cancel || ret == ACT_P_CREATED)
508: gate_setup_timer(gact, timer_clockid, tko);
509: p->tcfg_priority = prio;
]] TruncatedOutput:false]
|
| 53/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 24978
output: 37
thoughts: 3797
Thoughts: **Analysis of `act_gate.c` Timer Logic and Potential Overflow Issues**
Okay, so I've been dissecting the logic in `act_gate.c`, specifically concerning the timer functions and calculations involving `div64_u64`. The core concern revolves around the potential for `close_time` to be calculated in the past, potentially leading to an infinite timer loop due to incorrect calculations, or other unexpected behaviors.
First, I've confirmed that `tcfg_cycletime` is always positive and non-zero, that is a given. Next I looked at the scenario where `now < base` (where `base` is user-controlled), which leads to a negative value when using `ktime_sub_ns`. The problem, in short, is that `div64_u64` operates on unsigned 64-bit integers.
I've carefully traced the calculation of `close_time`. I've proven mathematically that `close_time` is always in the future relative to `now`. Specifically, it is defined by the formula `now - R + cycle` (modulo 2^64), where `R` is a value between 0 and `cycle`. This means `close_time` is always greater than or equal to `now + 1`, therefore always in the future. I did a specific example to confirm my understanding of this calculation.
The other key point I analyzed concerns overflows. The question is can `close_time` be negative because of an overflow in the calculation? The analysis indicates that because `now` and `cycle` are well-behaved, and `now` is not close to the maximum `s64` value, there should be no overflow. Specifically, I've considered scenarios where `now` is close to or greater than the maximum signed 64-bit integer, but in practice, based on the nature of the timing system, this scenario is highly unlikely.
I then did a sweep of where `div64_u64` is used. I found that in `gate_get_start_time`, `ktime_sub_ns(now, base)` is guaranteed to be non-negative because of the `if` condition used to check if `base > now`. Therefore, this use of `div64_u64` is safe.
However, in `gate_timer_func`, there's another use of `div64_u64`. This is where the concern about `close_time` re-calculation arises. If `ktime_after(now, close_time)` is true, the `close_time` calculation is triggered. The question is, can this lead to an infinite loop, or unexpected timer behavior?
I've worked through the various scenarios:
* **Clock jumps forward:** If the clock jumps forward, `now` becomes greater than `close_time`, so the re-calculation occurs. This should be okay, since `close_time` will be set to the *next* valid future time.
* **Clock jumps backward:** If the clock jumps backward, then `now` is less than `close_time` in most scenarios, so the re-calculation won't be triggered.
* **A race condition if `base` is in the future:** I looked to confirm there is never a condition where `now > close_time` AND `now < base`. Based on the timer logic, since `close_time` is *always* greater than `base` and the interval, this can't occur.
A critical point I noticed is that the *recalculated* `close_time` is *not* used to update `gact->current_close_time`. In other words, if `close_time` has been re-calculated, the state of the timer is not reset. This is concerning, because the next time the timer expires, the "old" (and now out of date) `close_time` would be used, leading to the re-calculation again.
Therefore, the main concern here is a bug in the code where `gact->current_close_time` is not updated with the newly calculated value. This could, in practice, lead to an infinite timer loop or at least incorrect behavior. It also means that the timer would consistently trigger *later* than scheduled if the clock "jumps".
|
| 54/4 |
2026/08/08 22:30 |
tool |
git-log |
0m
Args: map[CodeRegexp:gate_timer_func PathPrefix:net/sched/act_gate.c]
Results: map[Output:62413a9c3cb1 net/sched: act_gate: snapshot parameters with RCU on replace
efcb2d32a8f5 net/sched: Switch to use hrtimer_setup()
c362a06e96ea net/sched: act_gate: fix configuration of the periodic timer
a51c328df310 net: qos: introduce a gate control flow action
]
|
| 55/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 29861
output: 26
thoughts: 25
Thoughts: Here's a summary of my thought process, as requested:
**Diving into the Code History**
Okay, time to get my hands dirty. I need to understand what happened at commit `c362a06e96ea`. The most direct approach, of course, is to leverage `git show`. I'll use `git show` to quickly visualize the changes introduced by that commit. I'm expecting to see the diff, the author, the commit message, and any other metadata that will give me context. This should provide the foundational understanding of what was modified and why.
|
| 56/4 |
2026/08/08 22:30 |
tool |
git-show |
0m
Args:
Results: map[Output:commit c362a06e96eae16ccb7b0f4f93f19224279b8610
Author: Davide Caratti <dcaratti@redhat.com>
Date: Tue Jun 16 22:25:21 2020 +0200
net/sched: act_gate: fix configuration of the periodic timer
assigning a dummy value of 'clock_id' to avoid cancellation of the cycle
timer before its initialization was a temporary solution, and we still
need to handle the case where act_gate timer parameters are changed by
commands like the following one:
# tc action replace action gate <parameters>
the fix consists in the following items:
1) remove the workaround assignment of 'clock_id', and init the list of
entries before the first error path after IDR atomic check/allocation
2) validate 'clock_id' earlier: there is no need to do IDR atomic
check/allocation if we know that 'clock_id' is a bad value
3) use a dedicated function, 'gate_setup_timer()', to ensure that the
timer is cancelled and re-initialized on action overwrite, and also
ensure we initialize the timer in the error path of tcf_gate_init()
v3: improve comment in the error path of tcf_gate_init() (thanks to
Vladimir Oltean)
v2: avoid 'goto' in gate_setup_timer (thanks to Cong Wang)
CC: Ivan Vecera <ivecera@redhat.com>
Fixes: a01c245438c5 ("net/sched: fix a couple of splats in the error path of tfc_gate_init()")
Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
index 94e560c2f81d..323ae7f6315d 100644
--- a/net/sched/act_gate.c
+++ b/net/sched/act_gate.c
@@ -272,6 +272,27 @@ static int parse_gate_list(struct nlattr *list_attr,
return err;
}
+static void gate_setup_timer(struct tcf_gate *gact, u64 basetime,
+ enum tk_offsets tko, s32 clockid,
+ bool do_init)
+{
+ if (!do_init) {
+ if (basetime == gact->param.tcfg_basetime &&
+ tko == gact->tk_offset &&
+ clockid == gact->param.tcfg_clockid)
+ return;
+
+ spin_unlock_bh(&gact->tcf_lock);
+ hrtimer_cancel(&gact->hitimer);
+ spin_lock_bh(&gact->tcf_lock);
+ }
+ gact->param.tcfg_basetime = basetime;
+ gact->param.tcfg_clockid = clockid;
+ gact->tk_offset = tko;
+ hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS_SOFT);
+ gact->hitimer.function = gate_timer_func;
+}
+
static int tcf_gate_init(struct net *net, struct nlattr *nla,
struct nlattr *est, struct tc_action **a,
int ovr, int bind, bool rtnl_held,
@@ -303,6 +324,27 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (!tb[TCA_GATE_PARMS])
return -EINVAL;
+ if (tb[TCA_GATE_CLOCKID]) {
+ clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
+ switch (clockid) {
+ case CLOCK_REALTIME:
+ tk_offset = TK_OFFS_REAL;
+ break;
+ case CLOCK_MONOTONIC:
+ tk_offset = TK_OFFS_MAX;
+ break;
+ case CLOCK_BOOTTIME:
+ tk_offset = TK_OFFS_BOOT;
+ break;
+ case CLOCK_TAI:
+ tk_offset = TK_OFFS_TAI;
+ break;
+ default:
+ NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
+ return -EINVAL;
+ }
+ }
+
parm = nla_data(tb[TCA_GATE_PARMS]);
index = parm->index;
@@ -326,10 +368,6 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
tcf_idr_release(*a, bind);
return -EEXIST;
}
- if (ret == ACT_P_CREATED) {
- to_gate(*a)->param.tcfg_clockid = -1;
- INIT_LIST_HEAD(&(to_gate(*a)->param.entries));
- }
if (tb[TCA_GATE_PRIORITY])
prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
@@ -340,33 +378,14 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (tb[TCA_GATE_FLAGS])
gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
- if (tb[TCA_GATE_CLOCKID]) {
- clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
- switch (clockid) {
- case CLOCK_REALTIME:
- tk_offset = TK_OFFS_REAL;
- break;
- case CLOCK_MONOTONIC:
- tk_offset = TK_OFFS_MAX;
- break;
- case CLOCK_BOOTTIME:
- tk_offset = TK_OFFS_BOOT;
- break;
- case CLOCK_TAI:
- tk_offset = TK_OFFS_TAI;
- break;
- default:
- NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
- goto release_idr;
- }
- }
+ gact = to_gate(*a);
+ if (ret == ACT_P_CREATED)
+ INIT_LIST_HEAD(&gact->param.entries);
err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
if (err < 0)
goto release_idr;
- gact = to_gate(*a);
-
spin_lock_bh(&gact->tcf_lock);
p = &gact->param;
@@ -397,14 +416,10 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
p->tcfg_cycletime_ext =
nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
+ gate_setup_timer(gact, basetime, tk_offset, clockid,
+ ret == ACT_P_CREATED);
p->tcfg_priority = prio;
- p->tcfg_basetime = basetime;
- p->tcfg_clockid = clockid;
p->tcfg_flags = gflags;
-
- gact->tk_offset = tk_offset;
- hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS_SOFT);
- gact->hitimer.function = gate_timer_func;
gate_get_start_time(gact, &start);
gact->current_close_time = start;
@@ -433,6 +448,13 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
release_idr:
+ /* action is not inserted in any list: it's safe to init hitimer
+ * without taking tcf_lock.
+ */
+ if (ret == ACT_P_CREATED)
+ gate_setup_timer(gact, gact->param.tcfg_basetime,
+ gact->tk_offset, gact->param.tcfg_clockid,
+ true);
tcf_idr_release(*a, bind);
return err;
}
@@ -443,9 +465,7 @@ static void tcf_gate_cleanup(struct tc_action *a)
struct tcf_gate_params *p;
p = &gact->param;
- if (p->tcfg_clockid != -1)
- hrtimer_cancel(&gact->hitimer);
-
+ hrtimer_cancel(&gact->hitimer);
release_entry_list(&p->entries);
}
]
|
| 57/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 32513
output: 37
thoughts: 48
Thoughts: **Investigating Time-Related Code Modifications**
Okay, so I need to track down recent changes to code involving either `gate_timer_func` or `current_close_time`. My initial thought is to leverage `git log` β that's the natural first step for this kind of investigation. I can refine the search using some clever options to narrow the results.
The most direct approach seems to be using `CodeRegexp` with `git-log`. I will specify a regular expression that targets modifications to these variables. Specifically, I'll start with `"current_close_time"` as a key search term, understanding that I can adjust or expand the regex as needed based on the initial output. That should give me a good starting point to identify relevant commits. I'll need to remember to check the output carefully, though, and consider different forms of those keywords, to be certain I'm not missing anything important.
|
| 58/4 |
2026/08/08 22:30 |
tool |
git-log |
0m
Args: map[CodeRegexp:current_close_time PathPrefix:net/sched/act_gate.c]
Results: map[Output:a51c328df310 net: qos: introduce a gate control flow action
]
|
| 59/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 32828
output: 26
thoughts: 64
Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective:
**Diving into the History of `current_close_time`**
Alright, so the clue is `current_close_time` which was introduced in commit `a51c328df310` and, according to the information, hasn't seen any changes since. My initial thought is to go directly to the source. Given that this variable hasn't been touched, I can infer that the initial implementation is the definitive one. I need to get a clear picture of how `gate_timer_func` was originally designed. Examining the original definition in commit `a51c328df310` should illuminate the intended behavior and any dependencies it might have had when it was initially created. Knowing the original intent is key to understanding the current state and any potential issues that may have arisen from interacting code, even if the variable itself is unchanged.
|
| 60/4 |
2026/08/08 22:30 |
tool |
git-show |
0m
Args:
Results: map[Output:commit a51c328df3106663879645680609eb49b3ff6444
Author: Po Liu <Po.Liu@nxp.com>
Date: Fri May 1 08:53:15 2020 +0800
net: qos: introduce a gate control flow action
Introduce a ingress frame gate control flow action.
Tc gate action does the work like this:
Assume there is a gate allow specified ingress frames can be passed at
specific time slot, and be dropped at specific time slot. Tc filter
chooses the ingress frames, and tc gate action would specify what slot
does these frames can be passed to device and what time slot would be
dropped.
Tc gate action would provide an entry list to tell how much time gate
keep open and how much time gate keep state close. Gate action also
assign a start time to tell when the entry list start. Then driver would
repeat the gate entry list cyclically.
For the software simulation, gate action requires the user assign a time
clock type.
Below is the setting example in user space. Tc filter a stream source ip
address is 192.168.0.20 and gate action own two time slots. One is last
200ms gate open let frame pass another is last 100ms gate close let
frames dropped. When the ingress frames have reach total frames over
8000000 bytes, the excessive frames will be dropped in that 200000000ns
time slot.
> tc qdisc add dev eth0 ingress
> tc filter add dev eth0 parent ffff: protocol ip \
flower src_ip 192.168.0.20 \
action gate index 2 clockid CLOCK_TAI \
sched-entry open 200000000 -1 8000000 \
sched-entry close 100000000 -1 -1
> tc chain del dev eth0 ingress chain 0
"sched-entry" follow the name taprio style. Gate state is
"open"/"close". Follow with period nanosecond. Then next item is internal
priority value means which ingress queue should put. "-1" means
wildcard. The last value optional specifies the maximum number of
MSDU octets that are permitted to pass the gate during the specified
time interval.
Base-time is not set will be 0 as default, as result start time would
be ((N + 1) * cycletime) which is the minimal of future time.
Below example shows filtering a stream with destination mac address is
10:00:80:00:00:00 and ip type is ICMP, follow the action gate. The gate
action would run with one close time slot which means always keep close.
The time cycle is total 200000000ns. The base-time would calculate by:
1357000000000 + (N + 1) * cycletime
When the total value is the future time, it will be the start time.
The cycletime here would be 200000000ns for this case.
> tc filter add dev eth0 parent ffff: protocol ip \
flower skip_hw ip_proto icmp dst_mac 10:00:80:00:00:00 \
action gate index 12 base-time 1357000000000 \
sched-entry close 200000000 -1 -1 \
clockid CLOCK_TAI
Signed-off-by: Po Liu <Po.Liu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/net/tc_act/tc_gate.h b/include/net/tc_act/tc_gate.h
new file mode 100644
index 000000000000..330ad8b02495
--- /dev/null
+++ b/include/net/tc_act/tc_gate.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* Copyright 2020 NXP */
+
+#ifndef __NET_TC_GATE_H
+#define __NET_TC_GATE_H
+
+#include <net/act_api.h>
+#include <linux/tc_act/tc_gate.h>
+
+struct tcfg_gate_entry {
+ int index;
+ u8 gate_state;
+ u32 interval;
+ s32 ipv;
+ s32 maxoctets;
+ struct list_head list;
+};
+
+struct tcf_gate_params {
+ s32 tcfg_priority;
+ u64 tcfg_basetime;
+ u64 tcfg_cycletime;
+ u64 tcfg_cycletime_ext;
+ u32 tcfg_flags;
+ s32 tcfg_clockid;
+ size_t num_entries;
+ struct list_head entries;
+};
+
+#define GATE_ACT_GATE_OPEN BIT(0)
+#define GATE_ACT_PENDING BIT(1)
+
+struct tcf_gate {
+ struct tc_action common;
+ struct tcf_gate_params param;
+ u8 current_gate_status;
+ ktime_t current_close_time;
+ u32 current_entry_octets;
+ s32 current_max_octets;
+ struct tcfg_gate_entry *next_entry;
+ struct hrtimer hitimer;
+ enum tk_offsets tk_offset;
+};
+
+#define to_gate(a) ((struct tcf_gate *)a)
+
+#endif
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 9f06d29cab70..fc672b232437 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -134,6 +134,7 @@ enum tca_id {
TCA_ID_CTINFO,
TCA_ID_MPLS,
TCA_ID_CT,
+ TCA_ID_GATE,
/* other actions go here */
__TCA_ID_MAX = 255
};
diff --git a/include/uapi/linux/tc_act/tc_gate.h b/include/uapi/linux/tc_act/tc_gate.h
new file mode 100644
index 000000000000..f214b3a6d44f
--- /dev/null
+++ b/include/uapi/linux/tc_act/tc_gate.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/* Copyright 2020 NXP */
+
+#ifndef __LINUX_TC_GATE_H
+#define __LINUX_TC_GATE_H
+
+#include <linux/pkt_cls.h>
+
+struct tc_gate {
+ tc_gen;
+};
+
+enum {
+ TCA_GATE_ENTRY_UNSPEC,
+ TCA_GATE_ENTRY_INDEX,
+ TCA_GATE_ENTRY_GATE,
+ TCA_GATE_ENTRY_INTERVAL,
+ TCA_GATE_ENTRY_IPV,
+ TCA_GATE_ENTRY_MAX_OCTETS,
+ __TCA_GATE_ENTRY_MAX,
+};
+#define TCA_GATE_ENTRY_MAX (__TCA_GATE_ENTRY_MAX - 1)
+
+enum {
+ TCA_GATE_ONE_ENTRY_UNSPEC,
+ TCA_GATE_ONE_ENTRY,
+ __TCA_GATE_ONE_ENTRY_MAX,
+};
+#define TCA_GATE_ONE_ENTRY_MAX (__TCA_GATE_ONE_ENTRY_MAX - 1)
+
+enum {
+ TCA_GATE_UNSPEC,
+ TCA_GATE_TM,
+ TCA_GATE_PARMS,
+ TCA_GATE_PAD,
+ TCA_GATE_PRIORITY,
+ TCA_GATE_ENTRY_LIST,
+ TCA_GATE_BASE_TIME,
+ TCA_GATE_CYCLE_TIME,
+ TCA_GATE_CYCLE_TIME_EXT,
+ TCA_GATE_FLAGS,
+ TCA_GATE_CLOCKID,
+ __TCA_GATE_MAX,
+};
+#define TCA_GATE_MAX (__TCA_GATE_MAX - 1)
+
+#endif
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index bfbefb7bff9d..2f20073f4f84 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -981,6 +981,18 @@ config NET_ACT_CT
To compile this code as a module, choose M here: the
module will be called act_ct.
+config NET_ACT_GATE
+ tristate "Frame gate entry list control tc action"
+ depends on NET_CLS_ACT
+ help
+ Say Y here to allow to control the ingress flow to be passed at
+ specific time slot and be dropped at other specific time slot by
+ the gate entry list.
+
+ If unsure, say N.
+ To compile this code as a module, choose M here: the
+ module will be called act_gate.
+
config NET_IFE_SKBMARK
tristate "Support to encoding decoding skb mark on IFE action"
depends on NET_ACT_IFE
diff --git a/net/sched/Makefile b/net/sched/Makefile
index 31c367a6cd09..66bbf9a98f9e 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_NET_IFE_SKBPRIO) += act_meta_skbprio.o
obj-$(CONFIG_NET_IFE_SKBTCINDEX) += act_meta_skbtcindex.o
obj-$(CONFIG_NET_ACT_TUNNEL_KEY)+= act_tunnel_key.o
obj-$(CONFIG_NET_ACT_CT) += act_ct.o
+obj-$(CONFIG_NET_ACT_GATE) += act_gate.o
obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o
obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o
obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
new file mode 100644
index 000000000000..35fc48795541
--- /dev/null
+++ b/net/sched/act_gate.c
@@ -0,0 +1,636 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright 2020 NXP */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/skbuff.h>
+#include <linux/rtnetlink.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <net/act_api.h>
+#include <net/netlink.h>
+#include <net/pkt_cls.h>
+#include <net/tc_act/tc_gate.h>
+
+static unsigned int gate_net_id;
+static struct tc_action_ops act_gate_ops;
+
+static ktime_t gate_get_time(struct tcf_gate *gact)
+{
+ ktime_t mono = ktime_get();
+
+ switch (gact->tk_offset) {
+ case TK_OFFS_MAX:
+ return mono;
+ default:
+ return ktime_mono_to_any(mono, gact->tk_offset);
+ }
+
+ return KTIME_MAX;
+}
+
+static int gate_get_start_time(struct tcf_gate *gact, ktime_t *start)
+{
+ struct tcf_gate_params *param = &gact->param;
+ ktime_t now, base, cycle;
+ u64 n;
+
+ base = ns_to_ktime(param->tcfg_basetime);
+ now = gate_get_time(gact);
+
+ if (ktime_after(base, now)) {
+ *start = base;
+ return 0;
+ }
+
+ cycle = param->tcfg_cycletime;
+
+ /* cycle time should not be zero */
+ if (!cycle)
+ return -EFAULT;
+
+ n = div64_u64(ktime_sub_ns(now, base), cycle);
+ *start = ktime_add_ns(base, (n + 1) * cycle);
+ return 0;
+}
+
+static void gate_start_timer(struct tcf_gate *gact, ktime_t start)
+{
+ ktime_t expires;
+
+ expires = hrtimer_get_expires(&gact->hitimer);
+ if (expires == 0)
+ expires = KTIME_MAX;
+
+ start = min_t(ktime_t, start, expires);
+
+ hrtimer_start(&gact->hitimer, start, HRTIMER_MODE_ABS_SOFT);
+}
+
+static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
+{
+ struct tcf_gate *gact = container_of(timer, struct tcf_gate,
+ hitimer);
+ struct tcf_gate_params *p = &gact->param;
+ struct tcfg_gate_entry *next;
+ ktime_t close_time, now;
+
+ spin_lock(&gact->tcf_lock);
+
+ next = gact->next_entry;
+
+ /* cycle start, clear pending bit, clear total octets */
+ gact->current_gate_status = next->gate_state ? GATE_ACT_GATE_OPEN : 0;
+ gact->current_entry_octets = 0;
+ gact->current_max_octets = next->maxoctets;
+
+ gact->current_close_time = ktime_add_ns(gact->current_close_time,
+ next->interval);
+
+ close_time = gact->current_close_time;
+
+ if (list_is_last(&next->list, &p->entries))
+ next = list_first_entry(&p->entries,
+ struct tcfg_gate_entry, list);
+ else
+ next = list_next_entry(next, list);
+
+ now = gate_get_time(gact);
+
+ if (ktime_after(now, close_time)) {
+ ktime_t cycle, base;
+ u64 n;
+
+ cycle = p->tcfg_cycletime;
+ base = ns_to_ktime(p->tcfg_basetime);
+ n = div64_u64(ktime_sub_ns(now, base), cycle);
+ close_time = ktime_add_ns(base, (n + 1) * cycle);
+ }
+
+ gact->next_entry = next;
+
+ hrtimer_set_expires(&gact->hitimer, close_time);
+
+ spin_unlock(&gact->tcf_lock);
+
+ return HRTIMER_RESTART;
+}
+
+static int tcf_gate_act(struct sk_buff *skb, const struct tc_action *a,
+ struct tcf_result *res)
+{
+ struct tcf_gate *gact = to_gate(a);
+
+ spin_lock(&gact->tcf_lock);
+
+ tcf_lastuse_update(&gact->tcf_tm);
+ bstats_update(&gact->tcf_bstats, skb);
+
+ if (unlikely(gact->current_gate_status & GATE_ACT_PENDING)) {
+ spin_unlock(&gact->tcf_lock);
+ return gact->tcf_action;
+ }
+
+ if (!(gact->current_gate_status & GATE_ACT_GATE_OPEN))
+ goto drop;
+
+ if (gact->current_max_octets >= 0) {
+ gact->current_entry_octets += qdisc_pkt_len(skb);
+ if (gact->current_entry_octets > gact->current_max_octets) {
+ gact->tcf_qstats.overlimits++;
+ goto drop;
+ }
+ }
+
+ spin_unlock(&gact->tcf_lock);
+
+ return gact->tcf_action;
+drop:
+ gact->tcf_qstats.drops++;
+ spin_unlock(&gact->tcf_lock);
+
+ return TC_ACT_SHOT;
+}
+
+static const struct nla_policy entry_policy[TCA_GATE_ENTRY_MAX + 1] = {
+ [TCA_GATE_ENTRY_INDEX] = { .type = NLA_U32 },
+ [TCA_GATE_ENTRY_GATE] = { .type = NLA_FLAG },
+ [TCA_GATE_ENTRY_INTERVAL] = { .type = NLA_U32 },
+ [TCA_GATE_ENTRY_IPV] = { .type = NLA_S32 },
+ [TCA_GATE_ENTRY_MAX_OCTETS] = { .type = NLA_S32 },
+};
+
+static const struct nla_policy gate_policy[TCA_GATE_MAX + 1] = {
+ [TCA_GATE_PARMS] = { .len = sizeof(struct tc_gate),
+ .type = NLA_EXACT_LEN },
+ [TCA_GATE_PRIORITY] = { .type = NLA_S32 },
+ [TCA_GATE_ENTRY_LIST] = { .type = NLA_NESTED },
+ [TCA_GATE_BASE_TIME] = { .type = NLA_U64 },
+ [TCA_GATE_CYCLE_TIME] = { .type = NLA_U64 },
+ [TCA_GATE_CYCLE_TIME_EXT] = { .type = NLA_U64 },
+ [TCA_GATE_FLAGS] = { .type = NLA_U32 },
+ [TCA_GATE_CLOCKID] = { .type = NLA_S32 },
+};
+
+static int fill_gate_entry(struct nlattr **tb, struct tcfg_gate_entry *entry,
+ struct netlink_ext_ack *extack)
+{
+ u32 interval = 0;
+
+ entry->gate_state = nla_get_flag(tb[TCA_GATE_ENTRY_GATE]);
+
+ if (tb[TCA_GATE_ENTRY_INTERVAL])
+ interval = nla_get_u32(tb[TCA_GATE_ENTRY_INTERVAL]);
+
+ if (interval == 0) {
+ NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
+ return -EINVAL;
+ }
+
+ entry->interval = interval;
+
+ if (tb[TCA_GATE_ENTRY_IPV])
+ entry->ipv = nla_get_s32(tb[TCA_GATE_ENTRY_IPV]);
+ else
+ entry->ipv = -1;
+
+ if (tb[TCA_GATE_ENTRY_MAX_OCTETS])
+ entry->maxoctets = nla_get_s32(tb[TCA_GATE_ENTRY_MAX_OCTETS]);
+ else
+ entry->maxoctets = -1;
+
+ return 0;
+}
+
+static int parse_gate_entry(struct nlattr *n, struct tcfg_gate_entry *entry,
+ int index, struct netlink_ext_ack *extack)
+{
+ struct nlattr *tb[TCA_GATE_ENTRY_MAX + 1] = { };
+ int err;
+
+ err = nla_parse_nested(tb, TCA_GATE_ENTRY_MAX, n, entry_policy, extack);
+ if (err < 0) {
+ NL_SET_ERR_MSG(extack, "Could not parse nested entry");
+ return -EINVAL;
+ }
+
+ entry->index = index;
+
+ return fill_gate_entry(tb, entry, extack);
+}
+
+static void release_entry_list(struct list_head *entries)
+{
+ struct tcfg_gate_entry *entry, *e;
+
+ list_for_each_entry_safe(entry, e, entries, list) {
+ list_del(&entry->list);
+ kfree(entry);
+ }
+}
+
+static int parse_gate_list(struct nlattr *list_attr,
+ struct tcf_gate_params *sched,
+ struct netlink_ext_ack *extack)
+{
+ struct tcfg_gate_entry *entry;
+ struct nlattr *n;
+ int err, rem;
+ int i = 0;
+
+ if (!list_attr)
+ return -EINVAL;
+
+ nla_for_each_nested(n, list_attr, rem) {
+ if (nla_type(n) != TCA_GATE_ONE_ENTRY) {
+ NL_SET_ERR_MSG(extack, "Attribute isn't type 'entry'");
+ continue;
+ }
+
+ entry = kzalloc(sizeof(*entry), GFP_ATOMIC);
+ if (!entry) {
+ NL_SET_ERR_MSG(extack, "Not enough memory for entry");
+ err = -ENOMEM;
+ goto release_list;
+ }
+
+ err = parse_gate_entry(n, entry, i, extack);
+ if (err < 0) {
+ kfree(entry);
+ goto release_list;
+ }
+
+ list_add_tail(&entry->list, &sched->entries);
+ i++;
+ }
+
+ sched->num_entries = i;
+
+ return i;
+
+release_list:
+ release_entry_list(&sched->entries);
+
+ return err;
+}
+
+static int tcf_gate_init(struct net *net, struct nlattr *nla,
+ struct nlattr *est, struct tc_action **a,
+ int ovr, int bind, bool rtnl_held,
+ struct tcf_proto *tp, u32 flags,
+ struct netlink_ext_ack *extack)
+{
+ struct tc_action_net *tn = net_generic(net, gate_net_id);
+ enum tk_offsets tk_offset = TK_OFFS_TAI;
+ struct nlattr *tb[TCA_GATE_MAX + 1];
+ struct tcf_chain *goto_ch = NULL;
+ struct tcf_gate_params *p;
+ s32 clockid = CLOCK_TAI;
+ struct tcf_gate *gact;
+ struct tc_gate *parm;
+ int ret = 0, err;
+ u64 basetime = 0;
+ u32 gflags = 0;
+ s32 prio = -1;
+ ktime_t start;
+ u32 index;
+
+ if (!nla)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_GATE_MAX, nla, gate_policy, extack);
+ if (err < 0)
+ return err;
+
+ if (!tb[TCA_GATE_PARMS])
+ return -EINVAL;
+
+ parm = nla_data(tb[TCA_GATE_PARMS]);
+ index = parm->index;
+
+ err = tcf_idr_check_alloc(tn, &index, a, bind);
+ if (err < 0)
+ return err;
+
+ if (err && bind)
+ return 0;
+
+ if (!err) {
+ ret = tcf_idr_create(tn, index, est, a,
+ &act_gate_ops, bind, false, 0);
+ if (ret) {
+ tcf_idr_cleanup(tn, index);
+ return ret;
+ }
+
+ ret = ACT_P_CREATED;
+ } else if (!ovr) {
+ tcf_idr_release(*a, bind);
+ return -EEXIST;
+ }
+
+ if (tb[TCA_GATE_PRIORITY])
+ prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
+
+ if (tb[TCA_GATE_BASE_TIME])
+ basetime = nla_get_u64(tb[TCA_GATE_BASE_TIME]);
+
+ if (tb[TCA_GATE_FLAGS])
+ gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
+
+ if (tb[TCA_GATE_CLOCKID]) {
+ clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
+ switch (clockid) {
+ case CLOCK_REALTIME:
+ tk_offset = TK_OFFS_REAL;
+ break;
+ case CLOCK_MONOTONIC:
+ tk_offset = TK_OFFS_MAX;
+ break;
+ case CLOCK_BOOTTIME:
+ tk_offset = TK_OFFS_BOOT;
+ break;
+ case CLOCK_TAI:
+ tk_offset = TK_OFFS_TAI;
+ break;
+ default:
+ NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
+ goto release_idr;
+ }
+ }
+
+ err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
+ if (err < 0)
+ goto release_idr;
+
+ gact = to_gate(*a);
+
+ spin_lock_bh(&gact->tcf_lock);
+ p = &gact->param;
+
+ if (tb[TCA_GATE_CYCLE_TIME]) {
+ p->tcfg_cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
+ if (!p->tcfg_cycletime_ext)
+ goto chain_put;
+ }
+
+ INIT_LIST_HEAD(&p->entries);
+ if (tb[TCA_GATE_ENTRY_LIST]) {
+ err = parse_gate_list(tb[TCA_GATE_ENTRY_LIST], p, extack);
+ if (err < 0)
+ goto chain_put;
+ }
+
+ if (!p->tcfg_cycletime) {
+ struct tcfg_gate_entry *entry;
+ ktime_t cycle = 0;
+
+ list_for_each_entry(entry, &p->entries, list)
+ cycle = ktime_add_ns(cycle, entry->interval);
+ p->tcfg_cycletime = cycle;
+ }
+
+ if (tb[TCA_GATE_CYCLE_TIME_EXT])
+ p->tcfg_cycletime_ext =
+ nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
+
+ p->tcfg_priority = prio;
+ p->tcfg_basetime = basetime;
+ p->tcfg_clockid = clockid;
+ p->tcfg_flags = gflags;
+
+ gact->tk_offset = tk_offset;
+ hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS_SOFT);
+ gact->hitimer.function = gate_timer_func;
+
+ err = gate_get_start_time(gact, &start);
+ if (err < 0) {
+ NL_SET_ERR_MSG(extack,
+ "Internal error: failed get start time");
+ release_entry_list(&p->entries);
+ goto chain_put;
+ }
+
+ gact->current_close_time = start;
+ gact->current_gate_status = GATE_ACT_GATE_OPEN | GATE_ACT_PENDING;
+
+ gact->next_entry = list_first_entry(&p->entries,
+ struct tcfg_gate_entry, list);
+
+ goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
+
+ gate_start_timer(gact, start);
+
+ spin_unlock_bh(&gact->tcf_lock);
+
+ if (goto_ch)
+ tcf_chain_put_by_act(goto_ch);
+
+ if (ret == ACT_P_CREATED)
+ tcf_idr_insert(tn, *a);
+
+ return ret;
+
+chain_put:
+ spin_unlock_bh(&gact->tcf_lock);
+
+ if (goto_ch)
+ tcf_chain_put_by_act(goto_ch);
+release_idr:
+ tcf_idr_release(*a, bind);
+ return err;
+}
+
+static void tcf_gate_cleanup(struct tc_action *a)
+{
+ struct tcf_gate *gact = to_gate(a);
+ struct tcf_gate_params *p;
+
+ hrtimer_cancel(&gact->hitimer);
+
+ p = &gact->param;
+
+ release_entry_list(&p->entries);
+}
+
+static int dumping_entry(struct sk_buff *skb,
+ struct tcfg_gate_entry *entry)
+{
+ struct nlattr *item;
+
+ item = nla_nest_start_noflag(skb, TCA_GATE_ONE_ENTRY);
+ if (!item)
+ return -ENOSPC;
+
+ if (nla_put_u32(skb, TCA_GATE_ENTRY_INDEX, entry->index))
+ goto nla_put_failure;
+
+ if (entry->gate_state && nla_put_flag(skb, TCA_GATE_ENTRY_GATE))
+ goto nla_put_failure;
+
+ if (nla_put_u32(skb, TCA_GATE_ENTRY_INTERVAL, entry->interval))
+ goto nla_put_failure;
+
+ if (nla_put_s32(skb, TCA_GATE_ENTRY_MAX_OCTETS, entry->maxoctets))
+ goto nla_put_failure;
+
+ if (nla_put_s32(skb, TCA_GATE_ENTRY_IPV, entry->ipv))
+ goto nla_put_failure;
+
+ return nla_nest_end(skb, item);
+
+nla_put_failure:
+ nla_nest_cancel(skb, item);
+ return -1;
+}
+
+static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
+ int bind, int ref)
+{
+ unsigned char *b = skb_tail_pointer(skb);
+ struct tcf_gate *gact = to_gate(a);
+ struct tc_gate opt = {
+ .index = gact->tcf_index,
+ .refcnt = refcount_read(&gact->tcf_refcnt) - ref,
+ .bindcnt = atomic_read(&gact->tcf_bindcnt) - bind,
+ };
+ struct tcfg_gate_entry *entry;
+ struct tcf_gate_params *p;
+ struct nlattr *entry_list;
+ struct tcf_t t;
+
+ spin_lock_bh(&gact->tcf_lock);
+ opt.action = gact->tcf_action;
+
+ p = &gact->param;
+
+ if (nla_put(skb, TCA_GATE_PARMS, sizeof(opt), &opt))
+ goto nla_put_failure;
+
+ if (nla_put_u64_64bit(skb, TCA_GATE_BASE_TIME,
+ p->tcfg_basetime, TCA_GATE_PAD))
+ goto nla_put_failure;
+
+ if (nla_put_u64_64bit(skb, TCA_GATE_CYCLE_TIME,
+ p->tcfg_cycletime, TCA_GATE_PAD))
+ goto nla_put_failure;
+
+ if (nla_put_u64_64bit(skb, TCA_GATE_CYCLE_TIME_EXT,
+ p->tcfg_cycletime_ext, TCA_GATE_PAD))
+ goto nla_put_failure;
+
+ if (nla_put_s32(skb, TCA_GATE_CLOCKID, p->tcfg_clockid))
+ goto nla_put_failure;
+
+ if (nla_put_u32(skb, TCA_GATE_FLAGS, p->tcfg_flags))
+ goto nla_put_failure;
+
+ if (nla_put_s32(skb, TCA_GATE_PRIORITY, p->tcfg_priority))
+ goto nla_put_failure;
+
+ entry_list = nla_nest_start_noflag(skb, TCA_GATE_ENTRY_LIST);
+ if (!entry_list)
+ goto nla_put_failure;
+
+ list_for_each_entry(entry, &p->entries, list) {
+ if (dumping_entry(skb, entry) < 0)
+ goto nla_put_failure;
+ }
+
+ nla_nest_end(skb, entry_list);
+
+ tcf_tm_dump(&t, &gact->tcf_tm);
+ if (nla_put_64bit(skb, TCA_GATE_TM, sizeof(t), &t, TCA_GATE_PAD))
+ goto nla_put_failure;
+ spin_unlock_bh(&gact->tcf_lock);
+
+ return skb->len;
+
+nla_put_failure:
+ spin_unlock_bh(&gact->tcf_lock);
+ nlmsg_trim(skb, b);
+ return -1;
+}
+
+static int tcf_gate_walker(struct net *net, struct sk_buff *skb,
+ struct netlink_callback *cb, int type,
+ const struct tc_action_ops *ops,
+ struct netlink_ext_ack *extack)
+{
+ struct tc_action_net *tn = net_generic(net, gate_net_id);
+
+ return tcf_generic_walker(tn, skb, cb, type, ops, extack);
+}
+
+static void tcf_gate_stats_update(struct tc_action *a, u64 bytes, u32 packets,
+ u64 lastuse, bool hw)
+{
+ struct tcf_gate *gact = to_gate(a);
+ struct tcf_t *tm = &gact->tcf_tm;
+
+ tcf_action_update_stats(a, bytes, packets, false, hw);
+ tm->lastuse = max_t(u64, tm->lastuse, lastuse);
+}
+
+static int tcf_gate_search(struct net *net, struct tc_action **a, u32 index)
+{
+ struct tc_action_net *tn = net_generic(net, gate_net_id);
+
+ return tcf_idr_search(tn, a, index);
+}
+
+static size_t tcf_gate_get_fill_size(const struct tc_action *act)
+{
+ return nla_total_size(sizeof(struct tc_gate));
+}
+
+static struct tc_action_ops act_gate_ops = {
+ .kind = "gate",
+ .id = TCA_ID_GATE,
+ .owner = THIS_MODULE,
+ .act = tcf_gate_act,
+ .dump = tcf_gate_dump,
+ .init = tcf_gate_init,
+ .cleanup = tcf_gate_cleanup,
+ .walk = tcf_gate_walker,
+ .stats_update = tcf_gate_stats_update,
+ .get_fill_size = tcf_gate_get_fill_size,
+ .lookup = tcf_gate_search,
+ .size = sizeof(struct tcf_gate),
+};
+
+static __net_init int gate_init_net(struct net *net)
+{
+ struct tc_action_net *tn = net_generic(net, gate_net_id);
+
+ return tc_action_net_init(net, tn, &act_gate_ops);
+}
+
+static void __net_exit gate_exit_net(struct list_head *net_list)
+{
+ tc_action_net_exit(net_list, gate_net_id);
+}
+
+static struct pernet_operations gate_net_ops = {
+ .init = gate_init_net,
+ .exit_batch = gate_exit_net,
+ .id = &gate_net_id,
+ .size = sizeof(struct tc_action_net),
+};
+
+static int __init gate_init_module(void)
+{
+ return tcf_register_action(&act_gate_ops, &gate_net_ops);
+}
+
+static void __exit gate_cleanup_module(void)
+{
+ tcf_unregister_action(&act_gate_ops, &gate_net_ops);
+}
+
+module_init(gate_init_module);
+module_exit(gate_cleanup_module);
+MODULE_LICENSE("GPL v2");
]
|
| 61/4 |
2026/08/08 22:30 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 43189
output: 19
thoughts: 3309
Thoughts: **Analysis of `gate_timer_func` and Schedule Desynchronization**
Okay, let's dive into this `gate_timer_func` and figure out what's going on. The core issue, it seems, revolves around whether `gact->current_close_time` gets updated when `close_time` is recalculated, specifically when the timer "falls behind" the schedule.
I'm seeing that when `ktime_after(now, close_time)` is true (meaning the current time is beyond the scheduled time), a new `close_time` is calculated using cycle time and base time, effectively jumping to the *next* cycle boundary. However, and this is crucial, `gact->current_close_time` remains untouched! This is a red flag.
So, here's the consequence: `gact->current_close_time` continues to be calculated based on an outdated, past value. Therefore, in the subsequent timer expiration, `close_time` will again be in the past, triggering another recalculation to the next cycle boundary. This is starting to look like a problem with desynchronization.
The result is that the schedule entries are being traversed one by one, but their times are completely wrong because `gact->current_close_time` is lagging behind!
I'm hypothesizing that if `gact->current_close_time` remains in the past, it will always trigger the recalculation, effectively *skipping* any intermediate entries in the schedule. The timer will exclusively fire at cycle boundaries, completely ignoring the intended schedule's granularity.
I'm running through a scenario: with a cycle of three entries, each with an interval of 100ms, and then say the system is busy, and we hit the timer after it's supposed to fire at 350ms, meaning, the entire first cycle has completed. After that the timer fires every cycle and skips every intermediate entry.
I have just confirmed the desynchronization. The consequence is that instead of scheduling each entry for 100ms, the timer will execute the entry for a full cycle (300ms) instead of the specified interval (100ms)!
I'm now thinking: the fix would be to *also* update `gact->current_close_time` with the recalculated `close_time` and advance to the correct entry in the list, effectively resynchronizing the schedule. This would then cause the schedule to execute correctly. But, because that update isn't happening, the system is fundamentally broken. Any missed timer expiration will permanently desynchronize the schedule.
Time to search for similar logic in other network scheduler code... Let's check `act_taprio.c` and `sch_taprio.c`.
|
| 62/4 |
2026/08/08 22:31 |
tool |
grepper |
0m
Args: map[Expression:tcfg_basetime]
Results: map[Output:include/net/tc_act/tc_gate.h=26=struct tcf_gate_params {
include/net/tc_act/tc_gate.h-27- s32 tcfg_priority;
include/net/tc_act/tc_gate.h:28: u64 tcfg_basetime;
include/net/tc_act/tc_gate.h-29- u64 tcfg_cycletime;
--
include/net/tc_act/tc_gate.h=74=static inline u64 tcf_gate_basetime(const struct tc_action *a)
--
include/net/tc_act/tc_gate.h-76- struct tcf_gate_params *p;
include/net/tc_act/tc_gate.h:77: u64 tcfg_basetime;
include/net/tc_act/tc_gate.h-78-
include/net/tc_act/tc_gate.h-79- p = tcf_gate_params_locked(a);
include/net/tc_act/tc_gate.h:80: tcfg_basetime = p->tcfg_basetime;
include/net/tc_act/tc_gate.h-81-
include/net/tc_act/tc_gate.h:82: return tcfg_basetime;
include/net/tc_act/tc_gate.h-83-}
--
net/sched/act_gate.c=37=static void gate_get_start_time(struct tcf_gate *gact,
--
net/sched/act_gate.c-43-
net/sched/act_gate.c:44: base = ns_to_ktime(param->tcfg_basetime);
net/sched/act_gate.c-45- now = gate_get_time(gact);
--
net/sched/act_gate.c=71=static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
--
net/sched/act_gate.c-107- cycle = p->tcfg_cycletime;
net/sched/act_gate.c:108: base = ns_to_ktime(p->tcfg_basetime);
net/sched/act_gate.c-109- n = div64_u64(ktime_sub_ns(now, base), cycle);
--
net/sched/act_gate.c=347=static int tcf_gate_init(struct net *net, struct nlattr *nla,
--
net/sched/act_gate.c-442-
net/sched/act_gate.c:443: old_basetime = cur_p->tcfg_basetime;
net/sched/act_gate.c-444- old_clockid = cur_p->tcfg_clockid;
--
net/sched/act_gate.c-510- p->tcfg_flags = gflags;
net/sched/act_gate.c:511: p->tcfg_basetime = basetime;
net/sched/act_gate.c-512- p->tcfg_clockid = timer_clockid;
--
net/sched/act_gate.c=605=static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
--
net/sched/act_gate.c-627- if (nla_put_u64_64bit(skb, TCA_GATE_BASE_TIME,
net/sched/act_gate.c:628: p->tcfg_basetime, TCA_GATE_PAD))
net/sched/act_gate.c-629- goto nla_put_failure;
]
|
| 63/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 48071
output: 22
thoughts: 36
Thoughts: Okay, here's my interpretation of those thoughts, framed as my own, given my expertise:
**Examining TAPRIO's Timing Mechanisms**
Right, I need to get a handle on how this scheduling is working. The best place to start is with the `taprio` timer functions. I want to see exactly how they're handling these scheduling events. Let's dig into the code and see the logic used for the actual timer management. I suspect that understanding that will illuminate the critical path. Then, to get a broader view, I should look at all the files related to `taprio` within the `net/sched/` directory. That should give me a more complete picture of the overall architecture and how these timer functions fit into the larger scheme of things.
|
| 64/4 |
2026/08/08 22:31 |
tool |
codesearch-dir-index |
0m
Args:
Results: map[Files:[act_api.c act_bpf.c act_connmark.c act_csum.c act_ct.c act_ctinfo.c act_gact.c act_gate.c act_ife.c act_meta_mark.c act_meta_skbprio.c act_meta_skbtcindex.c act_mirred.c act_mpls.c act_nat.c act_pedit.c act_police.c act_sample.c act_simple.c act_skbedit.c act_skbmod.c act_tunnel_key.c act_vlan.c bpf_qdisc.c cls_api.c cls_basic.c cls_bpf.c cls_cgroup.c cls_flow.c cls_flower.c cls_fw.c cls_matchall.c cls_route.c cls_u32.c em_canid.c em_cmp.c em_ipset.c em_ipt.c em_meta.c em_nbyte.c em_text.c em_u32.c ematch.c sch_api.c sch_blackhole.c sch_cake.c sch_cbs.c sch_choke.c sch_codel.c sch_drr.c sch_dualpi2.c sch_etf.c sch_ets.c sch_fifo.c sch_fq.c sch_fq_codel.c sch_fq_pie.c sch_frag.c sch_generic.c sch_gred.c sch_hfsc.c sch_hhf.c sch_htb.c sch_ingress.c sch_mq.c sch_mqprio.c sch_mqprio_lib.c sch_mqprio_lib.h sch_multiq.c sch_netem.c sch_pie.c sch_plug.c sch_prio.c sch_qfq.c sch_red.c sch_sfb.c sch_sfq.c sch_skbprio.c sch_taprio.c sch_tbf.c sch_teql.c] Subdirs:<nil>]
|
| 65/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 49023
output: 37
thoughts: 70
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience:
**Analyzing the TAPRIO Scheduler Timer Implementation**
Right, so `sch_taprio.c` is present. That's good. Now, I need to delve into how TAPRIO handles its timing mechanisms. Specifically, I want to find the core timer functions within the scheduling logic. I'll need to locate how the time slots and cycle management are actually done. Given my familiarity with the kernel, I'll use `grepper` β itβs often the quickest way to home in on relevant code. My focus will be on finding functions related to `timer` or `hrtimer` within `net/sched/sch_taprio.c`. That should quickly reveal the heart of the scheduling mechanism and how the periodic scheduling is implemented.
|
| 66/4 |
2026/08/08 22:31 |
tool |
grepper |
0m
Args: map[Expression:static enum hrtimer_restart PathPrefix:net/sched/sch_taprio.c]
Results: map[Output:net/sched/sch_taprio.c=884=static bool should_change_schedules(const struct sched_gate_list *admin,
--
net/sched/sch_taprio.c-917-
net/sched/sch_taprio.c:918:static enum hrtimer_restart advance_sched(struct hrtimer *timer)
net/sched/sch_taprio.c-919-{
]
|
| 67/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 49418
output: 37
thoughts: 31
Thoughts: Here's my take on the process, framed as a first-person account suitable for a networking expert like myself:
**Diving into the `sch_taprio` Code**
Okay, so I need to get a handle on the `advance_sched` function within `net/sched/sch_taprio.c`. The `codesearch-definition-source` tool is my best bet for a rapid and accurate jump into the code itself. With the tool, I can get right to the source code of this scheduling class. From there I can determine how the algorithm works and which portions of the code are the key focus.
|
| 68/4 |
2026/08/08 22:31 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/sched/sch_taprio.c Name:advance_sched]
Results: map[SourceCode: 918: static enum hrtimer_restart advance_sched(struct hrtimer *timer)
919: {
920: struct taprio_sched *q = container_of(timer, struct taprio_sched,
921: advance_timer);
922: struct net_device *dev = qdisc_dev(q->root);
923: struct sched_gate_list *oper, *admin;
924: int num_tc = netdev_get_num_tc(dev);
925: struct sched_entry *entry, *next;
926: struct Qdisc *sch = q->root;
927: ktime_t end_time;
928: int tc;
929:
930: spin_lock(&q->current_entry_lock);
931: entry = rcu_dereference_protected(q->current_entry,
932: lockdep_is_held(&q->current_entry_lock));
933: oper = rcu_dereference_protected(q->oper_sched,
934: lockdep_is_held(&q->current_entry_lock));
935: admin = rcu_dereference_protected(q->admin_sched,
936: lockdep_is_held(&q->current_entry_lock));
937:
938: if (!oper)
939: switch_schedules(q, &admin, &oper);
940:
941: /* This can happen in two cases: 1. this is the very first run
942: * of this function (i.e. we weren't running any schedule
943: * previously); 2. The previous schedule just ended. The first
944: * entry of all schedules are pre-calculated during the
945: * schedule initialization.
946: */
947: if (unlikely(!entry || entry->end_time == oper->base_time)) {
948: next = list_first_entry(&oper->entries, struct sched_entry,
949: list);
950: end_time = next->end_time;
951: goto first_run;
952: }
953:
954: if (should_restart_cycle(oper, entry)) {
955: next = list_first_entry(&oper->entries, struct sched_entry,
956: list);
957: oper->cycle_end_time = ktime_add_ns(oper->cycle_end_time,
958: oper->cycle_time);
959: } else {
960: next = list_next_entry(entry, list);
961: }
962:
963: end_time = ktime_add_ns(entry->end_time, next->interval);
964: end_time = min_t(ktime_t, end_time, oper->cycle_end_time);
965:
966: for (tc = 0; tc < num_tc; tc++) {
967: if (next->gate_duration[tc] == oper->cycle_time)
968: next->gate_close_time[tc] = KTIME_MAX;
969: else
970: next->gate_close_time[tc] = ktime_add_ns(entry->end_time,
971: next->gate_duration[tc]);
972: }
973:
974: if (should_change_schedules(admin, oper, end_time)) {
975: switch_schedules(q, &admin, &oper);
976: /* After changing schedules, the next entry is the first one
977: * in the new schedule, with a pre-calculated end_time.
978: */
979: next = list_first_entry(&oper->entries, struct sched_entry, list);
980: end_time = next->end_time;
981: }
982:
983: next->end_time = end_time;
984: taprio_set_budgets(q, oper, next);
985:
986: first_run:
987: rcu_assign_pointer(q->current_entry, next);
988: spin_unlock(&q->current_entry_lock);
989:
990: hrtimer_set_expires(&q->advance_timer, end_time);
991:
992: rcu_read_lock();
993: __netif_schedule(sch);
994: rcu_read_unlock();
995:
996: return HRTIMER_RESTART;
997: }
SourceFile:net/sched/sch_taprio.c]
|
| 69/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 50970
output: 33
thoughts: 790
Thoughts: **Analyzing a Potential Timer Bug in `act_gate`**
Okay, so I'm looking at `sch_taprio.c` and how it handles timing, and it seems to have a different way of doing things, using `next->end_time` and `oper->cycle_end_time`. That's not what I'm focused on right now, though. Let's get back to `gate_timer_func`.
I'm starting to think there might be an issue. Why isn't `gact->current_close_time` being updated with the recalculated `close_time`? If it *isn't* being updated, then it's going to lag behind, and every single timer expiration will trigger that `if (ktime_after(now, close_time))` block! That can't be right.
I better check for any related commits or discussions. Let me search the web and the Git history for occurrences of `current_close_time` or `gate_timer_func`.
Alright, back to the code. Looking at `gate_timer_func` again, I see this:
```c
gact->current_close_time = ktime_add_ns(gact->current_close_time,
next->interval);
close_time = gact->current_close_time;
// ... [Other code] ...
now = gate_get_time(gact);
if (ktime_after(now, close_time)) {
// Recalculate close_time based on cycle time
cycle = p->tcfg_cycletime;
base = ns_to_ktime(p->tcfg_basetime);
n = div64_u64(ktime_sub_ns(now, base), cycle);
close_time = ktime_add_ns(base, (n + 1) * cycle);
}
gact->next_entry = next;
hrtimer_set_expires(&gact->hitimer, close_time);
```
Okay, so if `ktime_after(now, close_time)` is true, it recalculates `close_time` to the *next* cycle. But here's the kicker: `gact->current_close_time` is *not* updated to this *new* `close_time`. That means, the next time the timer fires, `gact->current_close_time` gets incremented by `next->interval`... but it is still way back in the past. Therefore, `close_time`, which *is* `gact->current_close_time`, will be in the past too. The result? The condition `ktime_after(now, close_time)` *will* be true, *again*, and we'll recalculate `close_time` for the next cycle, and... we're stuck in this infinite recalculation loop.
Wait. Is this a bug? It certainly looks like a bug to me. A clear logical flaw! Let me look for patches or commits that might address this, or at least discuss it.
I'm searching the git log for `act_gate`, `gate_timer_func`, or `current_close_time`. Let me broaden the search and scan the entire repository for commits that mention either `current_close_time` or `act_gate`. I'll use `git log` with regex filtering on the message and restrict it to the `net/sched/act_gate.c` path to narrow the scope.
|
| 70/4 |
2026/08/08 22:31 |
tool |
git-log |
0m
Args: map[MessageRegexps:[gate] PathPrefix:net/sched/act_gate.c]
Results: map[Output:62413a9c3cb1 net/sched: act_gate: snapshot parameters with RCU on replace
49b02a19c23a net: sched: Fill in MODULE_DESCRIPTION for act_gate
7afd073e5521 net/sched: act_gate: use percpu stats
ae3f9fc308d5 net: sched: act_gate: get rid of tcf_gate_walker and tcf_gate_search
4b61d3e8d3da net: qos offload add flow status with dropped count
c362a06e96ea net/sched: act_gate: fix configuration of the periodic timer
7024339a1cfa net/sched: act_gate: fix NULL dereference in tcf_gate_init()
a01c245438c5 net/sched: fix a couple of splats in the error path of tfc_gate_init()
a51c328df310 net: qos: introduce a gate control flow action
]
|
| 71/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 52845
output: 26
thoughts: 47
Thoughts: Okay, let's dive into this.
**Analyzing a Kernel Commit: `net/sched: act_gate: snapshot parameters with RCU on replace`**
Alright, the task at hand is to understand this kernel commit. My initial thought is to examine the commit message and the actual diff associated with `62413a9c3cb1`. The commit message itself is a good starting point: `net/sched: act_gate: snapshot parameters with RCU on replace`. It tells me this is related to the network scheduler (`net/sched`), specifically the `act_gate` action. The phrase "snapshot parameters with RCU on replace" immediately suggests a concurrency issue being addressed, likely related to parameter updates within the action's data structures, using Read-Copy-Update (RCU) for atomicity. I need to now examine the code and what changes were made. I'm expecting to see modifications aimed at ensuring that when an `act_gate` action is replaced, the old and new parameters are handled in a safe, RCU-compliant manner to avoid race conditions and data corruption. I need to check how the old data is cleared and how the new data is setup.
|
| 72/4 |
2026/08/08 22:31 |
tool |
git-show |
0m
Args:
Results: map[Output:commit 62413a9c3cb183afb9bb6e94dd68caf4e4145f4c
Author: Paul Moses <p@1g4.org>
Date: Mon Feb 23 15:05:44 2026 +0000
net/sched: act_gate: snapshot parameters with RCU on replace
The gate action can be replaced while the hrtimer callback or dump path is
walking the schedule list.
Convert the parameters to an RCU-protected snapshot and swap updates under
tcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits
the entry list, preserve the existing schedule so the effective state is
unchanged.
Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moses <p@1g4.org>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/20260223150512.2251594-2-p@1g4.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff --git a/include/net/tc_act/tc_gate.h b/include/net/tc_act/tc_gate.h
index b147a3bb1a46..e0fded18e18c 100644
--- a/include/net/tc_act/tc_gate.h
+++ b/include/net/tc_act/tc_gate.h
@@ -32,6 +32,7 @@ struct tcf_gate_params {
s32 tcfg_clockid;
size_t num_entries;
struct list_head entries;
+ struct rcu_head rcu;
};
#define GATE_ACT_GATE_OPEN BIT(0)
@@ -39,7 +40,7 @@ struct tcf_gate_params {
struct tcf_gate {
struct tc_action common;
- struct tcf_gate_params param;
+ struct tcf_gate_params __rcu *param;
u8 current_gate_status;
ktime_t current_close_time;
u32 current_entry_octets;
@@ -51,47 +52,65 @@ struct tcf_gate {
#define to_gate(a) ((struct tcf_gate *)a)
+static inline struct tcf_gate_params *tcf_gate_params_locked(const struct tc_action *a)
+{
+ struct tcf_gate *gact = to_gate(a);
+
+ return rcu_dereference_protected(gact->param,
+ lockdep_is_held(&gact->tcf_lock));
+}
+
static inline s32 tcf_gate_prio(const struct tc_action *a)
{
+ struct tcf_gate_params *p;
s32 tcfg_prio;
- tcfg_prio = to_gate(a)->param.tcfg_priority;
+ p = tcf_gate_params_locked(a);
+ tcfg_prio = p->tcfg_priority;
return tcfg_prio;
}
static inline u64 tcf_gate_basetime(const struct tc_action *a)
{
+ struct tcf_gate_params *p;
u64 tcfg_basetime;
- tcfg_basetime = to_gate(a)->param.tcfg_basetime;
+ p = tcf_gate_params_locked(a);
+ tcfg_basetime = p->tcfg_basetime;
return tcfg_basetime;
}
static inline u64 tcf_gate_cycletime(const struct tc_action *a)
{
+ struct tcf_gate_params *p;
u64 tcfg_cycletime;
- tcfg_cycletime = to_gate(a)->param.tcfg_cycletime;
+ p = tcf_gate_params_locked(a);
+ tcfg_cycletime = p->tcfg_cycletime;
return tcfg_cycletime;
}
static inline u64 tcf_gate_cycletimeext(const struct tc_action *a)
{
+ struct tcf_gate_params *p;
u64 tcfg_cycletimeext;
- tcfg_cycletimeext = to_gate(a)->param.tcfg_cycletime_ext;
+ p = tcf_gate_params_locked(a);
+ tcfg_cycletimeext = p->tcfg_cycletime_ext;
return tcfg_cycletimeext;
}
static inline u32 tcf_gate_num_entries(const struct tc_action *a)
{
+ struct tcf_gate_params *p;
u32 num_entries;
- num_entries = to_gate(a)->param.num_entries;
+ p = tcf_gate_params_locked(a);
+ num_entries = p->num_entries;
return num_entries;
}
@@ -105,7 +124,7 @@ static inline struct action_gate_entry
u32 num_entries;
int i = 0;
- p = &to_gate(a)->param;
+ p = tcf_gate_params_locked(a);
num_entries = p->num_entries;
list_for_each_entry(entry, &p->entries, list)
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
index 686eaed81b81..fdbfcaa3e2ab 100644
--- a/net/sched/act_gate.c
+++ b/net/sched/act_gate.c
@@ -32,9 +32,12 @@ static ktime_t gate_get_time(struct tcf_gate *gact)
return KTIME_MAX;
}
-static void gate_get_start_time(struct tcf_gate *gact, ktime_t *start)
+static void tcf_gate_params_free_rcu(struct rcu_head *head);
+
+static void gate_get_start_time(struct tcf_gate *gact,
+ const struct tcf_gate_params *param,
+ ktime_t *start)
{
- struct tcf_gate_params *param = &gact->param;
ktime_t now, base, cycle;
u64 n;
@@ -69,12 +72,14 @@ static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
{
struct tcf_gate *gact = container_of(timer, struct tcf_gate,
hitimer);
- struct tcf_gate_params *p = &gact->param;
struct tcfg_gate_entry *next;
+ struct tcf_gate_params *p;
ktime_t close_time, now;
spin_lock(&gact->tcf_lock);
+ p = rcu_dereference_protected(gact->param,
+ lockdep_is_held(&gact->tcf_lock));
next = gact->next_entry;
/* cycle start, clear pending bit, clear total octets */
@@ -225,6 +230,35 @@ static void release_entry_list(struct list_head *entries)
}
}
+static int tcf_gate_copy_entries(struct tcf_gate_params *dst,
+ const struct tcf_gate_params *src,
+ struct netlink_ext_ack *extack)
+{
+ struct tcfg_gate_entry *entry;
+ int i = 0;
+
+ list_for_each_entry(entry, &src->entries, list) {
+ struct tcfg_gate_entry *new;
+
+ new = kzalloc(sizeof(*new), GFP_ATOMIC);
+ if (!new) {
+ NL_SET_ERR_MSG(extack, "Not enough memory for entry");
+ return -ENOMEM;
+ }
+
+ new->index = entry->index;
+ new->gate_state = entry->gate_state;
+ new->interval = entry->interval;
+ new->ipv = entry->ipv;
+ new->maxoctets = entry->maxoctets;
+ list_add_tail(&new->list, &dst->entries);
+ i++;
+ }
+
+ dst->num_entries = i;
+ return 0;
+}
+
static int parse_gate_list(struct nlattr *list_attr,
struct tcf_gate_params *sched,
struct netlink_ext_ack *extack)
@@ -270,24 +304,44 @@ static int parse_gate_list(struct nlattr *list_attr,
return err;
}
-static void gate_setup_timer(struct tcf_gate *gact, u64 basetime,
- enum tk_offsets tko, s32 clockid,
- bool do_init)
+static bool gate_timer_needs_cancel(u64 basetime, u64 old_basetime,
+ enum tk_offsets tko,
+ enum tk_offsets old_tko,
+ s32 clockid, s32 old_clockid)
{
- if (!do_init) {
- if (basetime == gact->param.tcfg_basetime &&
- tko == gact->tk_offset &&
- clockid == gact->param.tcfg_clockid)
- return;
+ return basetime != old_basetime ||
+ clockid != old_clockid ||
+ tko != old_tko;
+}
- spin_unlock_bh(&gact->tcf_lock);
- hrtimer_cancel(&gact->hitimer);
- spin_lock_bh(&gact->tcf_lock);
+static int gate_clock_resolve(s32 clockid, enum tk_offsets *tko,
+ struct netlink_ext_ack *extack)
+{
+ switch (clockid) {
+ case CLOCK_REALTIME:
+ *tko = TK_OFFS_REAL;
+ return 0;
+ case CLOCK_MONOTONIC:
+ *tko = TK_OFFS_MAX;
+ return 0;
+ case CLOCK_BOOTTIME:
+ *tko = TK_OFFS_BOOT;
+ return 0;
+ case CLOCK_TAI:
+ *tko = TK_OFFS_TAI;
+ return 0;
+ default:
+ NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
+ return -EINVAL;
}
- gact->param.tcfg_basetime = basetime;
- gact->param.tcfg_clockid = clockid;
- gact->tk_offset = tko;
- hrtimer_setup(&gact->hitimer, gate_timer_func, clockid, HRTIMER_MODE_ABS_SOFT);
+}
+
+static void gate_setup_timer(struct tcf_gate *gact, s32 clockid,
+ enum tk_offsets tko)
+{
+ WRITE_ONCE(gact->tk_offset, tko);
+ hrtimer_setup(&gact->hitimer, gate_timer_func, clockid,
+ HRTIMER_MODE_ABS_SOFT);
}
static int tcf_gate_init(struct net *net, struct nlattr *nla,
@@ -296,15 +350,22 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
struct netlink_ext_ack *extack)
{
struct tc_action_net *tn = net_generic(net, act_gate_ops.net_id);
- enum tk_offsets tk_offset = TK_OFFS_TAI;
+ u64 cycletime = 0, basetime = 0, cycletime_ext = 0;
+ struct tcf_gate_params *p = NULL, *old_p = NULL;
+ enum tk_offsets old_tk_offset = TK_OFFS_TAI;
+ const struct tcf_gate_params *cur_p = NULL;
bool bind = flags & TCA_ACT_FLAGS_BIND;
struct nlattr *tb[TCA_GATE_MAX + 1];
+ enum tk_offsets tko = TK_OFFS_TAI;
struct tcf_chain *goto_ch = NULL;
- u64 cycletime = 0, basetime = 0;
- struct tcf_gate_params *p;
+ s32 timer_clockid = CLOCK_TAI;
+ bool use_old_entries = false;
+ s32 old_clockid = CLOCK_TAI;
+ bool need_cancel = false;
s32 clockid = CLOCK_TAI;
struct tcf_gate *gact;
struct tc_gate *parm;
+ u64 old_basetime = 0;
int ret = 0, err;
u32 gflags = 0;
s32 prio = -1;
@@ -321,26 +382,8 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (!tb[TCA_GATE_PARMS])
return -EINVAL;
- if (tb[TCA_GATE_CLOCKID]) {
+ if (tb[TCA_GATE_CLOCKID])
clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
- switch (clockid) {
- case CLOCK_REALTIME:
- tk_offset = TK_OFFS_REAL;
- break;
- case CLOCK_MONOTONIC:
- tk_offset = TK_OFFS_MAX;
- break;
- case CLOCK_BOOTTIME:
- tk_offset = TK_OFFS_BOOT;
- break;
- case CLOCK_TAI:
- tk_offset = TK_OFFS_TAI;
- break;
- default:
- NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
- return -EINVAL;
- }
- }
parm = nla_data(tb[TCA_GATE_PARMS]);
index = parm->index;
@@ -366,6 +409,60 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
return -EEXIST;
}
+ gact = to_gate(*a);
+
+ err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
+ if (err < 0)
+ goto release_idr;
+
+ p = kzalloc(sizeof(*p), GFP_KERNEL);
+ if (!p) {
+ err = -ENOMEM;
+ goto chain_put;
+ }
+ INIT_LIST_HEAD(&p->entries);
+
+ use_old_entries = !tb[TCA_GATE_ENTRY_LIST];
+ if (!use_old_entries) {
+ err = parse_gate_list(tb[TCA_GATE_ENTRY_LIST], p, extack);
+ if (err < 0)
+ goto err_free;
+ use_old_entries = !err;
+ }
+
+ if (ret == ACT_P_CREATED && use_old_entries) {
+ NL_SET_ERR_MSG(extack, "The entry list is empty");
+ err = -EINVAL;
+ goto err_free;
+ }
+
+ if (ret != ACT_P_CREATED) {
+ rcu_read_lock();
+ cur_p = rcu_dereference(gact->param);
+
+ old_basetime = cur_p->tcfg_basetime;
+ old_clockid = cur_p->tcfg_clockid;
+ old_tk_offset = READ_ONCE(gact->tk_offset);
+
+ basetime = old_basetime;
+ cycletime_ext = cur_p->tcfg_cycletime_ext;
+ prio = cur_p->tcfg_priority;
+ gflags = cur_p->tcfg_flags;
+
+ if (!tb[TCA_GATE_CLOCKID])
+ clockid = old_clockid;
+
+ err = 0;
+ if (use_old_entries) {
+ err = tcf_gate_copy_entries(p, cur_p, extack);
+ if (!err && !tb[TCA_GATE_CYCLE_TIME])
+ cycletime = cur_p->tcfg_cycletime;
+ }
+ rcu_read_unlock();
+ if (err)
+ goto err_free;
+ }
+
if (tb[TCA_GATE_PRIORITY])
prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
@@ -375,25 +472,26 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (tb[TCA_GATE_FLAGS])
gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
- gact = to_gate(*a);
- if (ret == ACT_P_CREATED)
- INIT_LIST_HEAD(&gact->param.entries);
+ if (tb[TCA_GATE_CYCLE_TIME])
+ cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
- err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
- if (err < 0)
- goto release_idr;
+ if (tb[TCA_GATE_CYCLE_TIME_EXT])
+ cycletime_ext = nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
- spin_lock_bh(&gact->tcf_lock);
- p = &gact->param;
+ err = gate_clock_resolve(clockid, &tko, extack);
+ if (err)
+ goto err_free;
+ timer_clockid = clockid;
- if (tb[TCA_GATE_CYCLE_TIME])
- cycletime = nla_get_u64(tb[TCA_GATE_CYCLE_TIME]);
+ need_cancel = ret != ACT_P_CREATED &&
+ gate_timer_needs_cancel(basetime, old_basetime,
+ tko, old_tk_offset,
+ timer_clockid, old_clockid);
- if (tb[TCA_GATE_ENTRY_LIST]) {
- err = parse_gate_list(tb[TCA_GATE_ENTRY_LIST], p, extack);
- if (err < 0)
- goto chain_put;
- }
+ if (need_cancel)
+ hrtimer_cancel(&gact->hitimer);
+
+ spin_lock_bh(&gact->tcf_lock);
if (!cycletime) {
struct tcfg_gate_entry *entry;
@@ -402,22 +500,20 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
list_for_each_entry(entry, &p->entries, list)
cycle = ktime_add_ns(cycle, entry->interval);
cycletime = cycle;
- if (!cycletime) {
- err = -EINVAL;
- goto chain_put;
- }
}
p->tcfg_cycletime = cycletime;
+ p->tcfg_cycletime_ext = cycletime_ext;
- if (tb[TCA_GATE_CYCLE_TIME_EXT])
- p->tcfg_cycletime_ext =
- nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
-
- gate_setup_timer(gact, basetime, tk_offset, clockid,
- ret == ACT_P_CREATED);
+ if (need_cancel || ret == ACT_P_CREATED)
+ gate_setup_timer(gact, timer_clockid, tko);
p->tcfg_priority = prio;
p->tcfg_flags = gflags;
- gate_get_start_time(gact, &start);
+ p->tcfg_basetime = basetime;
+ p->tcfg_clockid = timer_clockid;
+ gate_get_start_time(gact, p, &start);
+
+ old_p = rcu_replace_pointer(gact->param, p,
+ lockdep_is_held(&gact->tcf_lock));
gact->current_close_time = start;
gact->current_gate_status = GATE_ACT_GATE_OPEN | GATE_ACT_PENDING;
@@ -434,11 +530,15 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
+ if (old_p)
+ call_rcu(&old_p->rcu, tcf_gate_params_free_rcu);
+
return ret;
+err_free:
+ release_entry_list(&p->entries);
+ kfree(p);
chain_put:
- spin_unlock_bh(&gact->tcf_lock);
-
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
release_idr:
@@ -446,21 +546,29 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
* without taking tcf_lock.
*/
if (ret == ACT_P_CREATED)
- gate_setup_timer(gact, gact->param.tcfg_basetime,
- gact->tk_offset, gact->param.tcfg_clockid,
- true);
+ gate_setup_timer(gact, timer_clockid, tko);
+
tcf_idr_release(*a, bind);
return err;
}
+static void tcf_gate_params_free_rcu(struct rcu_head *head)
+{
+ struct tcf_gate_params *p = container_of(head, struct tcf_gate_params, rcu);
+
+ release_entry_list(&p->entries);
+ kfree(p);
+}
+
static void tcf_gate_cleanup(struct tc_action *a)
{
struct tcf_gate *gact = to_gate(a);
struct tcf_gate_params *p;
- p = &gact->param;
hrtimer_cancel(&gact->hitimer);
- release_entry_list(&p->entries);
+ p = rcu_dereference_protected(gact->param, 1);
+ if (p)
+ call_rcu(&p->rcu, tcf_gate_params_free_rcu);
}
static int dumping_entry(struct sk_buff *skb,
@@ -509,10 +617,9 @@ static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
struct nlattr *entry_list;
struct tcf_t t;
- spin_lock_bh(&gact->tcf_lock);
- opt.action = gact->tcf_action;
-
- p = &gact->param;
+ rcu_read_lock();
+ opt.action = READ_ONCE(gact->tcf_action);
+ p = rcu_dereference(gact->param);
if (nla_put(skb, TCA_GATE_PARMS, sizeof(opt), &opt))
goto nla_put_failure;
@@ -552,12 +659,12 @@ static int tcf_gate_dump(struct sk_buff *skb, struct tc_action *a,
tcf_tm_dump(&t, &gact->tcf_tm);
if (nla_put_64bit(skb, TCA_GATE_TM, sizeof(t), &t, TCA_GATE_PAD))
goto nla_put_failure;
- spin_unlock_bh(&gact->tcf_lock);
+ rcu_read_unlock();
return skb->len;
nla_put_failure:
- spin_unlock_bh(&gact->tcf_lock);
+ rcu_read_unlock();
nlmsg_trim(skb, b);
return -1;
}
]
|
| 73/4 |
2026/08/08 22:31 |
llm |
codeexpert |
0m
Model:
Tokens:
input: 59836
output: 1337
thoughts: 4405
Thoughts: **Analysis of the Gate Action Timer Logic**
Okay, here's my breakdown of the timer logic, as I see it. Let's delve into these questions.
First, the possibility of `now < base` causing a problem. Under normal conditions, and given how `gate_get_start_time` and `gact->current_close_time` are initialized and updated, where `base` is based on the user-controlled `basetime` which is set either to the input value or the current time: `now` can never be less than `base` when the condition `ktime_after(now, close_time)` is true. My analysis shows that under typical scenarios, the `gact->current_close_time` will always be equal to or greater than `base`. Furthermore, `close_time` will always be larger than the `base` and therefore `now`. Therefore `now < base` is impossible when the logic in `ktime_after(now, close_time)` is executed. Even if we consider anomalous conditions like clock jumps, even if `now` *were* less than `base`, the unsigned division wouldn't cause a past value for `close_time` or an infinite loop. It would cause `close_time` to be calculated correctly as a future point. Specifically, let's say the time difference (`ktime_sub_ns(now, base)`) is negative, this results in a large unsigned 64-bit value to `div64_u64`. We can represent this with modular arithmetic, working modulo 2^64. Mathematically, it works out to be `close_time` being in the interval `[now + 1, now + cycle]`. This guarantees a valid positive `s64` value in the future relative to `now`. Therefore, even in this case, there won't be an infinite loop.
Second, the question of whether `gact->current_close_time` should be updated or not, is a very important issue. The conclusion is that updating the `gact->current_close_time` within the `if` block *is* absolutely necessary for correct schedule operation. The code does not update it, which means it will become out-of-sync and that's a bug. If the timer falls behind for any reason, the `close_time` is recalculated to the next cycle boundary. However, the `gact->current_close_time` is not updated, causing the timer to fall out of sync with each subsequent entry in the schedule. Each subsequent timer invocation, it will evaluate the `ktime_after` condition as true and skip entries of the timer schedule. If the `gact->current_close_time` is updated to be the start of the next cycle, and `next` is reset to the first entry, the schedule will be perfectly aligned. The `close_time` is re-calculated to be the start of the cycle, and the timer set to run at `close_time + next->interval`. If this is not done, then the subsequent entries are skipped or run for the whole cycle (each entry will run for a full cycle time, so a large discrepancy arises).
|
| 74/4 |
2026/08/08 22:31 |
tool |
set-results |
0m
Args: map[Answer:### Part 1: Will `now < base` cause `close_time` to be in the past and lead to an infinite hrtimer loop (soft lockup)?
#### 1. Is `now < base` possible when `ktime_after(now, close_time)` is true?
**No.** Under normal conditions, `now < base` is mathematically impossible when the `if (ktime_after(now, close_time))` block is entered.
**Proof:**
* `gact->current_close_time` is initialized to `start`, which is calculated by `gate_get_start_time()`.
* If `base > now`, `start` is set to `base`. If `base <= now`, `start` is set to `base + (n + 1) * cycle > base`. Thus, `gact->current_close_time` is always initialized to a value greater than or equal to `base`.
* In `gate_timer_func()`, `gact->current_close_time` is only updated by adding `next->interval` (which is strictly positive). Thus, `gact->current_close_time` is always `>= base`.
* `close_time` is set to `gact->current_close_time`. Since `next->interval > 0`, `close_time` is always strictly greater than `base` (`close_time > base`).
* If `ktime_after(now, close_time)` is true, then `now > close_time`.
* By transitivity, since `now > close_time` and `close_time > base`, we must have `now > base`.
* Therefore, `now < base` is impossible when the `if (ktime_after(now, close_time))` block is entered.
#### 2. What if `now < base` hypothetically happens (e.g., due to clock jumps or other anomalies)?
Even if `now < base` hypothetically happens, the unsigned division math in `div64_u64` will **not** cause `close_time` to be in the past, nor will it cause an infinite hrtimer loop (soft lockup).
**Mathematical Proof:**
* Let $W = 2^{64}$. All 64-bit integer arithmetic is performed modulo $W$.
* Since `now < base`, `ktime_sub_ns(now, base)` is negative, which as a `u64` is represented as $D = W + \text{now} - \text{base}$.
* Let $cycle = C$.
* `n = div64_u64(D, C)` performs integer division: $D = n \cdot C + R$, where $R = D \pmod C$ and $0 \le R < C$.
* Thus, $(n + 1) \cdot C = n \cdot C + C = D - R + C = W + \text{now} - \text{base} - R + C$.
* `close_time` is calculated as:
$$\text{close\_time} = \text{base} + (n + 1) \cdot C \pmod W$$
$$\text{close\_time} = \text{base} + (W + \text{now} - \text{base} - R + C) \pmod W$$
$$\text{close\_time} = \text{now} - R + C \pmod W$$
* Since $0 \le R < C$, we have $0 < C - R \le C$.
* Therefore, $\text{close\_time}$ is in the range $[\text{now} + 1, \text{now} + C]$.
* Since `now` is the current time (a valid positive `s64` value far from `S64_MAX`) and $C$ is relatively small, `close_time` will be a valid positive `s64` value strictly in the future relative to `now`.
* Since `close_time` is in the future, the hrtimer will be scheduled for a future time and will **not** cause an infinite loop or a soft lockup.
---
### Part 2: Is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?
**No, it is not intentional; it is a significant logical bug.**
#### Consequences of not updating `gact->current_close_time`:
1. If the timer falls behind (e.g., due to temporary system delay, CPU starvation, or clock adjustments), `ktime_after(now, close_time)` becomes true.
2. `close_time` is recalculated to the next cycle boundary in the future, but `gact->current_close_time` is left unchanged (lagging far in the past).
3. In the next timer expiration, `gact->current_close_time` is incremented by `next->interval`. However, because it was lagging behind, it remains far in the past compared to the new `now`.
4. As a result, `ktime_after(now, close_time)` will evaluate to true on **every subsequent timer expiration**.
5. The timer will continually recalculate `close_time` to the next cycle boundary and reschedule itself.
6. Consequently, the timer will **only fire at cycle boundaries** (skipping all intermediate schedule entries/intervals). Each entry in the schedule will effectively run for a full cycle time instead of its specified interval, completely breaking the gate action's schedule.
#### How it should be fixed:
When `ktime_after(now, close_time)` is true, `gact->current_close_time` should be updated to the recalculated `close_time` (the start of the next cycle), and `next` should be reset to the first entry of the schedule (`list_first_entry(&p->entries, struct tcfg_gate_entry, list)`). This aligns the schedule perfectly with the next cycle boundary.]
Results: map[Answer:### Part 1: Will `now < base` cause `close_time` to be in the past and lead to an infinite hrtimer loop (soft lockup)?
#### 1. Is `now < base` possible when `ktime_after(now, close_time)` is true?
**No.** Under normal conditions, `now < base` is mathematically impossible when the `if (ktime_after(now, close_time))` block is entered.
**Proof:**
* `gact->current_close_time` is initialized to `start`, which is calculated by `gate_get_start_time()`.
* If `base > now`, `start` is set to `base`. If `base <= now`, `start` is set to `base + (n + 1) * cycle > base`. Thus, `gact->current_close_time` is always initialized to a value greater than or equal to `base`.
* In `gate_timer_func()`, `gact->current_close_time` is only updated by adding `next->interval` (which is strictly positive). Thus, `gact->current_close_time` is always `>= base`.
* `close_time` is set to `gact->current_close_time`. Since `next->interval > 0`, `close_time` is always strictly greater than `base` (`close_time > base`).
* If `ktime_after(now, close_time)` is true, then `now > close_time`.
* By transitivity, since `now > close_time` and `close_time > base`, we must have `now > base`.
* Therefore, `now < base` is impossible when the `if (ktime_after(now, close_time))` block is entered.
#### 2. What if `now < base` hypothetically happens (e.g., due to clock jumps or other anomalies)?
Even if `now < base` hypothetically happens, the unsigned division math in `div64_u64` will **not** cause `close_time` to be in the past, nor will it cause an infinite hrtimer loop (soft lockup).
**Mathematical Proof:**
* Let $W = 2^{64}$. All 64-bit integer arithmetic is performed modulo $W$.
* Since `now < base`, `ktime_sub_ns(now, base)` is negative, which as a `u64` is represented as $D = W + \text{now} - \text{base}$.
* Let $cycle = C$.
* `n = div64_u64(D, C)` performs integer division: $D = n \cdot C + R$, where $R = D \pmod C$ and $0 \le R < C$.
* Thus, $(n + 1) \cdot C = n \cdot C + C = D - R + C = W + \text{now} - \text{base} - R + C$.
* `close_time` is calculated as:
$$\text{close\_time} = \text{base} + (n + 1) \cdot C \pmod W$$
$$\text{close\_time} = \text{base} + (W + \text{now} - \text{base} - R + C) \pmod W$$
$$\text{close\_time} = \text{now} - R + C \pmod W$$
* Since $0 \le R < C$, we have $0 < C - R \le C$.
* Therefore, $\text{close\_time}$ is in the range $[\text{now} + 1, \text{now} + C]$.
* Since `now` is the current time (a valid positive `s64` value far from `S64_MAX`) and $C$ is relatively small, `close_time` will be a valid positive `s64` value strictly in the future relative to `now`.
* Since `close_time` is in the future, the hrtimer will be scheduled for a future time and will **not** cause an infinite loop or a soft lockup.
---
### Part 2: Is `gact->current_close_time` intentionally not updated with the recalculated `close_time`?
**No, it is not intentional; it is a significant logical bug.**
#### Consequences of not updating `gact->current_close_time`:
1. If the timer falls behind (e.g., due to temporary system delay, CPU starvation, or clock adjustments), `ktime_after(now, close_time)` becomes true.
2. `close_time` is recalculated to the next cycle boundary in the future, but `gact->current_close_time` is left unchanged (lagging far in the past).
3. In the next timer expiration, `gact->current_close_time` is incremented by `next->interval`. However, because it was lagging behind, it remains far in the past compared to the new `now`.
4. As a result, `ktime_after(now, close_time)` will evaluate to true on **every subsequent timer expiration**.
5. The timer will continually recalculate `close_time` to the next cycle boundary and reschedule itself.
6. Consequently, the timer will **only fire at cycle boundaries** (skipping all intermediate schedule entries/intervals). Each entry in the schedule will effectively run for a full cycle time instead of its specified interval, completely breaking the gate action's schedule.
#### How it should be fixed:
When `ktime_after(now, close_time)` is true, `gact->current_close_time` should be updated to the recalculated `close_time` (the start of the next cycle), and `next` should be reset to the first entry of the schedule (`list_first_entry(&p->entries, struct tcfg_gate_entry, list)`). This aligns the schedule perfectly with the next cycle boundary.]
|
| 75/2 |
2026/08/08 22:31 |
llm |
expert |
0m
Model:
Tokens:
input: 26064
output: 30
thoughts: 438
Thoughts: **Unraveling the Soft Lockup in the Gate Timer**
Okay, the codeexpert's analysis is spot on, that's a very sharp observation. Now, wait a minute, if the condition `now < base` is essentially impossible, why did we hit a soft lockup? Let's zoom back in on the soft lockup; it looks like it's happening in `gate_timer_func`. The logic says that if `close_time` gets recalculated as `now - R + C`, then it results in a time in the future.
Hang on... what if the `cycle` is actually very, very small? If `cycle` is tiny, then `close_time` would be practically equal to `now`. That would mean the timer fires almost immediately! But wait, `cycle` is calculated as the sum of `interval`s. Could an `interval` possibly be minuscule? Yes, it looks like an `interval` *could* be just 1 nanosecond! If the `interval` is 1 ns, and we have only one entry, `cycle` is just 1 ns. Thus, the `close_time` becomes `now + 1`, and the timer fires every nanosecond!
That would *absolutely* cause a soft lockup! The timer would just fire continuously. Let's dig deeper to make sure an `interval` of 1 ns is valid. In the `fill_gate_entry` function:
```c
if (tb[TCA_GATE_ENTRY_INTERVAL])
interval = nla_get_u32(tb[TCA_GATE_ENTRY_INTERVAL]);
if (interval == 0) {
NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
return -EINVAL;
}
entry->interval = interval;
```
Ah, here it is: `interval` can indeed be set to 1. If `interval` is set to 1, then `cycle` is also 1. Then the timer *will* fire every nanosecond. Since the overhead of handling the timer is far more than 1 ns, the timer is going to continuously fire, resulting in a soft lockup. Is there a lower bound on `interval`? Better check `net/sched/act_gate.c` to see if a minimum interval is enforced anywhere.
|
| 76/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:interval PathPrefix:net/sched/act_gate.c]
Results: map[Output:net/sched/act_gate.c=71=static enum hrtimer_restart gate_timer_func(struct hrtimer *timer)
--
net/sched/act_gate.c-90- gact->current_close_time = ktime_add_ns(gact->current_close_time,
net/sched/act_gate.c:91: next->interval);
net/sched/act_gate.c-92-
--
net/sched/act_gate.c=181=static int fill_gate_entry(struct nlattr **tb, struct tcfg_gate_entry *entry,
--
net/sched/act_gate.c-183-{
net/sched/act_gate.c:184: u32 interval = 0;
net/sched/act_gate.c-185-
--
net/sched/act_gate.c-188- if (tb[TCA_GATE_ENTRY_INTERVAL])
net/sched/act_gate.c:189: interval = nla_get_u32(tb[TCA_GATE_ENTRY_INTERVAL]);
net/sched/act_gate.c-190-
net/sched/act_gate.c:191: if (interval == 0) {
net/sched/act_gate.c:192: NL_SET_ERR_MSG(extack, "Invalid interval for schedule entry");
net/sched/act_gate.c-193- return -EINVAL;
--
net/sched/act_gate.c-195-
net/sched/act_gate.c:196: entry->interval = interval;
net/sched/act_gate.c-197-
--
net/sched/act_gate.c=233=static int tcf_gate_copy_entries(struct tcf_gate_params *dst,
--
net/sched/act_gate.c-250- new->gate_state = entry->gate_state;
net/sched/act_gate.c:251: new->interval = entry->interval;
net/sched/act_gate.c-252- new->ipv = entry->ipv;
--
net/sched/act_gate.c=347=static int tcf_gate_init(struct net *net, struct nlattr *nla,
--
net/sched/act_gate.c-500- list_for_each_entry(entry, &p->entries, list)
net/sched/act_gate.c:501: cycle = ktime_add_ns(cycle, entry->interval);
net/sched/act_gate.c-502- cycletime = cycle;
--
net/sched/act_gate.c=574=static int dumping_entry(struct sk_buff *skb,
--
net/sched/act_gate.c-588-
net/sched/act_gate.c:589: if (nla_put_u32(skb, TCA_GATE_ENTRY_INTERVAL, entry->interval))
net/sched/act_gate.c-590- goto nla_put_failure;
]
|
| 77/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 27838
output: 34
thoughts: 149
Thoughts: **My Concerns Regarding Timer Behavior**
Okay, so I'm looking at this code and immediately I see a gaping hole: there's *no* minimum interval check! If someone sets this `interval` parameter to 1, the timer is essentially firing every nanosecond. My initial thought? Soft lockup. Pure and simple. This is going to bring the whole system down.
Then, the exploitation part of my brain kicks in. Is there a way to weaponize this? Denial of service is practically guaranteed, but can we escalate this somehow? Can an unprivileged user even *create* a `gate` action? I need to figure out if that's even possible.
Right, `act_gate` is a Traffic Control (TC) action. Okay, TC actions are typically created using netlink messages, specifically `RTM_NEWACTION` or `RTM_NEWTFILTER`. So the key question is: are these netlink messages, and therefore the ability to create TC actions, accessible to unprivileged users? Usually, you'd need `CAP_NET_ADMIN` privileges for that, but I'd better be sure. I'm going to have to check `rtnetlink.c` and specifically look at how `RTM_NEWACTION` is handled. Let's see...
|
| 78/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Error:
Args: map[Expression:RTM_NEWACTION PathPrefix:net/core/rtnetlink.c]
Results:
|
| 79/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 28315
output: 35
thoughts: 17
Thoughts: Here's my take on those thoughts, tailored for an expert audience:
**TC Action Implementation Location**
Okay, so I'm thinking about Traffic Control (TC) actions, right? My brain immediately jumps to the kernel's source code. Where are the core implementations of these action modules? Let me see⦠yep, it's pretty clear: the central hub for TC action operations is definitely going to be in `net/sched/act_api.c`. That's where I would expect to find the common API functions, registration mechanisms, and core dispatch logic for all the various action types. It's the point of entry and the heart of the action framework within the TC subsystem. Anything I need to dive into regarding how new actions are registered, how the generic interface is handled, or how the specific action handlers are invoked would be centered there.
|
| 80/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:RTM_NEWACTION PathPrefix:net/sched/act_api.c]
Results: map[Output:net/sched/act_api.c=2056=static struct sk_buff *tcf_add_notify_msg(struct net *net, struct nlmsghdr *n,
--
net/sched/act_api.c-2067- if (tca_get_fill(skb, actions, portid, n->nlmsg_seq, n->nlmsg_flags,
net/sched/act_api.c:2068: RTM_NEWACTION, 0, 0, extack) <= 0) {
net/sched/act_api.c-2069- NL_SET_ERR_MSG(extack, "Failed to fill netlink attributes while adding TC action");
--
net/sched/act_api.c=2129=static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
--
net/sched/act_api.c-2153- switch (n->nlmsg_type) {
net/sched/act_api.c:2154: case RTM_NEWACTION:
net/sched/act_api.c-2155- /* we are going to assume all other flags
--
net/sched/act_api.c=2291=static const struct rtnl_msg_handler tc_action_rtnl_msg_handlers[] __initconst = {
net/sched/act_api.c:2292: {.msgtype = RTM_NEWACTION, .doit = tc_ctl_action},
net/sched/act_api.c-2293- {.msgtype = RTM_DELACTION, .doit = tc_ctl_action},
]
|
| 81/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 28970
output: 39
thoughts: 41
Thoughts: Okay, let's dive into this. Here's my thought process on the matter:
**RTNL_FLAG_DOIT_UNLOCKED and Capability Requirements for `tc_action_rtnl_msg_handlers`**
Right, let's take a look at the `tc_action_rtnl_msg_handlers` structure. I need to quickly verify a crucial detail: does it register with the `RTNL_FLAG_DOIT_UNLOCKED` flag, or something similar? This is fundamental to understanding the locking behavior and concurrency aspects.
Beyond that, I also need to understand what capabilities are required to invoke these handlers. The kernel security model is paramount, so I must know if it's protected and who is authorized to call those handlers. That is critical to the security considerations. I can't leave that to chance. I want to see this as soon as possible.
|
| 82/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:tc_action_rtnl_msg_handlers PathPrefix:net/sched/act_api.c]
Results: map[Output:net/sched/act_api.c=2203=static int tc_dump_action(struct sk_buff *skb, struct netlink_callback *cb)
--
net/sched/act_api.c-2290-
net/sched/act_api.c:2291:static const struct rtnl_msg_handler tc_action_rtnl_msg_handlers[] __initconst = {
net/sched/act_api.c-2292- {.msgtype = RTM_NEWACTION, .doit = tc_ctl_action},
--
net/sched/act_api.c=2298=static int __init tc_action_init(void)
net/sched/act_api.c-2299-{
net/sched/act_api.c:2300: rtnl_register_many(tc_action_rtnl_msg_handlers);
net/sched/act_api.c-2301- return 0;
]
|
| 83/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 29491
output: 36
thoughts: 23
Thoughts: Here's my thought process, summarized as you requested:
**Peering into the Kernel's Network Core**
Alright, I need to get a better handle on how these network messages are handled internally. My immediate focus is on the registration and dispatching of routing and networking messages, so I'm thinking I should start digging into the core functions responsible for that. Let's see...I should definitely check the definitions for `rtnl_register_many` and `rtnl_msg_handler`. Understanding how these functions work should give me the architectural overview I'm looking for. Time to open the code and dive in! I'm expecting to see how different message types are associated with specific handlers and how the system manages registering and unregistering these handlers dynamically. Let's see what's actually under the hood...
|
| 84/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:struct rtnl_msg_handler PathPrefix:include/net/rtnetlink.h]
Results: map[Output:include/net/rtnetlink.h=30=static inline enum rtnl_kinds rtnl_msgtype_kind(int msgtype)
--
include/net/rtnetlink.h-35-/**
include/net/rtnetlink.h:36: * struct rtnl_msg_handler - rtnetlink message type and handlers
include/net/rtnetlink.h-37- *
--
include/net/rtnetlink.h-44- */
include/net/rtnetlink.h:45:struct rtnl_msg_handler {
include/net/rtnetlink.h-46- struct module *owner;
--
include/net/rtnetlink.h=54=void rtnl_unregister_all(int protocol);
include/net/rtnetlink.h-55-
include/net/rtnetlink.h:56:int __rtnl_register_many(const struct rtnl_msg_handler *handlers, int n);
include/net/rtnetlink.h:57:void __rtnl_unregister_many(const struct rtnl_msg_handler *handlers, int n);
include/net/rtnetlink.h-58-
]
|
| 85/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 30019
output: 35
thoughts: 49
Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing:
**Analyzing `rtnl_register_many` and Capability Requirements**
Alright, hang on a second. I'm looking at `rtnl_register_many` and immediately my brain flags it as a handler registration function for netlink. And usually, a message type like `RTM_NEWACTION` - creating or modifying something substantial β would require `CAP_NET_ADMIN` at the very least. I need to confirm how the kernel handles capability checks within `rtnetlink.c` specifically. Time to dig in and see exactly how they've implemented the security model. I need to understand the relationship between the registration of the handlers and the authorization checks. I need to make sure I am not missing some detail.
|
| 86/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:rtnl_register_many PathPrefix:net/core/rtnetlink.c]
Results: map[Output:net/core/rtnetlink.c=508=EXPORT_SYMBOL_GPL(rtnl_unregister_all);
--
net/core/rtnetlink.c-510-/**
net/core/rtnetlink.c:511: * __rtnl_register_many - Register rtnetlink message types
net/core/rtnetlink.c-512- * @handlers: Array of struct rtnl_msg_handlers
--
net/core/rtnetlink.c-527- *
net/core/rtnetlink.c:528: * Use rtnl_register_many().
net/core/rtnetlink.c-529- */
net/core/rtnetlink.c:530:int __rtnl_register_many(const struct rtnl_msg_handler *handlers, int n)
net/core/rtnetlink.c-531-{
--
net/core/rtnetlink.c-550-}
net/core/rtnetlink.c:551:EXPORT_SYMBOL_GPL(__rtnl_register_many);
net/core/rtnetlink.c-552-
--
net/core/rtnetlink.c=7216=void __init rtnetlink_init(void)
--
net/core/rtnetlink.c-7222-
net/core/rtnetlink.c:7223: rtnl_register_many(rtnetlink_rtnl_msg_handlers);
net/core/rtnetlink.c-7224-}
]
|
| 87/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 30661
output: 36
thoughts: 24
Thoughts: Here's a summary of my thought process, as requested:
**Navigating the Netlink Terrain**
Okay, so I need to understand how this registration process for Netlink attributes works. Where do I start? Right, the obvious place: `include/net/rtnetlink.h`. I'll want to check for the function responsible for registering multiple handlers, something like `rtnl_register_many`. That name seems like a strong contender for what I'm looking for. This header file should provide the core definitions and hopefully the function prototypes I need to begin with. Then I can figure out how the kernel organizes its handler system. I anticipate that'll involve some form of linked list or a dispatch table... but let's see what `rtnl_register_many` has to tell us first. It'll hopefully provide pointers to other key data structures, right? This looks like a solid starting point for tracing the flow.
|
| 88/2 |
2026/08/08 22:32 |
tool |
read-file |
0m
Args: map[File:include/net/rtnetlink.h FirstLine:45 LineCount:30]
Results: map[Contents: 45: struct rtnl_msg_handler {
46: struct module *owner;
47: int protocol;
48: int msgtype;
49: rtnl_doit_func doit;
50: rtnl_dumpit_func dumpit;
51: int flags;
52: };
53:
54: void rtnl_unregister_all(int protocol);
55:
56: int __rtnl_register_many(const struct rtnl_msg_handler *handlers, int n);
57: void __rtnl_unregister_many(const struct rtnl_msg_handler *handlers, int n);
58:
59: #define rtnl_register_many(handlers) \
60: __rtnl_register_many(handlers, ARRAY_SIZE(handlers))
61: #define rtnl_unregister_many(handlers) \
62: __rtnl_unregister_many(handlers, ARRAY_SIZE(handlers))
63:
64: static inline int rtnl_msg_family(const struct nlmsghdr *nlh)
65: {
66: if (nlmsg_len(nlh) >= sizeof(struct rtgenmsg))
67: return ((struct rtgenmsg *) nlmsg_data(nlh))->rtgen_family;
68: else
69: return AF_UNSPEC;
70: }
71:
72: /**
73: * struct rtnl_newlink_params - parameters of rtnl_link_ops::newlink()
74: *
]
|
| 89/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 31360
output: 38
thoughts: 63
Thoughts: Okay, here's my interpretation of these thoughts, formatted as you requested, as if they were my own:
**RTNL_FLAG_DOIT_UNLOCKED and Capability Checks**
Hmm, so I'm looking at this `rtnl_msg_handler` and noticing this `flags` field. It's got `RTNL_FLAG_DOIT_UNLOCKED` in there, which is interesting. I'm wondering if there's a corresponding flag specifically for capability requirements related to the message handling. That would make a lot of sense.
And then I'm thinking about how the netlink stuff works, specifically digging into `net/core/rtnetlink.c`. I recall that `rtnetlink_rcv_msg` has some pretty solid checks for capabilities. It's almost certain that's where the capability validation happens, but I should probably check that, or find other functions called there.
|
| 90/2 |
2026/08/08 22:32 |
tool |
read-file |
0m
Args: map[File:net/core/rtnetlink.c FirstLine:6550 LineCount:50]
Results: map[Contents:6550:
6551: if (tb[IFLA_STATS_SET_OFFLOAD_XSTATS_L3_STATS]) {
6552: u8 req = nla_get_u8(tb[IFLA_STATS_SET_OFFLOAD_XSTATS_L3_STATS]);
6553:
6554: if (req)
6555: err = netdev_offload_xstats_enable(dev, t_l3, extack);
6556: else
6557: err = netdev_offload_xstats_disable(dev, t_l3);
6558:
6559: if (!err)
6560: notify = true;
6561: else if (err != -EALREADY)
6562: return err;
6563:
6564: response_filters.mask[0] |=
6565: IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK_OFFLOAD_XSTATS);
6566: response_filters.mask[IFLA_STATS_LINK_OFFLOAD_XSTATS] |=
6567: IFLA_STATS_FILTER_BIT(IFLA_OFFLOAD_XSTATS_HW_S_INFO);
6568: }
6569:
6570: if (notify)
6571: rtnl_offload_xstats_notify(dev);
6572:
6573: return 0;
6574: }
6575:
6576: static int rtnl_mdb_valid_dump_req(const struct nlmsghdr *nlh,
6577: struct netlink_ext_ack *extack)
6578: {
6579: struct br_port_msg *bpm;
6580:
6581: bpm = nlmsg_payload(nlh, sizeof(*bpm));
6582: if (!bpm) {
6583: NL_SET_ERR_MSG(extack, "Invalid header for mdb dump request");
6584: return -EINVAL;
6585: }
6586:
6587: if (bpm->ifindex) {
6588: NL_SET_ERR_MSG(extack, "Filtering by device index is not supported for mdb dump request");
6589: return -EINVAL;
6590: }
6591: if (nlmsg_attrlen(nlh, sizeof(*bpm))) {
6592: NL_SET_ERR_MSG(extack, "Invalid data after header in mdb dump request");
6593: return -EINVAL;
6594: }
6595:
6596: return 0;
6597: }
6598:
6599: struct rtnl_mdb_dump_ctx {
]
|
| 91/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 32432
output: 37
thoughts: 14
Thoughts: Here's my thought process, as if I were considering this:
**Hunting Down `rtnetlink_rcv_msg`**
Okay, so I need to find `rtnetlink_rcv_msg`. It's a kernel function, obviously, given the name. My first thought is to just search the kernel source directly, but that could be a bit cumbersome if I don't know the exact file structure or even a good starting point. I could use `grep` or `find` on the command line, but maybe there's a more efficient way to trace its usage or where it's defined.
I'm probably after understanding its role in the routing netlink message handling within the kernel. Is it a handler for incoming messages? Is it a processing function after a socket read? I need to figure out where it sits in the broader architecture. I should consider related functions like `netlink_rcv_msg` or other netlink message handlers. Those might provide some context by association. Perhaps I can work backwards from the netlink socket code to this function.
Ultimately, I want to understand how a raw `rtnetlink` message received on the socket gets processed, and it seems this is one of the important parts of the jigsaw.
|
| 92/2 |
2026/08/08 22:32 |
tool |
grepper |
0m
Args: map[Expression:rtnetlink_rcv_msg PathPrefix:net/core/rtnetlink.c]
Results: map[Output:net/core/rtnetlink.c=6963=static int rtnetlink_dump_start(struct sock *ssk, struct sk_buff *skb,
--
net/core/rtnetlink.c-6976-
net/core/rtnetlink.c:6977:static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
net/core/rtnetlink.c-6978- struct netlink_ext_ack *extack)
--
net/core/rtnetlink.c=7101=static void rtnetlink_rcv(struct sk_buff *skb)
net/core/rtnetlink.c-7102-{
net/core/rtnetlink.c:7103: netlink_rcv_skb(skb, &rtnetlink_rcv_msg);
net/core/rtnetlink.c-7104-}
]
|
| 93/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 32996
output: 38
thoughts: 14
Thoughts: Okay, here's my interpretation of what's going through my mind as I approach this function, `rtnetlink_rcv_msg`.
**Analyzing rtnetlink_rcv_msg**
Alright, let's dive into `rtnetlink_rcv_msg`. I'm already anticipating some of the core elements here. This function is likely the primary entry point for processing routing netlink messages, the heart of how user-space interacts with the kernel's routing information. I'm expecting to see the initial stages of message parsing - likely the examination of the message header to identify the message type (e.g., routing information, address information, link information).
I bet we'll see some error checking right off the bat, probably around message length, perhaps ensuring it's not maliciously truncated or malformed. Thereβs a high chance it will involve a dispatcher of some kind or a switch statement or perhaps a function pointer table, handling different message types. That structure likely maps the message type to the appropriate handler function responsible for carrying out the action requested.
Furthermore, I'm expecting some interaction with other kernel subsystems. `rtnetlink` is a crucial component for the routing system, so I'll be looking for calls to update routing tables, configure network interfaces, or potentially manage address assignments. We will probably see some locking happening, maybe per message type or at a higher level, which is standard in any multi-threaded kernel code. It will be interesting to see how they handle concurrency. I will also be eager to analyze their error handling. I'll be really watching how they use netlink's error reporting mechanism.
Finally, I'll be paying close attention to any security considerations. `rtnetlink` is a powerful interface, so I want to understand how the code protects against malicious actors or unintended consequences. This might involve checks on user permissions, access control lists, or validation of user-provided data. This is a very sensitive area.
|
| 94/2 |
2026/08/08 22:32 |
tool |
read-file |
0m
Args: map[File:net/core/rtnetlink.c FirstLine:6977 LineCount:50]
Results: map[Contents:6977: static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
6978: struct netlink_ext_ack *extack)
6979: {
6980: struct net *net = sock_net(skb->sk);
6981: struct rtnl_link *link;
6982: enum rtnl_kinds kind;
6983: struct module *owner;
6984: int err = -EOPNOTSUPP;
6985: rtnl_doit_func doit;
6986: unsigned int flags;
6987: int family;
6988: int type;
6989:
6990: type = nlh->nlmsg_type;
6991: if (type > RTM_MAX)
6992: return -EOPNOTSUPP;
6993:
6994: type -= RTM_BASE;
6995:
6996: /* All the messages must have at least 1 byte length */
6997: if (nlmsg_len(nlh) < sizeof(struct rtgenmsg))
6998: return 0;
6999:
7000: family = ((struct rtgenmsg *)nlmsg_data(nlh))->rtgen_family;
7001: kind = rtnl_msgtype_kind(type);
7002:
7003: if (kind != RTNL_KIND_GET && !netlink_net_capable(skb, CAP_NET_ADMIN))
7004: return -EPERM;
7005:
7006: rcu_read_lock();
7007: if (kind == RTNL_KIND_GET && (nlh->nlmsg_flags & NLM_F_DUMP)) {
7008: struct sock *rtnl;
7009: rtnl_dumpit_func dumpit;
7010: u32 min_dump_alloc = 0;
7011:
7012: link = rtnl_get_link(family, type);
7013: if (!link || !link->dumpit) {
7014: family = PF_UNSPEC;
7015: link = rtnl_get_link(family, type);
7016: if (!link || !link->dumpit)
7017: goto err_unlock;
7018: }
7019: owner = link->owner;
7020: dumpit = link->dumpit;
7021: flags = link->flags;
7022:
7023: if (type == RTM_GETLINK - RTM_BASE)
7024: min_dump_alloc = rtnl_calcit(skb, nlh);
7025:
7026: err = 0;
]
|
| 95/2 |
2026/08/08 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 34248
output: 37
thoughts: 2328
Thoughts: **Analysis of the act_gate Soft Lockup Vulnerability**
Okay, let's break this down. My initial thought is that `RTM_NEWACTION` requiring `CAP_NET_ADMIN` suggests the vulnerability might be tied to network namespaces and privileges. The prompt's constraints about user namespaces β specifically, that I *can't* assume unprivileged users can elevate to `CAP_NET_ADMIN` inside a user namespace β are critical here. So, "Accessible From Unprivileged Processes" is NO and "Accessible From User Namespaces" is YES.
Now, does network traffic trigger `act_gate` directly? No, it looks like this is a configuration issue. The key is how `act_gate` is *set up*, specifically the timer interval. A malicious administrator *could* configure it to lock up, but that's not a bug. The vulnerability emerges if an unprivileged user can set the timer with a small interval via a user namespace. So this looks like a denial-of-service, a DoS, specifically triggered by user configuration.
The core of the problem seems to be an infinite loop within the hrtimer. If `interval` is set to 1, the code calculates `close_time` as `now + 1`. The timer is set to expire immediately. Then the same thing happens, setting the timer to expire immediately, thus soft lockup. This infinite firing of the timer is the soft lockup's cause.
Iβm now wondering what happens with larger `interval` values. If `now < base`, `close_time` is recalculated, but the previous `gact->current_close_time` wasn't updated. This causes the timer to fire at *every* cycle boundary, breaking the intended gate schedule, but not causing the soft lockup. The soft lockup is triggered *only* when the cycle interval is very small so that the timer fires repeatedly.
Let's consider the math. With a large `interval`, but `now < base` and `cycle` is large, it still results in an incorrect `close_time`. It keeps lagging behind. But then I realized, this also is a soft lockup with a small `C` value, as explained above.
Now, a critical point: can the user control the `cycle` time? The code checks `TCA_GATE_CYCLE_TIME`. If the user supplies 0, it's recalculated as the sum of `interval`s, so it can't be *zero*. But what about very small values? If `cycletime = 1`, it causes the same soft lockup as `interval = 1`. The code seems to allow that. However, with `cycletime` being small, that causes the same "instant" soft lockup as `interval = 1`.
So can the user cause this with different combinations of settings? If `interval` is large, but `cycletime` is small, the timer will fire every `cycletime` ns. This confirms my suspicion: Setting `TCA_GATE_CYCLE_TIME` to 1, regardless of `interval`, will cause the soft lockup.
I need to confirm there aren't any guardrails on the `interval` and `cycletime` values. I already checked that `fill_gate_entry` validates `interval != 0`, but doesn't limit a value of 1. That's the vulnerability: `interval = 1` is *allowed* and results in a soft lockup! This is a typical race in timers. If I set a timer to 1 ns, and it fires instantly, and then re-triggers itself instantly, it soft locks. `hrtimer_run_softirq` and `hrtimer_run_queues` will constantly restart and re-queue the timer.
|
| 96/2 |
2026/08/08 22:33 |
tool |
read-file |
0m
Args: map[File:kernel/time/hrtimer.c FirstLine:2070 LineCount:50]
Results: map[Contents:2070: static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t now,
2071: unsigned long flags, unsigned int active_mask)
2072: {
2073: unsigned int active = cpu_base->active_bases & active_mask;
2074: struct hrtimer_clock_base *base;
2075:
2076: for_each_active_base(base, cpu_base, active) {
2077: ktime_t basenow = ktime_add(now, base->offset);
2078: struct hrtimer *timer;
2079:
2080: while ((timer = clock_base_next_timer(base))) {
2081: /*
2082: * The immediate goal for using the softexpires is
2083: * minimizing wakeups, not running timers at the
2084: * earliest interrupt after their soft expiration.
2085: * This allows us to avoid using a Priority Search
2086: * Tree, which can answer a stabbing query for
2087: * overlapping intervals and instead use the simple
2088: * BST we already have.
2089: * We don't add extra wakeups by delaying timers that
2090: * are right-of a not yet expired timer, because that
2091: * timer will have to trigger a wakeup anyway.
2092: */
2093: if (basenow < hrtimer_get_softexpires(timer))
2094: break;
2095:
2096: __run_hrtimer(cpu_base, base, timer, basenow, flags);
2097: if (active_mask == HRTIMER_ACTIVE_SOFT)
2098: hrtimer_sync_wait_running(cpu_base, flags);
2099: }
2100: }
2101: }
2102:
2103: static __latent_entropy void hrtimer_run_softirq(void)
2104: {
2105: struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
2106: unsigned long flags;
2107: ktime_t now;
2108:
2109: hrtimer_cpu_base_lock_expiry(cpu_base);
2110: raw_spin_lock_irqsave(&cpu_base->lock, flags);
2111:
2112: now = hrtimer_update_base(cpu_base);
2113: __hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_SOFT);
2114:
2115: cpu_base->softirq_activated = false;
2116: hrtimer_update_softirq_timer(cpu_base, true);
2117:
2118: raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
2119: hrtimer_cpu_base_unlock_expiry(cpu_base);
]
|
| 97/2 |
2026/08/08 22:33 |
llm |
expert |
0m
Model:
Tokens:
input: 38282
output: 37
thoughts: 82
Thoughts: Okay, let me break this down.
**Diving Deep into the High-Resolution Timer Mechanism**
Right, so `__run_hrtimer`... it's the heart of the high-resolution timer process. The key is in how it's *structured*. It *removes* the timer from the queue, executes it, and here's the kicker: if the timer function returns `HRTIMER_RESTART`, which tells the system that the timer should keep running, then the kernel *re-enqueues* it.
But... a serious thought is now kicking in. If the re-enqueuing process results in a new expiry time that's *less than or equal to* the current 'basenow' time β the time used as a starting point to run high resolution timers - then that timer will be re-fired, immediately. This is what concerns me.
We could end up with a timer that is re-enqueued, and then picked up *again*, and again in the *same* `while` loop that originally got it running. That could easily lead to an unintended recursive loop situation! To fully understand this, I need to go back and verify exactly what's happening inside `__run_hrtimer`. Let's check the code for that one now.
|
| 98/2 |
2026/08/08 22:33 |
tool |
read-file |
0m
Args: map[File:kernel/time/hrtimer.c FirstLine:1980 LineCount:50]
Results: map[Contents:1980: *
1981: * On the read side we ensure we observe timer->is_queued and cpu_base->running
1982: * from the same section, if anything changed while we looked at it, we retry.
1983: * This includes timer->base changing because sequence numbers alone are
1984: * insufficient for that.
1985: *
1986: * The sequence numbers are required because otherwise we could still observe
1987: * a false negative if the read side got smeared over multiple consecutive
1988: * __run_hrtimer() invocations.
1989: */
1990: static void __run_hrtimer(struct hrtimer_cpu_base *cpu_base, struct hrtimer_clock_base *base,
1991: struct hrtimer *timer, ktime_t now, unsigned long flags)
1992: __must_hold(&cpu_base->lock)
1993: {
1994: enum hrtimer_restart (*fn)(struct hrtimer *);
1995: bool expires_in_hardirq;
1996: int restart;
1997:
1998: lockdep_assert_held(&cpu_base->lock);
1999:
2000: debug_hrtimer_deactivate(timer);
2001: base->running = timer;
2002:
2003: /*
2004: * Separate the ->running assignment from the ->is_queued assignment.
2005: *
2006: * As with a regular write barrier, this ensures the read side in
2007: * hrtimer_active() cannot observe base->running == NULL &&
2008: * timer->is_queued == INACTIVE.
2009: */
2010: raw_write_seqcount_barrier(&base->seq);
2011:
2012: __remove_hrtimer(timer, base, HRTIMER_STATE_INACTIVE, false);
2013: fn = ACCESS_PRIVATE(timer, function);
2014:
2015: /*
2016: * Clear the 'is relative' flag for the TIME_LOW_RES case. If the
2017: * timer is restarted with a period then it becomes an absolute
2018: * timer. If its not restarted it does not matter.
2019: */
2020: if (IS_ENABLED(CONFIG_TIME_LOW_RES))
2021: timer->is_rel = false;
2022:
2023: /*
2024: * The timer is marked as running in the CPU base, so it is
2025: * protected against migration to a different CPU even if the lock
2026: * is dropped.
2027: */
2028: raw_spin_unlock_irqrestore(&cpu_base->lock, flags);
2029: trace_hrtimer_expire_entry(timer, now);
]
|
| 99/2 |
2026/08/08 22:33 |
llm |
expert |
0m
Model:
Tokens:
input: 39478
output: 37
thoughts: 14
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm deeply familiar with kernel internals and real-time systems:
**Diving into the Heart of the Timer**
Right, let's get down to brass tacks. We're looking at `__run_hrtimer`. That name itself tells me we're dealing with the core execution of a high-resolution timer. There's no fluff here, just the guts of how these critical timing mechanisms actually *work*. My focus sharpens immediately. I need to understand exactly what happens within this function β not just its function, but its mechanics. I expect to see the meat of interrupt handling, tick processing, and the scheduler interaction that makes accurate timing possible. The intricacies of this function hold the key to understanding the timer subsystem's performance and responsiveness. Let's see what secrets it holds.
|
| 100/2 |
2026/08/08 22:33 |
tool |
read-file |
0m
Args: map[File:kernel/time/hrtimer.c FirstLine:2030 LineCount:50]
Results: map[Contents:2030: expires_in_hardirq = lockdep_hrtimer_enter(timer);
2031:
2032: restart = fn(timer);
2033:
2034: lockdep_hrtimer_exit(expires_in_hardirq);
2035: trace_hrtimer_expire_exit(timer);
2036: raw_spin_lock_irq(&cpu_base->lock);
2037:
2038: /*
2039: * Note: We clear the running state after enqueue_hrtimer and
2040: * we do not reprogram the event hardware. Happens either in
2041: * hrtimer_start_range_ns() or in hrtimer_interrupt()
2042: *
2043: * Note: Because we dropped the cpu_base->lock above,
2044: * hrtimer_start_range_ns() can have popped in and enqueued the timer
2045: * for us already.
2046: */
2047: if (restart == HRTIMER_RESTART && !timer->is_queued)
2048: enqueue_hrtimer(timer, base, HRTIMER_MODE_ABS, false);
2049:
2050: /*
2051: * Separate the ->running assignment from the ->is_queued assignment.
2052: *
2053: * As with a regular write barrier, this ensures the read side in
2054: * hrtimer_active() cannot observe base->running.timer == NULL &&
2055: * timer->is_queued == INACTIVE.
2056: */
2057: raw_write_seqcount_barrier(&base->seq);
2058:
2059: WARN_ON_ONCE(base->running != timer);
2060: base->running = NULL;
2061: }
2062:
2063: static __always_inline struct hrtimer *clock_base_next_timer_safe(struct hrtimer_clock_base *base)
2064: {
2065: struct timerqueue_linked_node *next = timerqueue_linked_first(&base->active);
2066:
2067: return next ? hrtimer_from_timerqueue_node(next) : NULL;
2068: }
2069:
2070: static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t now,
2071: unsigned long flags, unsigned int active_mask)
2072: {
2073: unsigned int active = cpu_base->active_bases & active_mask;
2074: struct hrtimer_clock_base *base;
2075:
2076: for_each_active_base(base, cpu_base, active) {
2077: ktime_t basenow = ktime_add(now, base->offset);
2078: struct hrtimer *timer;
2079:
]
|
| 101/2 |
2026/08/08 22:33 |
llm |
expert |
0m
Model:
Tokens:
input: 40536
output: 34
thoughts: 1321
Thoughts: **Analyzing the High-Resolution Timer Bug**
Okay, so I've been digging into this hrtimer issue. My initial thought was that `__run_hrtimer` re-enqueues the timer, and then `__hrtimer_run_queues` loops, checking if the timer's expiry is before `basenow`. If the expiry is *before* `basenow`, it runs the timer again, leading to potential re-runs. Since `basenow` isn't updated during that `while` loop, I considered a scenario where the timer sets its expiry to `now + 1`, which could create a loop if that new expiry remains before `basenow`.
Then I realized that `gate_get_time(gact)` is the *current* time, and `basenow` is the time `__hrtimer_run_queues` *started*, so `gate_get_time(gact)` should always be >= `basenow`. This meant the loop should break as expected. If `close_time` (the new expiry time) is set to `now + 1`, and if the hardware timer interrupt fires again immediately, that would be an interrupt storm and a soft lockup.
I went back to the specific bug. It seems that if `gact->current_close_time` isn't updated properly when `ktime_after(now, close_time)` is true, there's a problem. Let me trace that.
1. `now` is `gate_get_time(gact)`.
2. `close_time` is recalculated to `now - R + C`.
3. `hrtimer_set_expires(&gact->hitimer, close_time)`.
4. The timer fires at `now - R + C`.
5. When it fires, `now2 = gate_get_time(gact)`.
6. `gact->current_close_time` is incremented.
7. `close_time = gact->current_close_time`.
8. Since `gact->current_close_time` was lagging, `close_time` is still in the past.
9. `ktime_after(now2, close_time)` is true.
10. `close_time` is recalculated.
11. `hrtimer_set_expires(&gact->hitimer, close_time)`.
12. The timer fires again.
This means the timer fires every *C* nanoseconds! If *C* is small (e.g., 1 ns), it's a soft lockup. Large *C* means it fires every second. So the problem is when *C* is small, meaning low interval settings. If interval is 1 ns, the soft lockup is triggered.
So, the issue is that `act_gate` allows `interval = 1`, which is the root cause!
What about the case where `now < base`? If so, `ktime_sub_ns(now, base)` is negative and becomes a huge positive number as a `u64`. We compute `n = div64_u64(huge, C)`. Thus, `close_time = base + (n + 1) * C`.
This is mathematically the same as `now - R + C`, so `close_time` is in the future. So, `now < base` doesn't cause a past `close_time`.
Is there an overflow in `(n + 1) * C`? `n = (2^{64} + now - base) / C`, thus `(n + 1) * C = 2^{64} + now - base - R + C`. Since `base` and `(n + 1) * C` are added as `ktime_t` (which is `s64`), the addition is `base + 2^{64} + now - base - R + C = 2^{64} + now - R + C`. Since it's `s64` addition, the $2^{64}$ overflows and is discarded, resulting in `now - R + C`.
I should check the `ktime_add_ns` function.
|
| 102/2 |
2026/08/08 22:33 |
tool |
grepper |
0m
Args: map[Expression:ktime_add_ns PathPrefix:include/linux/ktime.h]
Results: map[Output:include/linux/ktime.h=36=static inline ktime_t ktime_set(const s64 secs, const unsigned long nsecs)
--
include/linux/ktime.h-59- */
include/linux/ktime.h:60:#define ktime_add_ns(kt, nsval) ((kt) + (nsval))
include/linux/ktime.h-61-
--
include/linux/ktime.h=177=static inline ktime_t ktime_add_us(const ktime_t kt, const u64 usec)
include/linux/ktime.h-178-{
include/linux/ktime.h:179: return ktime_add_ns(kt, usec * NSEC_PER_USEC);
include/linux/ktime.h-180-}
--
include/linux/ktime.h=182=static inline ktime_t ktime_add_ms(const ktime_t kt, const u64 msec)
include/linux/ktime.h-183-{
include/linux/ktime.h:184: return ktime_add_ns(kt, msec * NSEC_PER_MSEC);
include/linux/ktime.h-185-}
]
|
| 103/2 |
2026/08/08 22:33 |
llm |
expert |
0m
Model:
Tokens:
input: 43159
output: 27
thoughts: 1194
Thoughts: **Analyzing Potential Soft Lockup in `act_gate` Timer**
Okay, let's break this down. `ktime_add_ns(kt, nsval)` is essentially just adding the nanoseconds value (`nsval`) to the `ktime_t` value (`kt`). `kt` is a signed 64-bit integer (`s64`), and `nsval` is an unsigned 64-bit integer (`u64`). When you add an `s64` and a `u64` in C, the `s64` gets implicitly cast to `u64`, the addition is done as `u64`, and the result is a `u64`. But `ktime_t` is `s64`, so the result is implicitly converted back to `s64`.
So, what we're effectively doing is `(s64)((u64)base + (u64)((n + 1) * C))`. This is pure modulo $2^{64}$ arithmetic. Perfect. This means that we should get correct wrapping behavior. Specifically, it should perfectly handle the case where `now < base` because of the modulo nature of the operation.
So why the soft lockup reported by syzbot? The soft lockup is in `gate_timer_func`. The code already checks that `cycle` and `interval` cannot be zero.
Could `(n + 1) * cycle` overflow `u64`? We calculate `n` as `div64_u64(ktime_sub_ns(now, base), cycle);`. If `now < base`, `ktime_sub_ns` is negative, which means a large `u64`. Let's say it's $2^{64} - 1000$.
Now, let's consider two cases. If $C$ (cycle) is large, say $C = 2^{63}$, then `n` is effectively 1. So, `(n + 1) * C = 2 * 2^{63} = 2^{64} = 0` (mod $2^{64}$). This would make the new `base` be equal to the initial `base`. No problem there. If $C$ is small, say $C = 1$, then `n = 2^{64} - 1000`, and `(n + 1) * C = 2^{64} - 999`. That's also mathematically correct, and we are not overflowing.
Let's now consider the more general case, where `(n + 1) * C` *does* overflow `u64`. Since `n = D / C`, `n * C <= D`. So, `(n + 1) * C = n * C + C <= D + C`. Since $D < 2^{64}$, $D + C$ can only overflow $2^{64}$ if $D + C \ge 2^{64}$. If it does, the result modulo $2^{64}$ is $D + C - 2^{64}$. Since $D = 2^{64} + now - base$, $D + C - 2^{64} = now - base + C$. Therefore `base + (now - base + C) = now + C`. Still mathematically sound, and we haven't found a bug. This math appears to be solid.
So the problem must lie elsewhere. It *could* be because `interval` (which sets C) can be 1. If `interval` is 1, the timer fires every nanosecond which *would* cause an interrupt storm and a soft lockup. So, that's definitely a likely cause.
Is there any other combination which would trigger the interrupt storm? How about a large `interval` value, with a *small* `cycle` (say, `cycletime` is provided as 1). Then $C = 1$. The calculation would be `close_time = now - R + 1 = now + 1`. The timer would also fire every 1 ns. This implies setting `TCA_GATE_CYCLE_TIME` to 1 also causes the same problem.
Let's check for other potential problems. Could `ktime_after(now, close_time)` be true, and yet `close_time` be incorrectly recalculated to be in the past? No, we just showed that `close_time` is always in the future (i.e. `now - R + C`).
What if `now - R + C` is negative? Since `now` is positive (
|
| 104/2 |
2026/08/08 22:33 |
tool |
git-log |
10m
Error:
Args: map[CodeRegexp:gate_timer_func Count:10]
Results:
|
| 105/2 |
2026/08/08 22:43 |
llm |
expert |
0m
Model:
Tokens:
input: 45440
output: 30
thoughts: 16
Thoughts: Okay, here's my summarized thought process, presented as if I were thinking it:
**Digging into the Traffic Shaping Gate Action**
Right, so I need to understand how this traffic shaping gate action works. My immediate thought is to dive into the kernel source code. Specifically, the implementation should be in the networking stack, so let's start with `net/sched/act_gate.c`. That's the most likely place to find the relevant code for this gate action. Let's see what's in there. I'll start by checking out the relevant data structures and functions. Hopefully, it's well-commented. Let's get cracking!
|
| 106/2 |
2026/08/08 22:43 |
tool |
git-log |
0m
Args: map[Count:10 PathPrefix:net/sched/act_gate.c]
Results: map[Output:62413a9c3cb1 net/sched: act_gate: snapshot parameters with RCU on replace
69050f8d6d07 treewide: Replace kmalloc with kmalloc_obj for non-scalar types
efcb2d32a8f5 net/sched: Switch to use hrtimer_setup()
a885a6b2d37e net: convert to nla_get_*_default()
241a94abcf46 net/sched: Add module aliases for cls_,sch_,act_ modules
c2a67de9bb54 net/sched: introduce ACT_P_BOUND return code
49b02a19c23a net: sched: Fill in MODULE_DESCRIPTION for act_gate
7afd073e5521 net/sched: act_gate: use percpu stats
871cf386dd16 net/sched: avoid indirect act functions on retpoline kernels
ae3f9fc308d5 net: sched: act_gate: get rid of tcf_gate_walker and tcf_gate_search
]
|
| 107/2 |
2026/08/08 22:43 |
llm |
expert |
0m
Model:
Tokens:
input: 45904
output: 40
thoughts: 22
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience:
**Investigating a Potential Soft Lockup in `net/sched/act_gate.c`**
Alright, time to dive in. My initial thought is to zero in on potential "soft lockup" issues, and my immediate instinct is to check `net/sched/act_gate.c`. This suggests I'm looking for a specific scenario within the Traffic Control framework, likely related to the gate action. I'm probably thinking that a gate action, if misconfigured or subject to a race condition, could be a source of unexpected behavior that manifests as a lockup β even a "soft" one that doesn't completely freeze the system. I'm already mentally running through potential pitfalls: interrupt handling, spinlocks, possible deadlock scenarios if the gate logic interacts with other kernel subsystems in a tricky way, or even a runaway loop within the gate's implementation. The `act_gate` module is complex, so this is a great starting point for investigation.
|
| 108/2 |
2026/08/08 22:43 |
tool |
git-log |
0m
Args: map[Count:10 MessageRegexps:[soft lockup] PathPrefix:net/sched/act_gate.c]
Results:
|
| 109/2 |
2026/08/08 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 46198
output: 39
thoughts: 21
Thoughts: Okay, here's my interpretation of that thought process, as if it were my own:
**Investigating the "lockup" Issue in the Traffic Control Gate Action**
Right, let's dive into this "lockup" issue. My first instinct, given the context, is to check the `net/sched/act_gate.c` file. It's the logical place to start. The "act_gate" part immediately points to the traffic control gate action, and a lockup⦠well, that suggests some sort of potential deadlock, livelock, or resource contention within that specific module. It could be anything from a simple mutex issue to something more complex involving interrupt handling or concurrent data structures. I'll need to carefully examine the code, particularly any areas dealing with locking, scheduling, or shared resources within that module. Let's see what we can find.
|
| 110/2 |
2026/08/08 22:44 |
tool |
git-log |
0m
Args: map[Count:10 MessageRegexps:[lockup] PathPrefix:net/sched/act_gate.c]
Results:
|
| 111/2 |
2026/08/08 22:44 |
llm |
expert |
5m
Model:
Tokens:
input: 46456
output: 38
thoughts: 20
Thoughts: Okay, here's my summary, taking the perspective of someone familiar with kernel networking:
**Investigating the Act_Gate Module for Timer Functionality**
Alright, let's dive into this. I need to understand how the `act_gate` traffic control action utilizes timers, if at all. My instinct is to start by searching for "timer" directly within the source code of the `net/sched/act_gate.c` file. This is the most logical starting point given the module's name. That should give me a good overview of whether timers are used directly by `act_gate`, and if so, how. From there I can assess related function calls and variables. I expect I'll probably also need to look at any included header files to understand the details of timer implementations. Hopefully, the search will be productive and point me in the right direction. Let's see what we uncover.
|
| 112/2 |
2026/08/08 22:49 |
tool |
git-log |
0m
Args: map[Count:10 MessageRegexps:[timer] PathPrefix:net/sched/act_gate.c]
Results: map[Output:62413a9c3cb1 net/sched: act_gate: snapshot parameters with RCU on replace
efcb2d32a8f5 net/sched: Switch to use hrtimer_setup()
c362a06e96ea net/sched: act_gate: fix configuration of the periodic timer
a01c245438c5 net/sched: fix a couple of splats in the error path of tfc_gate_init()
]
|
| 113/2 |
2026/08/08 22:49 |
llm |
expert |
0m
Model:
Tokens:
input: 46830
output: 26
thoughts: 17
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it's my own internal dialogue:
**Investigating a Hash β Let's Get to Work**
Alright, time to get down to business. `c362a06e96ea`. This hashβ¦ itβs staring back at me. I need to figure out what it represents, where it came from, and what it *means* in the context of whatever I'm working on. The immediate questions that spring to mind are:
* **Algorithm?** SHA-1? MD5, perhaps? Or something more modern like SHA-256 or BLAKE2? That'll determine my initial approach. I should quickly try and identify it, or at least eliminate possibilities if it is readily discernable.
* **Context?** Is this a file hash, a password hash, a commit hash, or something else entirely? The environment will heavily influence the interpretation. Where did I encounter this hash? What system/application/log file am I looking at?
* **Initial Verification?** Let's see if this hash is already known. Can I look it up in my internal database of known hashes, or against any relevant public repositories or threat intelligence feeds? A quick search might save a lot of time and effort.
* **Next Steps:** Depending on the answers to these initial questions, I can determine my approach to deeper analysis. Is it time for a brute-force crack, rainbow table lookup, or analysis of the associated file or code? Could it be a known vulnerability? Or, perhaps, a custom hashing scheme I need to understand?
* **Documentation:** I need to keep the context that I'm considering in this review noted. I'll need to keep track of this one, as I progress, to provide an easy to read, understandable analysis.
This hash isn't just a string of characters; it's a doorway to understanding a specific event or data artifact. Time to get started!
|
| 114/2 |
2026/08/08 22:49 |
tool |
git-show |
0m
Args:
Results: map[Output:commit c362a06e96eae16ccb7b0f4f93f19224279b8610
Author: Davide Caratti <dcaratti@redhat.com>
Date: Tue Jun 16 22:25:21 2020 +0200
net/sched: act_gate: fix configuration of the periodic timer
assigning a dummy value of 'clock_id' to avoid cancellation of the cycle
timer before its initialization was a temporary solution, and we still
need to handle the case where act_gate timer parameters are changed by
commands like the following one:
# tc action replace action gate <parameters>
the fix consists in the following items:
1) remove the workaround assignment of 'clock_id', and init the list of
entries before the first error path after IDR atomic check/allocation
2) validate 'clock_id' earlier: there is no need to do IDR atomic
check/allocation if we know that 'clock_id' is a bad value
3) use a dedicated function, 'gate_setup_timer()', to ensure that the
timer is cancelled and re-initialized on action overwrite, and also
ensure we initialize the timer in the error path of tcf_gate_init()
v3: improve comment in the error path of tcf_gate_init() (thanks to
Vladimir Oltean)
v2: avoid 'goto' in gate_setup_timer (thanks to Cong Wang)
CC: Ivan Vecera <ivecera@redhat.com>
Fixes: a01c245438c5 ("net/sched: fix a couple of splats in the error path of tfc_gate_init()")
Fixes: a51c328df310 ("net: qos: introduce a gate control flow action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/sched/act_gate.c b/net/sched/act_gate.c
index 94e560c2f81d..323ae7f6315d 100644
--- a/net/sched/act_gate.c
+++ b/net/sched/act_gate.c
@@ -272,6 +272,27 @@ static int parse_gate_list(struct nlattr *list_attr,
return err;
}
+static void gate_setup_timer(struct tcf_gate *gact, u64 basetime,
+ enum tk_offsets tko, s32 clockid,
+ bool do_init)
+{
+ if (!do_init) {
+ if (basetime == gact->param.tcfg_basetime &&
+ tko == gact->tk_offset &&
+ clockid == gact->param.tcfg_clockid)
+ return;
+
+ spin_unlock_bh(&gact->tcf_lock);
+ hrtimer_cancel(&gact->hitimer);
+ spin_lock_bh(&gact->tcf_lock);
+ }
+ gact->param.tcfg_basetime = basetime;
+ gact->param.tcfg_clockid = clockid;
+ gact->tk_offset = tko;
+ hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS_SOFT);
+ gact->hitimer.function = gate_timer_func;
+}
+
static int tcf_gate_init(struct net *net, struct nlattr *nla,
struct nlattr *est, struct tc_action **a,
int ovr, int bind, bool rtnl_held,
@@ -303,6 +324,27 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (!tb[TCA_GATE_PARMS])
return -EINVAL;
+ if (tb[TCA_GATE_CLOCKID]) {
+ clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
+ switch (clockid) {
+ case CLOCK_REALTIME:
+ tk_offset = TK_OFFS_REAL;
+ break;
+ case CLOCK_MONOTONIC:
+ tk_offset = TK_OFFS_MAX;
+ break;
+ case CLOCK_BOOTTIME:
+ tk_offset = TK_OFFS_BOOT;
+ break;
+ case CLOCK_TAI:
+ tk_offset = TK_OFFS_TAI;
+ break;
+ default:
+ NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
+ return -EINVAL;
+ }
+ }
+
parm = nla_data(tb[TCA_GATE_PARMS]);
index = parm->index;
@@ -326,10 +368,6 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
tcf_idr_release(*a, bind);
return -EEXIST;
}
- if (ret == ACT_P_CREATED) {
- to_gate(*a)->param.tcfg_clockid = -1;
- INIT_LIST_HEAD(&(to_gate(*a)->param.entries));
- }
if (tb[TCA_GATE_PRIORITY])
prio = nla_get_s32(tb[TCA_GATE_PRIORITY]);
@@ -340,33 +378,14 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (tb[TCA_GATE_FLAGS])
gflags = nla_get_u32(tb[TCA_GATE_FLAGS]);
- if (tb[TCA_GATE_CLOCKID]) {
- clockid = nla_get_s32(tb[TCA_GATE_CLOCKID]);
- switch (clockid) {
- case CLOCK_REALTIME:
- tk_offset = TK_OFFS_REAL;
- break;
- case CLOCK_MONOTONIC:
- tk_offset = TK_OFFS_MAX;
- break;
- case CLOCK_BOOTTIME:
- tk_offset = TK_OFFS_BOOT;
- break;
- case CLOCK_TAI:
- tk_offset = TK_OFFS_TAI;
- break;
- default:
- NL_SET_ERR_MSG(extack, "Invalid 'clockid'");
- goto release_idr;
- }
- }
+ gact = to_gate(*a);
+ if (ret == ACT_P_CREATED)
+ INIT_LIST_HEAD(&gact->param.entries);
err = tcf_action_check_ctrlact(parm->action, tp, &goto_ch, extack);
if (err < 0)
goto release_idr;
- gact = to_gate(*a);
-
spin_lock_bh(&gact->tcf_lock);
p = &gact->param;
@@ -397,14 +416,10 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
p->tcfg_cycletime_ext =
nla_get_u64(tb[TCA_GATE_CYCLE_TIME_EXT]);
+ gate_setup_timer(gact, basetime, tk_offset, clockid,
+ ret == ACT_P_CREATED);
p->tcfg_priority = prio;
- p->tcfg_basetime = basetime;
- p->tcfg_clockid = clockid;
p->tcfg_flags = gflags;
-
- gact->tk_offset = tk_offset;
- hrtimer_init(&gact->hitimer, clockid, HRTIMER_MODE_ABS_SOFT);
- gact->hitimer.function = gate_timer_func;
gate_get_start_time(gact, &start);
gact->current_close_time = start;
@@ -433,6 +448,13 @@ static int tcf_gate_init(struct net *net, struct nlattr *nla,
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
release_idr:
+ /* action is not inserted in any list: it's safe to init hitimer
+ * without taking tcf_lock.
+ */
+ if (ret == ACT_P_CREATED)
+ gate_setup_timer(gact, gact->param.tcfg_basetime,
+ gact->tk_offset, gact->param.tcfg_clockid,
+ true);
tcf_idr_release(*a, bind);
return err;
}
@@ -443,9 +465,7 @@ static void tcf_gate_cleanup(struct tc_action *a)
struct tcf_gate_params *p;
p = &gact->param;
- if (p->tcfg_clockid != -1)
- hrtimer_cancel(&gact->hitimer);
-
+ hrtimer_cancel(&gact->hitimer);
release_entry_list(&p->entries);
}
]
|
| 115/2 |
2026/08/08 22:49 |
llm |
expert |
0m
Model:
Tokens:
input: 49780
output: 66
thoughts: 1652
Thoughts: **Vulnerability Analysis of act_gate Soft Lockup**
Okay, so I'm looking at this commit from 2020, and this soft lockup bug is still present in the current code, thatβs not good. I need to figure out if this is exploitable. It's a soft lockup, so the immediate impact is Denial of Service, which is good to know.
First, can an unprivileged user trigger this? I know TC actions require `CAP_NET_ADMIN`, but what about user namespaces? If a user namespace is created, an unprivileged user can create one, get `CAP_NET_ADMIN` within it, and then create a TC action. So, it *is* accessible from user namespaces. But, it is not accessible from unprivileged processes. So the bug is not exploitable directly.
Is this network-triggered? No, it's configuration-triggered. The timer fires independently of network traffic.
Let me summarize: Exploitable? No, only DoS. Accessible from unprivileged processes? No. Accessible from user namespaces? Yes. VM guest/host triggers? No. Network/peripheral/filesystem triggers? No.
Alright, the core issue seems to be this: the *interval* setting in `act_gate`. I'm going to look at other possible bugs...
What if the *interval* is very large, and `cycletime` is also large, but `now < base`? It seems handled properly. What if `gact->current_close_time` isn't updated to `close_time`? If it keeps lagging, `ktime_after(now, close_time)` will *always* be true, right? Yeah, and then `close_time` gets recalculated to the *next* cycle boundary. The timer fires at the next cycle. When it fires, then it gets incremented by `next->interval`, and it will still be lagging! It will continue to fire at every cycle boundary!
If the cycle time is small, it fires frequently. If it's *tiny* (like 1 ns), it's a soft lockup! This is caused by the user configurable interval! Since a user can set this to be small, it can cause a soft lockup. I need to verify that there are no bounds. Okay, this is a DoS!
Is there any other way to cause a soft lockup? No, `interval` cannot be 0, negative. `cycletime` also can't be 0, or negative, and large. The wrapping handles the issues with very large numbers. So the only way is to set a small interval.
The only issue is that a user can set a very small interval, causing a soft lockup. Is there any other TC action that allows a very small interval and causes a soft lockup? Probably, but this is a specific bug in `act_gate`. Is it a bug that `gact->current_close_time` is not updated? Yes! The code expert confirmed it is a significant logical bug. Even if this `gact->current_close_time` was updated, the soft lockup still occurs!
If `interval = 1`, `gact->current_close_time` is incremented by 1. Then `close_time` is equal to it, so when is the alarm sent? It is set to `now + 1`. The timer will fire at every 1 ns. It is a soft lockup purely because there is no minimum limit on `interval`. Is this a vulnerability? Yes. A local user (with `CAP_NET_ADMIN` in a user namespace) can crash the system (soft lockup). It is a classic DoS from the user namespace.
Let me double-check: Can an unprivileged user namespace trigger this? `rtnetlink_rcv_msg` checks for `CAP_NET_ADMIN`. A new user namespace gets `CAP_NET_ADMIN` and this confirms it is accessible from the user namespace.
I will also check other capabilities. Okay, nothing else is needed in `tcf_gate_init`.
Let me summarize again: Exploitable? No, just DoS. Accessible from user namespaces? Yes. Unprivileged processes? No. Guest/Host/Network triggers? No. Malicious filesystems? No.
I'm ready to use the set-results tool.
|
| 116/2 |
2026/08/08 22:50 |
tool |
set-results |
0m
Args: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:false UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:false UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 117/2 |
2026/08/08 22:50 |
llm |
expert |
0m
Model:
Tokens:
input: 52501
output: 632
thoughts: 376
Thoughts: **My Analysis of the Soft Lockup Bug**
Okay, the results are in, and now it's time to craft the final response. My findings point to a soft lockup triggered by a very specific and subtle condition within the `act_gate` Traffic Control (TC) action. It seems this is caused by setting a miniscule interval, like 1 nanosecond, within the `act_gate` configuration.
What happens is that setting such a small interval causes the high-resolution timer (hrtimer) to trigger *constantly*. It's a continuous interrupt storm, and the system is overwhelmed, which results in the soft lockup.
The interesting angle is that a user with `CAP_NET_ADMIN` in a network namespace can configure this `act_gate` action. Moreover, an unprivileged user can create new user and network namespaces and acquire the necessary capability, making this bug accessible even from a less privileged context. This is very important.
From my evaluation, this is a Denial of Service (DoS) vulnerability. Fortunately, it's not a privilege escalation or information leak issue. It is *not* triggered by typical network traffic, which is a relief. Instead, itβs configuration-based.
Let me break down the root cause:
1. The `act_gate` action is flexible: the user can configure a schedule with time intervals for each entry.
2. Crucially, there's no minimal restriction or validation on the `interval` value, other than checking if it is `0`.
3. If a user sets `interval = 1` (a nanosecond), the hrtimer starts to fire, attempting to execute every nanosecond.
4. The system's overhead in handling the interrupt and running the softirq takes significantly more time than 1 nanosecond. This means the timer continuously fires, re-enqueuing itself almost immediately.
5. This is what creates the interrupt storm. The system is essentially caught in an infinite loop within the softirq context, leading to a CPU soft lockup.
6. There's also a secondary, logical issue where `gact->current_close_time` isn't updated when the timer falls behind. However, the lack of a minimum interval restriction is the primary cause of the lockup.
I'm confident in my explanation. Time to finalize the response.
|
| 118/1 |
2026/08/08 22:50 |
action |
format-explanation |
0m
Results: map[Explanation:**Bug Analysis & Root Cause:**
The bug is a CPU soft lockup occurring in the `gate_timer_func` of the
`act_gate` Traffic Control (TC) action.
The `act_gate` action uses an `hrtimer` to enforce a time-based schedule for
network traffic. Users can configure a list of schedule entries, each with a
specific `interval` (duration). The timer function `gate_timer_func()` advances
the schedule and reprograms the `hrtimer` to fire after the current entry's
`interval` has elapsed.
The root cause of the soft lockup is the lack of a minimum bound check on the
`interval` value. The configuration parsing function `fill_gate_entry()` only
rejects `interval == 0`, meaning a user can successfully configure an interval
of `1` nanosecond.
If an interval is set to 1 ns, the `hrtimer` will be programmed to fire every 1
nanosecond. Because executing the timer callback and the associated softirq
overhead takes significantly longer than 1 ns, the timer will immediately expire
again upon re-enqueuing. This creates an interrupt storm where the CPU gets
stuck in an infinite loop processing the `hrtimer` softirq, ultimately
triggering the kernel's soft lockup watchdog.
Additionally, there is a logical flaw in `gate_timer_func()` where
`gact->current_close_time` is not properly updated to the recalculated
`close_time` when the timer falls behind (`ktime_after(now, close_time)` is
true). This causes the timer to continuously think it is lagging behind, further
exacerbating the tight loop if the cycle time is small.
**Security Impact:**
* **Exploitable:** No. This is a pure CPU exhaustion/infinite loop issue. It
does not involve memory corruption, use-after-free, or out-of-bounds accesses,
so it cannot be exploited for privilege escalation or information leaks.
* **Denial Of Service:** Yes. Triggering this bug causes a hard CPU stall (soft
lockup), which degrades system performance and can lead to a kernel panic if
`softlockup_panic` is enabled, resulting in a complete Denial of Service.
* **Accessible From Unprivileged Processes:** No. Configuring TC actions
requires the `CAP_NET_ADMIN` capability in the network namespace. A standard
unprivileged process cannot reach this code.
* **Accessible From User Namespaces:** Yes. An unprivileged user can create a
new user namespace and a new network namespace (`CLONE_NEWUSER | CLONE_NEWNET`).
Within this isolated namespace, the user gains `CAP_NET_ADMIN` and can freely
configure TC actions, including `act_gate`, to trigger the soft lockup on the
host CPU.
* **Network / Remote / Peripheral Triggers:** No. The bug is triggered purely by
the local configuration of the TC action via netlink messages, not by processing
malicious network packets, remote traffic, or peripheral devices.]
|