linux.git/net/core/rtnetlink.c, branch v5.19

net: allow gro_max_size to exceed 65536

2022-05-16T09:18:56+00:00

Allow the gro_max_size to exceed a value larger than 65536.

There weren't really any external limitations that prevented this other
than the fact that IPv4 only supports a 16 bit length field. Since we have
the option of adding a hop-by-hop header for IPv6 we can allow IPv6 to
exceed this value and for IPv4 and non-TCP flows we can cap things at 65536
via a constant rather than relying on gro_max_size.

[edumazet] limit GRO_MAX_SIZE to (8 * 65535) to avoid overflows.

Signed-off-by: Alexander Duyck 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

net: allow gso_max_size to exceed 65536

2022-05-16T09:18:55+00:00

The code for gso_max_size was added originally to allow for debugging and
workaround of buggy devices that couldn't support TSO with blocks 64K in
size. The original reason for limiting it to 64K was because that was the
existing limits of IPv4 and non-jumbogram IPv6 length fields.

With the addition of Big TCP we can remove this limit and allow the value
to potentially go up to UINT_MAX and instead be limited by the tso_max_size
value.

So in order to support this we need to go through and clean up the
remaining users of the gso_max_size value so that the values will cap at
64K for non-TCPv6 flows. In addition we can clean up the GSO_MAX_SIZE value
so that 64K becomes GSO_LEGACY_MAX_SIZE and UINT_MAX will now be the upper
limit for GSO_MAX_SIZE.

v6: (edumazet) fixed a compile error if CONFIG_IPV6=n,
               in a new sk_trim_gso_size() helper.
               netif_set_tso_max_size() caps the requested TSO size
               with GSO_MAX_SIZE.

Signed-off-by: Alexander Duyck 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes

2022-05-16T09:18:55+00:00

New netlink attributes IFLA_TSO_MAX_SIZE and IFLA_TSO_MAX_SEGS
are used to report to user-space the device TSO limits.

ip -d link sh dev eth1
...
   tso_max_size 65536 tso_max_segs 65535

Signed-off-by: Eric Dumazet 
Acked-by: Alexander Duyck 
Signed-off-by: David S. Miller

rtnetlink: verify rate parameters for calls to ndo_set_vf_rate

2022-05-12T11:03:08+00:00

When calling ndo_set_vf_rate() the max_tx_rate parameter may be zero,
in which case the setting is cleared, or it must be greater or equal to
min_tx_rate.

Enforce this requirement on all calls to ndo_set_vf_rate via a wrapper
which also only calls ndo_set_vf_rate() if defined by the driver.

Based on work by Jakub Kicinski 

Signed-off-by: Bin Chen 
Signed-off-by: Baowen Zheng 
Signed-off-by: Simon Horman 
Signed-off-by: Paolo Abeni

rtnetlink: add extack support in fdb del handlers

2022-05-09T10:58:20+00:00

Add extack support to .ndo_fdb_del in netdevice.h and
all related methods.

Signed-off-by: Alaa Mohamed 
Signed-off-by: David S. Miller

net: don't allow user space to lift the device limits

2022-05-06T11:07:56+00:00

Up until commit 46e6b992c250 ("rtnetlink: allow GSO maximums to
be set on device creation") the gso_max_segs and gso_max_size
of a device were not controlled from user space.

The quoted commit added the ability to control them because of
the following setup:

 netns A  |  netns B
     veth<->veth   eth0

If eth0 has TSO limitations and user wants to efficiently forward
traffic between eth0 and the veths they should copy the TSO
limitations of eth0 onto the veths. This would happen automatically
for macvlans or ipvlan but veth users are not so lucky (given the
loose coupling).

Unfortunately the commit in question allowed users to also override
the limits on real HW devices.

It may be useful to control the max GSO size and someone may be using
that ability (not that I know of any user), so create a separate set
of knobs to reliably record the TSO limitations. Validate the user
requests.

Signed-off-by: Jakub Kicinski 
Signed-off-by: David S. Miller

rtnl: move rtnl_newlink_create()

2022-05-02T13:14:20+00:00

Pure code move.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Paolo Abeni

rtnl: split __rtnl_newlink() into two functions

2022-05-02T13:14:20+00:00

__rtnl_newlink() is 250LoC, but has a few clear sections.
Move the part which creates a new netdev to a separate
function.

For ease of review code will be moved in the next change.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Paolo Abeni

rtnl: allocate more attr tables on the heap

2022-05-02T13:14:20+00:00

Commit a293974590cf ("rtnetlink: avoid frame size warning in rtnl_newlink()")
moved to allocating the largest attribute array of rtnl_newlink()
on the heap. Kalle reports the stack has grown above 1k again:

  net/core/rtnetlink.c:3557:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Move more attrs to the heap, wrap them in a struct.
Don't bother with linkinfo, it's referenced a lot and we take
its size so it's awkward to move, plus it's small (6 elements).

Reported-by: Kalle Valo 
Signed-off-by: Jakub Kicinski 
Tested-by: Kalle Valo 
Signed-off-by: Paolo Abeni

Revert "rtnetlink: return EINVAL when request cannot succeed"

2022-04-22T10:02:00+00:00

This reverts commit b6177d3240a4

ip-link command is testing kernel capability by sending a RTM_NEWLINK
request, without any argument. It accepts everything in reply, except
EOPNOTSUPP and EINVAL (functions iplink_have_newlink / accept_msg)

So we must keep compatiblity here, invalid empty message should not
return EINVAL

Signed-off-by: Florent Fourcot 
Tested-by: Guillaume Nault 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller