When a dual stack tcp listener accepts an ipv4 flow,
it should not attempt to use an ipv6 header or tcp_v6_iif() helper.

Fixes: 1397ed35 ("ipv6: add flowinfo for tcp6 pkt_options for all cases")
Fixes: df3687ff ("ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET")
Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In case of kmemdup failure while setting the service name the patch
returns -ENOMEM upstream for processing.
Signed-off-by: NAditya Pakki <pakki001@umn.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In netdev_queue_add_kobject and rx_queue_add_kobject,
if sysfs_create_group failed, kobject_put will call
netdev_queue_release to decrease dev refcont, however
dev_hold has not be called. So we will see this while
unregistering dev:

unregister_netdevice: waiting for bcsh0 to become free. Usage count = -1
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: d0d66837 ("net: don't decrement kobj reference count on init failure")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using 16K DMA buffers and ring mode, the DES3 refill is not working
correctly as the function is using a bogus pointer for checking the
private data. As a result stale pointers will remain in the RX descriptor
ring, so DMA will now likely overwrite/corrupt some already freed memory.

As simple reproducer, just receive some UDP traffic:

	# ifconfig eth0 down; ifconfig eth0 mtu 9000; ifconfig eth0 up
	# iperf3 -c 192.168.253.40 -u -b 0 -R

If you didn't crash by now check the RX descriptors to find non-contiguous
RX buffers:

	cat /sys/kernel/debug/stmmaceth/eth0/descriptors_status
	[...]
	1 [0x2be5020]: 0xa3220321 0x9ffc1ffc 0x72d70082 0x130e207e
					     ^^^^^^^^^^^^^^^^^^^^^
	2 [0x2be5040]: 0xa3220321 0x9ffc1ffc 0x72998082 0x1311a07e
					     ^^^^^^^^^^^^^^^^^^^^^

A simple ping test will now report bad data:

	# ping -s 8200 192.168.253.40
	PING 192.168.253.40 (192.168.253.40) 8200(8228) bytes of data.
	8208 bytes from 192.168.253.40: icmp_seq=1 ttl=64 time=1.00 ms
	wrong data byte #8144 should be 0xd0 but was 0x88

Fix the wrong pointer. Also we must refill DES3 only if the DMA buffer
size is 16K.

Fixes: 54139cf3 ("net: stmmac: adding multiple buffers for rx")
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: NJose Abreu <joabreu@synopsys.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A recently added function in mlxsw triggers a harmless compiler warning:

In file included from drivers/net/ethernet/mellanox/mlxsw/core.h:17,
                 from drivers/net/ethernet/mellanox/mlxsw/core_env.c:7:
drivers/net/ethernet/mellanox/mlxsw/core_env.c: In function 'mlxsw_env_module_temp_thresholds_get':
drivers/net/ethernet/mellanox/mlxsw/reg.h:8015:45: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context]
 #define MLXSW_REG_MTMP_TEMP_TO_MC(val) (val * 125)
                                        ~~~~~^~~~~~
drivers/net/ethernet/mellanox/mlxsw/core_env.c:116:8: note: in expansion of macro 'MLXSW_REG_MTMP_TEMP_TO_MC'
   if (!MLXSW_REG_MTMP_TEMP_TO_MC(module_temp)) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~

The warning is normally disabled, but it would be nice to enable
it to find real bugs, and there are no other known instances at
the moment.

Replace the negation with a zero-comparison, which also matches
the comment above it.

Fixes: d93c19a1 ("mlxsw: core: Add API for QSFP module temperature thresholds reading")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Merge tag 'wireless-drivers-for-davem-2019-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

Kalle Valo says:

====================
wireless-drivers fixes for 5.1

First set of fixes for 5.1. Lots of fixes for mt76 this time.

iwlwifi

* fix warning with do_div()

mt7601u

* avoid using hardware which is supported by mt76

mt76

* more fixes for hweight8() usage

* fix hardware restart for mt76x2

* fix writing txwi on USB devices

* fix (and disable by default) ED/CCA support on 76x2

* fix powersave issues on 7603

* fix return value check for ioremap on 7603

* fix duplicate USB device IDs
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Merge branch 'ieee802154-for-davem-2019-03-19' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan

Stefan Schmidt says:

====================
pull-request: ieee802154 for net 2019-03-19

An update from ieee802154 for your *net* tree.

Kangjie Lu fixed a potential NULL pointer deref in the adf7242 driver and Li
RongQing make sure we propagate a netlink return code to the caller.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

