This is needed since it calls into the driver, which must have the
same context as if we got to destroy an interface through nl80211.
Fix this, and add a direct lockdep assertion so we don't see it
pop up only when the driver calls back to cfg80211.

Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver")
Reported-by: syzbot+4305e814f9b267131776@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20210128183454.d31df9cbd7ce.I1beb07c9492f0ade900e864a098c57041e7a7ebf@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Similar to the previous commit, we need to hold the wiphy lock
here. There's a second instance that is correct already, fix
this one as well.

Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver")
Link: https://lore.kernel.org/r/20210128183454.ea2f086465ed.I891d3bb44f068e6d97c160005010f052f28ab6e5@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This is needed now that all the driver callbacks are protected by
the wiphy lock rather than (just) the RTNL.

Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver")
Reported-by: syzbot+d2d412349f88521938aa@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20210128183454.e81bc6789b4b.I5deb8b6bfdc8b4ea7696cb2447ee6c58c7ce9a4e@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

This is required, and we have an assertion, move the RTNL
unlock down to cover cfg80211_dev_rename().

Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver")
Reported-by: syzbot+ed107c5fa3e21cdcd86e@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20210128183454.16a4ea036740.I2beeb391dc322d6f1df3ee2612e714e0a7817397@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

In the rtl8366rb driver there are some jam tables which contain
undocumented values.
While trying to understand what these tables actually do,
I noticed a discrepancy in how one of those was treated.
Most of them were plain u16 arrays, while the ethernet one was
an u16 matrix.
By looking at the vendor's droplets of source code these tables came from,
I found out that they were all originally u16 matrixes.

This commit standardizes the jam tables, turning them all into
jam_tbl_entry arrays. Each entry contains 2 u16 values.
This change makes it easier to understand how the jam tables are used
and also makes it possible for a single function to handle all of them,
removing some duplicated code.
Signed-off-by: NLorenzo Carletti <lorenzo.carletti98@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Saeed Mahameed says:

====================
mlx5 devlink traps support

Add support for devlink traps [1] reporting in mlx5,
mlx5 will also report/trap packets filtered due to dest mac steering miss

The first patch in the series defines the new DMAC trap type in devlink
for this purpose.

Other patches in the series are mlx5 only and they gradually traps support.
Supported traps:

DMAC: Drops due to destination MAC not configured in the MAC table
VLAN: Drops due to vlan not configured in the vlan table

Design note:
devlink instance is managed by the low level mlx5 core layer, mlx5 core will
serve as an abstraction layer for trap reporting, since we might have multiple
mlx5 interfaces who might want to report traps on the same device.
====================

Link: https://lore.kernel.org/r/20210126232419.175836-1-saeedm@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Avoid trapping packets when the interface is down, and revive them when
interface is back up. Add API to mlx5 core retrieving the action by trap
id. Use it to apply traps when interface is up, and disable then when
interface is down.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add support for trapping packets which didn't match any DMAC in the MAC
table. Add a listener which adds/removes MAC trap rule in the flow
steering according to the trap's action trap/drop.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add support for listening to blocking events in the ETH driver. Listen
on trap event. If received, call mlx5e_handle_trap_event() which:
1) Verifies if driver needs open/close trap-RQ with respect to the
active traps count.
2) Inspects trap id and its action (trap/drop) and add/remove the flow
steering rule accordingly.
Otherwise, return an error.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Introduce mlx5e_trap which includes a dedicated RQ and NAPI for trapped
packets. Trap-RQ processes packets that were destined to be dropped,
but for debug and visibility sake these packets are trapped and reported
to devlink.
Trap-RQ connects between the HW and the driver and is not a part of a
channel. Open mlx5e_create_rq() and mlx5_core_destroy_rq() as API and
add dedicate RQ handlers which report to devlink of trapped packets.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

In order to support RQs outside of channel context, change
mlx5e_init_di_list() signature to accept NUMA node instead of cpu.
In addition, expose dma info helpers as API. This API will be used for
RQ's creation in other files in downstream patches.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add flow group to the L2 table to hold the catch-all DMAC rule. Add API
which adds/removes DMAC trap rule. This rule catches packets that were
destined to be dropped due to no-match with previous DMAC rules. The
trap rule steer these packets to the trap tir related to the trap-RQ.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add flow group to the VLAN table to hold the catch-all VLAN rule. Add
API which adds/removes VLAN trap rule. This rule catches packets that
were destined to be dropped due to no-match with previous VLAN rules.
The trap rule steer these packets to the trap tir related to the
trap-RQ.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Change steering flow to optimize traffic in promiscuous mode. On demand,
add a high priority table containing a catch-all rule. All incoming
packets are caught by this rule and steered directly to the TTC table.
Prior to this change, packets in promiscuous mode may suffer from up to
4 steering hops before reaching TTC table.
In addition, this patch will allow us adding a catch-all rule at the end
of MAC table to serve MAC trap, with no impact on promiscuous mode
performance.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NMaor Gottlieb <maorg@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

In order to allow mlx5 core driver to trigger synchronous operations to
its consumers, add a blocking events handler. Add wrappers to
blocking_notifier_[call_chain/chain_register/chain_unregister]. Add trap
callback for action set and notify about this change. Following patches
in the set add a listener for this event.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Change the naming of events notifier head to clarify that it handles
only firmware events. Coming patches in the set, add event notifier for
software events.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Core driver is registered to the devlink traps service, which enables the
admin to redeem packets that were destined to be dropped due to a
particular reason. Register to DMAC filter, allow visibility of packets
that were filtered out by the MAC table.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add traps registration to mlx5_core devlink register/unregister flow.
This patch registers INGRESS_VLAN_FILTER trap.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add devlink traps infra-structure to mlx5 core driver. Add traps list to
mlx5_priv and corresponding API:
 - mlx5_devlink_trap_report() to wrap trap reports to devlink
 - mlx5_devlink_trap_get_num_active() to decide whether to open/close trap
   resources.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add packet trap that can report packets that were dropped due to
destination MAC filtering.
Signed-off-by: NAya Levin <ayal@nvidia.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Early generations of the mv88e6xxx did not have the global 2
registers. In order to keep the driver slim, it was decided to make
the code for these registers optional. Over time, more generations of
switches have been added, always supporting global 2 and adding more
and more registers. No effort has been made to keep these additional
registers also optional to slim the driver down when used for older
generations. Optional global 2 now just gives additional development
and maintenance burden for no real gain.

Make global 2 support always compiled in.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Tested-by: NVladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20210127003210.663173-1-andrew@lunn.chSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Merge tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

Johannes Berg says:

====================
More updates:
 * many minstrel improvements, including removal of the old
   minstrel in favour of minstrel_ht
 * speed improvements on FQ
 * support for RX decapsulation (header conversion) offload
 * RTNL reduction: limit RTNL usage in the wireless stack
   mostly to where really needed (regulatory not yet) to
   reduce contention on it

* tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (24 commits)
  mac80211: minstrel_ht: fix regression in the max_prob_rate fix
  virt_wifi: fix deadlock on RTNL
  cfg80211: avoid holding the RTNL when calling the driver
  cfg80211: change netdev registration/unregistration semantics
  mac80211: minstrel_ht: fix rounding error in throughput calculation
  mac80211: minstrel_ht: increase stats update interval
  mac80211: minstrel_ht: fix max probability rate selection
  mac80211: minstrel_ht: improve sample rate selection
  mac80211: minstrel_ht: improve ampdu length estimation
  mac80211: minstrel_ht: remove old ewma based rate average code
  mac80211: remove legacy minstrel rate control
  mac80211: minstrel_ht: add support for OFDM rates on non-HT clients
  mac80211: minstrel_ht: clean up CCK code
  mac80211: introduce aql_enable node in debugfs
  cfg80211: Add phyrate conversion support for extended MCS in 60GHz band
  cfg80211: add VHT rate entries for MCS-10 and MCS-11
  mac80211: reduce peer HE MCS/NSS to own capabilities
  mac80211: remove NSS number of 160MHz if not support 160MHz for HE
  mac80211_hwsim: add 6GHz channels
  mac80211: add LDPC encoding to ieee80211_parse_tx_radiotap
  ...
