| 0/0 |
2026/08/15 01:04 |
flow |
assessment-security |
36m
Results: map[DenialOfService:false Explanation:The bug report indicates a `WARNING` caused by calling a blocking operation
(`cancel_delayed_work_sync`) from an atomic context (a timer callback).
### Root Cause Analysis
The issue resides in the `vub300` USB-SD/SDIO host controller driver.
During initialization (`vub300_probe`), the driver sets up an `inactivity_timer`
that periodically fires to check for inactivity. The timer holds a reference
count (`kref`) to the `vub300` host object.
When the USB device is physically unplugged, `vub300_disconnect` is invoked. It
sets `vub300->interface = NULL`, synchronously cancels the MMC host detection
work (via `mmc_remove_host`), and drops its reference to the `vub300` object.
Later, when the `inactivity_timer` fires, it notices that `vub300->interface` is
`NULL`. It then drops its own reference to the object and does not re-arm
itself. If this timer happens to be the last entity holding a reference (e.g.,
all pending workqueues have finished), the `kref_put` call will invoke the
release function `vub300_delete` directly from the timer's softirq context.
`vub300_delete` calls `mmc_free_host`, which in turn calls
`cancel_delayed_work_sync(&host->detect)`. The `cancel_delayed_work_sync`
function contains a `might_sleep()` check, which triggers the `WARNING` because
sleeping is not allowed in softirq context.
### Security Impact
Despite the warning, this bug does not pose a security risk:
1. **No Actual Sleep/Deadlock**: Because `host->detect` was already
synchronously cancelled and disabled during `vub300_disconnect`,
`cancel_delayed_work_sync` will find no work to wait for and will return
immediately without actually calling `schedule()`.
2. **No Memory Corruption**: The timer properly holds a reference count to the
`vub300` object and does not re-arm itself after dropping it. The object is
safely freed without any use-after-free conditions.
3. **No Denial of Service**: In production kernel builds (where `panic_on_warn`
is disabled), the `WARNING` simply prints a stack trace to the kernel log and
execution continues normally.
### Trigger Vectors
The bug is triggered by the normal disconnection process of the VUB300 USB
device. Therefore, it requires physical access to plug and unplug the specific
USB peripheral (or a malicious device emulating it). It cannot be triggered
remotely or by unprivileged users interacting with the system. Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:true RemoteTrigger:false Unprivileged:false UserNamespace:false VMGuestTrigger:false VMHostTrigger:false]
|
| 1/1 |
2026/08/15 01:04 |
action |
syz-repro-to-c-repro |
0m
Results:
|
| 2/1 |
2026/08/15 01:04 |
action |
kernel-checkouter |
2m
Results: map[KernelSrc:/app/workdir/cache/src/5bb5f8e39acabe945d84041b9e1aa541dd2244ad]
|
| 3/1 |
2026/08/15 01:06 |
action |
kernel-builder |
16m
Results: map[KernelObj:/app/workdir/cache/build/64c534ddba273fa0cbfed5c58b243ae85f7091f7]
|
| 4/1 |
2026/08/15 01:23 |
action |
codesearch-prepare |
14m
Results: map[Index:codesearch-index]
|
| 5/1 |
2026/08/15 01:38 |
agent |
expert |
3m
Model:
Results: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:true RemoteTrigger:false Unprivileged:false UserNamespace:false 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:
------------[ cut here ]------------
do not call blocking ops when !TASK_RUNNING; state=402 set at [<ffffffff818d6cae>] prepare_to_swait_event+0xae/0x4a0 kernel/sched/swait.c:118
WARNING: kernel/sched/core.c:9120 at __might_sleep+0x94/0xc0 kernel/sched/core.c:9120, CPU#1: rcu_preempt/15
Modules linked in:
CPU: 1 UID: 0 PID: 15 Comm: rcu_preempt Not tainted syzkaller #0 PREEMPT(lazy)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
RIP: 0010:__might_sleep+0x97/0xc0 kernel/sched/core.c:9120
Code: 8b 94 24 88 17 00 00 48 85 d2 75 14 48 83 c4 08 89 ee 48 89 df 31 d2 5b 5d 41 5c e9 33 fc ff ff 48 8d 3d 0c 7b 71 09 48 89 d1 <67> 48 0f b9 3a eb db e8 ad 10 99 00 eb 9f 89 74 24 04 e8 d2 10 99
RSP: 0018:ffffc900001a8be8 EFLAGS: 00010282
RAX: dffffc0000000000 RBX: ffffffff878863c0 RCX: ffffffff818d6cae
RDX: ffffffff818d6cae RSI: 0000000000000402 RDI: ffffffff8af4ecc0
RBP: 0000000000001187 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888101ee1e00
R13: 1ffff9200003518e R14: ffffffff85e91b70 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff888268733000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4266710d74 CR3: 00000001174cc000 CR4: 00000000003506f0
Call Trace:
<IRQ>
__cancel_work_sync kernel/workqueue.c:4487 [inline]
cancel_delayed_work_sync+0xb8/0xf0 kernel/workqueue.c:4568
mmc_free_host+0x19/0x30 drivers/mmc/core/host.c:700
vub300_delete drivers/mmc/host/vub300.c:379 [inline]
kref_put include/linux/kref.h:65 [inline]
vub300_inactivity_timer_expired drivers/mmc/host/vub300.c:747 [inline]
vub300_inactivity_timer_expired+0x42f/0x550 drivers/mmc/host/vub300.c:742
call_timer_fn+0x19a/0x610 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers+0x757/0xb00 kernel/time/timer.c:2374
__run_timer_base kernel/time/timer.c:2386 [inline]
__run_timer_base kernel/time/timer.c:2378 [inline]
run_timer_base+0x114/0x190 kernel/time/timer.c:2395
run_timer_softirq+0x1a/0x50 kernel/time/timer.c:2405
handle_softirqs+0x1dd/0x990 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x160/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:179 [inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0x31/0x80 kernel/locking/spinlock.c:198
Code: f5 53 48 8b 74 24 10 48 89 fb 48 83 c7 18 e8 56 13 11 fa 48 89 df e8 de 62 11 fa f7 c5 00 02 00 00 75 23 9c 58 f6 c4 02 75 37 <bf> 01 00 00 00 e8 25 f0 03 fa 65 8b 05 6e a2 7f 05 85 c0 74 16 5b
RSP: 0018:ffffc900000ffa80 EFLAGS: 00000246
RAX: 0000000000000006 RBX: ffff8881f5725ec0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff890f4061 RDI: ffffffff87b15700
RBP: 0000000000000287 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff8881f5725ec0
R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8881f5725f08
__mod_timer+0x409/0xca0 kernel/time/timer.c:1139
add_timer+0x62/0x90 kernel/time/timer.c:1249
schedule_timeout+0x122/0x280 kernel/time/sleep_timeout.c:98
rcu_gp_fqs_loop+0x1a9/0x900 kernel/rcu/tree.c:2123
rcu_gp_kthread+0x179/0x230 kernel/rcu/tree.c:2325
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 8b 94 24 88 17 00 00 mov 0x1788(%rsp),%edx
7: 48 85 d2 test %rdx,%rdx
a: 75 14 jne 0x20
c: 48 83 c4 08 add $0x8,%rsp
10: 89 ee mov %ebp,%esi
12: 48 89 df mov %rbx,%rdi
15: 31 d2 xor %edx,%edx
17: 5b pop %rbx
18: 5d pop %rbp
19: 41 5c pop %r12
1b: e9 33 fc ff ff jmp 0xfffffc53
20: 48 8d 3d 0c 7b 71 09 lea 0x9717b0c(%rip),%rdi # 0x9717b33
27: 48 89 d1 mov %rdx,%rcx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: eb db jmp 0xc
31: e8 ad 10 99 00 call 0x9910e3
36: eb 9f jmp 0xffffffd7
38: 89 74 24 04 mov %esi,0x4(%rsp)
3c: e8 .byte 0xe8
3d: d2 10 rclb %cl,(%rax)
3f: 99 cltd
Reply: The bug report indicates a `WARNING` caused by calling a blocking operation (`cancel_delayed_work_sync`) from an atomic context (a timer callback).
### Root Cause Analysis
The issue resides in the `vub300` USB-SD/SDIO host controller driver.
During initialization (`vub300_probe`), the driver sets up an `inactivity_timer` that periodically fires to check for inactivity. The timer holds a reference count (`kref`) to the `vub300` host object.
When the USB device is physically unplugged, `vub300_disconnect` is invoked. It sets `vub300->interface = NULL`, synchronously cancels the MMC host detection work (via `mmc_remove_host`), and drops its reference to the `vub300` object.
Later, when the `inactivity_timer` fires, it notices that `vub300->interface` is `NULL`. It then drops its own reference to the object and does not re-arm itself. If this timer happens to be the last entity holding a reference (e.g., all pending workqueues have finished), the `kref_put` call will invoke the release function `vub300_delete` directly from the timer's softirq context.
`vub300_delete` calls `mmc_free_host`, which in turn calls `cancel_delayed_work_sync(&host->detect)`. The `cancel_delayed_work_sync` function contains a `might_sleep()` check, which triggers the `WARNING` because sleeping is not allowed in softirq context.
### Security Impact
Despite the warning, this bug does not pose a security risk:
1. **No Actual Sleep/Deadlock**: Because `host->detect` was already synchronously cancelled and disabled during `vub300_disconnect`, `cancel_delayed_work_sync` will find no work to wait for and will return immediately without actually calling `schedule()`.
2. **No Memory Corruption**: The timer properly holds a reference count to the `vub300` object and does not re-arm itself after dropping it. The object is safely freed without any use-after-free conditions.
3. **No Denial of Service**: In production kernel builds (where `panic_on_warn` is disabled), the `WARNING` simply prints a stack trace to the kernel log and execution continues normally.
### Trigger Vectors
The bug is triggered by the normal disconnection process of the VUB300 USB device. Therefore, it requires physical access to plug and unplug the specific USB peripheral (or a malicious device emulating it). It cannot be triggered remotely or by unprivileged users interacting with the system.
|
| 6/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 8637
output: 50
thoughts: 650
Thoughts: **Analyzing a Kernel Bug: Blocking Operation in Atomic Context**
Okay, so I'm looking at this kernel bug report, and it immediately screams a classic problem: a blocking operation where it shouldn't be. The report highlights a critical issue: a kernel warning about a sleep in `prepare_to_swait_event` while the task state isn't `TASK_RUNNING`, which is bad news. And then we have the `__might_sleep` warning, which is the smoking gun! This happens in the `rcu_preempt` context on CPU #1, further narrowing down the potential culprits.
The call trace is the key here. It shows that `vub300_inactivity_timer_expired` is the root. It triggers a chain of events, starting with decrementing a `kref` using `kref_put`. This calls `vub300_delete`, which eventually cascades to `mmc_free_host`. Inside `mmc_free_host`, `cancel_delayed_work_sync` is called, which can lead to sleep. Here is the problem.
The timer callback `vub300_inactivity_timer_expired` runs in a softirq context, which is effectively an atomic context. Sleeping in this context is a strict no-no, as it can lead to deadlocks, data corruption, and general system instability. So the root cause seems that `mmc_free_host` is blocking when it shouldn't.
Now, my next step is to dive into `drivers/mmc/host/vub300.c` to see exactly what `mmc_free_host` and `cancel_delayed_work_sync` are doing and why they might be sleeping. I need to understand what's protected by the workqueue and why it's sleeping, or to look at how we can redesign it so that the sleep is not necessary in that context. We might have to move the work that's causing the sleep to a different context or use a non-blocking method, like using the non-blocking version of the workqueue API.
|
| 7/2 |
2026/08/15 01:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_inactivity_timer_expired]
Results: map[SourceCode: 742: static void vub300_inactivity_timer_expired(struct timer_list *t)
743: { /* softirq */
744: struct vub300_mmc_host *vub300 = timer_container_of(vub300, t,
745: inactivity_timer);
746: if (!vub300->interface) {
747: kref_put(&vub300->kref, vub300_delete);
748: } else if (vub300->cmd) {
749: mod_timer(&vub300->inactivity_timer, jiffies + HZ);
750: } else {
751: vub300_queue_dead_work(vub300);
752: mod_timer(&vub300->inactivity_timer, jiffies + HZ);
753: }
754: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 8/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 10099
output: 45
thoughts: 14
Thoughts: Okay, let's dive into this. Here's my take on it, presented as a first-person account:
**Analyzing vub300_delete**
Alright, let's get down to brass tacks. I need to take a close look at `vub300_delete`. Just the name itself tells me we're dealing with a deletion function, likely targeting something within the `vub300` context. Given my experience, I'm already mentally running through the various data structures and potential dependencies associated with that identifier. What's it deleting? Is it a single record, a range, or an entire dataset? Are there cascading effects to consider? Are there any obvious transactional implications I need to be aware of? Are there associated security concerns? My mind is already sketching out a mental map of potential gotchas and areas to prioritize in my analysis. It's a deletion function, so understanding its behavior and impact is critical. I'll need to dissect its implementation with a focus on potential side effects. I anticipate having to look into logging, error handling, and any cleanup mechanisms it employs. Time to put on my investigator hat.
|
| 9/2 |
2026/08/15 01:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_delete]
Results: map[SourceCode: 369: static void vub300_delete(struct kref *kref)
370: { /* kref callback - softirq */
371: struct vub300_mmc_host *vub300 = kref_to_vub300_mmc_host(kref);
372: struct mmc_host *mmc = vub300->mmc;
373:
374: usb_free_urb(vub300->command_out_urb);
375: vub300->command_out_urb = NULL;
376: usb_free_urb(vub300->command_res_urb);
377: vub300->command_res_urb = NULL;
378: usb_put_dev(vub300->udev);
379: mmc_free_host(mmc);
380: /*
381: * and hence also frees vub300
382: * which is contained at the end of struct mmc
383: */
384: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 10/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 10746
output: 58
thoughts: 98
Thoughts: **Analyzing the Elan Digital Systems VUB300 USB-SD/SDIO Driver Cleanup**
Okay, so I'm looking at the `vub300_delete` function. It seems pretty straightforwardβit calls `mmc_free_host(mmc)`. That's standard practice for cleaning up MMC hosts, nothing surprising there. However, digging a bit deeper, I see that `mmc_free_host` then calls `cancel_delayed_work_sync(&host->detect);`. The problem is that this function *sleeps*. That's where things get interesting and where potential issues can arise, especially in a USB context, where blocking can be problematic.
This is a driver for the Elan Digital Systems VUB300 USB-SD/SDIO device, so the context is important here. Now, since there's a sleep involved in the cleanup path, I need to make sure this is all handled safely. I need to know where else `vub300_delete` gets called to understand all the code paths where this could happen and where there could potentially be problems. I'll need to check the rest of the driver.
|
| 11/2 |
2026/08/15 01:38 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:vub300_delete SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_cmndwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:1742] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_cmndwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:1791] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_cmndwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:1797] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_deadwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:714] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_deadwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:739] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_disconnect SourceFile:drivers/mmc/host/vub300.c SourceLine:2388] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_enable_sdio_irq SourceFile:drivers/mmc/host/vub300.c SourceLine:2082] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:747] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1949] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1962] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_set_ios SourceFile:drivers/mmc/host/vub300.c SourceLine:2046] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_pollwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:683] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_pollwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:706] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2353] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_queue_cmnd_work SourceFile:drivers/mmc/host/vub300.c SourceLine:402] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_queue_dead_work SourceFile:drivers/mmc/host/vub300.c SourceLine:442] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_queue_poll_work SourceFile:drivers/mmc/host/vub300.c SourceLine:422]] TruncatedOutput:false]
|
| 12/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 12294
output: 55
thoughts: 395
Thoughts: **My Analysis of the `vub300_delete` SoftIRQ Sleep Issue**
Okay, so `vub300_delete` is a kref callback, and I see it's being called from a timer callback. The problem immediately jumps out at me: that timer callback is running in a softirq context, and `vub300_delete` is potentially sleeping. That's a huge red flag β a definite warning, even if it's not a kernel-crashing bug, yet. Itβs certainly not ideal.
Wait, hold on... `cancel_delayed_work_sync` can *block*. If it blocks within a softirq context, that's where things get really nasty. A deadlock is a real possibility, or at the very least, a "scheduling while atomic" bug. If it *does* actually sleep, that means it'll be calling `schedule()` from an atomic context which will trigger more warnings. The behavior will be configurable, and potentially worse if `CONFIG_PREEMPT` and `CONFIG_DEBUG_ATOMIC_SLEEP` are both enabled.
In a production environment, if it *just* sleeps without holding any spinlocks, the `schedule()` call *might* somehow work without a crash. The softirq context has preemption disabled, and that's the kicker. Even though `__might_sleep` is *just* a warning, it's a symptom, and the *real* problem is the subsequent `schedule()` call.
Let's break down the implications of that `schedule()` call. Digging into `__schedule()`, I see:
```c
if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);
preempt_count_set(PREEMPT_DISABLED);
}
```
Okay, `__schedule_bug` prints a warning and then *continues* scheduling. So, it's more of a denial-of-service situation if it deadlocks. But if it *just* sleeps and wakes up, it might not deadlock. Still, sleeping in the softirq context is a bug no matter how you slice it.
Could this be triggered by a peripheral? Yes, from a USB driver, the chance is very high. Can an unprivileged user trigger it? I should investigate how `vub300_inactivity_timer_expired` is triggered.
|
| 13/2 |
2026/08/15 01:38 |
tool |
codesearch-find-references |
0m
Error:
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:inactivity_timer SourceTreePrefix:]
Results: map[References:<nil> TruncatedOutput:false]
|
| 14/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 13286
output: 66
thoughts: 12
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Initial Assessment: Field Identification**
Ah, the code's referencing `inactivity_timer`. Right, that's immediately recognizable as a *field*. It's a fundamental piece of data, not a method or class. Simple enough to grasp at first glance. It suggests a focus on tracking periods of inactivity, and I can start to build a mental map of where it likely resides within the larger system.
|
| 15/2 |
2026/08/15 01:38 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:vub300_mmc_host::inactivity_timer SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:__do_poll SourceFile:drivers/mmc/host/vub300.c SourceLine:659] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_deadwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:737] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:744] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:749] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:752] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1940] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_pollwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:698] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2331] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2333] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2334]] TruncatedOutput:false]
|
| 16/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 14133
output: 45
thoughts: 118
Thoughts: **My Analysis of the VUB300 Probe Timer**
Okay, so the timer mechanism for this `vub300` device, specifically how it handles inactivity, is spread out across a few key areas. My initial thought is that setting this up in `vub300_probe` is standard operating procedure, makes sense, but the subsequent modifications within `vub300_mmc_request` and other locations indicate this is a dynamic process, and I'll need to examine these interactions closely for race conditions or unintended consequences. This timer expiring triggers a crucial check: `!vub300->interface`. If that interface pointer *is* null, as the comment suggests, that's where `kref_put` and the eventual `vub300_delete` call happen, indicating the device is being deinitialized. The fact that `vub300->interface` gets set to `NULL` explicitly during `vub300_disconnect` makes it a critical part of the disconnect sequence. I need to trace this control flow to be certain that the disconnect is atomic and that no lingering accesses can occur between `vub300_disconnect` and the timer firing. This design relies on a clean `NULL` check to indicate the device is safe to deallocate. A failure here could lead to use-after-free, double-free, or other memory corruption issues, which need to be verified in a deeper dive. I'll need to pay close attention to all the possible exit paths of the `vub300_probe` function to ensure that no dangling references are set before any deallocation takes place.
|
| 17/2 |
2026/08/15 01:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_disconnect]
Results: map[SourceCode:2373: static void vub300_disconnect(struct usb_interface *interface)
2374: { /* NOT irq */
2375: struct vub300_mmc_host *vub300 = usb_get_intfdata(interface);
2376: if (!vub300 || !vub300->mmc) {
2377: return;
2378: } else {
2379: struct mmc_host *mmc = vub300->mmc;
2380: if (!vub300->mmc) {
2381: return;
2382: } else {
2383: int ifnum = interface_to_InterfaceNumber(interface);
2384: usb_set_intfdata(interface, NULL);
2385: /* prevent more I/O from starting */
2386: vub300->interface = NULL;
2387: mmc_remove_host(mmc);
2388: kref_put(&vub300->kref, vub300_delete);
2389: pr_info("USB vub300 remote SDIO host controller[%d]"
2390: " now disconnected", ifnum);
2391: return;
2392: }
2393: }
2394: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 18/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 15054
output: 54
thoughts: 832
Thoughts: **Analyzing a Potential Race Condition and Use-After-Free Vulnerability**
Okay, so `vub300_disconnect` sets `vub300->interface = NULL;` and calls `kref_put`. The crux of the issue is what happens with the timer. If it expires *after* `vub300_disconnect` has set the interface to NULL, but *before* the timer is explicitly deleted (or if it *isn't* deleted), the timer callback will see that `vub300->interface` is NULL and, crucially, call `kref_put` again. Wait a minute... `vub300_disconnect` *doesn't* delete the timer; it just nulls out the interface and calls `kref_put`.
The timer, if still running, could trigger `kref_put` again. If *this* is the last reference, the dreaded `vub300_delete` gets called. Here's where it gets interesting: `vub300_disconnect` already called `kref_put`, so the timer's `kref_put` could very well be the one that drops the *last* reference. And the timer runs in softirq context. This means `vub300_delete` would be called from softirq. And *that* function calls `mmc_free_host`, which... sleeps!
This immediately raises red flags. A sleep in atomic context is usually a big, fat warning. It can lead to deadlocks if the sleeping function is waiting for something that requires the CPU to be yielded. But we're in softirq context, so perhaps it's "okay"?
Let me see, `cancel_delayed_work_sync` blocks until the work is finished. If the work is running on the same CPU, it *will* deadlock. But `cancel_delayed_work_sync` checks if the work is running. Ah... `cancel_delayed_work_sync` can be called from softirq... it explicitly calls `__might_sleep`. So, if it blocks, it will call `schedule()`. Okay, if it calls `schedule()` *in softirq*, it will just schedule another task. The softirq will be preempted. This is bad, but is this a security vulnerability? It could at least be a denial of service (DoS) and potentially a deadlock, right?
Wait, if `schedule()` is called from softirq, it can corrupt the softirq state or cause a panic if `panic_on_warn` is set. Okay, let's assume a production build without `panic_on_warn`. In that case, `schedule()` in softirq will just print a warning and then schedule. But, the question remains if there is any memory corruption.
Let's look for a use-after-free. In `vub300_disconnect`, the sequence is:
```c
vub300->interface = NULL;
mmc_remove_host(mmc);
kref_put(&vub300->kref, vub300_delete);
```
If the timer fires *after* the `kref_put` in `vub300_disconnect`, the code *could* access `vub300` *after* it's been freed! And yes, the timer is part of `vub300`. If `vub300_disconnect` drops the last reference, `vub300_delete` is called, which frees `vub300`. Then the timer fires, but the memory for the timer (which *is inside* `vub300`) has been freed! **This looks like a classic use-after-free.** We need to verify the timer's reference to `vub300`.
|
| 19/2 |
2026/08/15 01:38 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:mod_timer SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__do_poll SourceFile:drivers/mmc/host/vub300.c SourceLine:659] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__ext4_fill_super SourceFile:fs/ext4/super.c SourceLine:5730] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__ieee80211_sta_join_ibss SourceFile:net/mac80211/ibss.c SourceLine:366] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__ieee80211_start_rx_ba_session SourceFile:net/mac80211/agg-rx.c SourceLine:455] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__ieee80211_tx_status SourceFile:net/mac80211/status.c SourceLine:1125] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__inet_twsk_schedule SourceFile:net/ipv4/inet_timewait_sock.c SourceLine:297] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__start_timer SourceFile:arch/x86/kernel/cpu/mce/core.c SourceLine:1748] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__vector_cleanup SourceFile:arch/x86/kernel/apic/vector.c SourceLine:1079] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__xfrm_state_insert SourceFile:net/xfrm/xfrm_state.c SourceLine:1763] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8723be_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c SourceLine:200] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8723be_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c SourceLine:219] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8723be_set_fw_clock_on SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c SourceLine:162] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8821ae_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c SourceLine:198] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8821ae_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c SourceLine:218] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl8821ae_set_fw_clock_on SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c SourceLine:159] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl88ee_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c SourceLine:197] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl88ee_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c SourceLine:217] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl88ee_set_fw_clock_on SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c SourceLine:156] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl92ee_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c SourceLine:172] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl92ee_set_fw_clock_off SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c SourceLine:191] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_rtl92ee_set_fw_clock_on SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c SourceLine:132] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:activate_control_endpoints SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1885] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:activate_control_endpoints SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1889] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:addrconf_mod_rs_timer SourceFile:net/ipv6/addrconf.c SourceLine:332] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:aggr_process_recv_frm SourceFile:drivers/net/wireless/ath/ath6kl/txrx.c SourceLine:1221] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:aggr_timeout SourceFile:drivers/net/wireless/ath/ath6kl/txrx.c SourceLine:1669] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ahci_sw_activity SourceFile:drivers/ata/libahci.c SourceLine:1029] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ahci_sw_activity_blink SourceFile:drivers/ata/libahci.c SourceLine:1065] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:alps_handle_interleaved_ps2 SourceFile:drivers/input/mouse/alps.c SourceLine:1518] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:apple_battery_timer_tick SourceFile:drivers/hid/hid-apple.c SourceLine:654] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:apple_probe SourceFile:drivers/hid/hid-apple.c SourceLine:972] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:appleir_raw_event SourceFile:drivers/hid/hid-appleir.c SourceLine:225] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:appleir_raw_event SourceFile:drivers/hid/hid-appleir.c SourceLine:245] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ar5523_cmd_rx_cb SourceFile:drivers/net/wireless/ath/ar5523/ar5523.c SourceLine:141] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ar5523_tx_work_locked SourceFile:drivers/net/wireless/ath/ar5523/ar5523.c SourceLine:873] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:at76_ledtrig_tx_activity SourceFile:drivers/net/wireless/atmel/at76c50x-usb.c SourceLine:536] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:at76_ledtrig_tx_timerfunc SourceFile:drivers/net/wireless/atmel/at76c50x-usb.c SourceLine:527] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath10k_htt_rx_msdu_buff_replenish SourceFile:drivers/net/wireless/ath/ath10k/htt_rx.c SourceLine:251] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath10k_htt_rx_msdu_buff_replenish SourceFile:drivers/net/wireless/ath/ath10k/htt_rx.c SourceLine:254] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_cfg80211_connect SourceFile:drivers/net/wireless/ath/ath6kl/cfg80211.c SourceLine:669] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_recovery_hb_timer SourceFile:drivers/net/wireless/ath/ath6kl/recovery.c SourceLine:94] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_recovery_init SourceFile:drivers/net/wireless/ath/ath6kl/recovery.c SourceLine:111] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_recovery_resume SourceFile:drivers/net/wireless/ath/ath6kl/recovery.c SourceLine:157] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_recovery_work SourceFile:drivers/net/wireless/ath/ath6kl/recovery.c SourceLine:38] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath6kl_wmi_bssinfo_event_rx SourceFile:drivers/net/wireless/ath/ath6kl/wmi.c SourceLine:1182] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_btcoex_timer_resume SourceFile:drivers/net/wireless/ath/ath9k/gpio.c SourceLine:316] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_htc_reset SourceFile:drivers/net/wireless/ath/ath9k/htc_drv_main.c SourceLine:233] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_htc_set_channel SourceFile:drivers/net/wireless/ath/ath9k/htc_drv_main.c SourceLine:311] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_htc_start SourceFile:drivers/net/wireless/ath/ath9k/htc_drv_main.c SourceLine:966] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_htc_tx_cleanup_timer SourceFile:drivers/net/wireless/ath/ath9k/htc_drv_txrx.c SourceLine:805] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath9k_ps_restore SourceFile:drivers/net/wireless/ath/ath9k/main.c SourceLine:157] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath_ani_calibrate SourceFile:drivers/net/wireless/ath/ath9k/link.c SourceLine:437] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath_btcoex_period_timer SourceFile:drivers/net/wireless/ath/ath9k/gpio.c SourceLine:241] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath_btcoex_period_timer SourceFile:drivers/net/wireless/ath/ath9k/gpio.c SourceLine:247] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ath_start_ani SourceFile:drivers/net/wireless/ath/ath9k/link.c SourceLine:466] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_isoc_copy SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:576] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_isoc_copy SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:579] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_start_analog_streaming SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:836] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_start_analog_streaming SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:839] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_v4l2_resume SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:1735] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_v4l2_resume SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:1737] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_vbi_buffer_timeout SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:992] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:au0828_vid_buffer_timeout SourceFile:drivers/media/usb/au0828/au0828-video.c SourceLine:968] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:blk_add_timer SourceFile:block/blk-timeout.c SourceLine:164] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:blk_mq_timeout_work SourceFile:block/blk-mq.c SourceLine:1746] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:blk_stat_activate_msecs SourceFile:block/blk-stat.h SourceLine:170] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:blk_stat_activate_nsecs SourceFile:block/blk-stat.h SourceLine:151] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:blkcg_iolatency_throttle SourceFile:block/blk-iolatency.c SourceLine:485] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:brcmf_btcoex_handler SourceFile:drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c SourceLine:304] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:brcmf_btcoex_handler SourceFile:drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c SourceLine:307] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:brcmf_btcoex_handler SourceFile:drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c SourceLine:325] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:brcmf_cfg80211_scan SourceFile:drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c SourceLine:1586] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:buffer_activate SourceFile:drivers/media/pci/saa7134/saa7134-ts.c SourceLine:59] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:buffer_activate SourceFile:drivers/media/pci/saa7134/saa7134-vbi.c SourceLine:100] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:buffer_activate SourceFile:drivers/media/pci/saa7134/saa7134-video.c SourceLine:711] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:byd_process_byte SourceFile:drivers/input/mouse/byd.c SourceLine:330] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:call_rcu_tasks_generic SourceFile:kernel/rcu/tasks.h SourceLine:381] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:call_rcu_tasks_generic_timer SourceFile:kernel/rcu/tasks.h SourceLine:324] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:can_pernet_init SourceFile:net/can/af_can.c SourceLine:816] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:can_stat_update SourceFile:net/can/proc.c SourceLine:181] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:catc_open SourceFile:drivers/net/usb/catc.c SourceLine:732] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:catc_stats_timer SourceFile:drivers/net/usb/catc.c SourceLine:615] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:compliance_mode_recovery SourceFile:drivers/usb/host/xhci.c SourceLine:399] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:con_init SourceFile:drivers/tty/vt/vt.c SourceLine:3879] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:cxacru_start_wait_urb SourceFile:drivers/usb/atm/cxacru.c SourceLine:598] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dev_watchdog SourceFile:net/sched/sch_generic.c SourceLine:572] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:do_blank_screen SourceFile:drivers/tty/vt/vt.c SourceLine:4715] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:do_unblank_screen SourceFile:drivers/tty/vt/vt.c SourceLine:4751] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_vblank_put SourceFile:drivers/gpu/drm/drm_vblank.c SourceLine:1281] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dummy_wakeup SourceFile:drivers/usb/gadget/udc/dummy_hcd.c SourceLine:897] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dwc2_deschedule_periodic SourceFile:drivers/usb/dwc2/hcd_queue.c SourceLine:1373] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dwc2_handle_wakeup_detected_intr SourceFile:drivers/usb/dwc2/core_intr.c SourceLine:480] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dwc2_host_exit_clock_gating SourceFile:drivers/usb/dwc2/hcd.c SourceLine:5994] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dwc2_host_exit_partial_power_down SourceFile:drivers/usb/dwc2/hcd.c SourceLine:5901] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_intr SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:1873] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_intr_msi SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:1794] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_msix_other SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:1917] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_watchdog_task SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:5345] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_watchdog_task SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:5357] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e1000_watchdog_task SourceFile:drivers/net/ethernet/intel/e1000e/netdev.c SourceLine:5453] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e100_io_resume SourceFile:drivers/net/ethernet/intel/e100.c SourceLine:3158] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e100_up SourceFile:drivers/net/ethernet/intel/e100.c SourceLine:2287] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:e100_watchdog SourceFile:drivers/net/ethernet/intel/e100.c SourceLine:1733] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ehci_hub_control SourceFile:drivers/usb/host/ehci-hub.c SourceLine:916] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ehci_hub_status_data SourceFile:drivers/usb/host/ehci-hub.c SourceLine:689] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ehci_irq SourceFile:drivers/usb/host/ehci-hcd.c SourceLine:835] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:err_report_sec_store SourceFile:fs/ext4/sysfs.c SourceLine:158] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:est_timer SourceFile:net/core/gen_estimator.c SourceLine:109] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ethtool_mmsv_verify_timer SourceFile:net/ethtool/mm.c SourceLine:347] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ethtool_mmsv_verify_timer_arm SourceFile:net/ethtool/mm.c SourceLine:360] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ext4_update_super SourceFile:fs/ext4/super.c SourceLine:6287] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fib6_force_start_gc SourceFile:net/ipv6/ip6_fib.c SourceLine:1393] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fib6_run_gc SourceFile:net/ipv6/ip6_fib.c SourceLine:2436] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fib6_run_gc SourceFile:net/ipv6/ip6_fib.c SourceLine:2448] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fib6_start_gc SourceFile:net/ipv6/ip6_fib.c SourceLine:1386] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fl_release SourceFile:net/ipv6/ip6_flowlabel.c SourceLine:138] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:garmin_flush_queue SourceFile:drivers/usb/serial/garmin_gps.c SourceLine:1301] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gen_new_estimator SourceFile:net/core/gen_estimator.c SourceLine:189] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:get_periodic_rssi SourceFile:drivers/net/wireless/microchip/wilc1000/hif.c SourceLine:1516] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ghl_magic_poke_cb SourceFile:drivers/hid/hid-sony.c SourceLine:591] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gud_usb_bulk SourceFile:drivers/gpu/drm/gud/gud_pipe.c SourceLine:257] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gve_queues_start SourceFile:drivers/net/ethernet/google/gve/gve_main.c SourceLine:1452] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gve_rx_post_buffers_dqo SourceFile:drivers/net/ethernet/google/gve/gve_rx_dqo.c SourceLine:434] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gve_set_priv_flags SourceFile:drivers/net/ethernet/google/gve/gve_ethtool.c SourceLine:726] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gve_stats_report_timer SourceFile:drivers/net/ethernet/google/gve/gve_main.c SourceLine:276] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:handle_port_status SourceFile:drivers/usb/host/xhci-ring.c SourceLine:2087] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hdm_request_netinfo SourceFile:drivers/most/most_usb.c SourceLine:658] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hid_io_error SourceFile:drivers/hid/usbhid/hid-core.c SourceLine:180] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hidp_set_timer SourceFile:net/bluetooth/hidp/core.c SourceLine:440] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hub_resubmit_irq_urb SourceFile:drivers/usb/core/hub.c SourceLine:694] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_sw_fence_await_dma_fence SourceFile:drivers/gpu/drm/i915/i915_sw_fence.c SourceLine:527] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:idle_cull_fn SourceFile:kernel/workqueue.c SourceLine:3030] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:idle_worker_timeout SourceFile:kernel/workqueue.c SourceLine:2989] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_dynamic_ps_enable_work SourceFile:net/mac80211/mlme.c SourceLine:3925] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_dynamic_ps_enable_work SourceFile:net/mac80211/mlme.c SourceLine:3941] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_dynamic_ps_enable_work SourceFile:net/mac80211/mlme.c SourceLine:3953] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_enable_ps SourceFile:net/mac80211/mlme.c SourceLine:3761] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_handle_filtered_frame SourceFile:net/mac80211/status.c SourceLine:151] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_ocb_housekeeping SourceFile:net/mac80211/ocb.c SourceLine:121] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_offchannel_ps_disable SourceFile:net/mac80211/offchannel.c SourceLine:75] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_process_addba_resp SourceFile:net/mac80211/agg-tx.c SourceLine:1060] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_reconfig SourceFile:net/mac80211/util.c SourceLine:2384] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_reset_ap_probe SourceFile:net/mac80211/mlme.c SourceLine:4791] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_rx_h_ctrl SourceFile:net/mac80211/rx.c SourceLine:3416] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_rx_h_data SourceFile:net/mac80211/rx.c SourceLine:3360] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_send_addba_with_timeout SourceFile:net/mac80211/agg-tx.c SourceLine:460] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_conn_mon_timer SourceFile:net/mac80211/mlme.c SourceLine:9296] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_find_ibss SourceFile:net/mac80211/ibss.c SourceLine:1448] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_merge_ibss SourceFile:net/mac80211/ibss.c SourceLine:1234] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_reorder_release SourceFile:net/mac80211/rx.c SourceLine:1333] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_reset_beacon_monitor SourceFile:net/mac80211/mlme.c SourceLine:126] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_sta_reset_conn_monitor SourceFile:net/mac80211/mlme.c SourceLine:143] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_start_tpt_led_trig SourceFile:net/mac80211/led.c SourceLine:335] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_tx_h_dynamic_ps SourceFile:net/mac80211/tx.c SourceLine:263] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ieee80211_tx_h_unicast_ps_buf SourceFile:net/mac80211/tx.c SourceLine:516] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:if_usb_receive_fwload SourceFile:drivers/net/wireless/marvell/libertas/if_usb.c SourceLine:594] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:if_usb_receive_fwload SourceFile:drivers/net/wireless/marvell/libertas_tf/if_usb.c SourceLine:557] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:igmp_gq_start_timer SourceFile:net/ipv4/igmp.c SourceLine:257] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:igmp_ifc_start_timer SourceFile:net/ipv4/igmp.c SourceLine:267] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:igmp_start_timer SourceFile:net/ipv4/igmp.c SourceLine:241] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:igorplugusb_callback SourceFile:drivers/media/rc/igorplugusb.c SourceLine:107] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:imon_touch_event SourceFile:drivers/media/rc/imon.c SourceLine:1389] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:inet_frag_create SourceFile:net/ipv4/inet_fragment.c SourceLine:410] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:input_repeat_key SourceFile:drivers/input/input.c SourceLine:2251] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:input_start_autorepeat SourceFile:drivers/input/input.c SourceLine:93] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_wakeref_auto SourceFile:drivers/gpu/drm/i915/intel_wakeref.c SourceLine:193] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:io_watchdog_func SourceFile:drivers/usb/host/ohci-hcd.c SourceLine:865] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ip6_fl_gc SourceFile:net/ipv6/ip6_flowlabel.c SourceLine:179] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ipmr_cache_unresolved SourceFile:net/ipv4/ipmr.c SourceLine:1190] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ipmr_expire_process SourceFile:net/ipv4/ipmr.c SourceLine:796] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ipmr_expire_process SourceFile:net/ipv4/ipmr.c SourceLine:820] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ir_do_keydown SourceFile:drivers/media/rc/rc-main.c SourceLine:831] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ir_raw_edge_handle SourceFile:drivers/media/rc/rc-ir-raw.c SourceLine:571] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ir_raw_event_store_with_timeout SourceFile:drivers/media/rc/rc-ir-raw.c SourceLine:146] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ir_timer_repeat SourceFile:drivers/media/rc/rc-main.c SourceLine:715] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:isp116x_irq SourceFile:drivers/usb/host/isp116x-hcd.c SourceLine:623] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:isp1760_hub_control SourceFile:drivers/usb/isp1760/isp1760-hcd.c SourceLine:2306] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:isp1760_udc_connect SourceFile:drivers/usb/isp1760/isp1760-udc.c SourceLine:1130] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:isp1760_udc_vbus_poll SourceFile:drivers/usb/isp1760/isp1760-udc.c SourceLine:1434] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:kd_mksound SourceFile:drivers/tty/vt/keyboard.c SourceLine:284] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:key_schedule_gc SourceFile:security/keys/gc.c SourceLine:65] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lan78xx_bh SourceFile:drivers/net/usb/lan78xx.c SourceLine:4387] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lan78xx_delayedwork SourceFile:drivers/net/usb/lan78xx.c SourceLine:4510] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lan78xx_resume SourceFile:drivers/net/usb/lan78xx.c SourceLine:5320] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lbs_submit_command SourceFile:drivers/net/wireless/marvell/libertas/cmd.c SourceLine:910] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lbs_thread SourceFile:drivers/net/wireless/marvell/libertas/main.c SourceLine:580] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lbtf_submit_command SourceFile:drivers/net/wireless/marvell/libertas_tf/cmd.c SourceLine:266] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:led_set_software_blink SourceFile:drivers/leds/led-core.c SourceLine:217] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:led_timer_function SourceFile:drivers/leds/led-core.c SourceLine:120] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:letsketch_raw_event SourceFile:drivers/hid/hid-letsketch.c SourceLine:194] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:magicmouse_battery_timer_tick SourceFile:drivers/hid/hid-magicmouse.c SourceLine:866] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:magicmouse_probe SourceFile:drivers/hid/hid-magicmouse.c SourceLine:906] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:maybe_create_worker SourceFile:kernel/workqueue.c SourceLine:3118] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mctp_sk_expire_keys SourceFile:net/mctp/af_mctp.c SourceLine:690] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:md_write_end SourceFile:drivers/md/md.c SourceLine:9340] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ml_schedule_timer SourceFile:drivers/input/ff-memless.c SourceLine:143] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mmc_retune_enable SourceFile:drivers/mmc/core/host.c SourceLine:108] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mos7840_led_activity SourceFile:drivers/usb/serial/mos7840.c SourceLine:408] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mos7840_led_off SourceFile:drivers/usb/serial/mos7840.c SourceLine:389] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt7615_mcu_roc_event SourceFile:drivers/net/wireless/mediatek/mt76/mt7615/mcu.c SourceLine:489] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt7921_channel_switch_rx_beacon SourceFile:drivers/net/wireless/mediatek/mt76/mt7921/main.c SourceLine:1531] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt7921_mcu_uni_roc_event SourceFile:drivers/net/wireless/mediatek/mt76/mt7921/mcu.c SourceLine:158] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt7925_channel_switch_rx_beacon SourceFile:drivers/net/wireless/mediatek/mt76/mt7925/main.c SourceLine:2482] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt7925_mcu_roc_handle_grant SourceFile:drivers/net/wireless/mediatek/mt76/mt7925/mcu.c SourceLine:337] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mt_touch_report SourceFile:drivers/hid/hid-multitouch.c SourceLine:1387] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:musb_handle_intr_reset SourceFile:drivers/usb/musb/musb_core.c SourceLine:1014] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:musb_handle_intr_suspend SourceFile:drivers/usb/musb/musb_core.c SourceLine:860] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:musb_port_suspend SourceFile:drivers/usb/musb/musb_virthub.c SourceLine:93] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_11n_rxreorder_timer_restart SourceFile:drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c SourceLine:419] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_check_auto_tdls SourceFile:drivers/net/wireless/marvell/mwifiex/tdls.c SourceLine:1472] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_dnld_cmd_to_fw SourceFile:drivers/net/wireless/marvell/mwifiex/cmdevt.c SourceLine:280] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_main_process SourceFile:drivers/net/wireless/marvell/mwifiex/main.c SourceLine:303] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_setup_auto_tdls_timer SourceFile:drivers/net/wireless/marvell/mwifiex/tdls.c SourceLine:1480] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_usb_aggr_tx_data SourceFile:drivers/net/wireless/marvell/mwifiex/usb.c SourceLine:1046] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_usb_aggr_tx_data SourceFile:drivers/net/wireless/marvell/mwifiex/usb.c SourceLine:1055] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mwifiex_usb_aggr_tx_data SourceFile:drivers/net/wireless/marvell/mwifiex/usb.c SourceLine:1110] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nci_cmd_work SourceFile:net/nfc/nci/core.c SourceLine:1635] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nci_tx_work SourceFile:net/nfc/nci/core.c SourceLine:1551] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:neigh_add_timer SourceFile:net/core/neighbour.c SourceLine:312] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:neigh_proxy_process SourceFile:net/core/neighbour.c SourceLine:1704] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:neigh_timer_handler SourceFile:net/core/neighbour.c SourceLine:1184] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:netdev_watchdog_up SourceFile:net/sched/sch_generic.c SourceLine:599] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:netif_rx_mode_schedule_retry SourceFile:net/core/dev_addr_lists.c SourceLine:1263] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_activate_target SourceFile:net/nfc/core.c SourceLine:426] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_check_pres_work SourceFile:net/nfc/core.c SourceLine:1003] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_data_exchange SourceFile:net/nfc/core.c SourceLine:518] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_llcp_mac_is_up SourceFile:net/nfc/llcp_core.c SourceLine:1626] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_llcp_sdreq_timeout_work SourceFile:net/nfc/llcp_core.c SourceLine:279] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_llcp_send_snl_sdreq SourceFile:net/nfc/llcp_commands.c SourceLine:593] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_llcp_tx_work SourceFile:net/nfc/llcp_core.c SourceLine:814] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfcmrvl_fw_dnld_start SourceFile:drivers/nfc/nfcmrvl/fw_dnld.c SourceLine:532] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_retry_blocked SourceFile:fs/lockd/svclock.c SourceLine:1073] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:note_interrupt SourceFile:kernel/irq/spurious.c SourceLine:377] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_change_mtu SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3116] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_do_nic_poll SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:4198] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_do_stats_poll SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:4273] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_napi_poll SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3795] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_napi_poll SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3817] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_nic_irq_other SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3920] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_nic_irq_other SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3933] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_nic_irq_rx SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3854] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_nic_irq_rx SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3867] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_nic_irq_tx SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:3750] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_open SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:5593] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_open SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:5597] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_self_test SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:5310] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nv_set_ringparam SourceFile:drivers/net/ethernet/nvidia/forcedeth.c SourceLine:4756] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ohci_urb_enqueue SourceFile:drivers/usb/host/ohci-hcd.c SourceLine:238] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:oxu210_hcd_irq SourceFile:drivers/usb/host/oxu210hp-hcd.c SourceLine:2902] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:oxu_hub_control SourceFile:drivers/usb/host/oxu210hp-hcd.c SourceLine:3657] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:parport_wait_event SourceFile:drivers/parport/ieee1284.c SourceLine:74] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pcan_usb_restart_pending SourceFile:drivers/net/can/usb/peak_usb/pcan_usb.c SourceLine:337] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pcmidi_handle_report3 SourceFile:drivers/hid/hid-prodikeys.c SourceLine:357] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:perform_sglist SourceFile:drivers/usb/misc/usbtest.c SourceLine:626] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:phylink_fixed_poll SourceFile:drivers/net/phy/phylink.c SourceLine:1761] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:phylink_pcs_poll_start SourceFile:drivers/net/phy/phylink.c SourceLine:983] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:phylink_start SourceFile:drivers/net/phy/phylink.c SourceLine:2481] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pm_wakeup_ws_event SourceFile:drivers/base/power/wakeup.c SourceLine:807] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pn533_start_poll SourceFile:drivers/nfc/pn533/pn533.c SourceLine:1739] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pn533_wq_poll SourceFile:drivers/nfc/pn533/pn533.c SourceLine:1621] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pneigh_enqueue SourceFile:net/core/neighbour.c SourceLine:1741] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:poke_blanked_console SourceFile:drivers/tty/vt/vt.c SourceLine:4813] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:poll_spurious_irqs SourceFile:kernel/irq/spurious.c SourceLine:132] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pool_mayday_timeout SourceFile:kernel/workqueue.c SourceLine:3089] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:prepare_uretprobe SourceFile:kernel/events/uprobes.c SourceLine:2310] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:print_daily_error_info SourceFile:fs/ext4/super.c SourceLine:3731] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:queue_iova SourceFile:drivers/iommu/dma-iommu.c SourceLine:246] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:quirk_poll_init SourceFile:drivers/usb/host/ehci-platform.c SourceLine:223] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:quirk_poll_timer SourceFile:drivers/usb/host/ehci-platform.c SourceLine:216] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_hub_control SourceFile:drivers/usb/host/r8a66597-hcd.c SourceLine:2223] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_irq SourceFile:drivers/usb/gadget/udc/r8a66597-udc.c SourceLine:1494] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_root_hub_start_polling SourceFile:drivers/usb/host/r8a66597-hcd.c SourceLine:989] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_start SourceFile:drivers/usb/gadget/udc/r8a66597-udc.c SourceLine:1745] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_timer SourceFile:drivers/usb/gadget/udc/r8a66597-udc.c SourceLine:1535] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_timer SourceFile:drivers/usb/gadget/udc/r8a66597-udc.c SourceLine:1541] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:r8a66597_urb_enqueue SourceFile:drivers/usb/host/r8a66597-hcd.c SourceLine:1931] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rc_keydown SourceFile:drivers/media/rc/rc-main.c SourceLine:861] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rc_repeat SourceFile:drivers/media/rc/rc-main.c SourceLine:762] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:remain_on_channel SourceFile:drivers/net/wireless/microchip/wilc1000/cfg80211.c SourceLine:1134] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:reqsk_queue_hash_req SourceFile:net/ipv4/inet_connection_sock.c SourceLine:1163] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:reqsk_timer_handler SourceFile:net/ipv4/inet_connection_sock.c SourceLine:1113] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rh_queue_status SourceFile:drivers/usb/core/hcd.c SourceLine:800] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rh_queue_status SourceFile:drivers/usb/core/hcd.c SourceLine:804] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rps_start_timer SourceFile:drivers/gpu/drm/i915/gt/intel_rps.c SourceLine:164] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rps_timer SourceFile:drivers/gpu/drm/i915/gt/intel_rps.c SourceLine:154] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rtl88e_dm_fast_ant_training SourceFile:drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c SourceLine:1679] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rtl_watch_dog_timer_callback SourceFile:drivers/net/wireless/realtek/rtlwifi/base.c SourceLine:2232] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rts51x_modi_suspend_timer SourceFile:drivers/usb/storage/realtek_cr.c SourceLine:752] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rtw_tx_report_enqueue SourceFile:drivers/net/wireless/realtek/rtw88/tx.c SourceLine:215] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:run_again SourceFile:net/mac80211/mlme.c SourceLine:115] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:rx_complete SourceFile:drivers/net/usb/usbnet.c SourceLine:640] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:s2255_fwload_start SourceFile:drivers/media/usb/s2255/s2255drv.c SourceLine:2194] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:safe_delay_store SourceFile:drivers/md/md.c SourceLine:4018] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:serial8250_backup_timeout SourceFile:drivers/tty/serial/8250/8250_core.c SourceLine:260] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:serial8250_timeout SourceFile:drivers/tty/serial/8250/8250_core.c SourceLine:214] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:set_td_timer SourceFile:drivers/usb/host/r8a66597-hcd.c SourceLine:1261] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:set_timer_ms SourceFile:drivers/gpu/drm/i915/i915_timer_util.c SourceLine:35] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sk_reset_timer SourceFile:net/core/sock.c SourceLine:3724] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sky2_link_up SourceFile:drivers/net/ethernet/marvell/sky2.c SourceLine:2190] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sky2_watchdog SourceFile:drivers/net/ethernet/marvell/sky2.c SourceLine:2989] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sl811h_hub_control SourceFile:drivers/usb/host/sl811-hcd.c SourceLine:1265] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sl811h_hub_control SourceFile:drivers/usb/host/sl811-hcd.c SourceLine:1328] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:slif_data_plane_sap_timer_callb SourceFile:drivers/net/wireless/purelifi/plfxlc/usb.c SourceLine:556] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:snd_timer_s_start SourceFile:sound/core/timer.c SourceLine:1236] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:snd_usbmidi_in_urb_complete SourceFile:sound/usb/midi.c SourceLine:252] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:snd_usbmidi_out_urb_complete SourceFile:sound/usb/midi.c SourceLine:281] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sony_probe SourceFile:drivers/hid/hid-sony.c SourceLine:2409] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:speedtch_atm_start SourceFile:drivers/usb/atm/speedtch.c SourceLine:682] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:speedtch_handle_int SourceFile:drivers/usb/atm/speedtch.c SourceLine:647] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:speedtch_resubmit_int SourceFile:drivers/usb/atm/speedtch.c SourceLine:592] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:speedtch_status_poll SourceFile:drivers/usb/atm/speedtch.c SourceLine:571] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sta_info_cleanup SourceFile:net/mac80211/sta_info.c SourceLine:1672] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sta_queue_cleanup_timer_callb SourceFile:drivers/net/wireless/purelifi/plfxlc/usb.c SourceLine:577] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sta_rx_agg_session_timer_expired SourceFile:net/mac80211/agg-rx.c SourceLine:153] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sta_tx_agg_session_timer_expired SourceFile:net/mac80211/agg-tx.c SourceLine:593] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:start_urb_transfer SourceFile:drivers/media/usb/au0828/au0828-dvb.c SourceLine:248] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:svc_add_new_temp_xprt SourceFile:net/sunrpc/svc_xprt.c SourceLine:825] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:svc_age_temp_xprts SourceFile:net/sunrpc/svc_xprt.c SourceLine:1029] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:svc_age_temp_xprts SourceFile:net/sunrpc/svc_xprt.c SourceLine:1052] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tcp_init SourceFile:net/ipv4/tcp.c SourceLine:5298] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tcp_orphan_update SourceFile:net/ipv4/tcp.c SourceLine:3105] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:thunderstrike_psy_stats_timer_handler SourceFile:drivers/hid/hid-nvidia-shield.c SourceLine:540] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:timer_action SourceFile:drivers/usb/host/oxu210hp-hcd.c SourceLine:703] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tpt_trig_timer SourceFile:net/mac80211/led.c SourceLine:269] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tx_complete SourceFile:drivers/net/usb/usbnet.c SourceLine:1329] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uclogic_raw_event_pen SourceFile:drivers/hid/hid-uclogic-core.c SourceLine:387] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:udc_basic_init SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1466] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:udc_basic_init SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1470] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:udc_queue SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1140] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:udc_set_rde SourceFile:drivers/usb/gadget/udc/snps_udc_core.c SourceLine:1038] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uhci_check_ports SourceFile:drivers/usb/host/uhci-hub.c SourceLine:176] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uhci_irq SourceFile:drivers/usb/host/uhci-hcd.c SourceLine:491] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uhci_scan_schedule SourceFile:drivers/usb/host/uhci-q.c SourceLine:1786] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uhci_set_next_interrupt SourceFile:drivers/usb/host/uhci-q.c SourceLine:32] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:univ8250_setup_timer SourceFile:drivers/tty/serial/8250/8250_core.c SourceLine:276] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:univ8250_setup_timer SourceFile:drivers/tty/serial/8250/8250_core.c SourceLine:286] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_bus_start_enum SourceFile:drivers/usb/core/hcd.c SourceLine:2448] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_hcd_poll_rh_status SourceFile:drivers/usb/core/hcd.c SourceLine:766] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usbatm_complete SourceFile:drivers/usb/atm/usbatm.c SourceLine:270] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usbatm_submit_urb SourceFile:drivers/usb/atm/usbatm.c SourceLine:237] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:v_kick_timer SourceFile:drivers/usb/usbip/vudc_transfer.c SourceLine:485] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:v_timer SourceFile:drivers/usb/usbip/vudc_transfer.c SourceLine:438] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_deadwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:737] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:749] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:752] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1940] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_pollwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:698] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wacom_wac_pen_event SourceFile:drivers/hid/wacom_wac.c SourceLine:2430] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wakeup_rh SourceFile:drivers/usb/host/uhci-hcd.c SourceLine:447] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wb_domain_writeout_add SourceFile:mm/page-writeback.c SourceLine:565] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wiimote_init_detect SourceFile:drivers/hid/hid-wiimote-core.c SourceLine:903] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wiimote_init_hotplug SourceFile:drivers/hid/hid-wiimote-core.c SourceLine:1179] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wiimote_init_poll_mp SourceFile:drivers/hid/hid-wiimote-core.c SourceLine:933] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wilc_init SourceFile:drivers/net/wireless/microchip/wilc1000/hif.c SourceLine:1533] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wilc_scan SourceFile:drivers/net/wireless/microchip/wilc1000/hif.c SourceLine:263] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wilc_set_join_req SourceFile:drivers/net/wireless/microchip/wilc1000/hif.c SourceLine:1344] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wiphy_delayed_work_queue SourceFile:net/wireless/core.c SourceLine:1947] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:worker_enter_idle SourceFile:kernel/workqueue.c SourceLine:1068] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wq_watchdog_set_thresh SourceFile:kernel/workqueue.c SourceLine:7882] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wq_watchdog_timer_fn SourceFile:kernel/workqueue.c SourceLine:7855] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:writeout_period SourceFile:mm/page-writeback.c SourceLine:610] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xdst_queue_output SourceFile:net/xfrm/xfrm_policy.c SourceLine:3011] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_policy_insert SourceFile:net/xfrm/xfrm_policy.c SourceLine:1609] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_policy_queue_process SourceFile:net/xfrm/xfrm_policy.c SourceLine:2930] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_policy_requeue SourceFile:net/xfrm/xfrm_policy.c SourceLine:1475] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_policy_timer SourceFile:net/xfrm/xfrm_policy.c SourceLine:412] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_replay_notify SourceFile:net/xfrm/xfrm_replay.c SourceLine:94] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_replay_notify_bmp SourceFile:net/xfrm/xfrm_replay.c SourceLine:352] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xfrm_replay_notify_esn SourceFile:net/xfrm/xfrm_replay.c SourceLine:418] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xhci_handle_usb2_port_link_resume SourceFile:drivers/usb/host/xhci-hub.c SourceLine:952] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xprt_schedule_autodisconnect SourceFile:net/sunrpc/xprt.c SourceLine:851] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:yenta_probe SourceFile:drivers/pcmcia/yenta_socket.c SourceLine:1252] map[ReferenceKind:takes-address-of ReferencingEntityKind:global_variable ReferencingEntityName:__UNIQUE_ID_addressable_mod_timer_1335 SourceFile:kernel/time/timer.c SourceLine:1197] map[ReferenceKind:takes-address-of ReferencingEntityKind:global_variable ReferencingEntityName:__gendwarfksyms_ptr_mod_timer SourceFile:kernel/time/timer.c SourceLine:1197] map[ReferenceKind:takes-address-of ReferencingEntityKind:global_variable ReferencingEntityName:__gendwarfksyms_ptr_mod_timer SourceFile:kernel/time/timer.c SourceLine:1197]] TruncatedOutput:false]
|
| 20/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 39099
output: 45
thoughts: 37
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience:
**Debugging Disconnect Logic**
Alright, a quick sanity check is in order. I was under the impression that the `vub300_disconnect` function handled the cleanup and timer de-allocation through a call to `del_timer_sync`. But, let me pause and confirm that assumption. There's a nagging feeling that something is amiss here. I need to revisit the `vub300_disconnect` code path itself and make absolutely sure I haven't missed a crucial detail, or that a refactoring didn't introduce a regression. Double-checking that specific function is the next logical step. I need to verify that the timer is, in fact, being handled correctly during disconnect, or I could be looking at potential resource leaks or race conditions. Let's delve back into `vub300_disconnect`.
|
| 21/2 |
2026/08/15 01:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_disconnect]
Results: map[SourceCode:2373: static void vub300_disconnect(struct usb_interface *interface)
2374: { /* NOT irq */
2375: struct vub300_mmc_host *vub300 = usb_get_intfdata(interface);
2376: if (!vub300 || !vub300->mmc) {
2377: return;
2378: } else {
2379: struct mmc_host *mmc = vub300->mmc;
2380: if (!vub300->mmc) {
2381: return;
2382: } else {
2383: int ifnum = interface_to_InterfaceNumber(interface);
2384: usb_set_intfdata(interface, NULL);
2385: /* prevent more I/O from starting */
2386: vub300->interface = NULL;
2387: mmc_remove_host(mmc);
2388: kref_put(&vub300->kref, vub300_delete);
2389: pr_info("USB vub300 remote SDIO host controller[%d]"
2390: " now disconnected", ifnum);
2391: return;
2392: }
2393: }
2394: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 22/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 39782
output: 45
thoughts: 35
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience:
**Missing Timer Synchronization - A Puzzling Absence**
Alright, let me get this straight. I'm looking at the cleanup path for this VUB300 device, and something's immediately jumping out at me. I'm not seeing the expected call to `del_timer_sync` anywhere in the cleanup sequence. Wait a second, this is odd. I thought I might have missed it in a brief skim, but even a deeper look at `vub300_delete` shows no sign of it either. That's...unusual, to say the least. It raises a major red flag in my mind. We're either missing a critical synchronization step during the device teardown, opening the door for resource leaks or potential race conditions, or there is something else that is happening which I do not immediately understand. Time to dig deeper and figure out where the timer synchronization is happening, or, far worse, why it is *not* happening. Let's see what's actually going on.
|
| 23/2 |
2026/08/15 01:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_delete]
Results: map[SourceCode: 369: static void vub300_delete(struct kref *kref)
370: { /* kref callback - softirq */
371: struct vub300_mmc_host *vub300 = kref_to_vub300_mmc_host(kref);
372: struct mmc_host *mmc = vub300->mmc;
373:
374: usb_free_urb(vub300->command_out_urb);
375: vub300->command_out_urb = NULL;
376: usb_free_urb(vub300->command_res_urb);
377: vub300->command_res_urb = NULL;
378: usb_put_dev(vub300->udev);
379: mmc_free_host(mmc);
380: /*
381: * and hence also frees vub300
382: * which is contained at the end of struct mmc
383: */
384: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 24/2 |
2026/08/15 01:38 |
llm |
expert |
0m
Model:
Tokens:
input: 40437
output: 45
thoughts: 217
Thoughts: **My Analysis of a Potential Use-After-Free Vulnerability**
Okay, so I'm looking at this `vub300_delete` function, and it's calling `mmc_free_host` to free `vub300`. That's standard enough, but the potential problem is the timer. If `vub300_delete` is called, and the timer is still pending, we've got a classic race condition.
Wait, let me think this through. If `vub300_delete` is called *from* the timer callback, the timer isn't pending; it's *running*. So that scenario is fine. But what about if `vub300_delete` gets called from `vub300_disconnect`? Ah, *that's* the likely culprit. If `vub300_disconnect` is the final reference release, then `vub300_delete` gets called to free `vub300` right away. Now, the timer *could* still be pending... and if it fires later, it'll try to access the memory that's already been freed! That's a textbook use-after-free vulnerability!
Right, I need to confirm that `vub300_disconnect` is responsible for dropping the last reference. I should check `vub300_probe` since that's where things are usually setup to track the reference counts.
|
| 25/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_probe]
Results: map[SourceCode:2092: static int vub300_probe(struct usb_interface *interface,
2093: const struct usb_device_id *id)
2094: { /* NOT irq */
2095: struct vub300_mmc_host *vub300;
2096: struct usb_host_interface *iface_desc;
2097: struct usb_device *udev = usb_get_dev(interface_to_usbdev(interface));
2098: int i;
2099: int retval = -ENOMEM;
2100: struct urb *command_out_urb;
2101: struct urb *command_res_urb;
2102: struct mmc_host *mmc;
2103: char manufacturer[48];
2104: char product[32];
2105: char serial_number[32];
2106: usb_string(udev, udev->descriptor.iManufacturer, manufacturer,
2107: sizeof(manufacturer));
2108: usb_string(udev, udev->descriptor.iProduct, product, sizeof(product));
2109: usb_string(udev, udev->descriptor.iSerialNumber, serial_number,
2110: sizeof(serial_number));
2111: dev_info(&udev->dev, "probing VID:PID(%04X:%04X) %s %s %s\n",
2112: le16_to_cpu(udev->descriptor.idVendor),
2113: le16_to_cpu(udev->descriptor.idProduct),
2114: manufacturer, product, serial_number);
2115: command_out_urb = usb_alloc_urb(0, GFP_KERNEL);
2116: if (!command_out_urb) {
2117: retval = -ENOMEM;
2118: goto err_put_udev;
2119: }
2120: command_res_urb = usb_alloc_urb(0, GFP_KERNEL);
2121: if (!command_res_urb) {
2122: retval = -ENOMEM;
2123: goto err_free_out_urb;
2124: }
2125: /* this also allocates memory for our VUB300 mmc host device */
2126: mmc = mmc_alloc_host(sizeof(*vub300), &udev->dev);
2127: if (!mmc) {
2128: retval = -ENOMEM;
2129: dev_err(&udev->dev, "not enough memory for the mmc_host\n");
2130: goto err_free_res_urb;
2131: }
2132: /* MMC core transfer sizes tunable parameters */
2133: mmc->caps = 0;
2134: if (!force_1_bit_data_xfers)
2135: mmc->caps |= MMC_CAP_4_BIT_DATA;
2136: if (!force_polling_for_irqs)
2137: mmc->caps |= MMC_CAP_SDIO_IRQ;
2138: mmc->caps &= ~MMC_CAP_NEEDS_POLL;
2139: /*
2140: * MMC_CAP_NEEDS_POLL causes core.c:mmc_rescan() to poll
2141: * for devices which results in spurious CMD7's being
2142: * issued which stops some SDIO cards from working
2143: */
2144: if (limit_speed_to_24_MHz) {
2145: mmc->caps |= MMC_CAP_MMC_HIGHSPEED;
2146: mmc->caps |= MMC_CAP_SD_HIGHSPEED;
2147: mmc->f_max = 24000000;
2148: dev_info(&udev->dev, "limiting SDIO speed to 24_MHz\n");
2149: } else {
2150: mmc->caps |= MMC_CAP_MMC_HIGHSPEED;
2151: mmc->caps |= MMC_CAP_SD_HIGHSPEED;
2152: mmc->f_max = 48000000;
2153: }
2154: mmc->f_min = 200000;
2155: mmc->max_blk_count = 511;
2156: mmc->max_blk_size = 512;
2157: mmc->max_segs = 128;
2158: if (force_max_req_size)
2159: mmc->max_req_size = force_max_req_size * 1024;
2160: else
2161: mmc->max_req_size = 64 * 1024;
2162: mmc->max_seg_size = mmc->max_req_size;
2163: mmc->ocr_avail = 0;
2164: mmc->ocr_avail |= MMC_VDD_165_195;
2165: mmc->ocr_avail |= MMC_VDD_20_21;
2166: mmc->ocr_avail |= MMC_VDD_21_22;
2167: mmc->ocr_avail |= MMC_VDD_22_23;
2168: mmc->ocr_avail |= MMC_VDD_23_24;
2169: mmc->ocr_avail |= MMC_VDD_24_25;
2170: mmc->ocr_avail |= MMC_VDD_25_26;
2171: mmc->ocr_avail |= MMC_VDD_26_27;
2172: mmc->ocr_avail |= MMC_VDD_27_28;
2173: mmc->ocr_avail |= MMC_VDD_28_29;
2174: mmc->ocr_avail |= MMC_VDD_29_30;
2175: mmc->ocr_avail |= MMC_VDD_30_31;
2176: mmc->ocr_avail |= MMC_VDD_31_32;
2177: mmc->ocr_avail |= MMC_VDD_32_33;
2178: mmc->ocr_avail |= MMC_VDD_33_34;
2179: mmc->ocr_avail |= MMC_VDD_34_35;
2180: mmc->ocr_avail |= MMC_VDD_35_36;
2181: mmc->ops = &vub300_mmc_ops;
2182: vub300 = mmc_priv(mmc);
2183: vub300->mmc = mmc;
2184: vub300->card_powered = 0;
2185: vub300->bus_width = 0;
2186: vub300->cmnd.head.block_size[0] = 0x00;
2187: vub300->cmnd.head.block_size[1] = 0x00;
2188: vub300->app_spec = 0;
2189: mutex_init(&vub300->cmd_mutex);
2190: mutex_init(&vub300->irq_mutex);
2191: vub300->command_out_urb = command_out_urb;
2192: vub300->command_res_urb = command_res_urb;
2193: vub300->usb_timed_out = 0;
2194: vub300->dynamic_register_count = 0;
2195:
2196: for (i = 0; i < ARRAY_SIZE(vub300->fn); i++) {
2197: vub300->fn[i].offload_point = 0;
2198: vub300->fn[i].offload_count = 0;
2199: }
2200:
2201: vub300->total_offload_count = 0;
2202: vub300->irq_enabled = 0;
2203: vub300->irq_disabled = 0;
2204: vub300->irqs_queued = 0;
2205:
2206: for (i = 0; i < ARRAY_SIZE(vub300->sdio_register); i++)
2207: vub300->sdio_register[i++].activate = 0;
2208:
2209: vub300->udev = udev;
2210: vub300->interface = interface;
2211: vub300->cmnd_res_ep = 0;
2212: vub300->cmnd_out_ep = 0;
2213: vub300->data_inp_ep = 0;
2214: vub300->data_out_ep = 0;
2215:
2216: for (i = 0; i < ARRAY_SIZE(vub300->fbs); i++)
2217: vub300->fbs[i] = 512;
2218:
2219: /*
2220: * set up the endpoint information
2221: *
2222: * use the first pair of bulk-in and bulk-out
2223: * endpoints for Command/Response+Interrupt
2224: *
2225: * use the second pair of bulk-in and bulk-out
2226: * endpoints for Data In/Out
2227: */
2228: vub300->large_usb_packets = 0;
2229: iface_desc = interface->cur_altsetting;
2230: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
2231: struct usb_endpoint_descriptor *endpoint =
2232: &iface_desc->endpoint[i].desc;
2233: dev_info(&vub300->udev->dev,
2234: "vub300 testing %s EndPoint(%d) %02X\n",
2235: usb_endpoint_is_bulk_in(endpoint) ? "BULK IN" :
2236: usb_endpoint_is_bulk_out(endpoint) ? "BULK OUT" :
2237: "UNKNOWN", i, endpoint->bEndpointAddress);
2238: if (endpoint->wMaxPacketSize > 64)
2239: vub300->large_usb_packets = 1;
2240: if (usb_endpoint_is_bulk_in(endpoint)) {
2241: if (!vub300->cmnd_res_ep) {
2242: vub300->cmnd_res_ep =
2243: endpoint->bEndpointAddress;
2244: } else if (!vub300->data_inp_ep) {
2245: vub300->data_inp_ep =
2246: endpoint->bEndpointAddress;
2247: } else {
2248: dev_warn(&vub300->udev->dev,
2249: "ignoring"
2250: " unexpected bulk_in endpoint");
2251: }
2252: } else if (usb_endpoint_is_bulk_out(endpoint)) {
2253: if (!vub300->cmnd_out_ep) {
2254: vub300->cmnd_out_ep =
2255: endpoint->bEndpointAddress;
2256: } else if (!vub300->data_out_ep) {
2257: vub300->data_out_ep =
2258: endpoint->bEndpointAddress;
2259: } else {
2260: dev_warn(&vub300->udev->dev,
2261: "ignoring"
2262: " unexpected bulk_out endpoint");
2263: }
2264: } else {
2265: dev_warn(&vub300->udev->dev,
2266: "vub300 ignoring EndPoint(%d) %02X", i,
2267: endpoint->bEndpointAddress);
2268: }
2269: }
2270: if (vub300->cmnd_res_ep && vub300->cmnd_out_ep &&
2271: vub300->data_inp_ep && vub300->data_out_ep) {
2272: dev_info(&vub300->udev->dev,
2273: "vub300 %s packets"
2274: " using EndPoints %02X %02X %02X %02X\n",
2275: vub300->large_usb_packets ? "LARGE" : "SMALL",
2276: vub300->cmnd_out_ep, vub300->cmnd_res_ep,
2277: vub300->data_out_ep, vub300->data_inp_ep);
2278: /* we have the expected EndPoints */
2279: } else {
2280: dev_err(&vub300->udev->dev,
2281: "Could not find two sets of bulk-in/out endpoint pairs\n");
2282: retval = -EINVAL;
2283: goto err_free_host;
2284: }
2285: retval =
2286: usb_control_msg(vub300->udev, usb_rcvctrlpipe(vub300->udev, 0),
2287: GET_HC_INF0,
2288: USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
2289: 0x0000, 0x0000, &vub300->hc_info,
2290: sizeof(vub300->hc_info), 1000);
2291: if (retval < 0)
2292: goto err_free_host;
2293: retval =
2294: usb_control_msg(vub300->udev, usb_sndctrlpipe(vub300->udev, 0),
2295: SET_ROM_WAIT_STATES,
2296: USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
2297: firmware_rom_wait_states, 0x0000, NULL, 0, 1000);
2298: if (retval < 0)
2299: goto err_free_host;
2300: dev_info(&vub300->udev->dev,
2301: "operating_mode = %s %s %d MHz %s %d byte USB packets\n",
2302: (mmc->caps & MMC_CAP_SDIO_IRQ) ? "IRQs" : "POLL",
2303: (mmc->caps & MMC_CAP_4_BIT_DATA) ? "4-bit" : "1-bit",
2304: mmc->f_max / 1000000,
2305: pad_input_to_usb_pkt ? "padding input data to" : "with",
2306: vub300->large_usb_packets ? 512 : 64);
2307: retval =
2308: usb_control_msg(vub300->udev, usb_rcvctrlpipe(vub300->udev, 0),
2309: GET_SYSTEM_PORT_STATUS,
2310: USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
2311: 0x0000, 0x0000, &vub300->system_port_status,
2312: sizeof(vub300->system_port_status), 1000);
2313: if (retval < 0) {
2314: goto err_free_host;
2315: } else if (sizeof(vub300->system_port_status) == retval) {
2316: vub300->card_present =
2317: (0x0001 & vub300->system_port_status.port_flags) ? 1 : 0;
2318: vub300->read_only =
2319: (0x0010 & vub300->system_port_status.port_flags) ? 1 : 0;
2320: } else {
2321: retval = -EINVAL;
2322: goto err_free_host;
2323: }
2324: usb_set_intfdata(interface, vub300);
2325: INIT_DELAYED_WORK(&vub300->pollwork, vub300_pollwork_thread);
2326: INIT_WORK(&vub300->cmndwork, vub300_cmndwork_thread);
2327: INIT_WORK(&vub300->deadwork, vub300_deadwork_thread);
2328: kref_init(&vub300->kref);
2329: timer_setup(&vub300->sg_transfer_timer, vub300_sg_timed_out, 0);
2330: kref_get(&vub300->kref);
2331: timer_setup(&vub300->inactivity_timer,
2332: vub300_inactivity_timer_expired, 0);
2333: vub300->inactivity_timer.expires = jiffies + HZ;
2334: add_timer(&vub300->inactivity_timer);
2335: if (vub300->card_present)
2336: dev_info(&vub300->udev->dev,
2337: "USB vub300 remote SDIO host controller[%d]"
2338: "connected with SD/SDIO card inserted\n",
2339: interface_to_InterfaceNumber(interface));
2340: else
2341: dev_info(&vub300->udev->dev,
2342: "USB vub300 remote SDIO host controller[%d]"
2343: "connected with no SD/SDIO card inserted\n",
2344: interface_to_InterfaceNumber(interface));
2345: retval = mmc_add_host(mmc);
2346: if (retval)
2347: goto err_stop_io;
2348:
2349: return 0;
2350:
2351: err_stop_io:
2352: vub300->interface = NULL;
2353: kref_put(&vub300->kref, vub300_delete);
2354:
2355: return retval;
2356:
2357: err_free_host:
2358: mmc_free_host(mmc);
2359: /*
2360: * and hence also frees vub300
2361: * which is contained at the end of struct mmc
2362: */
2363: err_free_res_urb:
2364: usb_free_urb(command_res_urb);
2365: err_free_out_urb:
2366: usb_free_urb(command_out_urb);
2367: err_put_udev:
2368: usb_put_dev(udev);
2369:
2370: return retval;
2371: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 26/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 46542
output: 40
thoughts: 874
Thoughts: **Analyzing the Reference Counting and Sleep-in-Atomic Context Bug**
Okay, let's break this down. In `vub300_probe`, a `kref` is initialized to 1, but then `kref_get` is called, so it becomes 2. I need to understand why. Ah, right. One reference is for the USB interface, and that's dropped in `vub300_disconnect`. But what about the other? I have to trace where that second reference goes.
Looking at `vub300_inactivity_timer_expired`, I see it now. The timer drops the second reference when `!vub300->interface`. So, when the interface is disconnected, `vub300_disconnect` drops the first reference, and then the timer fires, sees that `vub300->interface` is NULL, and drops the second reference! That means the timer is responsible for calling `vub300_delete` because it's the last one to release the reference. This confirms that the timer isn't a use-after-free, since the timer itself maintains a reference. When the timer fires, it drops its own reference. Since `vub300_disconnect` already dropped its reference, the timer's `kref_put` will be the last one, and it will call `vub300_delete`.
However, now I see a problem. Since `vub300_delete` is called from the timer callback, it runs in a softirq context. And `vub300_delete` calls `mmc_free_host`, which calls `cancel_delayed_work_sync`. And `cancel_delayed_work_sync` sleeps! This is a classic sleep-in-atomic context bug. It's calling a potentially sleeping function from a softirq, which is bad!
Okay, let's explore this further. Beyond the immediate crash potential, what are the security implications? If `cancel_delayed_work_sync` sleeps, it will eventually call `schedule()` within the softirq context. Although in a production kernel (without those debug configs), it might just log a warning and schedule. But... if `cancel_delayed_work_sync` is called from softirq, *and* the work it's cancelling is currently running on the *same* CPU, that's a deadlock! But which work? Oh, it's `vub300->detect` which is part of `mmc_host`. `mmc_free_host` *does* call `cancel_delayed_work_sync(&host->detect)`. But is `host->detect` actually running? Wait, no, `mmc_remove_host` cancels `host->detect` *synchronously*. So, it *shouldn't* deadlock.
|
| 27/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/core/host.c Name:mmc_remove_host]
Results: map[SourceCode: 671: /**
672: * mmc_remove_host - remove host hardware
673: * @host: mmc host
674: *
675: * Unregister and remove all cards associated with this host,
676: * and power down the MMC bus. No new requests will be issued
677: * after this function has returned.
678: */
679: void mmc_remove_host(struct mmc_host *host)
680: {
681: mmc_stop_host(host);
682:
683: mmc_remove_host_debugfs(host);
684:
685: device_del(&host->class_dev);
686:
687: led_trigger_unregister_simple(host->led);
688: }
SourceFile:drivers/mmc/core/host.c]
|
| 28/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 48357
output: 40
thoughts: 12
Thoughts: Okay, here's my attempt at summarizing that thought process, tailored for an expert audience:
**Checking `mmc_stop_host`**
Alright, let's dive in. The code's calling `mmc_stop_host`, and I need to figure out *exactly* what's happening there. I know from experience that this function is critical for proper card handling, especially during shutdown or error conditions. It probably involves disabling interrupts, flushing any pending transactions, and putting the host controller into a safe, inactive state. I need to refresh my understanding of how it interacts with the underlying hardware, the data structures like the `mmc_host` struct, and the state machines involved. Is it a synchronous or asynchronous operation? Does it involve any specific timing constraints that could cause issues? I'm thinking about potential race conditions if other threads or processes are still trying to access the host while `mmc_stop_host` is executing. Specifically, I need to look for areas related to:
* **Interrupt Handling:** How are interrupts masked and unmasked? Are there any potential interrupt storms?
* **DMA Operations:** Are DMA channels being properly disabled and cleaned up? Any dangling descriptors?
* **Command Queues:** How are pending commands flushed or cancelled? What's the protocol for ensuring data integrity during this process?
* **Power Management:** Is the host controller being put into a low-power state? Are any clocks disabled?
* **Error Handling:** What kind of error checking is done? Are errors reported correctly? Are there any retry mechanisms?
* **Host Reset:** Are the hardware registers reset to a known state?
I'll be specifically looking to see if there are any potential pitfalls such as:
* **Race Conditions:** Are shared resources properly protected?
* **Deadlocks:** Are there any lock acquisition orders that could cause problems?
* **Memory Corruption:** Could the host controller write to invalid memory addresses?
* **Driver Errors:** Are there any places where we could have incorrect checks to see if the driver is initialized or not?
* **Power Down Sequencing:** Is the sequencing correct such that the host has completed all of its operations before it is completely shut down?
Understanding the precise sequence of operations within `mmc_stop_host` is crucial for avoiding data corruption, ensuring system stability, and preventing unexpected behavior. Time to dig in and trace the execution path.
|
| 29/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/core/core.c Name:mmc_stop_host]
Results: map[SourceCode:2371: void mmc_stop_host(struct mmc_host *host)
2372: {
2373: __mmc_stop_host(host);
2374:
2375: /* clear pm flags now and let card drivers set them as needed */
2376: host->pm_flags = 0;
2377:
2378: if (host->bus_ops) {
2379: /* Calling bus_ops->remove() with a claimed host can deadlock */
2380: host->bus_ops->remove(host);
2381: mmc_claim_host(host);
2382: mmc_detach_bus(host);
2383: mmc_power_off(host);
2384: mmc_release_host(host);
2385: return;
2386: }
2387:
2388: mmc_claim_host(host);
2389: mmc_power_off(host);
2390: mmc_release_host(host);
2391: }
SourceFile:drivers/mmc/core/core.c]
|
| 30/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 49254
output: 41
thoughts: 13
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Investigating `__mmc_stop_host`**
Okay, time to dive into this. I'm taking a look at `__mmc_stop_host`. My initial thought is to understand the core functionality of this function. We're talking about stopping the MMC/SD host, so I need to quickly recall the general architecture of the driver and its interaction with the hardware. What specific tasks is this function responsible for? Does it primarily handle power management, bus transactions, or both? Are there any obvious potential race conditions I should be on the lookout for, such as if the host is actively transmitting data when this function is called? I'm already thinking about where this function might be called from, considering that this is stop, it's critical to ensure resources are properly cleaned up, and that the host is placed into a safe, quiescent state. I will immediately want to review its return values and error handling to ensure robustness; especially important for embedded systems where a crash means a bricked device.
|
| 31/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/core/core.c Name:__mmc_stop_host]
Results: map[SourceCode:2357: void __mmc_stop_host(struct mmc_host *host)
2358: {
2359: if (host->rescan_disable)
2360: return;
2361:
2362: if (host->slot.cd_irq >= 0) {
2363: mmc_gpio_set_cd_wake(host, false);
2364: disable_irq(host->slot.cd_irq);
2365: }
2366:
2367: host->rescan_disable = 1;
2368: cancel_delayed_work_sync(&host->detect);
2369: }
SourceFile:drivers/mmc/core/core.c]
|
| 32/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 49757
output: 36
thoughts: 219
Thoughts: **Analyzing the MMC Host Removal Process**
Okay, so I'm tracing the MMC host removal sequence here. It looks like `__mmc_stop_host` kicks things off by calling `cancel_delayed_work_sync(&host->detect)`. That makes sense; we want to stop any pending detection work. But then, looking at `mmc_remove_host`, it already cancels the work synchronously. Right after that, `vub300_disconnect` is called and executes `kref_put`. Eventually, the timer fires and we end up in `vub300_delete`, which calls `mmc_free_host`.
Now, here's where it gets interesting. `mmc_free_host` *also* calls `cancel_delayed_work_sync(&host->detect)`. Hold on a second... the work has already been cancelled by `mmc_remove_host`, and `rescan_disable` is definitely set, so that work isn't running. So, that call to `cancel_delayed_work_sync` *should* just return immediately, right? It's just a no-op at this point.
But wait, `cancel_delayed_work_sync` *itself* calls `__cancel_work_sync`, which then calls `__might_sleep`. Uh oh. So that means itβs going to print a warning. But it won't actually sleep, because there's no work to wait for, right? It's been cancelled! Let me quickly double-check the implementation of `__cancel_work_sync` just to make sure.
|
| 33/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/workqueue.c Name:__cancel_work_sync]
Results: map[SourceCode:4478: static bool __cancel_work_sync(struct work_struct *work, u32 cflags)
4479: {
4480: bool ret;
4481:
4482: ret = __cancel_work(work, cflags | WORK_CANCEL_DISABLE);
4483:
4484: if (*work_data_bits(work) & WORK_OFFQ_BH)
4485: WARN_ON_ONCE(in_hardirq());
4486: else
4487: might_sleep();
4488:
4489: /*
4490: * Skip __flush_work() during early boot when we know that @work isn't
4491: * executing. This allows canceling during early boot.
4492: */
4493: if (wq_online)
4494: __flush_work(work, true);
4495:
4496: if (!(cflags & WORK_CANCEL_DISABLE))
4497: enable_work(work);
4498:
4499: return ret;
4500: }
SourceFile:kernel/workqueue.c]
|
| 34/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 50698
output: 34
thoughts: 45
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm deep in the kernel code:
**Analyzing `__cancel_work_sync` and its Flushing Behavior**
Right, so `__cancel_work_sync` is unconditionally calling `might_sleep()`. Thatβs a key detail to note. It's essentially saying "Hey, be aware, this might block, even if you think you're in a non-blocking context!" Then, it immediately calls `__flush_work(work, true)`. The `true` there tells me it's likely a synchronous flush, which makes sense given the function name. Okay, I need to understand what `__flush_work` is doing in more detail. I'm going to quickly check its implementation to understand the implications of this synchronous flushing behavior.
|
| 35/2 |
2026/08/15 01:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/workqueue.c Name:__flush_work]
Results: map[SourceCode:4328: static bool __flush_work(struct work_struct *work, bool from_cancel)
4329: {
4330: struct wq_barrier barr;
4331:
4332: if (WARN_ON(!wq_online))
4333: return false;
4334:
4335: if (WARN_ON(!work->func))
4336: return false;
4337:
4338: if (!start_flush_work(work, &barr, from_cancel))
4339: return false;
4340:
4341: /*
4342: * start_flush_work() returned %true. If @from_cancel is set, we know
4343: * that @work must have been executing during start_flush_work() and
4344: * can't currently be queued. Its data must contain OFFQ bits. If @work
4345: * was queued on a BH workqueue, we also know that it was running in the
4346: * BH context and thus can be busy-waited.
4347: */
4348: if (from_cancel) {
4349: unsigned long data = *work_data_bits(work);
4350:
4351: if (!WARN_ON_ONCE(data & WORK_STRUCT_PWQ) &&
4352: (data & WORK_OFFQ_BH)) {
4353: /*
4354: * On RT, prevent a live lock when %current preempted
4355: * soft interrupt processing by blocking on lock which
4356: * is owned by the thread invoking the callback.
4357: */
4358: while (!try_wait_for_completion(&barr.done)) {
4359: if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
4360: struct worker_pool *pool;
4361:
4362: guard(rcu)();
4363: pool = get_work_pool(work);
4364: if (pool)
4365: workqueue_callback_cancel_wait_running(pool);
4366: } else {
4367: cpu_relax();
4368: }
4369: }
4370: goto out_destroy;
4371: }
4372: }
4373:
4374: wait_for_completion(&barr.done);
4375:
4376: out_destroy:
4377: destroy_work_on_stack(&barr.work);
4378: return true;
4379: }
SourceFile:kernel/workqueue.c]
|
| 36/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 51710
output: 54
thoughts: 1268
Thoughts: **Analyzing the Disconnect Sequence and Timer Interaction**
Okay, let's break this down systematically. My initial thought was that the `start_flush_work` returning false was a red herring. It seemed like a harmless warning, not leading to any real issues with sleeps or use-after-frees. The critical point is the interaction between `vub300_disconnect` and the timer, `vub300->inactivity_timer`.
If `start_flush_work` returns false, it looks like `__flush_work` exits quickly, which means `wait_for_completion` isn't called, and thus `schedule()` doesn't get called. So, all that happens is a simple warning via `might_sleep()`. That's not the issue.
The real problem lies with the timer firing *concurrently* with `vub300_disconnect`. I had to map out all possible scenarios. If the timer fires *before* the disconnect, the `vub300->interface` isn't NULL, and the timer's behaviour is conditional based on `vub300->cmd`. However, if the timer fires *after* `vub300_disconnect` has been called, but before it completes `kref_put`, then things get interesting. `vub300_disconnect` sets `vub300->interface` to NULL and then calls `mmc_remove_host(mmc)` *before* calling `kref_put`. If the timer fires between those two lines, it will think that `vub300->interface` is NULL, call `kref_put`, decrementing the refcount. Then the `vub300_disconnect` calls `kref_put` again, and decrementing the refcount to zero, which then calls `vub300_delete`.
The critical point is that I realized the timer's `kref_put` and `vub300_disconnect`'s `kref_put` can race. This can lead to the warning if the timer fires after the disconnect has called `kref_put`. In either case, it's called just once, but from different contexts.
But wait, the real danger is still there. Now I see it. It's a classic *use-after-free* scenario. If `vub300_delete` *is* called from `vub300_disconnect` directly (and, in *process* context), then the timer is *still* pending! Since `vub300_delete` frees `vub300`, the timer, when it eventually fires, will try to access freed memory! So what if the timer drops the last ref? Where does the timer get its reference? Let's trace from `vub300_probe`. Okay, `kref_init` and then `kref_get`. That gives the timer its initial reference. The initial state of the reference is 2 (one for USB, one for the timer). The timer *itself* drops the reference in the callback *only* if `!vub300->interface`. The `vub300_disconnect` function *also* drops a reference. So if the `vub300_disconnect` removes its reference and the timer fires *after* setting `vub300->interface = NULL`, then the timer will decrement the refcount to 0 which calls `vub300_delete`.
Therefore, the `vub300_delete` is always called from the timer callback in the problematic scenario. This means that a call to `kref_put` from the disconnect routine won't do anything because the ref is already being decremented from the timer call. Now, the question is, *where else* is the timer removed? I need to search for that.
|
| 37/2 |
2026/08/15 01:39 |
tool |
codesearch-find-references |
0m
Error:
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:del_timer SourceTreePrefix:]
Results: map[References:<nil> TruncatedOutput:false]
|
| 38/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 53897
output: 56
thoughts: 11
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Delving into `del_timer_sync`**
Alright, time to dive into `del_timer_sync`. This function name, on its own, suggests it likely handles the deletion or de-allocation of a timer, and the "sync" part strongly implies there's a synchronization aspect involved. This probably means it's designed to be thread-safe or interact with shared resources in a controlled manner. I need to understand the underlying implementation and context. I need to be sure the function handles any race conditions around timer resources. I'll need to look at what locks are in place and if there are edge cases in the locking sequence. Are there any potential deadlocks? Are there any specific conditions or states the timer can be in when it's deleted? Does this delete function ensure that no callbacks are running on the timer object when deallocating, as this would likely lead to use-after-free bugs. I'm going to look for any calls to `del_timer_sync`, any locking primitives around them, and if the resources are protected properly against concurrent accesses. Furthermore, I'll need to check if the timer is properly invalidated or cleared before being deleted, to avoid any unintended behavior downstream.
|
| 39/2 |
2026/08/15 01:39 |
tool |
codesearch-find-references |
0m
Error:
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:del_timer_sync SourceTreePrefix:]
Results: map[References:<nil> TruncatedOutput:false]
|
| 40/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 54264
output: 43
thoughts: 29
Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective:
**Concerning Timer Deletion in `vub300.c`**
Alright, hang on a second. I'm digging into this `vub300.c` code, specifically the timer management. And I'm starting to think I might have missed something *big*. I'm staring at these function calls, and I'm asking myself, am I seeing things? Because it's suddenly hitting me β neither `del_timer` *nor* `del_timer_sync` appear to be invoked *anywhere* within this particular source file. I mean, I've checked all the relevant contexts, and nothing! That's...unusual, to say the least. This raises some serious questions about how the timers are being handled and cleaned up in this module. Are they being managed elsewhere and, if so, why aren't the deletion routines being used here at all? This requires more investigation to understand the complete timer lifecycle within this system. I need to understand this discrepancy immediately.
|
| 41/2 |
2026/08/15 01:39 |
tool |
grepper |
0m
Error:
Args: map[Expression:del_timer.*vub300 PathPrefix:drivers/mmc/host/vub300.c]
Results:
|
| 42/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 54582
output: 37
thoughts: 20
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience:
**Grep Time!**
Alright, let's cut the fluff. I'm thinking, "Let's just grep `del_timer` in `vub300.c`." That's the most efficient way to get a quick overview of how timers are handled within that module. There's no need to overthink it; a simple grep will immediately pinpoint all uses of that function. I'm expecting to find the timer initialization, start, stop and maybe even some edge case handling related to this timer. A direct approach like this is often the most productive starting point for understanding a specific function's usage, especially when you're already familiar with the codebase's general architecture. A quick scan of the results is probably enough to refresh my memory or to get a quick overview. Then I'll dive deeper based on what the grep turns up. Simple and effective.
|
| 43/2 |
2026/08/15 01:39 |
tool |
grepper |
0m
Error:
Args: map[Expression:del_timer PathPrefix:drivers/mmc/host/vub300.c]
Results:
|
| 44/2 |
2026/08/15 01:39 |
llm |
expert |
0m
Model:
Tokens:
input: 54857
output: 55
thoughts: 124
Thoughts: **Analyzing the Timer's Behavior**
Okay, this is interesting. I'm focusing on this timer mechanism here, and it's hitting me that this thing *never* gets explicitly deleted. That's unusual and suggests it's designed to fire indefinitely. So, it's safe to say this timer *always* triggers. Now, when it *does* fire, the conditional `!vub300->interface` is crucial. If that's true, the code calls `kref_put`. Since `vub300_disconnect` is also decrementing a reference, the timer's `kref_put` is almost *guaranteed* to be the one that actually drops the final reference to the object.
But, a thought is gnawing at me. Suppose `vub300_disconnect` is invoked, and then the timer fires, triggering `vub300_delete` from within the timer's context. That race condition has the potential to lead to issues if not carefully considered.
I need to quickly backtrack and survey the landscape. Are there any other locations where either `kref_get` or `kref_put` are called? Understanding the full reference counting picture is essential before I can draw any concrete conclusions.
|
| 45/2 |
2026/08/15 01:40 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:kref_get SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__core_scsi3_alloc_registration SourceFile:drivers/target/target_core_pr.c SourceLine:764] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__core_scsi3_check_aptpl_registration SourceFile:drivers/target/target_core_pr.c SourceLine:967] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__core_scsi3_do_alloc_registration SourceFile:drivers/target/target_core_pr.c SourceLine:662] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__init_node_memory_type SourceFile:mm/memory-tiers.c SourceLine:538] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__media_device_get SourceFile:drivers/media/mc/mc-dev-allocator.c SourceLine:71] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__nvmem_device_get SourceFile:drivers/nvmem/core.c SourceLine:1114] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__reset_control_get_internal SourceFile:drivers/reset/core.c SourceLine:856] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:_nfs4_proc_open_confirm SourceFile:fs/nfs/nfs4proc.c SourceLine:2453] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:acpi_ec_get_query_handler_by_value SourceFile:drivers/acpi/ec.c SourceLine:1069] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:alloc_lookup_fw_priv SourceFile:drivers/base/firmware_loader/main.c SourceLine:182] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:alloc_session SourceFile:drivers/tee/amdtee/core.c SourceLine:117] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:as102_open SourceFile:drivers/media/usb/as102/as102_usb_drv.c SourceLine:432] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ata_host_get SourceFile:drivers/ata/libata-core.c SourceLine:5785] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:auth_domain_lookup SourceFile:net/sunrpc/svcauth.c SourceLine:249] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:bdi_get SourceFile:include/linux/backing-dev.h SourceLine:22] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:cache_get SourceFile:include/linux/sunrpc/cache.h SourceLine:205] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:carl9170_tx_get_skb SourceFile:drivers/net/wireless/ath/carl9170/tx.c SourceLine:335] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:clk_hw_create_clk SourceFile:drivers/clk/clk.c SourceLine:4170] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:comedi_buf_map_get SourceFile:drivers/comedi/comedi_buf.c SourceLine:145] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:comedi_dev_get SourceFile:drivers/comedi/comedi_fops.c SourceLine:147] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:commit_get SourceFile:drivers/gpu/drm/i915/display/intel_global_state.c SourceLine:76] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:config_item_get SourceFile:fs/configfs/item.c SourceLine:104] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:core_get_se_deve_from_rtpi SourceFile:drivers/target/target_core_device.c SourceLine:223] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:core_tpg_check_initiator_node_acl SourceFile:drivers/target/target_core_tpg.c SourceLine:266] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:cougar_get_shared_data SourceFile:drivers/hid/hid-cougar.c SourceLine:126] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:cpu_rmap_get SourceFile:lib/cpu_rmap.c SourceLine:78] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:device_link_add SourceFile:drivers/base/core.c SourceLine:881] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:device_link_add SourceFile:drivers/base/core.c SourceLine:907] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dj_find_receiver_dev SourceFile:drivers/hid/hid-logitech-dj.c SourceLine:680] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dj_find_receiver_dev SourceFile:drivers/hid/hid-logitech-dj.c SourceLine:685] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dj_find_receiver_dev SourceFile:drivers/hid/hid-logitech-dj.c SourceLine:690] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dma_fence_get SourceFile:include/linux/dma-fence.h SourceLine:317] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dma_set_unmap SourceFile:include/linux/dmaengine.h SourceLine:638] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_atomic_commit_get SourceFile:include/drm/drm_atomic.h SourceLine:695] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_bridge_get SourceFile:drivers/gpu/drm/drm_bridge.c SourceLine:295] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_crtc_commit_get SourceFile:include/drm/drm_atomic.h SourceLine:664] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_dev_get SourceFile:drivers/gpu/drm/drm_drv.c SourceLine:934] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_dp_mst_get_mstb_malloc SourceFile:drivers/gpu/drm/display/drm_dp_mst_topology.c SourceLine:1464] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_dp_mst_get_port_malloc SourceFile:drivers/gpu/drm/display/drm_dp_mst_topology.c SourceLine:1515] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_dp_mst_topology_get_mstb SourceFile:drivers/gpu/drm/display/drm_dp_mst_topology.c SourceLine:1799] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_dp_mst_topology_get_port SourceFile:drivers/gpu/drm/display/drm_dp_mst_topology.c SourceLine:1911] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_gem_object_get SourceFile:include/drm/drm_gem.h SourceLine:555] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_gpuvm_bo_get SourceFile:include/drm/drm_gpuvm.h SourceLine:756] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_gpuvm_get SourceFile:include/drm/drm_gpuvm.h SourceLine:363] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_master_get SourceFile:drivers/gpu/drm/drm_auth.c SourceLine:373] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_mode_object_get SourceFile:drivers/gpu/drm/drm_mode_object.c SourceLine:217] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_panel_get SourceFile:drivers/gpu/drm/drm_panel.c SourceLine:390] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:drm_syncobj_get SourceFile:include/drm/drm_syncobj.h SourceLine:82] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dvb_ca_private_get SourceFile:drivers/media/dvb-core/dvb_ca_en50221.c SourceLine:184] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dvb_device_get SourceFile:drivers/media/dvb-core/dvbdev.c SourceLine:621] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:dvb_frontend_get SourceFile:drivers/media/dvb-core/dvb_frontend.c SourceLine:171] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_audio_init SourceFile:drivers/media/usb/em28xx/em28xx-audio.c SourceLine:822] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_dvb_init SourceFile:drivers/media/usb/em28xx/em28xx-dvb.c SourceLine:2242] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_ir_init SourceFile:drivers/media/usb/em28xx/em28xx-input.c SourceLine:701] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_v4l2_init SourceFile:drivers/media/usb/em28xx/em28xx-video.c SourceLine:3051] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_v4l2_open SourceFile:drivers/media/usb/em28xx/em28xx-video.c SourceLine:2357] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:em28xx_v4l2_open SourceFile:drivers/media/usb/em28xx/em28xx-video.c SourceLine:2358] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:eventfd_ctx_fileget SourceFile:fs/eventfd.c SourceLine:374] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fb_deferred_io_state_get SourceFile:drivers/video/fbdev/core/fb_defio.c SourceLine:89] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:find_port_by_devt_in_portdev SourceFile:drivers/char/virtio_console.c SourceLine:262] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:frontbuffer_active SourceFile:drivers/gpu/drm/i915/gem/i915_gem_object_frontbuffer.c SourceLine:14] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:fw_cache_piggyback_on_request SourceFile:drivers/base/firmware_loader/main.c SourceLine:1440] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gadget_bind SourceFile:drivers/usb/gadget/legacy/raw_gadget.c SourceLine:324] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gb_connection_get SourceFile:drivers/greybus/connection.c SourceLine:38] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gb_operation_get SourceFile:drivers/greybus/operation.c SourceLine:663] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:get_current_rng SourceFile:drivers/char/hw_random/core.c SourceLine:169] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:get_current_rng_nolock SourceFile:drivers/char/hw_random/core.c SourceLine:157] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:get_ei SourceFile:fs/tracefs/event_inode.c SourceLine:157] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:get_parallel SourceFile:fs/nfs/blocklayout/blocklayout.c SourceLine:86] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gss_alloc_msg SourceFile:net/sunrpc/auth_gss/auth_gss.c SourceLine:546] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gss_create_cred SourceFile:net/sunrpc/auth_gss/auth_gss.c SourceLine:1394] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:gss_dup_cred SourceFile:net/sunrpc/auth_gss/auth_gss.c SourceLine:1263] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hid_debug_events_open SourceFile:drivers/hid/hid-debug.c SourceLine:3701] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hidp_session_get SourceFile:net/bluetooth/hidp/core.c SourceLine:991] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hso_serial_open SourceFile:drivers/net/usb/hso.c SourceLine:1269] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hub_get SourceFile:drivers/usb/core/hub.c SourceLine:1792] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hugetlb_unmap_file_folio SourceFile:fs/hugetlbfs/inode.c SourceLine:413] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:hugetlb_vm_op_open SourceFile:mm/hugetlb.c SourceLine:4661] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_active_get SourceFile:drivers/gpu/drm/i915/i915_active.c SourceLine:1137] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_drm_client_get SourceFile:drivers/gpu/drm/i915/i915_drm_client.h SourceLine:53] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_gem_context_get SourceFile:drivers/gpu/drm/i915/gem/i915_gem_context.h SourceLine:147] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_gem_object_frontbuffer_get SourceFile:drivers/gpu/drm/i915/gem/i915_gem_object_frontbuffer.c SourceLine:55] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_gem_object_frontbuffer_ref SourceFile:drivers/gpu/drm/i915/gem/i915_gem_object_frontbuffer.c SourceLine:73] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_gem_vm_lookup SourceFile:drivers/gpu/drm/i915/gem/i915_gem_context.c SourceLine:360] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_gpu_coredump_get SourceFile:drivers/gpu/drm/i915/i915_gpu_error.h SourceLine:311] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_refct_sgt_get SourceFile:drivers/gpu/drm/i915/i915_scatterlist.h SourceLine:208] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_sched_engine_get SourceFile:drivers/gpu/drm/i915/i915_scheduler.h SourceLine:58] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_vm_get SourceFile:drivers/gpu/drm/i915/gt/intel_gtt.h SourceLine:483] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:i915_vm_resv_get SourceFile:drivers/gpu/drm/i915/gt/intel_gtt.h SourceLine:506] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:idmouse_open SourceFile:drivers/usb/misc/idmouse.c SourceLine:260] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:iio_buffer_dmabuf_get SourceFile:drivers/iio/industrialio-buffer.c SourceLine:1603] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:iio_buffer_get SourceFile:drivers/iio/industrialio-buffer.c SourceLine:2506] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_atomic_global_state_get SourceFile:drivers/gpu/drm/i915/display/intel_global_state.c SourceLine:106] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_breadcrumbs_get SourceFile:drivers/gpu/drm/i915/gt/intel_breadcrumbs.h SourceLine:54] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_context_get SourceFile:drivers/gpu/drm/i915/gt/intel_context.h SourceLine:238] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_ring_get SourceFile:drivers/gpu/drm/i915/gt/intel_ring.h SourceLine:31] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:intel_timeline_get SourceFile:drivers/gpu/drm/i915/gt/intel_timeline.h SourceLine:36] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:iowarrior_open SourceFile:drivers/usb/misc/iowarrior.c SourceLine:644] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:irq_affinity_schedule_notify_work SourceFile:kernel/irq/manage.c SourceLine:369] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:klist_next SourceFile:lib/klist.c SourceLine:394] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:klist_prev SourceFile:lib/klist.c SourceLine:352] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:kobject_get SourceFile:lib/kobject.c SourceLine:643] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:kunit_get_resource SourceFile:include/kunit/resource.h SourceLine:102] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:l2cap_chan_hold SourceFile:net/bluetooth/l2cap_core.c SourceLine:503] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:l2cap_conn_get SourceFile:net/bluetooth/l2cap_core.c SourceLine:1851] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:lcd_open SourceFile:drivers/usb/misc/usblcd.c SourceLine:95] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ld_usb_open SourceFile:drivers/usb/misc/ldusb.c SourceLine:361] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:llsec_key_get SourceFile:net/mac802154/llsec.c SourceLine:179] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:media_request_get SourceFile:include/media/media-request.h SourceLine:183] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:media_request_object_get SourceFile:include/media/media-request.h SourceLine:327] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mon_exit SourceFile:drivers/usb/mon/mon_main.c SourceLine:400] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mon_reader_add SourceFile:drivers/usb/mon/mon_main.c SourceLine:57] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfc_llcp_local_get SourceFile:net/nfc/llcp_core.c SourceLine:155] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs4_run_open_task SourceFile:fs/nfs/nfs4proc.c SourceLine:2622] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_direct_add_page_head SourceFile:fs/nfs/direct.c SourceLine:529] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_direct_add_page_head SourceFile:fs/nfs/direct.c SourceLine:530] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_direct_req_alloc SourceFile:fs/nfs/direct.c SourceLine:194] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_direct_write_completion SourceFile:fs/nfs/direct.c SourceLine:801] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_direct_write_completion SourceFile:fs/nfs/direct.c SourceLine:807] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_folio_find_head_request SourceFile:fs/nfs/write.c SourceLine:181] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_inode_add_request SourceFile:fs/nfs/write.c SourceLine:729] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_io_completion_get SourceFile:fs/nfs/write.c SourceLine:138] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_page_group_init SourceFile:fs/nfs/pagelist.c SourceLine:331] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_page_group_init SourceFile:fs/nfs/pagelist.c SourceLine:339] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_page_set_inode_ref SourceFile:fs/nfs/write.c SourceLine:151] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nfs_scan_commit_list SourceFile:fs/nfs/write.c SourceLine:968] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_find_block SourceFile:fs/lockd/svclock.c SourceLine:202] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_grant_blocked SourceFile:fs/lockd/svclock.c SourceLine:858] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_insert_block_locked SourceFile:fs/lockd/svclock.c SourceLine:95] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_lookup_block SourceFile:fs/lockd/svclock.c SourceLine:164] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:nlmsvc_traverse_blocks SourceFile:fs/lockd/svclock.c SourceLine:334] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:pcmcia_device_add SourceFile:drivers/pcmcia/ds.c SourceLine:532] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:qh_get SourceFile:drivers/usb/host/oxu210hp-hcd.c SourceLine:1073] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:raw_ioctl_run SourceFile:drivers/usb/gadget/legacy/raw_gadget.c SourceLine:608] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:relay_create_buf SourceFile:kernel/relay.c SourceLine:165] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:relay_file_open SourceFile:kernel/relay.c SourceLine:744] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:report_io_error SourceFile:drivers/char/xillybus/xillyusb.c SourceLine:626] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sco_conn_hold SourceFile:net/bluetooth/sco.c SourceLine:112] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:scsi_alloc_sdev SourceFile:drivers/scsi/scsi_scan.c SourceLine:347] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:scsi_remove_target SourceFile:drivers/scsi/scsi_sysfs.c SourceLine:1596] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:scsi_sysfs_device_initialize SourceFile:drivers/scsi/scsi_sysfs.c SourceLine:1721] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sev_misc_init SourceFile:drivers/crypto/ccp/sev-dev.c SourceLine:2659] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sfs_misc_init SourceFile:drivers/crypto/ccp/sfs.c SourceLine:242] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sg_add_sfp SourceFile:drivers/scsi/sg.c SourceLine:2183] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sg_common_write SourceFile:drivers/scsi/sg.c SourceLine:828] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sg_get_dev SourceFile:drivers/scsi/sg.c SourceLine:2294] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:sisusb_open SourceFile:drivers/usb/misc/sisusbvga/sisusbvga.c SourceLine:2243] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:smsdvb_stats_open SourceFile:drivers/media/common/siano/smsdvb-debugfs.c SourceLine:232] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:smsdvb_stats_poll SourceFile:drivers/media/common/siano/smsdvb-debugfs.c SourceLine:273] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:smsdvb_stats_read SourceFile:drivers/media/common/siano/smsdvb-debugfs.c SourceLine:289] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:snd_em28xx_capture_open SourceFile:drivers/media/usb/em28xx/em28xx-audio.c SourceLine:275] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:snd_timer_ref_get SourceFile:sound/core/timer.c SourceLine:239] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ssam_controller_get SourceFile:drivers/platform/surface/aggregator/controller.c SourceLine:907] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ssh_packet_get SourceFile:drivers/platform/surface/aggregator/ssh_packet_layer.c SourceLine:532] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:submit_async_request SourceFile:drivers/usb/misc/uss720.c SourceLine:143] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:submit_async_request SourceFile:drivers/usb/misc/uss720.c SourceLine:167] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:svc_xprt_get SourceFile:include/linux/sunrpc/svc_xprt.h SourceLine:192] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:svcauth_unix_set_client SourceFile:net/sunrpc/svcauth_unix.c SourceLine:987] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:target_get_sess_cmd SourceFile:drivers/target/target_core_transport.c SourceLine:3062] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:teedev_ctx_get SourceFile:drivers/tee/tee_core.c SourceLine:80] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tower_open SourceFile:drivers/usb/misc/legousbtower.c SourceLine:386] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ttm_bo_get SourceFile:drivers/gpu/drm/ttm/ttm_bo_internal.h SourceLine:37] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tty_driver_kref_get SourceFile:include/linux/tty_driver.h SourceLine:586] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:tty_kref_get SourceFile:include/linux/tty.h SourceLine:398] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ufx_ops_open SourceFile:drivers/video/fbdev/smscufx.c SourceLine:1033] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:ufx_usb_probe SourceFile:drivers/video/fbdev/smscufx.c SourceLine:1605] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:update SourceFile:net/sunrpc/svcauth_unix.c SourceLine:144] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_console_setup SourceFile:drivers/usb/serial/console.c SourceLine:147] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_get_hcd SourceFile:drivers/usb/core/hcd.c SourceLine:2696] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_get_urb SourceFile:drivers/usb/core/urb.c SourceLine:113] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_serial_port_get_by_minor SourceFile:drivers/usb/serial/usb-serial.c SourceLine:74] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usb_set_configuration SourceFile:drivers/usb/core/message.c SourceLine:2170] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usbatm_get_instance SourceFile:drivers/usb/atm/usbatm.c SourceLine:706] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usbtmc_open SourceFile:drivers/usb/class/usbtmc.c SourceLine:186] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:usbtmc_probe SourceFile:drivers/usb/class/usbtmc.c SourceLine:2464] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uvc_register_video_device SourceFile:drivers/media/usb/uvc/uvc_driver.c SourceLine:2089] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:uvc_video_decode_data SourceFile:drivers/media/usb/uvc/uvc_video.c SourceLine:1373] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:v4l2_device_get SourceFile:include/media/v4l2-device.h SourceLine:69] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vma_pfnmap_track_ctx_dup SourceFile:mm/vma_init.c SourceLine:95] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_enable_sdio_irq SourceFile:drivers/mmc/host/vub300.c SourceLine:2060] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1938] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_set_ios SourceFile:drivers/mmc/host/vub300.c SourceLine:2019] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2330] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_queue_cmnd_work SourceFile:drivers/mmc/host/vub300.c SourceLine:388] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_queue_dead_work SourceFile:drivers/mmc/host/vub300.c SourceLine:428] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:vub300_queue_poll_work SourceFile:drivers/mmc/host/vub300.c SourceLine:408] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wacom_get_hdev_data SourceFile:drivers/hid/wacom_sys.c SourceLine:840] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:wacom_get_hdev_data SourceFile:drivers/hid/wacom_sys.c SourceLine:848] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xillyusb_open SourceFile:drivers/char/xillybus/xillyusb.c SourceLine:1253] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:yurex_open SourceFile:drivers/usb/misc/yurex.c SourceLine:375]] TruncatedOutput:false]
|
| 46/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 66079
output: 56
thoughts: 471
Thoughts: **Analyzing the Reference Counting and Timer Issue**
Okay, let me lay this out clearly. I see that `kref_get` is being called in several key functions: `vub300_queue_cmnd_work`, `vub300_queue_dead_work`, `vub300_queue_poll_work`, `vub300_mmc_request`, `vub300_mmc_set_ios`, and `vub300_enable_sdio_irq`. Correspondingly, `kref_put` is called within the associated work threads or when a request completes. This means `vub300_delete` should only execute when *all* references have been dropped.
I'm following the flow now. `vub300_disconnect` will drop the "interface" reference. The timer, if pending, holds a reference. Pending work items also hold references. When the timer fires, it drops its reference. If that's the final reference, `vub300_delete` is called from the timer's callback. And... this is precisely what the bug report describes! The timer fires, drops the last reference, and `vub300_delete` is invoked within a softirq context.
The problem, as I understand it, stems from `vub300_delete` calling `mmc_free_host`, which then calls `cancel_delayed_work_sync(&host->detect)`. Now, `cancel_delayed_work_sync` *includes* a `might_sleep()` call, which triggers the warning we're seeing. But, as I've already determined, `cancel_delayed_work_sync` *shouldn't* actually sleep because the work has already been cancelled. It's just a warning, and the code continues.
So, is there a *real* issue here besides the warning? Let's consider the worst-case scenario: what if `vub300_delete` frees `vub300` while the timer *is* still pending? Wait, that can't happen. If `vub300_delete` is called from *within* the timer callback, the timer is NOT pending anymore, it's *currently executing*! When the timer callback completes, the timer is finished. The timer isn't pending.
But, is there another timer that I'm overlooking? Ah! `vub300->sg_transfer_timer`. I need to investigate that one.
|
| 47/2 |
2026/08/15 01:40 |
tool |
codesearch-find-references |
0m
Error:
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:sg_transfer_timer SourceTreePrefix:]
Results: map[References:<nil> TruncatedOutput:false]
|
| 48/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 67181
output: 67
thoughts: 8
Thoughts: Okay, here's my attempt at summarizing the thought process, tailored for an expert audience:
**Initial Assessment: Navigating the Landscape**
Wait. Okay, hold on a second. This isn't a simple list, a single concept, or a straightforward problem. It's... a field. As an expert, I'm already mentally charting the territory. It's the whole encompassing space where these components interact. This isn't a problem to solve; it's a domain to understand. I need to figure out the boundaries, key players, dominant paradigms, and potential methodologies applicable here.
|
| 49/2 |
2026/08/15 01:40 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:vub300_mmc_host::sg_transfer_timer SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:__command_read_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1451] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:__command_read_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1454] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:__command_read_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1456] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:__command_write_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1568] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:__command_write_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1571] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:__command_write_data SourceFile:drivers/mmc/host/vub300.c SourceLine:1576] map[ReferenceKind:takes-address-of ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2329] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_sg_timed_out SourceFile:drivers/mmc/host/vub300.c SourceLine:1184]] TruncatedOutput:false]
|
| 50/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 67892
output: 44
thoughts: 13
Thoughts: Okay, let's dive into this. Here's my take on it:
**Analyzing the `__command_read_data` Function**
Alright, let's get down to it. My initial focus, as always, is on the function `__command_read_data`. I need to understand its core purpose, its inputs, and its expected outputs. Based on its name, I'm already formulating some hypotheses. It's almost certainly involved in data retrieval, perhaps from a file, a database, or even a network stream. The double underscores at the start suggests that this might be an internal or private function, or perhaps one thatβs part of a specific system. Itβs critical to figure out the environment in which this function operates, is it running on a system with limited resources? How does it handle errors?
I'm thinking about the data structures this function might utilize. Does it return raw bytes, parsed data, or perhaps an object containing the read data and some metadata? What about potential security considerations? Is there any risk of injection attacks or unauthorized access to data if this function is used improperly or in a system with insufficient validation? And most importantly, how does it fit into the broader system architecture? What modules or functions call it, and what functions does it depend on? This is critical for understanding the overall data flow and any potential bottlenecks or weaknesses. My goal is to grasp its functionality at a low level, but also see its impact on the system.
|
| 51/2 |
2026/08/15 01:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:__command_read_data]
Results: map[SourceCode:1429: static int __command_read_data(struct vub300_mmc_host *vub300,
1430: struct mmc_command *cmd, struct mmc_data *data)
1431: {
1432: /* cmd_mutex is held by vub300_cmndwork_thread */
1433: int linear_length = vub300->datasize;
1434: int padded_length = vub300->large_usb_packets ?
1435: ((511 + linear_length) >> 9) << 9 :
1436: ((63 + linear_length) >> 6) << 6;
1437: if ((padded_length == linear_length) || !pad_input_to_usb_pkt) {
1438: int result;
1439: unsigned pipe;
1440: pipe = usb_rcvbulkpipe(vub300->udev, vub300->data_inp_ep);
1441: result = usb_sg_init(&vub300->sg_request, vub300->udev,
1442: pipe, 0, data->sg,
1443: data->sg_len, 0, GFP_KERNEL);
1444: if (result < 0) {
1445: usb_unlink_urb(vub300->command_out_urb);
1446: usb_unlink_urb(vub300->command_res_urb);
1447: cmd->error = result;
1448: data->bytes_xfered = 0;
1449: return 0;
1450: } else {
1451: vub300->sg_transfer_timer.expires =
1452: jiffies + msecs_to_jiffies(2000 +
1453: (linear_length / 16384));
1454: add_timer(&vub300->sg_transfer_timer);
1455: usb_sg_wait(&vub300->sg_request);
1456: timer_delete(&vub300->sg_transfer_timer);
1457: if (vub300->sg_request.status < 0) {
1458: cmd->error = vub300->sg_request.status;
1459: data->bytes_xfered = 0;
1460: return 0;
1461: } else {
1462: data->bytes_xfered = vub300->datasize;
1463: return linear_length;
1464: }
1465: }
1466: } else {
1467: u8 *buf = kmalloc(padded_length, GFP_KERNEL);
1468: if (buf) {
1469: int result;
1470: unsigned pipe = usb_rcvbulkpipe(vub300->udev,
1471: vub300->data_inp_ep);
1472: int actual_length = 0;
1473: result = vub300_usb_bulk_msg(vub300, pipe, buf,
1474: padded_length, &actual_length,
1475: 2000 + (padded_length / 16384));
1476: if (result < 0) {
1477: cmd->error = result;
1478: data->bytes_xfered = 0;
1479: kfree(buf);
1480: return 0;
1481: } else if (actual_length < linear_length) {
1482: cmd->error = -EREMOTEIO;
1483: data->bytes_xfered = 0;
1484: kfree(buf);
1485: return 0;
1486: } else {
1487: sg_copy_from_buffer(data->sg, data->sg_len, buf,
1488: linear_length);
1489: kfree(buf);
1490: data->bytes_xfered = vub300->datasize;
1491: return linear_length;
1492: }
1493: } else {
1494: cmd->error = -ENOMEM;
1495: data->bytes_xfered = 0;
1496: return 0;
1497: }
1498: }
1499: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 52/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 69544
output: 45
thoughts: 893
Thoughts: **Analyzing the `timer_delete` Call and Potential Race Conditions**
Okay, so I see `timer_delete` being called on `vub300->sg_transfer_timer`. This is just an alias for `del_timer`, so that's straightforward. But, what about the `inactivity_timer`? Ah, I see, it's *never* deleted explicitly! This is a key point.
This means the `inactivity_timer` will *always* fire eventually. And when it fires, it calls `kref_put`. Since `vub300_disconnect` drops another reference, the timer *will always* be the one dropping the last reference! And `vub300_delete` gets called from the timer callback. This precisely matches the scenario described in that bug report.
Now, is there any memory corruption here? If `vub300_delete` gets called from within the timer callback, it *will* free `vub300`. Since the timer callback is actively executing, the timer itself is not pending at this point. The critical question: Is it safe to free the memory containing the timer from within the timer callback?
Yes, it is, as long as the timer isn't re-armed and the callback doesn't try to access the now-freed memory afterward. Let's look at `vub300_inactivity_timer_expired`:
```c
if (!vub300->interface) {
kref_put(&vub300->kref, vub300_delete);
} else if (vub300->cmd) {
mod_timer(&vub300->inactivity_timer, jiffies + HZ);
} else {
vub300_queue_dead_work(vub300);
mod_timer(&vub300->inactivity_timer, jiffies + HZ);
}
```
If `!vub300->interface` is true, it calls `kref_put`, which in turn calls `vub300_delete`, freeing `vub300`. But *after* `kref_put` returns, the timer callback simply returns; it doesn't access `vub300` any further. So, freeing the timer's memory from within its own callback is perfectly safe in this control flow!
The *only* issue I see is that `vub300_delete` calls `mmc_free_host`, which in turn calls `cancel_delayed_work_sync`, which then calls `might_sleep()`. Since we're in softirq context here, that call to `might_sleep()` will generate a warning. However, as I've analyzed, `cancel_delayed_work_sync` won't actually sleep because the work is already cancelled and not running. It's just a warning, then.
But what if the work WAS running? Could `host->detect` be running when `vub300_delete` gets called? `host->detect` is cancelled in `mmc_remove_host`, which calls `mmc_stop_host`, which calls `cancel_delayed_work_sync(&host->detect)`. Therefore, `host->detect` is *definitely* not running after `mmc_remove_host` returns. And `vub300_disconnect` calls `mmc_remove_host` *before* calling `kref_put`. This means that when the timer fires and calls `vub300_delete`, `host->detect` won't be running. So that `cancel_delayed_work_sync` *won't* sleep, and will just print a warning.
Any other concerns? Let's consider `vub300->pollwork`, `vub300->cmndwork`, and `vub300->deadwork`. Are these cancelled properly? Let's jump to the definition of `vub300_delete`.
|
| 53/2 |
2026/08/15 01:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_delete]
Results: map[SourceCode: 369: static void vub300_delete(struct kref *kref)
370: { /* kref callback - softirq */
371: struct vub300_mmc_host *vub300 = kref_to_vub300_mmc_host(kref);
372: struct mmc_host *mmc = vub300->mmc;
373:
374: usb_free_urb(vub300->command_out_urb);
375: vub300->command_out_urb = NULL;
376: usb_free_urb(vub300->command_res_urb);
377: vub300->command_res_urb = NULL;
378: usb_put_dev(vub300->udev);
379: mmc_free_host(mmc);
380: /*
381: * and hence also frees vub300
382: * which is contained at the end of struct mmc
383: */
384: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 54/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 71723
output: 45
thoughts: 75
Thoughts: Here's my take on the situation:
**Urgent Considerations Regarding Resource Management**
Okay, hold on a second...it just hit me. This `vub300_delete` function *doesn't* automatically cancel those critical background processes: `pollwork`, `cmndwork`, and `deadwork`. That's a huge oversight, potentially a massive vulnerability! If any of those tasks are still in a pending or active state when `vub300` gets freed, they're going to try accessing that memory after it's been deallocated. That's a guaranteed disaster - a classic use-after-free scenario. We're looking at potential crashes, corrupted data, and possibly even more severe security implications.
The obvious question now is: where *are* we ensuring these workers are stopped? I need to check `vub300_disconnect` immediately. Hopefully, those tasks are being properly canceled there, and all is safe. If not, we have a serious bug on our hands.
|
| 55/2 |
2026/08/15 01:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_disconnect]
Results: map[SourceCode:2373: static void vub300_disconnect(struct usb_interface *interface)
2374: { /* NOT irq */
2375: struct vub300_mmc_host *vub300 = usb_get_intfdata(interface);
2376: if (!vub300 || !vub300->mmc) {
2377: return;
2378: } else {
2379: struct mmc_host *mmc = vub300->mmc;
2380: if (!vub300->mmc) {
2381: return;
2382: } else {
2383: int ifnum = interface_to_InterfaceNumber(interface);
2384: usb_set_intfdata(interface, NULL);
2385: /* prevent more I/O from starting */
2386: vub300->interface = NULL;
2387: mmc_remove_host(mmc);
2388: kref_put(&vub300->kref, vub300_delete);
2389: pr_info("USB vub300 remote SDIO host controller[%d]"
2390: " now disconnected", ifnum);
2391: return;
2392: }
2393: }
2394: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 56/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 72466
output: 50
thoughts: 58
Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing as an expert:
**Investigating a Disconnect Issue**
Alright, hang on a second. I'm clearly missing something crucial. I was looking for the command cancellations within the `vub300_disconnect` function, but it's jumping out at me that they aren't happening there. That's not the right place to be looking.
Wait a minute...if commands are *pending*, that inherently means they must maintain a reference, a handle, to the `vub300` object itself. That's the key! It gives me a crucial clue to follow. Instead of focusing on the cancellation process itself within `vub300_disconnect`, I need to identify where this "pending" state is being established. My attention must shift. The "queue" is the common term used in this kind of scenario. My next step is obvious - I must dive straight into `vub300_queue_cmnd_work`. That's where the pending state is established. It's time to follow the trail.
|
| 57/2 |
2026/08/15 01:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_queue_cmnd_work]
Results: map[SourceCode: 386: static void vub300_queue_cmnd_work(struct vub300_mmc_host *vub300)
387: {
388: kref_get(&vub300->kref);
389: if (queue_work(cmndworkqueue, &vub300->cmndwork)) {
390: /*
391: * then the cmndworkqueue was not previously
392: * running and the above get ref is obvious
393: * required and will be put when the thread
394: * terminates by a specific call
395: */
396: } else {
397: /*
398: * the cmndworkqueue was already running from
399: * a previous invocation and thus to keep the
400: * kref counts correct we must undo the get
401: */
402: kref_put(&vub300->kref, vub300_delete);
403: }
404: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 58/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 73149
output: 49
thoughts: 94
Thoughts: Okay, let me break this down.
**Understanding `queue_work` and Threading Logic**
Right, so `queue_work` is crucial here. It's telling me whether something *new* has been added to the work queue. If it returns `true`, then the work wasn't already pending, and a reference to the work is being held. Essentially, that means the system's tracking this new task. Conversely, if `queue_work` returns `false`, the work was *already* queued (or is running), so there's no need to track it as the system is already handling it, and the reference is dropped. Makes sense; you don't want duplicate entries.
So, the key takeaway is: if a reference exists, it means the work is either newly queued, currently pending execution, or actively running. Once the work completes, that reference is subsequently released. It's a nice, clean way to manage the lifecycle of this work item. Now I need to see how `vub300_cmndwork_thread` interacts with this process. That's the next piece of the puzzle.
|
| 59/2 |
2026/08/15 01:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c Name:vub300_cmndwork_thread]
Results: map[SourceCode:1736: /* this thread runs only when there is an upper level command req outstanding */
1737: static void vub300_cmndwork_thread(struct work_struct *work)
1738: {
1739: struct vub300_mmc_host *vub300 =
1740: container_of(work, struct vub300_mmc_host, cmndwork);
1741: if (!vub300->interface) {
1742: kref_put(&vub300->kref, vub300_delete);
1743: return;
1744: } else {
1745: struct mmc_request *req = vub300->req;
1746: struct mmc_command *cmd = vub300->cmd;
1747: struct mmc_data *data = vub300->data;
1748: bool reset_device;
1749: int data_length;
1750: mutex_lock(&vub300->cmd_mutex);
1751: init_completion(&vub300->command_complete);
1752: if (likely(vub300->vub_name[0]) || !vub300->mmc->card) {
1753: /*
1754: * the name of the EMPTY Pseudo firmware file
1755: * is used as a flag to indicate that the file
1756: * has been already downloaded to the VUB300 chip
1757: */
1758: } else if (0 == vub300->mmc->card->sdio_funcs) {
1759: strscpy(vub300->vub_name, "SD memory device",
1760: sizeof(vub300->vub_name));
1761: } else {
1762: download_offload_pseudocode(vub300);
1763: }
1764: send_command(vub300);
1765: if (!data)
1766: data_length = 0;
1767: else if (MMC_DATA_READ & data->flags)
1768: data_length = __command_read_data(vub300, cmd, data);
1769: else
1770: data_length = __command_write_data(vub300, cmd, data);
1771: reset_device = __vub300_command_response(vub300, cmd,
1772: data, data_length);
1773: vub300->req = NULL;
1774: vub300->cmd = NULL;
1775: vub300->data = NULL;
1776: if (cmd->error) {
1777: if (cmd->error == -ENOMEDIUM)
1778: check_vub300_port_status(vub300);
1779: mutex_unlock(&vub300->cmd_mutex);
1780: if (reset_device) {
1781: int result;
1782:
1783: result = usb_lock_device_for_reset(vub300->udev,
1784: vub300->interface);
1785: if (result == 0) {
1786: result = usb_reset_device(vub300->udev);
1787: usb_unlock_device(vub300->udev);
1788: }
1789: }
1790: mmc_request_done(vub300->mmc, req);
1791: kref_put(&vub300->kref, vub300_delete);
1792: return;
1793: } else {
1794: construct_request_response(vub300, cmd);
1795: vub300->resp_len = 0;
1796: mutex_unlock(&vub300->cmd_mutex);
1797: kref_put(&vub300->kref, vub300_delete);
1798: mmc_request_done(vub300->mmc, req);
1799: return;
1800: }
1801: }
1802: }
SourceFile:drivers/mmc/host/vub300.c]
|
| 60/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 74777
output: 63
thoughts: 1121
Thoughts: **Analysis of the vub300 Driver's Disconnect Sequence and Potential Warning**
Okay, so `vub300_cmndwork_thread` *does* call `kref_put` at the end, that's good. That reference count mechanism means that while the work is running or pending, `vub300_delete` won't be called. This eliminates any immediate use-after-free concerns. Great. This confirms my intuition.
The only remaining issue is that pesky `might_sleep()` warning within `cancel_delayed_work_sync` called from `vub300_delete`, especially since `vub300_delete` executes in the softirq context when triggered by the inactivity timer. However, if the work is already cancelled, the sync function *shouldn't* actually sleep, so it's a false positive, right?
But, wait... could `cancel_delayed_work_sync` *ever* sleep in this context? Ah, it sleeps if the work is running. Could `host->detect` (a delayed work item) be running when `vub300_delete` is invoked? `host->detect` gets cancelled in `mmc_remove_host`. This function also calls `mmc_stop_host`, which does the cancel. So, `mmc_remove_host` does indeed wait for `host->detect` to complete. After `mmc_remove_host` returns, `host->detect` should be done. And `host->rescan_disable` is set, so it's guaranteed not to be re-queued. Then `vub300_disconnect` drops a reference, and the timer then fires and calls `vub300_delete`. `vub300_delete` calls `mmc_free_host`, which *also* calls `cancel_delayed_work_sync(&host->detect)`. Since `host->detect` is already finished, `cancel_delayed_work_sync` returns immediately, so no sleep. So the function *never* actually sleeps in this scenario. It just prints that warning.
Now, wait, what if `vub300_delete` *is* called from the `vub300_cmndwork_thread`? In this situation, the thread, in process context, drops the last reference and calls `vub300_delete`. That `might_sleep()` in `cancel_delayed_work_sync` is perfectly acceptable in the process context! No warning! The warning *only* happens when the timer callback (`vub300_inactivity_timer_expired`) calls `vub300_delete`. And since the timer is *never* deleted, it will always fire eventually. If the timer fires *after* `vub300_disconnect` drops its reference, then the warning happens.
So, this is a *reproducible* warning upon device disconnect. Okay, is this a security vulnerability? In most production kernels, `panic_on_warn` isn't enabled. So, it's just a log message, no crash, no memory corruption, no information leakage. So, the kernel doesn't crash, it just logs a message. It's just a warning.
Could this cause a denial of service? Only if `panic_on_warn` is set, but we assume a standard production build. If it's not set, it's just a log message.
Does `might_sleep()` in softirq context cause any other issues? No, all it does is warn and provide a stack trace.
Can an unprivileged user trigger this? The bug is triggered when the device is disconnected or the driver is unbound. Unbinding a driver needs root privileges. Disconnecting the device requires physical access. Is there a way for an unprivileged user to unplug the device? No, unless they have physical access.
Can an unprivileged user trigger the timer to fire? The timer is armed in `vub300_probe` and re-armed in `vub300_mmc_request` and `vub300_inactivity_timer_expired`. It fires every second. As long as the device is connected it will fire. However, it *only* drops a reference if `!vub300->interface`. And `vub300->interface` is only set to NULL in `vub300_disconnect`. Thus, the warning *only* happens when the device is disconnected.
This makes it a peripheral trigger.
Let me double-check if there's any other way to set `vub300->interface` to NULL, just to be sure...
|
| 61/2 |
2026/08/15 01:40 |
tool |
codesearch-find-references |
0m
Args: map[ContextFile:drivers/mmc/host/vub300.c IncludeSnippetLines:0 Name:vub300_mmc_host::interface SourceTreePrefix:]
Results: map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_cmndwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:1741] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_cmndwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:1784] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_deadwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:713] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:vub300_disconnect SourceFile:drivers/mmc/host/vub300.c SourceLine:2386] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_enable_sdio_irq SourceFile:drivers/mmc/host/vub300.c SourceLine:2058] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_inactivity_timer_expired SourceFile:drivers/mmc/host/vub300.c SourceLine:746] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1912] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_request SourceFile:drivers/mmc/host/vub300.c SourceLine:1933] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_mmc_set_ios SourceFile:drivers/mmc/host/vub300.c SourceLine:2017] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:vub300_pollwork_thread SourceFile:drivers/mmc/host/vub300.c SourceLine:682] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2210] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:vub300_probe SourceFile:drivers/mmc/host/vub300.c SourceLine:2352]] TruncatedOutput:false]
|
| 62/2 |
2026/08/15 01:40 |
llm |
expert |
0m
Model:
Tokens:
input: 77745
output: 40
thoughts: 812
Thoughts: **My Analysis of the VUB300 Driver Issue**
Okay, let's break this down. From what I'm seeing, `vub300_probe` sets the `vub300_probe` to either an `interface` or `NULL` on an error path, and it does the same in `vub300_disconnect` with a `NULL` assignment. So, if the device disconnects or if probe fails, it's set to `NULL`. The probe error path is interesting because `vub300_probe` calls `kref_put` and I see the timer getting armed.
Now, if `mmc_add_host` fails, `vub300->interface` gets set to `NULL`, and `kref_put` gets called. Bingo - the timer is armed! So, the timer's callback will fire later, realize `!vub300->interface`, and then call `kref_put`, which is what triggers the warning. The thing is, `mmc_add_host` failing isn't something a normal user can trigger easily, and even if they could, it just results in a warning.
So, here's my assessment of the impact:
* **Exploitable:** No. This is really just a **WARNING**. `cancel_delayed_work_sync` calls `might_sleep()`, but it doesn't actually sleep and there's no memory corruption or use-after-free, so it's all fine.
* **Denial of Service:** Also no, it's just a warning. This isn't crashing production kernels!
* **Access from Unprivileged/User Namespaces/VM Guest/Host/Network/Filesystem:** No for all these. It is not really a system-level issue.
* **Peripheral Trigger:** Yes, plugging in a VUB300 device, malicious or otherwise, and then unplugging it will trigger the warning.
Now, wait...is there a potential for a deadlock? If `cancel_delayed_work_sync` is called from a softirq and the work is running on the same CPU, it could deadlock. However, from my analysis, `host->detect` is *definitely* NOT running when `vub300_delete` is called. `vub300_disconnect` calls `mmc_remove_host`, which waits for `host->detect` to finish and disables it, and `vub300_delete` is called *after* `vub300_disconnect` has dropped its reference. This means `host->detect` is already cancelled, and can't be running. So, `cancel_delayed_work_sync` will NEVER deadlock.
Is there any other work that could be running? `mmc_free_host` only cancels `host->detect` so let's check `mmc_free_host`...
|
| 63/2 |
2026/08/15 01:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/core/host.c Name:mmc_free_host]
Results: map[SourceCode: 692: /**
693: * mmc_free_host - free the host structure
694: * @host: mmc host
695: *
696: * Free the host once all references to it have been dropped.
697: */
698: void mmc_free_host(struct mmc_host *host)
699: {
700: cancel_delayed_work_sync(&host->detect);
701: mmc_pwrseq_free(host);
702: put_device(&host->class_dev);
703: }
SourceFile:drivers/mmc/core/host.c]
|
| 64/2 |
2026/08/15 01:41 |
llm |
expert |
0m
Model:
Tokens:
input: 79445
output: 43
thoughts: 44
Thoughts: Here's my take on the process, framed as my own internal thought process:
**Deconstructing mmc_free_host's Cleanup**
Okay, so I'm looking at `mmc_free_host`. My immediate concern is always resource management, especially with devices. It seems like the core cleanup here is tied to the `put_device(&host->class_dev)` call. This is key: I know `put_device` is the standard kernel mechanism for decrementing a device's reference count. My brain immediately runs through the implications. This means, somewhere earlier, the `class_dev` had its refcount incremented - probably during initialization or registration. Now, here, we're releasing our hold on the device.
The critical piece here is the *when* of the deallocation. The text says that when the refcount hits zero, that's what triggers the call to `mmc_host_classdev_release`. That's smart design, right? It means the cleanup of `host->class_dev` is deferred until all other users are done with it. We're not making assumptions about who is using this particular host, only ensuring that we release it once it is not needed anymore. This is a crucial design consideration to avoid race conditions. `mmc_host_classdev_release` is *the* callback that performs the actual deallocation, so I should be familiar with its implementation, as it will likely handle the host hardware specific cleanup. I need to keep that in mind.
|
| 65/2 |
2026/08/15 01:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/mmc/core/host.c Name:mmc_host_classdev_release]
Results: map[SourceCode: 66: static void mmc_host_classdev_release(struct device *dev)
67: {
68: struct mmc_host *host = cls_dev_to_mmc_host(dev);
69: wakeup_source_unregister(host->ws);
70: if (of_alias_get_id(host->parent->of_node, "mmc") < 0)
71: ida_free(&mmc_host_ida, host->index);
72: kfree(host);
73: }
SourceFile:drivers/mmc/core/host.c]
|
| 66/2 |
2026/08/15 01:41 |
llm |
expert |
0m
Model:
Tokens:
input: 80032
output: 66
thoughts: 1179
Thoughts: **Analysis of the `mmc_host_classdev_release` Issue**
Okay, let's break this down. `mmc_host_classdev_release` calls `kfree(host)`. Since `vub300` is allocated within `mmc_host`, this `kfree` actually frees `vub300` as well. This happens during a softirq context, which *should* be fine for `kfree`. The problem is the `might_sleep()` warning.
Essentially, the *only* issue here is that warning. This warning arises from a function, `cancel_delayed_work_sync`, that *might* sleep being called from an atomic context (the timer callback). However, it *doesn't* actually sleep because the work is already cancelled. So, no deadlock, no memory corruption. We're safe on that front. It's not exploitable, and it won't lead to a Denial of Service unless, of course, `panic_on_warn` is set, which is unlikely. So, `Exploitable` is `false`, `DenialOfService` is `false`.
The good news is that this is a bug that can be triggered by a physical peripheral device β so, `PeripheralTrigger` is `true`.
Now, I need to check every angle here to be absolutely sure. Can an unprivileged user cause this? Nope, they can't disconnect USB devices or unbind drivers. Remote trigger? No way.
Let's review the trigger conditions: `Exploitable: False`, `DenialOfService: False`, `Unprivileged: False`, `UserNamespace: False`, `VMGuestTrigger: False`, `VMHostTrigger: False`, `NetworkTrigger: False`, `RemoteTrigger: False`, `PeripheralTrigger: True`, `FilesystemTrigger: False`.
Wait. Let me think about `vub300_delete` and the interaction with `vub300_disconnect`. If the timer fires *before* `vub300_disconnect`, it sees `vub300->interface != NULL`, doesn't call `kref_put`. Then, `vub300_disconnect` sets `vub300->interface = NULL` and *does* call `kref_put`. The timer *then* fires again (because it re-arms), sees `!vub300->interface`, and calls `kref_put`. The *last* reference is dropped, and `vub300_delete` is called from the timer context. So `vub300_delete` *always* gets called from the timer! Unless the timer is deleted, which it never is...
Wait, what if `vub300_disconnect` is called *before* the `vub300_cmndwork_thread` is finished?
`vub300_cmndwork_thread` holds a reference.
The timer fires, sees `!vub300->interface`, and calls `kref_put`.
This drops the timer's reference.
Then `vub300_cmndwork_thread` finishes, and calls `kref_put`.
This drops the *last* reference. And `vub300_delete` is called from the process context!
The warning is NOT triggered!
So, the timer is still pending?
No, the timer *fired* and didn't re-arm itself (because `!vub300->interface`).
So the timer is not pending any more.
So, if `vub300_cmndwork_thread` finishes *after* the timer fires, then `vub300_delete` will be called from process context, and there's no warning.
If the timer fires *after* `vub300_cmndwork_thread` finishes, then `vub300_delete` is called from softirq context, and the warning *is* triggered.
The timing is non-deterministic, so the warning is triggered *sometimes*. There's no use-after-free in *either* scenario. Because the last reference is dropped by the code path that finishes last. And the timer doesn't re-arm itself if `!vub300->interface`.
Wait. Let's make sure. The timer fires, sees `!vub300->interface`, and then calls `kref_put`. The timer *doesn't* re-arm itself. The timer is no longer pending. `vub300_cmndwork_thread` finishes, calls `kref_put`, and then calls `vub
|
| 67/2 |
2026/08/15 01:41 |
tool |
set-results |
0m
Args: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:true RemoteTrigger:false Unprivileged:false UserNamespace:false VMGuestTrigger:false VMHostTrigger:false]
Results: map[DenialOfService:false Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:true RemoteTrigger:false Unprivileged:false UserNamespace:false VMGuestTrigger:false VMHostTrigger:false]
|
| 68/2 |
2026/08/15 01:41 |
llm |
expert |
0m
Model:
Tokens:
input: 82366
output: 593
thoughts: 408
Thoughts: **My Analysis of the VUB300 MMC Driver Issue**
Okay, the results are in, and it's time to craft the final response. My assessment points directly to a warning within the `vub300` MMC driver, specifically related to how it handles USB device disconnection. The core of the problem lies in the interaction between the disconnect process and the inactivity timer.
When the USB device is unplugged, the `vub300_disconnect` function is correctly called. It nulls out `vub300->interface` and drops its reference to the `vub300` object, as expected. The driver also uses an `inactivity_timer` that periodically checks `vub300->interface`. If this interface is NULL, the timer drops its own reference to the `vub300` object and does not re-arm.
Now, hereβs where it gets interesting. If this timer happens to be the last piece of code with a reference to the `vub300` object (say, all workqueues have completed), the subsequent `kref_put` call in the timer callback will then trigger `vub300_delete`. `vub300_delete` then calls `mmc_free_host`, which in turn calls `cancel_delayed_work_sync(&host->detect)`.
The crucial detail here is that `cancel_delayed_work_sync` includes a `might_sleep()` check. This check *does* generate a warning because the function is being called from a timer callback, which is a softirq/atomic context. However, it's not a real issue because the `host->detect` has *already* been cancelled synchronously in `vub300_disconnect` through `mmc_remove_host`. So, `cancel_delayed_work_sync` returns immediately without blocking.
Importantly, there's no risk of a use-after-free scenario. The timer callback *still* holds a valid reference to the `vub300` object during its execution. It doesn't re-arm itself after dropping its reference, so this is handled correctly.
Therefore, the issue is a harmless warning that can be triggered simply by physically unplugging the USB device. It poses no risk of memory corruption, privilege escalation, or denial of service in production builds where `panic_on_warn` is disabled. This is a peripheral trigger, but the effect is limited to that warning message.
|
| 69/1 |
2026/08/15 01:41 |
action |
format-explanation |
0m
Results: map[Explanation:The bug report indicates a `WARNING` caused by calling a blocking operation
(`cancel_delayed_work_sync`) from an atomic context (a timer callback).
### Root Cause Analysis
The issue resides in the `vub300` USB-SD/SDIO host controller driver.
During initialization (`vub300_probe`), the driver sets up an `inactivity_timer`
that periodically fires to check for inactivity. The timer holds a reference
count (`kref`) to the `vub300` host object.
When the USB device is physically unplugged, `vub300_disconnect` is invoked. It
sets `vub300->interface = NULL`, synchronously cancels the MMC host detection
work (via `mmc_remove_host`), and drops its reference to the `vub300` object.
Later, when the `inactivity_timer` fires, it notices that `vub300->interface` is
`NULL`. It then drops its own reference to the object and does not re-arm
itself. If this timer happens to be the last entity holding a reference (e.g.,
all pending workqueues have finished), the `kref_put` call will invoke the
release function `vub300_delete` directly from the timer's softirq context.
`vub300_delete` calls `mmc_free_host`, which in turn calls
`cancel_delayed_work_sync(&host->detect)`. The `cancel_delayed_work_sync`
function contains a `might_sleep()` check, which triggers the `WARNING` because
sleeping is not allowed in softirq context.
### Security Impact
Despite the warning, this bug does not pose a security risk:
1. **No Actual Sleep/Deadlock**: Because `host->detect` was already
synchronously cancelled and disabled during `vub300_disconnect`,
`cancel_delayed_work_sync` will find no work to wait for and will return
immediately without actually calling `schedule()`.
2. **No Memory Corruption**: The timer properly holds a reference count to the
`vub300` object and does not re-arm itself after dropping it. The object is
safely freed without any use-after-free conditions.
3. **No Denial of Service**: In production kernel builds (where `panic_on_warn`
is disabled), the `WARNING` simply prints a stack trace to the kernel log and
execution continues normally.
### Trigger Vectors
The bug is triggered by the normal disconnection process of the VUB300 USB
device. Therefore, it requires physical access to plug and unplug the specific
USB peripheral (or a malicious device emulating it). It cannot be triggered
remotely or by unprivileged users interacting with the system.]
|