Re: [PATCH net-next v2 1/9] devlink: fix the enum behind DEVLINK_ATTR_RELOAD_LIMITS

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 16 Sep 2026 19:15:18 +0000 netdev-bot+sashiko@kernel.org wrote:
> That reasoning covers the value bits, since only value bits reach
> devlink_reload_limit_is_supported().  But validate_nla_bitfield32() in
> lib/nlattr.c checks the selector against the mask on its own:
> 
> 	/*disallow invalid bit selector */
> 	if (bf->selector & ~valid_flags_mask)
> 		return -EINVAL;
> 
> and devlink_nl_reload_doit() in net/devlink/dev.c only ever looks at
> 
> 	limits_selected = limits.value & limits.selector;
> 
> so selector-only bits never reach any driver check.  Doesn't that make the
> mask change user-visible in both directions?
> 
> Going from 6 to 3 accepts selector bit 0 again.  The natural selector for
> userspace is the exported DEVLINK_RELOAD_LIMITS_VALID_MASK in
> include/uapi/linux/devlink.h:
> 
> #define DEVLINK_RELOAD_LIMITS_VALID_MASK (_BITUL(__DEVLINK_RELOAD_LIMIT_MAX) - 1)
> 
> which is 3.  With mask 6 that request fails early, since 3 & ~6 == 1, so
> DEVLINK_CMD_RELOAD with selector DEVLINK_RELOAD_LIMITS_VALID_MASK and
> value BIT(DEVLINK_RELOAD_LIMIT_NO_RESET) returns -EINVAL on current
> kernels and starts working again with this patch.  Should this therefore
> carry a Fixes tag for f2f9dd164db079 ("netlink: specs: devlink: add the
> remaining command to generate complete split_ops"), which is where mask 6
> came from (its parent used DEVLINK_RELOAD_LIMITS_VALID_MASK in
> net/devlink/netlink.c)?  Without a Fixes tag, and described as cosmetic,
> stable backporters will likely skip it and the -EINVAL behaviour stays in
> place from v6.7 onwards.

My point was that bit 1 / mask 0x2 is the only one that has practical
use, and it so happens that both old 0x6 and new 0x3 covers it. Which
is why I think it's is cosmetic.