====================

Link: https://lore.kernel.org/r/20210127210915.135550-1-johannes@sipsolutions.netSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Merge tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2021-01-27

The first two patches are by me and fix typos on the CAN gw protocol and the
flexcan driver.

The next patch is by Vincent Mailhol and targets the CAN driver infrastructure,
it exports the function that converts the CAN state into a human readable
string.

A patch by me, which target the CAN driver infrastructure, too, makes the
calculation in can_fd_len2dlc() more readable.

A patch by Tom Rix fixes a checkpatch warning in the mcba_usb driver.

The next seven patches target the mcp251xfd driver. Su Yanjun's patch replaces
several hardcoded assumptions when calling regmap, by using
regmap_get_val_bytes(). The remaining patches are by me. First an open coded
check is replaced by an existing helper function, then in the TX path the
padding for CAN-FD frames is cleaned up. The next two patches clean up the RTR
frame handling in the RX and TX path. Then support for len8_dlc is added. The
last patch adds BQL support.

* tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: mcp251xfd: add BQL support
  can: mcp251xfd: add len8_dlc support
  can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): don't copy data for RTR CAN frames in TX-path
  can: mcp251xfd: mcp251xfd_hw_rx_obj_to_skb(): don't copy data for RTR CAN frames in RX-path
  can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): clean up padding of CAN-FD frames
  can: mcp251xfd: mcp251xfd_start_xmit(): use mcp251xfd_get_tx_free() to check TX is is full
  can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap
  can: mcba_usb: remove h from printk format specifier
  can: length: can_fd_len2dlc(): make legnth calculation readable again
  can: dev: export can_get_state_str() function
  can: flexcan: fix typos
  can: gw: fix typo
====================

Link: https://lore.kernel.org/r/20210127092227.2775573-1-mkl@pengutronix.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Remove a duplicate code checking for header size in tipc_msg_create() as
it's already being done in tipc_msg_init().
Acked-by: NJon Maloy <jmaloy@redhat.com>
Signed-off-by: NHoang Huu Le <hoang.h.le@dektech.com.au>
Link: https://lore.kernel.org/r/20210127025123.6390-1-hoang.h.le@dektech.com.auSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Nikolay Aleksandrov says:

====================
net: bridge: multicast: per-port EHT hosts limit

This set adds a simple configurable per-port EHT tracked hosts limit.
Patch 01 adds a default limit of 512 tracked hosts per-port, since the EHT
changes are still only in net-next that shouldn't be a problem. Then
patch 02 adds the ability to configure and retrieve the hosts limit
and to retrieve the current number of tracked hosts per port.
Let's be on the safe side and limit the number of tracked hosts by
default while allowing the user to increase that limit if needed.
====================

Link: https://lore.kernel.org/r/20210126093533.441338-1-razor@blackwall.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Add two new port attributes which make EHT hosts limit configurable and
export the current number of tracked EHT hosts:
 - IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT: configure/retrieve current limit
 - IFLA_BRPORT_MCAST_EHT_HOSTS_CNT: current number of tracked hosts
Setting IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT to 0 is currently not allowed.

Note that we have to increase RTNL_SLAVE_MAX_TYPE to 38 minimum, I've
increased it to 40 to have space for two more future entries.