My commit 26a7b547 ("mt76x02: set protection according to ht
operation element") enabled by default RTS/CTS protection for OFDM
and CCK traffic, because MT_TX_RTS_CFG_THRESH is configured to non
0xffff by initvals and .set_rts_threshold callback is not called by
mac80211 on initialization, only on user request or during
ieee80211_reconfig() (suspend/resuem or restart_hw).

Enabling RTS/CTS cause some problems when sending probe request
frames by hcxdumptool penetration tool, but I expect it can cause
other issues on different scenarios.

Restore previous setting of RTS/CTS being disabled by default for
OFDM/CCK by changing MT_TX_RTS_CFG_THRESH initvals to 0xffff.

Fixes: 26a7b547 ("mt76x02: set protection according to ht operation element")
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Fix following schedule while atomic in mt76x02_reset_state
since synchronize_rcu is run inside a RCU section

[44036.944222] mt76x2e 0000:06:00.0: MCU message 31 (seq 3) timed out
[44036.944281] BUG: sleeping function called from invalid context at kernel/rcu/tree_exp.h:818
[44036.944284] in_atomic(): 1, irqs_disabled(): 0, pid: 28066, name: kworker/u4:1
[44036.944287] INFO: lockdep is turned off.
[44036.944292] CPU: 1 PID: 28066 Comm: kworker/u4:1 Tainted: G        W         5.0.0-rc7-wdn-t1+ #7
[44036.944294] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
[44036.944305] Workqueue: phy1 mt76x02_wdt_work [mt76x02_lib]
[44036.944308] Call Trace:
[44036.944317]  dump_stack+0x67/0x90
[44036.944322]  ___might_sleep.cold.88+0x9f/0xaf
[44036.944327]  rcu_blocking_is_gp+0x13/0x50
[44036.944330]  synchronize_rcu+0x17/0x80
[44036.944337]  mt76_sta_state+0x138/0x1d0 [mt76]
[44036.944349]  mt76x02_wdt_work+0x1c9/0x610 [mt76x02_lib]
[44036.944355]  process_one_work+0x2a5/0x620
[44036.944361]  worker_thread+0x35/0x3e0
[44036.944368]  kthread+0x11c/0x140
[44036.944376]  ret_from_fork+0x3a/0x50
[44036.944384] BUG: scheduling while atomic: kworker/u4:1/28066/0x00000002
[44036.944387] INFO: lockdep is turned off.
[44036.944389] Modules linked in: cmac ctr ccm af_packet snd_hda_codec_hdmi

Introduce __mt76_sta_remove in order to run sta_remove without holding dev->mutex.
Move __mt76_sta_remove outside of RCU section in mt76x02_reset_state

Fixes: e4ebb8b403d1 ("mt76: mt76x2: implement full device restart on watchdog reset")
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

__sw_hweight8() is only defined if CONFIG_GENERIC_HWEIGHT is enabled.
The function that works on all architectures is hweight8().
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Since some USB device IDs are duplicated between mt76x0u, mt7601u
and mt76x2u device, check chip version on probe and return error if
not match the driver.

Don't think this is serious issue, probe most likely will fail at
some other point for wrong device, but we do not have to configure
it if we know is not our device.
Reported-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Since some USB device IDs are duplicated between mt7601u and mt76x0u
devices, check chip version on probe and return error if not match
0x7601.

Don't think this is serious issue, probe most likely will fail at
some other point for wrong device, but we do not have to configure
it if we know is not mt7601u device.
Reported-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NJakub Kicinski <kubakici@wp.pl>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Provide an explanation of what is expected with respect to sending new
versions of specific patches within a patch series, as well as what
happens if an earlier patch series accidentally gets merged).
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Julian Wiedmann says:

====================
s390/qeth: fixes 2019-03-18

please apply the following three patches to -net. The first two are fixes
for minor race conditions in the probe code, while the third one gets
dropwatch working (again).
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As part of the TX completion path, qeth_release_skbs() frees the completed
skbs with __skb_queue_purge(). This ends in kfree_skb(), reporting every
completed skb as dropped.
On the other hand when dropping an skb in .ndo_start_xmit, we end up
calling consume_skb()... where we should be using kfree_skb() so that
drop monitors get notified.

Switch the drop/consume logic around, and also don't accumulate dropped
packets in the tx_errors statistics.

Fixes: dc149e37 ("s390/qeth: replace open-coded skb_queue_walk()")
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ucast IP table is utilized by some of the L3-specific sysfs attributes
that qeth_l3_create_device_attributes() provides. So initialize the table
_before_ registering the attributes.

