Re: [PATCH v2 1/2] powercap: dtpm_cpu: Guard em_cpu_get() against NULL return in sysfs callbacks

[Elazar Leibovich]

On Wed, 24 Jun 2026 at 23:44, Daniel Lezcano
<daniel.lezcano@xxxxxxxxxxxxxxxx> wrote:
>
>
> Can you provide a script or a recipe spotting these issues ?
>
Thanks!

I'll describe the thought process.

In 46dc57406887 we found a single instance of `em_cpu_get()` without a
NULL check even though it can return a NULL. I think the catalyst was
seeing that this function could return NULL and not seeing NULL test
on a call site.

After some discussion we concluded that when a CPU becomes impossible
`em_cpu_get` can race and dereference a NULL pointer theoretically.

While we acknowledge this isn't a huge issue, a NULL test in a
non-critical path doesn't seem like a huge issue either.

We grep'ed the code for other usages of em_cpu_get, and traced the
calling process to see if they can race a CPU becoming impossible.

(While looking at the code, we noticed the rcu does not guard the PD
pointer, but that's for another WIP patch)

I'm not sure if that's was the question, but we used AI to:

1. Trace the possible call stack of a function. It did a tremendous
job there. Faster and more precise than myself, seeing through
"vtables" and describing the callstack correctly.
2. Find similar cases of RCU used in the kernel, and try to imitate
the behavior (for the not-yet-sent RCU WIP patch)
3. General kernel chores (find maintainers list, running sparse, etc.)
4. Create a reproducer for the RCU race to test it on a VM.

Let me know if you want more details!