linux-kernel - Re: [PATCH net-next 2/2] net/mlx5e: Log error messages when extack is not present

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c0f4a69-dd90-4822-9981-faa90f7a58a6@nvidia.com>
Date: Wed, 4 Jun 2025 00:01:05 +0300
From: Yael Chemla <ychemla@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>, Tariq Toukan <tariqt@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>,
 netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
 linux-kernel@...r.kernel.org, Moshe Shemesh <moshe@...dia.com>,
 Mark Bloch <mbloch@...dia.com>, Gal Pressman <gal@...dia.com>
Subject: Re: [PATCH net-next 2/2] net/mlx5e: Log error messages when extack is
 not present

On 28/05/2025 3:49, Jakub Kicinski wrote:
> On Sun, 25 May 2025 14:47:32 +0300 Tariq Toukan wrote:
>> Encapsulate netlink error message macros to ensure error message remain
>> visible in dmesg when the userspace does not support netlink.
>>
>> This allows drivers to continue providing meaningful error messages even
>> when netlink is available in kernel but not in userspace.
>>
>> Replace direct extack macro calls with new wrapper macros to support
>> this fallback behavior.
> 
> Please break this down API by API and explain for each why user space
> can't use netlink. If we thought this was a good idea we would have
> added the pr_err() to the NL_SET_ERR_MSG_MOD() from the start.

Hi Jakub,

Thanks for the feedback.

To clarify: extack can be NULL when userspace tools (like ethtool, tc,
or devlink) send Netlink messages without the NLM_F_ACK flag. In such
cases, the kernel usually won’t send an NLMSG_ERROR unless the failure
is immediate. For more complex or asynchronous operations (like hardware
offloads), NLM_F_ACK enables meaningful error reporting; otherwise,
userspace might see only a generic errno or nothing at all.

The NL_SET_ERR_MSG_MOD() and NL_SET_ERR_MSG_FMT_MOD() macros are safe in
this context—they internally check for extack and no-op if it’s NULL.

Regarding the APIs modified in this patch:

Ethtool APIs: While Netlink support was introduced around versions
5.6–5.8, many LTS distributions (e.g., Ubuntu 20.04, CentOS 7) still
ship with older userspace ethtool utilities that rely on ioctl for
certain operations. In these ioctl-based paths, the extack pointer
passed down to the driver may legitimately be NULL.

TC APIs: Even though TC is predominantly Netlink-based, extack can still
be NULL in certain internal driver code, legacy handling, or specific
test/debug scenarios.

If a narrower scope is preferred, I can revise the patch to include only
the ethtool-related changes, which were the primary motivation behind
this work.

Thanks again,
Yael Chemla