On 12/20/24 10:06 AM, Daniel Borkmann wrote:
On 12/20/24 3:23 AM, Jakub Kicinski wrote:
On Thu, 19 Dec 2024 18:39:26 +0100 Daniel Borkmann wrote:
+ if (headroom) {
+ peer->needed_headroom = headroom;
+ dev->needed_headroom = headroom;
+ }
+ if (tailroom) {
+ peer->needed_tailroom = tailroom;
+ dev->needed_tailroom = tailroom;
+ }
Since you use the same one for main dev and peer should there be
something rejecting the use of the new attr in the peer attrs?
(IFLA_NETKIT_PEER_INFO)
The peer info is parsed via rtnl_nla_parse_ifinfomsg() which internally
uses ifla_policy filter where IFLA_INFO_DATA is not part of, but to be
sure I can add one more selftest case to confirm.
Looks like we don't bail out anymore after the conversion in fefd5d082172
("netkit: Set IFLA_NETKIT_PEER_INFO to netkit_link_ops.peer_type."), so I
left it out for now from the series.. need to experiment some more whether
fefd5d082172 dropping the error has any unintended side-effects. But I'm
currently not seeing how it would be much different to, for example, the
preceding netif_inherit_tso_max() call.
Thanks,
Daniel
