From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
Sashiko <sashiko-bot@kernel.org>, Zihan Xi <zihanx@nebusec.ai>
Subject: Re: [PATCH 3/3] can: enable memcg accounting for user triggered allocations
Date: Sun, 8 Nov 2026 09:25:02 +0100 [thread overview]
Message-ID: <avAx3l9-EFrSN8IN@pengutronix.de> (raw)
In-Reply-To: <20261107-can-bcmlock-memcg-v1-3-482d9f5be1fd@hartkopp.net>
On Sat, Nov 07, 2026 at 02:06:46PM +0100, Oliver Hartkopp wrote:
> Unprivileged users can create CAN sockets and trigger allocations that
> stay in the kernel for the lifetime of the socket or of the related
> objects. E.g. each CAN_BCM RX_SETUP for a new CAN ID creates a bcm_op
> with optional frame arrays of up to 257 CAN FD frames and a CAN
> receiver, without requiring a CAN device (ifindex 0) and without a
> limit for the number of ops per socket.
>
> None of these allocations are accounted to the memory cgroup of the
> process that triggers them. So a process can bypass the memory limit
> of its cgroup, e.g. of a container or a systemd service, and exhaust
> the memory of the whole system. The OOM killer can not attribute this
> kernel memory to the responsible process either, which has nearly no
> RSS, and terminates unrelated processes instead.
>
> Enable memcg accounting for these allocations, as it has been done for
> other objects that can be created by unprivileged users. This does not
> introduce any new CAN specific limit and does not make assumptions
> about the number of sockets, filters or BCM operations an application
> needs. The CAN related kernel memory is just charged to the cgroup of
> the allocating process, so that the memory limits which are already
> configured for this cgroup apply to it as well. Without a configured
> limit the behaviour is unchanged.
>
> A per socket limit for the number or the memory of the BCM operations,
> as suggested in the reports, does not bound the memory consumption, as
> a process can open many sockets and fork. Hard-coded limits can also
> break existing applications, e.g. one that monitors all 2048 SFF CAN
> IDs with individual RX operations, without a possibility to adjust
> them.
>
> The following allocations are accounted:
>
> - af_can: the CAN socket structures (e.g. struct isotp_sock contains
> two DEFAULT_MAX_PDU_SIZE buffers), the CAN receivers of all CAN
> protocols and the per-netns receive lists and statistics
> - bcm: the bcm_op structures and their frames/last_frames arrays
> - raw: the per-cpu uniq data and the CAN_RAW_FILTER filters
> - isotp: the TX buffer for PDUs > DEFAULT_MAX_PDU_SIZE
> - j1939: the SO_J1939_FILTER filters and the per device j1939_priv,
> which is created by the first bind() to a CAN device
>
> The CAN socket structures are allocated with GFP_KERNEL_ACCOUNT in
> sk_alloc() instead of creating dedicated slab caches with
> proto_register(), as the CAN protocols copy socket options directly
> from their socket structures to user space, which would require
> usercopy whitelists for these caches.
>
> memdup_sockptr() does not support memcg accounting, so the filters are
> allocated and copied explicitly.
>
> The isotp RX buffer and the j1939 RX sessions are allocated in softirq
> context and can not be attributed to a process. The j1939 TX sessions
> only exist for the duration of a transfer and the can-gw jobs require
> CAP_NET_ADMIN in the initial user namespace, so they are not changed.
> Temporary buffers that are freed before the syscall returns are not
> accounted either.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260707-bcm_fixes-v5-0-c3c74f8d8ff7@hartkopp.net
> Reported-by: Zihan Xi <zihanx@nebusec.ai>
> Closes: https://lore.kernel.org/linux-can/cover.1793089479.git.zihanx@nebusec.ai/
> Link: https://lore.kernel.org/linux-can/350df96b-5f69-490e-b39e-ed6e9bca4754@hartkopp.net/
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> ---
> net/can/af_can.c | 12 +++++++-----
> net/can/bcm.c | 10 +++++-----
> net/can/isotp.c | 2 +-
> net/can/j1939/main.c | 2 +-
> net/can/j1939/socket.c | 11 ++++++++---
For the J1939 part:
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Thank you!
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2026-11-08 8:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 13:06 [PATCH 0/3] can: bcm: avoid RTNL stalls and enable memcg accounting Oliver Hartkopp
2026-11-07 13:06 ` [PATCH 1/3] can: bcm: copy the CAN frames outside of lock_sock() Oliver Hartkopp
2026-11-07 13:15 ` sashiko-bot
2026-11-07 13:29 ` Oliver Hartkopp
2026-11-09 2:18 ` netdev-bot+sashiko
2026-11-09 7:56 ` Oliver Hartkopp
2026-11-07 13:06 ` [PATCH 2/3] can: bcm: do not remove the procfs entry in bcm_notify() Oliver Hartkopp
2026-11-09 2:18 ` netdev-bot+sashiko
2026-11-09 8:00 ` Oliver Hartkopp
2026-11-07 13:06 ` [PATCH 3/3] can: enable memcg accounting for user triggered allocations Oliver Hartkopp
2026-11-07 13:14 ` sashiko-bot
2026-11-07 13:35 ` Oliver Hartkopp
2026-11-08 8:23 ` Oleksij Rempel
2026-11-08 8:21 ` Oleksij Rempel
2026-11-08 8:25 ` Oleksij Rempel [this message]
2026-11-09 2:18 ` netdev-bot+sashiko
2026-11-09 8:09 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avAx3l9-EFrSN8IN@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=sashiko-bot@kernel.org \
--cc=socketcan@hartkopp.net \
--cc=zihanx@nebusec.ai \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.