Here is a single fix, a revert, for the 8250 serial driver to resolve a
reported problem. There was some attempted patches to fix the issue,
but people are arguing about them, so reverting the patch to revert back
to the 4.19 and older behavior is the best thing to do at this late in
the release cycle.
The revert has been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXBuJvA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylRnQCgqMf3Y5uhohSjyTgagIaV2iVY2w8AniDnYWXe
cHDpt5USoLXRUSd8BJBn
=xdLq
-----END PGP SIGNATURE-----
Merge tag 'tty-4.20-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fix from Greg KH:
"Here is a single fix, a revert, for the 8250 serial driver to resolve
a reported problem.
There was some attempted patches to fix the issue, but people are
arguing about them, so reverting the patch to revert back to the 4.19
and older behavior is the best thing to do at this late in the release
cycle.
The revert has been in linux-next with no reported issues"
* tag 'tty-4.20-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
Revert "serial: 8250: Fix clearing FIFOs in RS485 mode again"
Here are some late xhci fixes for 4.20-rc8 as well as a few new device
ids for the option usb-serial driver.
The xhci fixes resolve some many-reported issues and all of these have
been in linux-next for a while with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXBuKqA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yl4tgCfbENVLa5iUbj6S3KxEl+k6yhENXoAoJ309Gr5
P1+XqKorzORhpilucdyJ
=CZ9a
-----END PGP SIGNATURE-----
Merge tag 'usb-4.20-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes and ids from Greg KH:
"Here are some late xhci fixes for 4.20-rc8 as well as a few new device
ids for the option usb-serial driver.
The xhci fixes resolve some many-reported issues and all of these have
been in linux-next for a while with no reported problems"
* tag 'usb-4.20-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: xhci: fix 'broken_suspend' placement in struct xchi_hcd
xhci: Don't prevent USB2 bus suspend in state check intended for USB3 only
USB: serial: option: add Telit LN940 series
USB: serial: option: add Fibocom NL668 series
USB: serial: option: add Simcom SIM7500/SIM7600 (MBIM mode)
USB: serial: option: add GosunCn ZTE WeLink ME3630
USB: serial: option: add HP lt4132
- Restore code to allow BKOPS and CACHE ctrl even if no HPI support
- Reset HPI enabled state during re-init
- Use a default minimum timeout when enabling CACHE ctrl
MMC host:
- omap_hsmmc: Fix DMA API warning
- sdhci-tegra: Fix dt parsing of SDMMC pads autocal values
- Correct register accesses when enabling v4 mode
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAlwbZuAXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjClwrQ//Qwfkk6goAozaNpvFawVLWy1y
EHpjSfcipMiYrXaztRx7mrxslj/G0HNY7+272M6OSvv61zVb8s5cdTw6e23f98Td
ZvswoOc5IWnfG1zfVPw2N+AvOMDlg1XNpS2IdjBt3M2WXf/vPBnG36wZlUFtt7TG
exYXg55IArDwCBDVrP3NPEam+LjRglPKpetzSvh1NkuZRVBicLcry4kVpaOXU20V
2AbwSkGGTZenXnSez32hvP2k/Rj7WpcrkkgDKRmmKwu22mem+imhSlDBQFk5ZBFJ
cr6NECYmsvPh7bWAlWzzi4nVSIVtmtlk7dIFRiAc1RHOjqtLBllZSCwsqdjQrV5a
8lugdk0gCSQhEkMwdcXDf6YzBznNrVFf7W5OZ0gzVYyEIfqkS1SMW585LkjSY6e4
iFRqWSB9kS9LWixPfyN2baxO7qSUGUFJA302d2DGvyRP2o7D9zWy3NOByfPtRbDl
7DKtiqSHy1LE/DF/meRiiy+wzvr1+uH2sYpfZ8/1gf0uEbdDb+96W8ghUDyVgisg
u0UycCUXWBDpXyIT6QLdOIzO8kIsV2k9EJVe4sl7/rDrjGKCugRbUOav4cNFigvE
hQrWd2BPYTqHz1rntAo34vMCrzPmkmlb78entgCTGLy4Tx7BIItVafuZoKS0jqcL
h9bbH4C17eNYcQFB3nQ=
=zypg
-----END PGP SIGNATURE-----
Merge tag 'mmc-v4.20-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"MMC core:
- Restore code to allow BKOPS and CACHE ctrl even if no HPI support
- Reset HPI enabled state during re-init
- Use a default minimum timeout when enabling CACHE ctrl
MMC host:
- omap_hsmmc: Fix DMA API warning
- sdhci-tegra: Fix dt parsing of SDMMC pads autocal values
- Correct register accesses when enabling v4 mode"
* tag 'mmc-v4.20-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl
mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support
mmc: core: Reset HPI enabled state during re-init and in case of errors
mmc: omap_hsmmc: fix DMA API warning
mmc: tegra: Fix for SDMMC pads autocal parsing from dt
mmc: sdhci: Fix sdhci_do_enable_v4_mode
This reverts commit 61c6de6672.
The reverted commit added page reference counting to iomap page
structures that are used to track block size < page size state. This
was supposed to align the code with page migration page accounting
assumptions, but what it has done instead is break XFS filesystems.
Every fstests run I've done on sub-page block size XFS filesystems
has since picking up this commit 2 days ago has failed with bad page
state errors such as:
# ./run_check.sh "-m rmapbt=1,reflink=1 -i sparse=1 -b size=1k" "generic/038"
....
SECTION -- xfs
FSTYP -- xfs (debug)
PLATFORM -- Linux/x86_64 test1 4.20.0-rc6-dgc+
MKFS_OPTIONS -- -f -m rmapbt=1,reflink=1 -i sparse=1 -b size=1k /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /mnt/scratch
generic/038 454s ...
run fstests generic/038 at 2018-12-20 18:43:05
XFS (sdc): Unmounting Filesystem
XFS (sdc): Mounting V5 Filesystem
XFS (sdc): Ending clean mount
BUG: Bad page state in process kswapd0 pfn:3a7fa
page:ffffea0000ccbeb0 count:0 mapcount:0 mapping:ffff88800d9b6360 index:0x1
flags: 0xfffffc0000000()
raw: 000fffffc0000000 dead000000000100 dead000000000200 ffff88800d9b6360
raw: 0000000000000001 0000000000000000 00000000ffffffff
page dumped because: non-NULL mapping
CPU: 0 PID: 676 Comm: kswapd0 Not tainted 4.20.0-rc6-dgc+ #915
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
Call Trace:
dump_stack+0x67/0x90
bad_page.cold.116+0x8a/0xbd
free_pcppages_bulk+0x4bf/0x6a0
free_unref_page_list+0x10f/0x1f0
shrink_page_list+0x49d/0xf50
shrink_inactive_list+0x19d/0x3b0
shrink_node_memcg.constprop.77+0x398/0x690
? shrink_slab.constprop.81+0x278/0x3f0
shrink_node+0x7a/0x2f0
kswapd+0x34b/0x6d0
? node_reclaim+0x240/0x240
kthread+0x11f/0x140
? __kthread_bind_mask+0x60/0x60
ret_from_fork+0x24/0x30
Disabling lock debugging due to kernel taint
....
The failures are from anyway that frees pages and empties the
per-cpu page magazines, so it's not a predictable failure or an easy
to debug failure.
generic/038 is a reliable reproducer of this problem - it has a 9 in
10 failure rate on one of my test machines. Failure on other
machines have been at random points in fstests runs but every run
has ended up tripping this problem. Hence generic/038 was used to
bisect the failure because it was the most reliable failure.
It is too close to the 4.20 release (not to mention holidays) to
try to diagnose, fix and test the underlying cause of the problem,
so reverting the commit is the only option we have right now. The
revert has been tested against a current tot 4.20-rc7+ kernel across
multiple machines running sub-page block size XFs filesystems and
none of the bad page state failures have been seen.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Cc: Piotr Jaroszynski <pjaroszynski@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Brian Foster <bfoster@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull networking fixes from David Miller:
1) Off by one in netlink parsing of mac802154_hwsim, from Alexander
Aring.
2) nf_tables RCU usage fix from Taehee Yoo.
3) Flow dissector needs nhoff and thoff clamping, from Stanislav
Fomichev.
4) Missing sin6_flowinfo initialization in SCTP, from Xin Long.
5) Spectrev1 in ipmr and ip6mr, from Gustavo A. R. Silva.
6) Fix r8169 crash when DEBUG_SHIRQ is enabled, from Heiner Kallweit.
7) Fix SKB leak in rtlwifi, from Larry Finger.
8) Fix state pruning in bpf verifier, from Jakub Kicinski.
9) Don't handle completely duplicate fragments as overlapping, from
Michal Kubecek.
10) Fix memory corruption with macb and 64-bit DMA, from Anssi Hannula.
11) Fix TCP fallback socket release in smc, from Myungho Jung.
12) gro_cells_destroy needs to napi_disable, from Lorenzo Bianconi.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (130 commits)
rds: Fix warning.
neighbor: NTF_PROXY is a valid ndm_flag for a dump request
net: mvpp2: fix the phylink mode validation
net/sched: cls_flower: Remove old entries from rhashtable
net/tls: allocate tls context using GFP_ATOMIC
iptunnel: make TUNNEL_FLAGS available in uapi
gro_cell: add napi_disable in gro_cells_destroy
lan743x: Remove MAC Reset from initialization
net/mlx5e: Remove the false indication of software timestamping support
net/mlx5: Typo fix in del_sw_hw_rule
net/mlx5e: RX, Fix wrong early return in receive queue poll
ipv6: explicitly initialize udp6_addr in udp_sock_create6()
bnxt_en: Fix ethtool self-test loopback.
net/rds: remove user triggered WARN_ON in rds_sendmsg
net/rds: fix warn in rds_message_alloc_sgs
ath10k: skip sending quiet mode cmd for WCN3990
mac80211: free skb fraglist before freeing the skb
nl80211: fix memory leak if validate_pae_over_nl80211() fails
net/smc: fix TCP fallback socket release
vxge: ensure data0 is initialized in when fetching firmware version information
...
>> net/rds/send.c:1109:42: warning: Using plain integer as NULL pointer
Fixes: ea010070d0 ("net/rds: fix warn in rds_message_alloc_sgs")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A last-minute fix for a test build.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcGtMtAAoJECgfDbjSjVRpps4H/27UFb1IcPR2AVITTk8BTZA0
eBPxr7d3JoaVLUXkxi4tju3kJ8dI1bqrfJQkmAfa26esw6q5CDau1G7m34UdUqY3
kJMJ0Ce+HOdsSVC7a4PlT9UjgaCkIIi2X+uahAigshvJwumBYISnj2dt37SoDlTg
lIBwWfwNdSkmoEc4bJ9s26xyAnBXRSgz0CQlvhzZthHtorfzkaoL3P1/o7BznHqR
rMIzge7S3E/hN4sRK15DJ5y/QNVKKSiuy2uFxQuLft3sQdEndM+GUnEMrvqlRvUu
iSCdquAXkk08Ok7pINkMGcQ3TE5JPl+Q8BPGzK/a8Aiqsty13jcUjReMySvezrI=
=ik55
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fix from Michael Tsirkin:
"A last-minute fix for a test build"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio: fix test build after uio.h change
Bugfixes:
- Fix TCP socket disconnection races by ensuring we always call
xprt_disconnect_done() after releasing the socket.
- Fix a race when clearing both XPRT_CONNECTING and XPRT_LOCKED
- Remove xprt_connect_status() so it does not mask errors that should
be handled by call_connect_status()
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcGnQMAAoJEA4mA3inWBJc3OIP/iRGQeEKuJrGxarssdzIXrqZ
ID6t6XuYxuh6nknS3PAvn1TpAPGFRcTya5MIjvMEMCknH4tQVmD7S2v2vOlx395E
5Cg5Q6FX1dj3i2/flzS1YcByQonUrkJuuMZ36bRJ5uCGjXdryhgC1YNcsq3HXAiA
G/O4W+BpvxLC9z3KGwWz2+v5K4gnIh9sypSye8qsQdrgDlFDo88jWH57gtxQTVjv
13vke64pv/bm97EfZ8gfZprcwLegQ3JJsmcoOfwnh2jRd2i5j4S/xmCLaTjOn9Fg
8fgev7klAzO/39gNV+syGKXVwgOh6mKk5PifDYv986ghvzamPmVT+chIpjgXKSJp
KOpGXY/547KFHWwMQVsmNI+5RPC7FTwDkTwXuOVcmtVyNiJgpveX45pQS8kwRYxq
kZXk/t1T1lXbsBPd0S+1KDjUUPd9DjSm3T3CZKvvfJBbH+ITV2gol2eqneizgxDo
JLBdNFRVTPnud7IEdXiXgjMzl8aFAZsPkXfUmqWPEMtiTn5izSUbXxa04KYgHQpI
GAAMVAZttl6cYoRkPIVIbQLbpY4LsBxA9iTTR39SGINLYiFQBFUNkP02OR+HaD4l
bzY8n5Li1/WekxHagq6RFt+ajBgXSPeCXS3WqigEMc0Xw58u/3Td+0DuRIABmhhr
IJDorHWizxgh2VseZkUB
=+M4X
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-4.20-6' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
- Fix TCP socket disconnection races by ensuring we always call
xprt_disconnect_done() after releasing the socket.
- Fix a race when clearing both XPRT_CONNECTING and XPRT_LOCKED
- Remove xprt_connect_status() so it does not mask errors that should
be handled by call_connect_status()
* tag 'nfs-for-4.20-6' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
SUNRPC: Remove xprt_connect_status()
SUNRPC: Fix a race with XPRT_CONNECTING
SUNRPC: Fix disconnection races
* A less nasty use-after-free that can only zero some words at
the beginning of the page, and hence is not really exploitable
* A NULL pointer dereference
* A dummy implementation of an AMD chicken bit MSR that Windows uses
for some unknown reason
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJcGWZUAAoJEL/70l94x66DhecIAKhyarwvQ1HyKUCmeeVAuQHi
8RW8iisiCAQdhtrzjrOjt025gYskeuKItw0V/ipg0orgTTgti4TRoJpfDpZV+550
2EHT2UyUNCjSUwwtUNJ60ky+GRyFCgY8kdqiMTqFmFnpbK/TWY7jx7jtPToRQron
tL1H0RCeYJlPThK/UM7i3UIvS5oVIZ8YOJ18PVcKCoiynrbPk7wgw3it5OdiO2bS
VnI5JMfNy4YIXPc6QqdcKmsLqtinHxVObg+0PnLFtaI6xUqzTzEa12toZxsc9Sf3
rHyYhpNO8kaTw2inLpvbgLX3TZbw5DckHEoOn+s4e5Q193HGTjsTfG9P9oph2hA=
=VQE8
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
- One nasty use-after-free bugfix, from this merge window however
- A less nasty use-after-free that can only zero some words at the
beginning of the page, and hence is not really exploitable
- A NULL pointer dereference
- A dummy implementation of an AMD chicken bit MSR that Windows uses
for some unknown reason
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs
KVM: X86: Fix NULL deref in vcpu_scan_ioapic
KVM: Fix UAF in nested posted interrupt processing
KVM: fix unregistering coalesced mmio zone from wrong bus
Fix a regression in dma-direct that didn't take account the magic AMD
memory encryption mask in the DMA address.
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAlwaVAULHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYOY4A/9FYHCK486kbEA1df8DxLT6Hz0U6NU9fxgOBMb347K
uQdmdRB8oR3+aaWnohdr6/qT2oAEn3HM9db4L+eu4D28Fxjfv9Pn0QwjFnAUKGKS
90ZvmE8FxHOZydR0l3glHgSxuK+aKGs4Qv6Im5vDWkzwVfMqN0WDbBUfbNbG4nsh
spkdRnx32orstPpUkqbr/26iUAFk9TI3tvg7QDgL88cFArwCBW5ZTmznCnbFeGoz
TxptRFzDYslWZJYAgKWJ9VQ1sCRyZeMD6maoHsFZNL+XQiZ9/WzLN8GZm8/Tn7sP
Rcc8D0qkNqcZbUFku2n1r2Z9iHjB3+fI87zdaarSytB5mhHNkpES5boC2ExTjXTu
QsQt33zbrJXO+8F/571u3k5n8QkkazmYewtviGnNpGq2AofinSOU4BsKxQePI00l
gN3FjVpFyvgxzRdxp4kpa3UfRFOp61zWqVYZYzGrH8Au99t4ineD+iY1ztd0Z2mH
23zjAfnCjGF8VOBNi9vxQFeNLlZoWCCuShENePJ76Bm6lBNjPT1O2Tilc+pbBs2A
RJPoUgMCSfZ+RHyS3ohKM/LLJaX1wEQHYTXa6FyskvOWa9vD4bXJ4kNwc5LY7SyK
i+KAnEierBxvtRMzo5uu9DJXaJZx1Cw711/2IAPkmXUMDld5rwsrdEbgqDD2mlD8
6l0=
=EybB
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-4.20-4' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping fix from Christoph Hellwig:
"Fix a regression in dma-direct that didn't take account the magic AMD
memory encryption mask in the DMA address"
* tag 'dma-mapping-4.20-4' of git://git.infradead.org/users/hch/dma-mapping:
dma-direct: do not include SME mask in the DMA supported check
When dumping proxy entries the dump request has NTF_PROXY set in
ndm_flags. strict mode checking needs to be updated to allow this
flag.
Fixes: 51183d233b ("net/neighbor: Update neigh_dump_info for strict data checking")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mvpp2_phylink_validate() sets all modes that are supported by a
given PPv2 port. An mistake made the 10000baseT_Full mode being
advertised in some cases when a port wasn't configured to perform at
10G. This patch fixes this.
Fixes: d97c9f4ab0 ("net: mvpp2: 1000baseX support")
Reported-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When replacing a rule we add the new rule to the rhashtable
but only remove the old if not in skip_sw.
This commit fix this and remove the old rule anyway.
Fixes: 35cc3cefc4 ("net/sched: cls_flower: Reject duplicated rules also under skip_sw")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap Key example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
In the lwtunnel situation, some TUNNEL_FLAGS should can be set by
userspace
Signed-off-by: wenxu <wenxu@ucloud.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
The MAC Reset was noticed to erase important EEPROM settings.
It is also unnecessary since a chip wide reset was done earlier
in initialization, and that reset preserves EEPROM settings.
There for this patch removes the unnecessary MAC specific reset.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some fixes for the mlx5 driver
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcGrikAAoJEEg/ir3gV/o+tSEH/A6192OXs+B6phGdMr6GyhbK
nzw6bkJfjHLMDj00F+9qLYYQbqfG1QjDYZnthPCezD9Kv0thFuP8cvSSY1S6SsJq
uMwlHwYQ4ljZvl49pkwiiKMufWGcuVYf+NiEmvrYVWXugej1wENe1xiTS9V3OCAA
j9gQA7gYeEwveOLWLakwzbfvLJ+fyUkLDjB1EJPOzh2fnfkGl8Z8LovAmoXOywdn
PdMh9xAlqovJyY9kS4vaj/1WDCO9+rUfGHXDLjjzG5ygsfipyb8xSdzsY9WgriMu
NKgg1VpEjc9egalT9qqznUE7ilfBUvW++Yc0wsrH+Cme3Rj322L3Es+j5fduKGo=
=YiD1
-----END PGP SIGNATURE-----
Merge tag 'mlx5-fixes-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-fixes-2018-12-19
Some fixes for the mlx5 driver
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Expression terminated with "," instead of ";", resulted in
set_fte getting bad value for modify_enable_mask field.
Fixes: bd5251dbf1 ("net/mlx5_core: Introduce flow steering destination of type counter")
Signed-off-by: Yuval Avnery <yuvalav@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
When the completion queue of the RQ is empty, do not immediately return.
If left-over decompressed CQEs (from the previous cycle) were processed,
need to go to the finalization part of the poll function.
Bug exists only when CQE compression is turned ON.
This solves the following issue:
mlx5_core 0000:82:00.1: mlx5_eq_int:544:(pid 0): CQ error on CQN 0xc08, syndrome 0x1
mlx5_core 0000:82:00.1 p4p2: mlx5e_cq_error_event: cqn=0x000c08 event=0x04
Fixes: 4b7dfc9925 ("net/mlx5e: Early-return on empty completion queues")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
syzbot reported the use of uninitialized udp6_addr::sin6_scope_id.
We can just set ::sin6_scope_id to zero, as tunnels are unlikely
to use an IPv6 address that needs a scope id and there is no
interface to bind in this context.
For net-next, it looks different as we have cfg->bind_ifindex there
so we can probably call ipv6_iface_scope_id().
Same for ::sin6_flowinfo, tunnels don't use it.
Fixes: 8024e02879 ("udp: Add udp_sock_create for UDP tunnels to open listener socket")
Reported-by: syzbot+c56449ed3652e6720f30@syzkaller.appspotmail.com
Cc: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code has 2 problems. It assumes that the RX ring for
the loopback packet is combined with the TX ring. This is not
true if the ethtool channels are set to non-combined mode. The
second problem is that it won't work on 57500 chips without
adjusting the logic to get the proper completion ring (cpr) pointer.
Fix both issues by locating the proper cpr pointer through the RX
ring.
Fixes: e44758b78a ("bnxt_en: Use bnxt_cp_ring_info struct pointer as parameter for RX path.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shamir Rabinovitch says:
====================
WARNING in rds_message_alloc_sgs
This patch set fix google syzbot rds bug found in linux-next.
The first patch solve the syzbot issue.
The second patch fix issue mentioned by Leon Romanovsky that
drivers should not call WARN_ON as result from user input.
syzbot bug report can be foud here: https://lkml.org/lkml/2018/10/31/28
v1->v2:
- patch 1: make rds_iov_vector fields name more descriptive (Hakon)
- patch 1: fix potential mem leak in rds_rm_size if krealloc fail
(Hakon)
v2->v3:
- patch 2: harden rds_sendmsg for invalid number of sgs (Gerd)
v3->v4
- Santosh a.b. on both patches + repost to net-dev
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
per comment from Leon in rdma mailing list
https://lkml.org/lkml/2018/10/31/312 :
Please don't forget to remove user triggered WARN_ON.
https://lwn.net/Articles/769365/
"Greg Kroah-Hartman raised the problem of core kernel API code that will
use WARN_ON_ONCE() to complain about bad usage; that will not generate
the desired result if WARN_ON_ONCE() is configured to crash the machine.
He was told that the code should just call pr_warn() instead, and that
the called function should return an error in such situations. It was
generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be
triggered from user space need to be fixed."
in addition harden rds_sendmsg to detect and overcome issues with
invalid sg count and fail the sendmsg.
Suggested-by: Leon Romanovsky <leon@kernel.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: shamir rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Last set of fixes for 4.20. All (except the mt76 fix) of these are
important fixes to user reported problems and pretty small in size.
rtlwifi
* fix skb leak
mwifiex
* revert a commit from v4.19 due to problems with locking
mt76
* fix a potential NULL derenfence
* add entry to MAINTAINERS
iwlwifi
* fix a firmware crash which was a regression introduced in v4.20-rc4
ath10k
* fix a firmware crash with wcn3990 firmware
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcGlNvAAoJEG4XJFUm622boJ0H/AjDASkdxSG4n+s1wCmsUizE
jK9YwS2dOc1oVSzGPm35GccFgkc4x1IpS1qoTo1rykVD7Cn6G7mj6eqy8vTiJ24S
6HPhdkS5YynWvYfbQmuhhhaQ6ew8/dJzqhPJAH1/kPfDsy08qUaVl5tGw4CwP4Pp
Ufvrn8VNmRbrAg9Jq28+xmANNURtKNtHmXI5WWuSvA4LzkdEz2aebG8ynOwTrVW6
f6NHTDeJ5tWrswr0EWGjBbGRfb8TlacOxqzytrFYFuYHH3WiqCQZdsvRBazvryqJ
szrYMlI+bSN4m3ZEAtEWlZYTU1YNPwbRDXc+GYkbDr19YKevHxi+46SvXa36cJM=
=ECaW
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for 4.20
Last set of fixes for 4.20. All (except the mt76 fix) of these are
important fixes to user reported problems and pretty small in size.
rtlwifi
* fix skb leak
mwifiex
* revert a commit from v4.19 due to problems with locking
mt76
* fix a potential NULL derenfence
* add entry to MAINTAINERS
iwlwifi
* fix a firmware crash which was a regression introduced in v4.20-rc4
ath10k
* fix a firmware crash with wcn3990 firmware
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
* fix a memory leak in an error path
* fix TXQs in interface teardown
* free fraglist if we used it internally
before returning SKB
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAlwaBJAACgkQB8qZga/f
l8QvBg/9ESMGPa4F+AdXfvwlDWHkb3fBuv8E1HAkiDiV3G0eyziOwqIo4mSD49fT
tSM+3AFBe9D97O0Y669qnKrcqSWVpGY31hI2MmxskcwwJ+BVgf9M33GjvHa548Bt
c3DEKVLDIfOfQG9+LySeNNz8kRipqIe11WDjpoHZ1i2LtV/uEGOC+cSAxTRwqxpG
HyjF2GBz24PVz69eGNODQNIWgIkkGCil8b8BCED94jUio015t7H+b3hzWDDC83m1
pJwK/Uq4UkJzpjQykSf9805blB0h7PdXo8CSrNNw9+PnEVcvu+81IqD0q5VfZL1a
CePmM43ud59kx1DtPQ0LB4XSIJX7PPiMskK9ZoPUduDvOsaJU32gFmK/Rvm45Xdt
8mQrZM8EsBLCFq8M/Gk89QadXByItUD8B6jZcJgMEddUOa5QPnCaodTQqqO2I8ky
T76FXRegTOMFeGhr/NrWAw3xxCY8TZqwB4P9F4juoKCa9Wz0b1dbIrD7nx1SajoA
jhb795CTczMKCzFywNIh97fKa2yp0YQO0/EQDOFrbYxEyQozSr+cudU4EBN6B08i
A4rVRAAPTlwfFz5TSr7gvT/JHlsku+kfjFAY1tmSWxLgWxFJb3cc0Uj1ak05bmv4
fdANk9g81U4W/bUBKqmeIIrYW0icXHtGZBLX0Khpcx3KQSH11vw=
=X7vr
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Just three fixes:
* fix a memory leak in an error path
* fix TXQs in interface teardown
* free fraglist if we used it internally
before returning SKB
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
HL2.0 firmware does not support setting quiet mode. If the host driver sends
the quiet mode setting command to the HL2.0 firmware, it crashes with the below
signature.
fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN RT:207a:PC=b001b4f0
The quiet mode command support is exposed by the firmware via thermal throttle
wmi service. Enable ath10k thermal support if thermal throttle wmi service bit
is set. 10.x firmware versions support this feature by default, but
unfortunately do not advertise the support via service flags, hence have to
manually set the service flag in ath10k_core_compat_services().
Tested on QCA988X with 10.2.4.70.9-2. Also tested on WCN3990.
Co-developed-by: Govind Singh <govinds@codeaurora.org>
Co-developed-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mac80211 uses the frag list to build AMSDU. When freeing
the skb, it may not be really freed, since someone is still
holding a reference to it.
In that case, when TCP skb is being retransmitted, the
pointer to the frag list is being reused, while the data
in there is no longer valid.
Since we will never get frag list from the network stack,
as mac80211 doesn't advertise the capability, we can safely
free and nullify it before releasing the SKB.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If validate_pae_over_nl80211() were to fail in nl80211_crypto_settings(),
we might leak the 'connkeys' allocation. Fix this.
Fixes: 64bf3d4bc2 ("nl80211: Add CONTROL_PORT_OVER_NL80211 attribute")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Alexei Starovoitov says:
====================
pull-request: bpf 2018-12-18
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) promote bpf_perf_event.h to mandatory UAPI header, from Masahiro.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
clcsock can be released while kernel_accept() references it in TCP
listen worker. Also, clcsock needs to wake up before released if TCP
fallback is used and the clcsock is blocked by accept. Add a lock to
safely release clcsock and call kernel_sock_shutdown() to wake up
clcsock from accept in smc_release().
Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
Reported-by: syzbot+e3132895630f957306bc@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently variable data0 is not being initialized so a garbage value is
being passed to vxge_hw_vpath_fw_api and this value is being written to
the rts_access_steer_data0 register. There are other occurrances where
data0 is being initialized to zero (e.g. in function
vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0
is initialized likewise to 0.
Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable")
Fixes: 8424e00dfd ("vxge: serialize access to steering control register")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.
Modify the BUG_ON() condition accordingly.
Tested-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Even though the link is down before entering hibernation,
there is an issue that the network interface always links up after resuming
from hibernation.
If the link is still down before enabling the network interface,
and after resuming from hibernation, the phydev->state is forcibly set
to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend()
calls phy_stop_machine(), and mdio_bus_phy_resume() calls
phy_start_machine().
In resume sequence, it's enough to do the same as mdio_bus_phy_resume()
because the state has been preserved.
This patch fixes the issue by calling phy_start_machine() in
mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume().
Fixes: bc87922ff5 ("phy: Move PHY PM operations into phy_device")
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Current state for the lan78xx driver does not allow for changing the
MAC address of the interface, without either removing the module (if
you compiled it that way) or rebooting the machine. If you attempt to
change the MAC address, ifconfig will show the new address, however,
the system/interface will not respond to any traffic using that
configuration. A few short-term options to work around this are to
unload the module and reload it with the new MAC address, change the
interface to "promisc", or reboot with the correct configuration to
change the MAC.
This patch enables the ability to change the MAC address via fairly normal means...
ifdown <interface>
modify entry in /etc/network/interfaces OR a similar method
ifup <interface>
Then test via any network communication, such as ICMP requests to gateway.
My only test platform for this patch has been a raspberry pi model 3b+.
Signed-off-by: Jason Martinsen <jasonmartinsen@msn.com>
-----
Signed-off-by: David S. Miller <davem@davemloft.net>
The LAN7431 uses an external phy, and it can be found anywhere in
the phy address space. This patch uses phy address 1 for LAN7430
only. And searches all addresses otherwise.
Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata says:
====================
vxlan: Various fixes
This patch set contains three fixes for the vxlan driver.
Patch #1 fixes handling of offload mark on replaced VXLAN FDB entries. A
way to trigger this is to replace the FDB entry with one that can not be
offloaded. A future patch set should make it possible to veto such FDB
changes. However the FDB might still fail to be offloaded due to another
issue, and the offload mark should reflect that.
Patch #2 fixes problems in __vxlan_dev_create() when a call to
rtnl_configure_link() fails. These failures would be tricky to hit on a
real system, the most likely vector is through an error in vxlan_open().
However, with the abovementioned vetoing patchset, vetoing the created
entry would trigger the same problems (and be easier to reproduce).
Patch #3 fixes a problem in vxlan_changelink(). In situations where the
default remote configured in the FDB table (if any) does not exactly
match the remote address configured at the VXLAN device, changing the
remote address breaks the default FDB entry. Patch #4 is then a self
test for this issue.
v3:
- Patch #2:
- Reuse the same errout block for both cleanup paths. Use a bool to
decide whether the unregister_netdevice() call should be made.
v2:
- Drop former patch #3
- Patch #2:
- Delete the default entry before calling unregister_netdevice(). That
takes care of former patch #3, hence tweak the commit message to
mention that problem as well.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a test to exercise the fix from the previous patch.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Default remotes are stored as FDB entries with an Ethernet address of
00:00:00:00:00:00. When a request is made to change a remote address of
a VXLAN device, vxlan_changelink() first deletes the existing default
remote, and then creates a new FDB entry.
This works well as long as the list of default remotes matches exactly
the configuration of a VXLAN remote address. Thus when the VXLAN device
has a remote of X, there should be exactly one default remote FDB entry
X. If the VXLAN device has no remote address, there should be no such
entry.
Besides using "ip link set", it is possible to manipulate the list of
default remotes by using the "bridge fdb". It is therefore easy to break
the above condition. Under such circumstances, the __vxlan_fdb_delete()
call doesn't delete the FDB entry itself, but just one remote. The
following vxlan_fdb_create() then creates a new FDB entry, leading to a
situation where two entries exist for the address 00:00:00:00:00:00,
each with a different subset of default remotes.
An even more obvious breakage rooted in the same cause can be observed
when a remote address is configured for a VXLAN device that did not have
one before. In that case vxlan_changelink() doesn't remove any remote,
and just creates a new FDB entry for the new address:
$ ip link add name vx up type vxlan id 2000 dstport 4789
$ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.20 self permanent
$ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.30 self permanent
$ ip link set dev vx type vxlan remote 192.0.2.30
$ bridge fdb sh dev vx | grep 00:00:00:00:00:00
00:00:00:00:00:00 dst 192.0.2.30 self permanent <- new entry, 1 rdst
00:00:00:00:00:00 dst 192.0.2.20 self permanent <- orig. entry, 2 rdsts
00:00:00:00:00:00 dst 192.0.2.30 self permanent
To fix this, instead of calling vxlan_fdb_create() directly, defer to
vxlan_fdb_update(). That has logic to handle the duplicates properly.
Additionally, it also handles notifications, so drop that call from
changelink as well.
Fixes: 0241b83673 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a failure occurs in rtnl_configure_link(), the current code
calls unregister_netdevice() to roll back the earlier call to
register_netdevice(), and jumps to errout, which calls
vxlan_fdb_destroy().
However unregister_netdevice() calls transitively ndo_uninit, which is
vxlan_uninit(), and that already takes care of deleting the default FDB
entry by calling vxlan_fdb_delete_default(). Since the entry added
earlier in __vxlan_dev_create() is exactly the default entry, the
cleanup code in the errout block always leads to double free and thus a
panic.
Besides, since vxlan_fdb_delete_default() always destroys the FDB entry
with notification enabled, the deletion of the default entry is notified
even before the addition was notified.
Instead, move the unregister_netdevice() call after the manual destroy,
which solves both problems.
Fixes: 0241b83673 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When rdst of an offloaded FDB entry is replaced, it certainly isn't
offloaded anymore. Drivers are notified about such replacements, and can
re-mark the entry as offloaded again if they so wish. However until a
driver does so explicitly, assume a replaced FDB entry is not offloaded.
Note that replaces coming via vxlan_fdb_external_learn_add() are always
immediately followed by an explicit offload marking.
Fixes: 0efe117333 ("vxlan: Support marking RDSTs as offloaded")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Anssi Hannula says:
====================
net: macb: DMA race condition fixes
Here are a couple of race condition fixes for the macb driver. The first
two are for issues observed at runtime on real HW.
v2:
- added received Tested-bys and Acked-bys to the first two patches
- in patch 3/3, moved the timestamp protection barrier closer to the
timestamp reads
- in patch 3/3, removed unnecessary move of the addr assignment in
gem_rx() to keep the patch minimal for maximum clarity
- in patch 3/3, clarified commit message and comments
The 3/3 is the same one I improperly sent last week as a standalone
patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When reading buffer descriptors on RX or on TX completion, an
RX_USED/TX_USED bit is checked first to ensure that the descriptors have
been populated, i.e. the ownership has been transferred. However, there
are no memory barriers to ensure that the data protected by the
RX_USED/TX_USED bit is up-to-date with respect to that bit.
Specifically:
- TX timestamp descriptors may be loaded before ctrl is loaded for the
TX_USED check, which is racy as the descriptors may be updated between
the loads, causing old timestamp descriptor data to be used.
- RX ctrl may be loaded before addr is loaded for the RX_USED check,
which is racy as a new frame may be written between the loads, causing
old ctrl descriptor data to be used.
This issue exists for both macb_rx() and gem_rx() variants.
Fix the races by adding DMA read memory barriers on those paths and
reordering the reads in macb_rx().
I have not observed any actual problems in practice caused by these
being missing, though.
Tested on a ZynqMP based system.
Fixes: 89e5785fc8 ("[PATCH] Atmel MACB ethernet driver")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bit RX_USED set to 0 in the address field allows the controller to write
data to the receive buffer descriptor.
The driver does not ensure the ctrl field is ready (cleared) when the
controller sees the RX_USED=0 written by the driver. The ctrl field might
only be cleared after the controller has already updated it according to
a newly received frame, causing the frame to be discarded in gem_rx() due
to unexpected ctrl field contents.
A message is logged when the above scenario occurs:
macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor
Fix the issue by ensuring that when the controller sees RX_USED=0 the
ctrl field is already cleared.
This issue was observed on a ZynqMP based system.
Fixes: 4df95131ea ("net/macb: change RX path for GEM")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
64-bit DMA addresses are split in upper and lower halves that are
written in separate fields on GEM. For RX, bit 0 of the address is used
as the ownership bit (RX_USED). When the RX_USED bit is unset the
controller is allowed to write data to the buffer.
The driver does not guarantee that the controller already sees the upper
half when the RX_USED bit is cleared, possibly resulting in the
controller writing an incoming frame to an address with an incorrect
upper half and therefore possibly corrupting unrelated system memory.
Fix that by adding the necessary DMA memory barrier between the writes.
This corruption was observed on a ZynqMP based system.
Fixes: fff8019a08 ("net: macb: Add 64 bit addressing support for GEM")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Acked-by: Harini Katakam <harini.katakam@xilinx.com>
Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Herton reports the following error when building a userspace program that
includes net_stamp.h:
In file included from foo.c:2:
/usr/include/linux/net_tstamp.h:158:2: error: unknown type name
‘clockid_t’
clockid_t clockid; /* reference clockid */
^~~~~~~~~
Fix it by using __kernel_clockid_t in place of clockid_t.
Fixes: 80b14dee2b ("net: Add a new socket option for a future transmit time.")
Cc: Timothy Redaelli <tredaelli@redhat.com>
Reported-by: Herton R. Krzesinski <herton@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Tested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On some platforms (currently detected only on SAMA5D4) TX might stuck
even the pachets are still present in DMA memories and TX start was
issued for them. This happens due to race condition between MACB driver
updating next TX buffer descriptor to be used and IP reading the same
descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
is asserted TX must be restarted. Restart TX if used bit is read and
packets are present in software TX queue. Packets are removed from software
TX queue if TX was successful for them (see macb_tx_interrupt()).
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