Fixes: ebccc739 ("s390/qeth: add missing hash table initializations")
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The HW trap and VNICC configuration is exposed via sysfs, and may have
already been modified when qeth_l?_probe_device() attempts to initialize
them. So (1) initialize the VNICC values a little earlier, and (2) don't
bother about the HW trap mode, it was already initialized before.
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device ID alone does not uniquely identify a device.  Test both the
vendor and device ID to make sure we don't mistakenly think some other
vendor's 0xB410 device is a Digium HFC4S.  Also, instead of the bare hex
ID, use the same constant (PCI_DEVICE_ID_DIGIUM_HFC4S) used in the device
ID table.

No functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Xin Long says:

====================
sctp: fix ignoring asoc_id for tcp-style sockets on some setsockopts

This is a patchset to fix ignoring asoc_id for tcp-style sockets on
some setsockopts, introduced by SCTP_CURRENT_ASSOC of the patchset:

  [net-next,00/24] sctp: support SCTP_FUTURE/CURRENT/ALL_ASSOC
  (https://patchwork.ozlabs.org/cover/1031706/)

As Marcelo suggested, we fix it on each setsockopt that is using
SCTP_CURRENT_ASSOC one by one by adding the check:

    if (sctp_style(sk, TCP))
        	xxx.xxx_assoc_id = SCTP_FUTURE_ASSOC;

so that assoc_id will be completely ingored for tcp-style socket on
setsockopts, and works as SCTP_FUTURE_ASSOC.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_STREAM_SCHEDULER sockopt.

Fixes: 7efba10d ("sctp: add SCTP_FUTURE_ASOC and SCTP_CURRENT_ASSOC for SCTP_STREAM_SCHEDULER sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_EVENT sockopt.

Fixes: d251f05e ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_EVENT sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_ENABLE_STREAM_RESET sockopt.

Fixes: 99a62135 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_ENABLE_STREAM_RESET sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DEFAULT_PRINFO sockopt.

Fixes: 3a583059 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_PRINFO sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_AUTH_DEACTIVATE_KEY sockopt.

Fixes: 2af66ff3 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_AUTH_DEACTIVATE_KEY sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_AUTH_DELETE_KEY sockopt.

Fixes: 3adcc300 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_AUTH_DELETE_KEY sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_AUTH_ACTIVE_KEY sockopt.

Fixes: bf9fb6ad ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_AUTH_ACTIVE_KEY sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_AUTH_KEY sockopt.

Fixes: 7fb3be13 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_AUTH_KEY sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_MAX_BURST sockopt.

Fixes: e0651a0d ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_MAX_BURST sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_CONTEXT sockopt.

Fixes: 49b037ac ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_CONTEXT sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DEFAULT_SNDINFO sockopt.

Fixes: 92fc3bd9 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SNDINFO sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DELAYED_SACK sockopt.

Fixes: 9c5829e1 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DELAYED_SACK sockopt")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently if the user pass an invalid asoc_id to SCTP_DEFAULT_SEND_PARAM
on a TCP-style socket, it will silently ignore the new parameters.
That's because after not finding an asoc, it is checking asoc_id against
the known values of CURRENT/FUTURE/ALL values and that fails to match.

IOW, if the user supplies an invalid asoc id or not, it should either
match the current asoc or the socket itself so that it will inherit
these later. Fixes it by forcing asoc_id to SCTP_FUTURE_ASSOC in case it
is a TCP-style socket without an asoc, so that the values get set on the
socket.

Fixes: 707e45b3 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SEND_PARAM sockopt")
Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now sctp_copy_descendant() copies pd_lobby from old sctp scok to new
sctp sock. If sctp_sock_migrate() returns error, it will panic when
releasing new sock and trying to purge pd_lobby due to the incorrect
pointers in pd_lobby.

  [  120.485116] kasan: CONFIG_KASAN_INLINE enabled
  [  120.486270] kasan: GPF could be caused by NULL-ptr deref or user
  [  120.509901] Call Trace:
  [  120.510443]  sctp_ulpevent_free+0x1e8/0x490 [sctp]
  [  120.511438]  sctp_queue_purge_ulpevents+0x97/0xe0 [sctp]
  [  120.512535]  sctp_close+0x13a/0x700 [sctp]
  [  120.517483]  inet_release+0xdc/0x1c0
  [  120.518215]  __sock_release+0x1d2/0x2a0
  [  120.519025]  sctp_do_peeloff+0x30f/0x3c0 [sctp]

We fix it by not copying sctp_sock pd_lobby in sctp_copy_descendan(),
and skb_queue_head_init() can also be removed in sctp_sock_migrate().

Reported-by: syzbot+85e0b422ff140b03672a@syzkaller.appspotmail.com
Fixes: 89664c62 ("sctp: sctp_sock_migrate() returns error if sctp_bind_addr_dup() fails")
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sctp_hdr(skb) only works when skb->transport_header is set properly.

But in Netfilter, skb->transport_header for ipv6 is not guaranteed
to be right value for sctphdr. It would cause to fail to check the
checksum for sctp packets.

So fix it by using offset, which is always right in all places.

v1->v2:
  - Fix the changelog.

Fixes: e6d8b64b ("net: sctp: fix and consolidate SCTP checksumming code")
Reported-by: NLi Shuang <shuali@redhat.com>
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I am using "protocol ip" filters in TC to manipulate TC flower
classifiers, which are only available with "protocol ip". However,
I faced an issue that packets sent via raw sockets with ETH_P_ALL
did not match the ip filters even if they did satisfy the condition
(e.g., DHCP offer from dhcpd).

I have determined that the behavior was caused by an unexpected
value stored in skb->protocol, namely, ETH_P_ALL instead of ETH_P_IP,
when packets were sent via raw sockets with ETH_P_ALL set.

IMHO, storing ETH_P_ALL in skb->protocol is not appropriate for
packets sent via raw sockets because ETH_P_ALL is not a real ether
type used on wire, but a virtual one.

This patch fixes the tx protocol selection in cases of transmission
via raw sockets created with ETH_P_ALL so that it asks the driver to
extract protocol from the Ethernet header.

Fixes: 75c65772 ("net/packet: Ask driver for protocol if not provided by user")
Signed-off-by: NYoshiki Komachi <komachi.yoshiki@lab.ntt.co.jp>
Acked-by: NWillem de Bruijn <willemb@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using fanouts with AF_PACKET, the demux functions such as
fanout_demux_cpu will return an index in the fanout socket array, which
corresponds to the selected socket.

The ordering of this array depends on the order the sockets were added
to a given fanout group, so for FANOUT_CPU this means sockets are bound
to cpus in the order they are configured, which is OK.

However, when stopping then restarting the interface these sockets are
bound to, the sockets are reassigned to the fanout group in the reverse
order, due to the fact that they were inserted at the head of the
interface's AF_PACKET socket list.

This means that traffic that was directed to the first socket in the
fanout group is now directed to the last one after an interface restart.

In the case of FANOUT_CPU, traffic from CPU0 will be directed to the
socket that used to receive traffic from the last CPU after an interface
restart.

This commit introduces a helper to add a socket at the tail of a list,
then uses it to register AF_PACKET sockets.

Note that this changes the order in which sockets are listed in /proc and
with sock_diag.

Fixes: dc99f600 ("packet: Add fanout support")
Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
Acked-by: NWillem de Bruijn <willemb@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit ad6c9986 ("vxlan: Fix GRO cells race condition between
receive and link delete") fixed a race condition for the typical case a vxlan
device is dismantled from the current netns. But if a netns is dismantled,
vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue()
of all the vxlan tunnels that are related to this netns.

In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before
unregister_netdevice_queue(). This means that the gro_cells_destroy() call is
done too soon, for the same reasons explained in above commit.

So we need to fully respect the RCU rules, and thus must remove the
gro_cells_destroy() call or risk use after-free.

Fixes: 58ce31cc ("vxlan: GRO support at tunnel layer")
Signed-off-by: NSuanming.Mou <mousuanming@huawei.com>
Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
Reviewed-by: NStefano Brivio <sbrivio@redhat.com>
Reviewed-by: NZhiqiang Liu <liuzhiqiang26@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

TCP/UDP checksum validity was propagated to skb
only if IP checksum is valid.
But for IPv6 there is no validity as there is no checksum in IPv6.
This patch propagates TCP/UDP checksum validity regardless of IP checksum.

Fixes: 018423e9 ("net: ethernet: aquantia: Add ring support code")
Signed-off-by: NIgor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: NNikita Danilov <nikita.danilov@aquantia.com>
Signed-off-by: NDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The bug that Stan reported is as follows. After a restart, a 16-bit NIC
may be incorrectly identified as a 32-bit NIC and stop working.

mac8390 slot.E: Memory length resource not found, probing
mac8390 slot.E: Farallon EtherMac II-C (type farallon)
mac8390 slot.E: MAC 00:00:c5:30:c2:99, IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access.

The bug never arises after a cold start and only intermittently after a
warm start. (I didn't investigate why the bug is intermittent.)

It turns out that memcpy_toio() is deprecated and memcmp_withio() also
has issues. Replacing these calls with mmio accessors fixes the problem.
Reported-and-tested-by: NStan Johnson <userm57@yahoo.com>
Fixes: 2964db0f ("m68k: Mac DP8390 update")
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>