Re: [PATCH net-next] rtnetlink: Honour NLM_F_ECHO flag in rtnl_{new, set}link

On 21/09/2022 16:01, Jakub Kicinski wrote:

On Wed, 21 Sep 2022 11:07:21 +0800 Hangbin Liu wrote:

quoted

Netlink messages are used for communicating between user and kernel space.
When user space configures the kernel with netlink messages, it can set the
NLM_F_ECHO flag to request the kernel to send the applied configuration back
to the caller. This allows user space to retrieve configuration information
that are filled by the kernel (either because these parameters can only be
set by the kernel or because user space let the kernel choose a default
value).

This patch handles NLM_F_ECHO flag and send link info back after
rtnl_{new, set}link.

Suggested-by: Guillaume Nault <redacted>
Signed-off-by: Hangbin Liu <redacted>
---

In this patch I use rtnl_unicast to send the nlmsg directly. But we can
also pass "struct nlmsghdr *nlh" to rtnl_newlink_create() and
do_setlink(), then call rtnl_notify to send the nlmsg. I'm not sure
which way is better, any comments?

For iproute2 patch, please see
https://patchwork.kernel.org/project/netdevbpf/patch/20220916033428.400131-2-liuhangbin@gmail.com/

I feel like the justification for the change is lacking.

I'm biased [and frankly it takes a lot of self-restraint for me not
to say how I _really_ feel about netlink msg flags ;)] but IMO the
message flags fall squarely into the "this is magic which was never
properly implemented" bucket.

What makes this flag better than just issuing a GET command form user
space?

The flag was never checked on input and is not implemented by 99% of
netlink families and commands.

quoted

I'd love to hear what others think. IMO we should declare a moratorium

on any use of netlink flags and fixed fields, push netlink towards
being a simple conduit for TLVs.

+1
Just issue a "get" after the change.