v2: move br_multicast_eht_set_hosts_limit() to br_multicast_eht.c,
    no functional change
Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add a default limit of 512 for number of tracked EHT hosts per-port.
Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Fix the following coccicheck warnings:

./drivers/net/ethernet/rocker/rocker_ofdpa.c:926:34-36: WARNING !A || A
&& B is equivalent to !A || B.
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Zhong <abaci-bugfix@linux.alibaba.com>
Link: https://lore.kernel.org/r/1611648783-3916-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

These Kconfig files are included from net/Kconfig, inside the
if NET ... endif.

Remove 'depends on NET', which we know it is already met.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125232026.106855-1-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

CONFIG_NET_L3_MASTER_DEV is a bool option. Change the ifeq conditional
to the standard obj-$(CONFIG_NET_L3_MASTER_DEV) form.

Use obj-y in net/l3mdev/Makefile because Kbuild visits this Makefile
only when CONFIG_NET_L3_MASTER_DEV=y.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NDavid Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-4-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

CONFIG_NET_SWITCHDEV is a bool option. Change the ifeq conditional to
the standard obj-$(CONFIG_NET_SWITCHDEV) form.

Use obj-y in net/switchdev/Makefile because Kbuild visits this Makefile
only when CONFIG_NET_SWITCHDEV=y.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-3-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

CONFIG_DCB is a bool option. Change the ifeq conditional to the
standard obj-$(CONFIG_DCB) form.

Use obj-y in net/dcb/Makefile because Kbuild visits this Makefile
only when CONFIG_DCB=y.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-2-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

When CONFIG_NET is disabled, nothing under the net/ directory is
compiled. Move the CONFIG_NET guard to the top Makefile so the net/
directory is entirely skipped.

When Kbuild visits net/Makefile, CONFIG_NET is obvioulsy 'y' because
CONFIG_NET is a bool option. Clean up net/Makefile.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-1-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

CONFIG_NET is a bool option, and this file is compiled only when
CONFIG_NET=y.

Remove #ifdef CONFIG_NET, which we know it is always met.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231421.105936-1-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Mat Martineau says:

====================
MPTCP: IPv4-mapped IPv6 addressing for subflows

This patch series from the MPTCP tree adds support for IPv4-mapped IPv6
addressing that was missing when multiple subflows were first
implemented.

Patches 1 and 2 handle the conversion and comparison of the mapped
addresses.

Patch 3 contains a minor refactor in the path manager's handling of
addresses.

Patches 4 and 5 add selftests for the new functionality and adjust the
selftest timeout.
====================

Link: https://lore.kernel.org/r/20210125185904.6997-1-mathew.j.martineau@linux.intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

On slow systems with kernel debug settings, we can reach the current
timeout when all tests are executed.

Likely some tests need be improved to remove some 'sleep' and wait
(less) for a specific action. This can also improve stability.
Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Here, we make sure we support IPv4-mapped in IPv6 addresses in different
contexts:

- a v4-mapped address is received by the PM and can be used as v4.
- a v4 address is received by the PM and can be used even with a v4
  mapped socket.

We also make sure we don't try to establish subflows between v4 and v6
addresses, e.g. if a real v6 address ends with a valid v4 address.
Co-developed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

To avoid confusions like when working on the previous patch, better to
declare and assign this variable only where it is needed.
Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

On one side, we can allow the creation of subflows between v4 mapped in
v6 and v4 addresses. For that we look for v4mapped addresses between the
local address we want to select and the remote one.

On the other side, we also properly deal with received v4mapped
addresses, either announced ones or set via Netlink.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Suggested-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Co-developed-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

With an IPv4 mapped in v6 socket, we were trying to call inet6_bind()
with an IPv4 address resulting in a -EINVAL error because the given
addr_len -- size of the address structure -- was too short.

We now make sure to use address structures for the same family as the
MPTCP socket for both the bind() and the connect(). It means we convert
v4 addresses to v4 mapped in v6 or the opposite if needed.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Co-developed-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>