* [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
@ 2026-11-05 21:29 Kuniyuki Iwashima
2026-11-05 21:37 ` netdev-bot+sinfo
2026-11-10 23:40 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 6+ messages in thread
From: Kuniyuki Iwashima @ 2026-11-05 21:29 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
__sk_mem_raise_allocated() calls sk_memory_allocated_add() and
reuses the return value to check if it was called.
However, sk_memory_allocated_{add,sub}() cache a value in per-cpu
counter, sk->sk_prot->per_cpu_fw_alloc, up to sysctl_mem_pcpu_rsv
before reflecting it to sk->sk_prot->memory_allocated.
Thus, sk->sk_prot->memory_allocated could have a negative value,
and proto_memory_allocated() returns 0 in such a case.
Then, if mem_cgroup_sk_charge() succeeds, sk_prot_mem_limits()
checks are bypassed, and if mem_cgroup_sk_charge() fails,
sk_memory_allocated_sub() is not called, leaking counters.
Let's use sk->sk_bypass_prot_mem instead of allocated.
Fixes: 7c268eaeec63 ("net: Allow opt-out from global protocol memory accounting.")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
Found this while converting sk_memcg to obj_cgroup.
---
net/core/sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index e2401d735c5a..ad414878dc5b 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -3427,7 +3427,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
goto suppress_allocation;
}
- if (!allocated)
+ if (sk->sk_bypass_prot_mem)
return 1;
/* Under limit. */
@@ -3508,7 +3508,7 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
trace_sock_exceed_buf_limit(sk, prot, allocated, kind);
- if (allocated)
+ if (!sk->sk_bypass_prot_mem)
sk_memory_allocated_sub(sk, amt);
if (charged)
--
2.56.0.455.g6c5a503b38-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
2026-11-05 21:29 [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated() Kuniyuki Iwashima
@ 2026-11-05 21:37 ` netdev-bot+sinfo
2026-11-05 21:45 ` Kuniyuki Iwashima
2026-11-10 23:40 ` patchwork-bot+netdevbpf
1 sibling, 1 reply; 6+ messages in thread
From: netdev-bot+sinfo @ 2026-11-05 21:37 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, netdev
Hi!
This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:
- Whether the issue was actually triggered, or is only theoretical
(e.g. found by code inspection). If it was triggered please include
the symptoms, like the stack trace or error messages.
Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
2026-11-05 21:37 ` netdev-bot+sinfo
@ 2026-11-05 21:45 ` Kuniyuki Iwashima
2026-11-10 23:25 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Kuniyuki Iwashima @ 2026-11-05 21:45 UTC (permalink / raw)
To: netdev-bot+sinfo
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, netdev
On Thu, Nov 5, 2026 at 1:37 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
> - Whether the issue was actually triggered, or is only theoretical
> (e.g. found by code inspection).
"Found this while converting sk_memcg to obj_cgroup."
> If it was triggered please include
> the symptoms, like the stack trace or error messages.
"Then, if mem_cgroup_sk_charge() succeeds, sk_prot_mem_limits()
checks are bypassed, and if mem_cgroup_sk_charge() fails,
sk_memory_allocated_sub() is not called, leaking counters."
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
2026-11-05 21:45 ` Kuniyuki Iwashima
@ 2026-11-10 23:25 ` Jakub Kicinski
2026-11-11 0:19 ` Kuniyuki Iwashima
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Kicinski @ 2026-11-10 23:25 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: netdev-bot+sinfo, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, netdev
On Thu, 5 Nov 2026 13:45:21 -0800 Kuniyuki Iwashima wrote:
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> >
> > - Whether the issue was actually triggered, or is only theoretical
> > (e.g. found by code inspection).
>
> "Found this while converting sk_memcg to obj_cgroup."
I assume you mean to imply that this sentence answers the question of
whether it was triggered, but either I'm too limited or it doesn't.
It only explains how you find the issue, which is _not_ what the bot
is asking.
> > If it was triggered please include
> > the symptoms, like the stack trace or error messages.
>
> "Then, if mem_cgroup_sk_charge() succeeds, sk_prot_mem_limits()
> checks are bypassed, and if mem_cgroup_sk_charge() fails,
> sk_memory_allocated_sub() is not called, leaking counters."
"symptoms" mean dmesg basically. Please suggest better phrasing,
if you can think of it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
2026-11-10 23:25 ` Jakub Kicinski
@ 2026-11-11 0:19 ` Kuniyuki Iwashima
0 siblings, 0 replies; 6+ messages in thread
From: Kuniyuki Iwashima @ 2026-11-11 0:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev-bot+sinfo, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, netdev
On Tue, Nov 10, 2026 at 3:25 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 5 Nov 2026 13:45:21 -0800 Kuniyuki Iwashima wrote:
> > > This is an automated message. This series looks like a fix, but its
> > > commit messages seem to be missing some information:
> > >
> > > - Whether the issue was actually triggered, or is only theoretical
> > > (e.g. found by code inspection).
> >
> > "Found this while converting sk_memcg to obj_cgroup."
>
> I assume you mean to imply that this sentence answers the question of
> whether it was triggered, but either I'm too limited or it doesn't.
> It only explains how you find the issue, which is _not_ what the bot
> is asking.
Sorry, I assumed it would fall under the latter category by
breaking the line (not before "or"), but I should have clarified that.
>
> > > If it was triggered please include
> > > the symptoms, like the stack trace or error messages.
> >
> > "Then, if mem_cgroup_sk_charge() succeeds, sk_prot_mem_limits()
> > checks are bypassed, and if mem_cgroup_sk_charge() fails,
> > sk_memory_allocated_sub() is not called, leaking counters."
>
> "symptoms" mean dmesg basically. Please suggest better phrasing,
> if you can think of it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
2026-11-05 21:29 [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated() Kuniyuki Iwashima
2026-11-05 21:37 ` netdev-bot+sinfo
@ 2026-11-10 23:40 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 6+ messages in thread
From: patchwork-bot+netdevbpf @ 2026-11-10 23:40 UTC (permalink / raw)
To: Kuniyuki Iwashima; +Cc: davem, edumazet, kuba, pabeni, horms, kuni1840, netdev
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Nov 2026 21:29:00 +0000 you wrote:
> __sk_mem_raise_allocated() calls sk_memory_allocated_add() and
> reuses the return value to check if it was called.
>
> However, sk_memory_allocated_{add,sub}() cache a value in per-cpu
> counter, sk->sk_prot->per_cpu_fw_alloc, up to sysctl_mem_pcpu_rsv
> before reflecting it to sk->sk_prot->memory_allocated.
>
> [...]
Here is the summary with links:
- [v1,net] net: Fix memory_allocated leak in __sk_mem_raise_allocated().
https://git.kernel.org/netdev/net/c/8012eec76b7e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-11-11 0:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-05 21:29 [PATCH v1 net] net: Fix memory_allocated leak in __sk_mem_raise_allocated() Kuniyuki Iwashima
2026-11-05 21:37 ` netdev-bot+sinfo
2026-11-05 21:45 ` Kuniyuki Iwashima
2026-11-10 23:25 ` Jakub Kicinski
2026-11-11 0:19 ` Kuniyuki Iwashima
2026-11-10 23:40 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox