linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 0/4] can: rework the CAN MTU logic (CAN XL preparation step 2/3)
@ 2025-09-23  6:37 Vincent Mailhol
  2025-09-23  6:37 ` [PATCH v3 1/4] can: annotate mtu accesses with READ_ONCE() Vincent Mailhol
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Vincent Mailhol @ 2025-09-23  6:37 UTC (permalink / raw)
  To: Oliver Hartkopp, Marc Kleine-Budde
  Cc: linux-can, linux-kernel, Vincent Mailhol

The CAN MTU logic is currently broken. can_change_mtu() will update
both the MTU and the CAN_CTRLMODE_FD flag.

Back then, commit bc05a8944a34 ("can: allow to change the device mtu
for CAN FD capable devices") stated that:

  The configuration can be done either with the 'fd { on | off }'
  option in the 'ip' tool from iproute2 or by setting the CAN
  netdevice MTU to CAN_MTU (16) or to CANFD_MTU (72).

  Link: https://git.kernel.org/torvalds/c/bc05a8944a34

The problem is that after doing for example:

  $ ip link set can0 mtu 72 bittiming 500000

on a CAN FD interface, we are left with a device on which CAN FD is
enabled but which does not have the FD databittiming parameters
configured.

The same goes on when setting the mtu back to 16:

  ip link set can0 type can bitrate 500000 fd on dbitrate 5000000
  ip link set can0 mtu 16

The device is now in Classical CAN mode but iproute2 is still
reporting the databittiming values (although this time, the issue
seems less critical as it is only a reporting problem).

The only way to resolve the problem and bring the device back to a
coherent state is to call again the netlink interface using the
"fd on" or "fd off" options.

The idea of being able to infer the CAN_CTRLMODE_FD flag from the MTU
value is just incorrect for physical devices. Note that this logic
remains valid on virtual interfaces (vcan and vxcan) because those do
not have control mode flags and thus no conflict occurs.

This series reworks the CAN MTU logic. The goal is to always maintain
a coherent state between the MTU and the control mode flags as listed
in below table:

		fd off, xl off		fd on, xl off		fd any, xl on
  ---------------------------------------------------------------------------
  default mtu	CAN_MTU			CANFD_MTU		CANXL_MTU
  min mtu	CAN_MTU			CANFD_MTU		CANXL_MIN_MTU
  max mtu	CAN_MTU			CANFD_MTU		CANXL_MAX_MTU

In order to switch between one column to another, the user must use
the fd/xl on/off flags. Directly modifying the MTU from one column to
the other is not permitted any more.

The CAN XL is not yet supported at the moment, so the last column is
just given as a reference to better understand what is coming up. This
series will just implement the first two columns.

While doing the rewrite, the logic is adjusted to reuse as much as
possible the net core infrastructure. By populating:

  net_device->min_mtu

and

  net_device->max_mtu

the net core infrastructure will automatically:

  1. validate that the user's inputs are in range.

  2. report those min and max MTU values through the netlink
     interface.

Point 1. will allow us to get rid of the can_change_mtu() in a near
future for all the physical devices and point 2. allows the end user
to see the valid MTU range by doing a:

  $ ip --details link show can0

Finally, because using the net core, it will be possible after the
removal of can_change_mtu() to modify the MTU while the device is up.
As stated previously, the only modifications allowed will be within
the MTU range of a given CAN protocol. So for Classical CAN and CAN
FD, the MTU is fixed to, respectively, CAN_MTU and CANFD_MTU. For the
upcoming CAN XL, the user will be able to change the MTU to anything
between CANXL_MIN_MTU and CANXL_MAX_MTU even if the device is up.

The first patch of this series annotates the read access on
net_device->mtu. This preparation is needed to prevent any race
condition to occur when modifying the MTU while the device is up.

The second patch is another preparation change which moves
can_set_static_ctrlmode() from dev.h to dev.c.

The third patch populates the MTU minimum and maximum value.

The fourth patch is just a clean-up to remove the old
can_change_mtu().

The fourth and last patch comes as a bonus content and modifies the
default MTU of the vcan and vxcan so that CAN XL is on by default.

Note that after this series, the old can_change_mtu() becomes
useless. That function can not yet be removed because some pending
changes from other maintainers' trees still depend on it. It will be
removed in the next development window once all those changes reach
net-next.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Changes in v3:

  - v2 was based on Linus tree and, as a result, my other series which
    depends on this one did not apply smoothly:

      https://lore.kernel.org/linux-can/13f98eed-b535-4360-a545-0a11dbc8aa12@kernel.org/

    Rebase on net-next.

Link to v2: https://lore.kernel.org/r/20250923-can-fix-mtu-v2-0-984f9868db69@kernel.org

Changes in v2:

  - Drop RFC prefix

  - Patch "can: treewide: remove can_change_mtu()" is removed because
    it depends on the MTU fix:

      https://lore.kernel.org/linux-can/20250918-can-fix-mtu-v1-0-0d1cada9393b@kernel.org/

    which at the time of writing, does not yet appear in net-next. It
    is also still used in the Nuvoton driver which is also not yet
    merged. This patch will be resent in the next development window.

Link to v1: https://lore.kernel.org/r/20250918-can-fix-mtu-v1-0-471edb942295@kernel.org

---
Vincent Mailhol (4):
      can: annotate mtu accesses with READ_ONCE()
      can: dev: turn can_set_static_ctrlmode() into a non-inline function
      can: populate the minimum and maximum MTU values
      can: enable CAN XL for virtual CAN devices by default

 drivers/net/can/dev/dev.c     | 38 +++++++++++++++++++++++++++++++++++++-
 drivers/net/can/dev/netlink.c |  9 ++++-----
 drivers/net/can/vcan.c        |  2 +-
 drivers/net/can/vxcan.c       |  2 +-
 include/linux/can/dev.h       | 24 +++---------------------
 net/can/af_can.c              |  2 +-
 net/can/isotp.c               |  2 +-
 net/can/raw.c                 |  2 +-
 8 files changed, 49 insertions(+), 32 deletions(-)
---
base-commit: 9b277fca90c39c8b749e659bf5c23e924c46c93b
change-id: 20250915-can-fix-mtu-050a94b563a0

Best regards,
-- 
Vincent Mailhol <mailhol@kernel.org>


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-09-23  9:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-23  6:37 [PATCH v3 0/4] can: rework the CAN MTU logic (CAN XL preparation step 2/3) Vincent Mailhol
2025-09-23  6:37 ` [PATCH v3 1/4] can: annotate mtu accesses with READ_ONCE() Vincent Mailhol
2025-09-23  6:37 ` [PATCH v3 2/4] can: dev: turn can_set_static_ctrlmode() into a non-inline function Vincent Mailhol
2025-09-23  6:37 ` [PATCH v3 3/4] can: populate the minimum and maximum MTU values Vincent Mailhol
2025-09-23  6:37 ` [PATCH v3 4/4] can: enable CAN XL for virtual CAN devices by default Vincent Mailhol
2025-09-23  9:10 ` [PATCH v3 0/4] can: rework the CAN MTU logic (CAN XL preparation step 2/3) Marc Kleine-Budde

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).