Re: [PATCH RFC 02/16] proc: add pde_pin() and pde_unpin()

[Christian Brauner]

On Wed, Nov 04, 2026 at 10:03:38PM +0300, Alexey Dobriyan wrote:
> Permanent flags is set after publishing PDE to the world,
> so there is a window where +1 is done but -1 is not done.

The patch doesn't add this. You did in ef1d61781bc6 ("proc: mark more
files as permanent") and a61c01e8f4a5 ("proc: mark /proc/cmdline as
permanent").

Both call pde_make_permanent() after proc_create_single() has published
the entry.

And then 912289ee831d ("proc: allow to mark /proc files permanent
outside of fs/proc/") handed that pattern to the rest of the tree this
year.

And the specific split is yours as well from d919b33dafb3 ("proc: faster
open/read/close with "permanent" files") which put the shortcut into
proc_reg_open() and proc_reg_release().

An open in your window lists a pde_opener. The release after it takes
your shortcut and that pde_opener is never unlisted or freed.

So pde_pin() inherits this bug.

But to be very clear: The bug is unreachable.

Every one of those is an initcall. There's zero userspace to open
anything at that point.

Fixing it is also easy? We just set the at registration for everything
that is permanent the same way ->proc_flags already does it and then
pde_make_permanent() can be killed.

> And then 2147483647 security researchers arrive and overflow it.

How? The window is one initcall per boot before there is any userspace.
And in_use starts from zero at every boot. Nothing accumulates.

The only thing that ever biases and waits for in_use is
proc_entry_rundown(), which never runs for an entry that is never
removed. A pin leaked on a permanent entry is a number nobody ever
reads.

> There is no detection of buggy usage: proc_make_permanent on dynamic
> PDEs from buggy modules. It's easy to grep but I'm not signing up for
> that.

Modules can't do that? You defined PROC_ENTRY_PERMANENT as 0 under
MODULE in d919b33dafb3 and you didn't export impl_proc_make_permanent()
in 912289ee831d.

And for built-in code the detection exists? It's your WARN in
remove_proc_entry() from the same 2020 commit. Nothing in this series
changes any of that.

I'm confused by this review.