Add support for FATSOv2 to the driver. FATSOv2 offloads far more of the task
of TCP segmentation to the firmware, such that we now just pass a single
super-packet to the NIC. This means TSO has a great deal in common with a
normal DMA transmit, apart from adding a couple of option descriptors.
NIC-specific checks have been moved off the fast path and in to
initialisation where possible.
This also moves FATSOv1/SWTSO to a new file (tx_tso.c). The end of transmit
and some error handling is now outside TSO, since it is common with other
code.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Finally, after being puzzled by a bunch of recurrent UML
build failures on randconfigs from the build robot, Keno
Fischer nailed it: GPIO_DEVRES is optional and depends on
HAS_IOMEM even though many users just unconditionally rely
on it to be available. And it *should* be available:
garbage collection is nice for this and it *certainly* has
nothing to do with having IOMEM. So we got rid of it, and
now the UML builds should JustWork(TM).
- Do not call .get_direction() on sleeping GPIO chips on the
fastpath when locking GPIOs for interrupts: it is done
from atomic context, no way.
- Some driver fixes.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYLr35AAoJEEEQszewGV1zdGkP/jPFN1oInhLFxRul2RBoI6kH
2D681F1c90PuEnLQU4JhzHjXizVn91u3/9tvGV7jpKePYe+Xvj8b1La8B+FPJ+Xr
jc4OwXiiH0Q5hbDS8WkO6lrR7wY9sqJPl+Z7iOTQy7nuBJgsAq9A+h9clqAttQaI
9QYrk4lb3V1tEnUZszu9/Bp0F/YQNHOMAgZvvsWz1S5wN1RD0Uk1YpEkXfQLL7H3
sv20Wvl3IXuggkDoHciSlb7Z/Kjtn0dgYiKSSSsr2Ph9yQTVWVfIf2r1NJUyZ5j5
C8bvD6/tgSPgoHZY+nx+wOhl7BxLNzTGPGiUVRuL9b2XhS0zyuBZx+SGIMvdaczi
t8+OLGub5z4Yqk9Fg18iql6KFoPXMtpvYHm9bWlevQm7KwMtky+HUU3VyzgV6UUD
7/pw62XF9gn06i7DI9mwEqRu2xZTPKEOj3Xz4WgW2g7HL4oXe8OvFvUG1arXTcLp
vvjD0bG7owmN51vsCu0XbACUEC2bIPLkHncd0Azn8/aWTgDRoukkJvlFx3AOGHIE
QdUBycQJ2WDlpcfbCuN+6YGFM+NOMWKy0T1R+121tvK3AYae69BuRxhb3L2BldY9
nNrJ5hOM1+ZA6jN+hjJPZH0JgvEzQyq/91QnjSJiTHnuLLkflP0Sm53YWdbS/OXE
/tvYeTw/a2O5xWSTtMSu
=MySu
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"These are hopefully the last GPIO fixes for v4.9. The most important
is that it fixes the UML randconfig builds that have been nagging me
for some time and me being confused about where the problem was really
sitting, now this fix give this nice feeling that everything is solid
and builds fine.
Summary:
- Finally, after being puzzled by a bunch of recurrent UML build
failures on randconfigs from the build robot, Keno Fischer nailed
it: GPIO_DEVRES is optional and depends on HAS_IOMEM even though
many users just unconditionally rely on it to be available. And it
*should* be available: garbage collection is nice for this and it
*certainly* has nothing to do with having IOMEM. So we got rid of
it, and now the UML builds should JustWork(TM).
- Do not call .get_direction() on sleeping GPIO chips on the fastpath
when locking GPIOs for interrupts: it is done from atomic context,
no way.
- Some driver fixes"
* tag 'gpio-v4.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: Remove GPIO_DEVRES option
gpio: tc3589x: fix up .get_direction()
gpio: do not double-check direction on sleeping chips
gpio: pca953x: Move memcpy into mutex lock for set multiple
gpio: pca953x: Fix corruption of other gpios in set_multiple.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYLlIgAAoJEAx081l5xIa+mjoP/2wh9hcrX4bG4XWnixR/KSf/
xAtqsNl87oQE6cq+PGD0WsmyCjnLFKbvi12ChM0slu3r4qSRlAOtmdGaqmha/jkv
8Km4tBgxrxsh8H+rN/x+1aXCVbt8H2qeOikeQgHTdluX7fnBs37vJAfccw7W010p
Ezv5N65UEgtS+HxDBKp5hQG3416ycU1gj1cmRMYhzTKp5EFSB48zoZ+r1dH07/MG
989D1v/YkR/KyKTj+mhdsPZ6lKLdnEWP1SHR7kRQcxrxBJGgtYIiRY4x7TSKBa+x
EoyX3srhex/TvYrlmlMZqqXhE8ddgvjJmE3zV5mDFJOgDtaSvZBdkU5IxjSPJfzK
yfEz6vUlLxGxsIxlT6oG7CBghsuZtED7vDbDOdf+2HR1X/i/i3VMnAKrLe/p8Z4L
VwRkf3Pri+PV4iZpT8jSMFVE0uXLLswK/UyFpAT07JbwqxbPceQa6FB0IlAwcAJd
ueFq+nQ6CdL4h98YNNqCaKAIa/686lf0Vh+6BHY4Pqp8ePSVdCpbEKd08UDHoAw2
RYHMNQY6gvS+P7laN+qFUC1nLIvd3ynhHRqIsaZgCraVjKJaGBbkT8WaV9LeGeO+
/+Se9zbvlZmnFO0ynhRJZITY/n2hgaRcLgzwV611F1qHVk6ZcUac0AOR8NQleXm/
psGWhW/QNog3VObrlC/M
=EAA/
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.9-rc6-brown-paper-bag' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"i915 fixes + 2 mediatek regressions.
So some i915 fixes came in which I thought they might so I'm sending
those along with two reverts for two patches to the mediatek driver
that didn't seem to build so well, I've fixed up my -fixes ARM build
and .config so I could see it, but yes brown paper bag time"
* tag 'drm-fixes-for-v4.9-rc6-brown-paper-bag' of git://people.freedesktop.org/~airlied/linux:
Revert "drm/mediatek: set vblank_disable_allowed to true"
Revert "drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE"
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
drm/i915: Refresh that status of MST capable connectors in ->detect()
drm/i915: Grab the rotation from the passed plane state for VLV sprites
drm/i915: Mark CPU cache as dirty when used for rendering
Make struct pernet_operations::id unsigned.
There are 2 reasons to do so:
1)
This field is really an index into an zero based array and
thus is unsigned entity. Using negative value is out-of-bound
access by definition.
2)
On x86_64 unsigned 32-bit data which are mixed with pointers
via array indexing or offsets added or subtracted to pointers
are preffered to signed 32-bit data.
"int" being used as an array index needs to be sign-extended
to 64-bit before being used.
void f(long *p, int i)
{
g(p[i]);
}
roughly translates to
movsx rsi, esi
mov rdi, [rsi+...]
call g
MOVSX is 3 byte instruction which isn't necessary if the variable is
unsigned because x86_64 is zero extending by default.
Now, there is net_generic() function which, you guessed it right, uses
"int" as an array index:
static inline void *net_generic(const struct net *net, int id)
{
...
ptr = ng->ptr[id - 1];
...
}
And this function is used a lot, so those sign extensions add up.
Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
messing with code generation):
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
Unfortunately some functions actually grow bigger.
This is a semmingly random artefact of code generation with register
allocator being used differently. gcc decides that some variable
needs to live in new r8+ registers and every access now requires REX
prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
used which is longer than [r8]
However, overall balance is in negative direction:
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
function old new delta
nfsd4_lock 3886 3959 +73
tipc_link_build_proto_msg 1096 1140 +44
mac80211_hwsim_new_radio 2776 2808 +32
tipc_mon_rcv 1032 1058 +26
svcauth_gss_legacy_init 1413 1429 +16
tipc_bcbase_select_primary 379 392 +13
nfsd4_exchange_id 1247 1260 +13
nfsd4_setclientid_confirm 782 793 +11
...
put_client_renew_locked 494 480 -14
ip_set_sockfn_get 730 716 -14
geneve_sock_add 829 813 -16
nfsd4_sequence_done 721 703 -18
nlmclnt_lookup_host 708 686 -22
nfsd4_lockt 1085 1063 -22
nfs_get_client 1077 1050 -27
tcf_bpf_init 1106 1076 -30
nfsd4_encode_fattr 5997 5930 -67
Total: Before=154856051, After=154854321, chg -0.00%
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
UDP busy polling is restricted to connected UDP sockets.
This is because sk_busy_loop() only takes care of one NAPI context.
There are cases where it could be extended.
1) Some hosts receive traffic on a single NIC, with one RX queue.
2) Some applications use SO_REUSEPORT and associated BPF filter
to split the incoming traffic on one UDP socket per RX
queue/thread/cpu
3) Some UDP sockets are used to send/receive traffic for one flow, but
they do not bother with connect()
This patch records the napi_id of first received skb, giving more
reach to busy polling.
Tested:
lpaa23:~# echo 70 >/proc/sys/net/core/busy_read
lpaa24:~# echo 70 >/proc/sys/net/core/busy_read
lpaa23:~# for f in `seq 1 10`; do ./super_netperf 1 -H lpaa24 -t UDP_RR -l 5; done
Before patch :
27867 28870 37324 41060 41215
36764 36838 44455 41282 43843
After patch :
73920 73213 70147 74845 71697
68315 68028 75219 70082 73707
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Recently algif_hash has been changed to allow null hashes. This
triggers a bug when used with an shash algorithm whereby it will
cause a crash during the digest operation.
This patch fixes it by avoiding the digest operation and instead
doing an init followed by a final which avoids the buggy code in
shash.
This patch also ensures that the result buffer is freed after an
error so that it is not returned as a genuine hash result on the
next recv call.
The shash/ahash wrapper code will be fixed later to handle this
case correctly.
Fixes: 493b2ed3f7 ("crypto: algif_hash - Handle NULL hashes correctly")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Laura Abbott <labbott@redhat.com>
We need to update on secondaries for the selected MMU mode.
Fixes: ad410674f5 ("powerpc/mm: Update the HID bit when switching from radix to hash")
Reported-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
function shouldn't return immediately; instead it needs to check further
if select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
blindly to attr.config. Instead it ought to convert the request to the
"cpu cycle" event type (i.e. 0x11).
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Cc: stable@vger.kernel.org # 4.6+
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
We're missing the handling code for the cycle counter accessed
from a 32bit guest, leading to unexpected results.
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.
Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On POWER9 DD1, when we do a local TLB invalidate we also need to explicitly
invalidate the ERAT.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
since clk_prepare_enable() is used to get i2c->clk, we should
use clk_disable_unprepare() to release it for the error path.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
A fix to reintroduce missing pinmux options that turned out not to be
optional.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJYK3mGAAoJEBx+YmzsjxAg2nEQAK/mc4R4yram78qXD5B+tbji
o04PuC2xvST0xI7N4fnNxueZQOYoqKEvbUlGa32kQ4Zs20qCrnRntlfjjNvs+UQc
O9EOTJnH1T+sABY+LOq3rcoK8zswl7ka+dsQ3STaL+OFVfox+Bw2IjCZ1KBOLjgU
4joOeuOTrmSTS5i6IxvGPmGZBb5hbq9TaYsQyIKUozaLjDGgDgZ1GKjJhN9LdjM5
n7K8Bf87YQhuxKgQv2H3rxseooe95IVmfc8zv+CnLSrC63oJwpiAemVuaPKOq7dt
gTxkYIBBtHMwY/OHpXRI0FNxuhaPUn8Nxo9QxTij9aH44lfZr2RS/0f/KHIe2KrM
Nh8mUMTotgSfdmD5OrShgJV28B6MxzJMhUisi+GGglR0N4GNeXZ5dtNOgY35Rmjw
geJNPjnL7ALkXcrLPxGyPttcw8p/wtSgDnbOINWZ0aJ7NfTgqCsi4uYkOJSm4NII
unthkLr/y5uwWMkPNoGtoqGOF0kMTcXy5gf/S45mdKzU2c8dKi6POph7kVeVxC1F
OBIQ+s2H0E4D6rOz9g7R7lwO/tFVltXz1lhvQ+CebM5/NH1vjVuKDe0+SrvDfQBm
6IYzepW3tVjJTWJr09xUfzwtkm5ii6lEvChllnmrInhpgDCnKv9qDgbnJCnLlUYs
D7JrBkNV+976JqdOlX5l
=WBs5
-----END PGP SIGNATURE-----
Merge tag 'sunxi-fixes-for-4.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
Allwinner fixes for 4.9
A fix to reintroduce missing pinmux options that turned out not to be
optional.
* tag 'sunxi-fixes-for-4.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: dts: sun8i: fix the pinmux for UART1
Signed-off-by: Olof Johansson <olof@lixom.net>
It fixes a boot failure on imx53-qsb board with a DA9053 PMIC, which is
caused by the regulator core change, commit fa93fd4ecc ("regulator:
core: Ensure we are at least in bounds for our constraints").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYKnQ1AAoJEFBXWFqHsHzOyEYH/0F1TKtmJwLeDBKBinmeG0wx
IX/0mXCV0E72T7W6PuifofG7H9jax9UY8qGyDl9+h/dMBQCaKPfXDo6wg5FoXaBe
UAQVHbRbEuazI2xW0UWeiywt6soGBe1/iNpt+OXXfmJY77vS5nuGfFCLGey6+uTe
WeGi3J6g2Oxa65FndvfTm5dNj6vCa3VHs5UKQKCId3KoTjuLZu4EUrN81e47tkmJ
pmzaGBfAUyvACfwkITzc6rAbBp29FtxMK52ieuh+w4L3DWa3kpCabHPMIAeP8C9P
GQ80PTyfs/F163yYM6dWRipwhz/XJhjtT8SWBG/hnYBJDEHOua4uqW3YcoNdm7E=
=xunY
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
i.MX fixes for 4.9, 2nd round:
It fixes a boot failure on imx53-qsb board with a DA9053 PMIC, which is
caused by the regulator core change, commit fa93fd4ecc ("regulator:
core: Ensure we are at least in bounds for our constraints").
* tag 'imx-fixes-4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx53-qsb: Fix regulator constraints
Signed-off-by: Olof Johansson <olof@lixom.net>
features printed, all these are quite trivial and tiny. The omap5 jack
detection and gpadc patches are not strictly fixes, but I wanted to get
binding document typo fixed before it pops up on other boards. The
gpadc one liner was in the same series and I applied and pushed it out
already before noticing it could have waited. The list of changes is:
- Fix omap3 SoC features printed
- Make sure OMAP_INTERCONNECT is selected for am43xx only configurations
- Add missing memory node for torpedo
- Initialize uart4_mask properly to avoid writing garbage to PRM registers
- Fix NULL pointer dereference for omap4 volt_data
- Add alias for omap5 gpadc needed by iio drivers
- Enable omap5 jack headset jack detection and fix it's binding typo
- Add missing memory node for logicpd-som-lv
- Fix wrong SMPS6 voltage for VDD-DDR3 for omap5
-----BEGIN PGP SIGNATURE-----
iQIuBAABCAAYBQJYKlYvERx0b255QGF0b21pZGUuY29tAAoJEBvUPslcq6VzT50Q
AJEsYX1dYwMyVeditzSWb65ajT53uhxPw51vIfA/bV3FUsMTaD5aZ9fsxYMt/3Eo
ayEzDFM74FM9nMGB4gXW4wryta4r5NT/lBg6vvwJfivVjTUkhQUKmH6C94dg3t2d
bHr9isM7ONJ5wxx02olg9vHyNXXgWEwPLhWKtxZKanKpoxKJajSA5dJuZR9T39X5
ZuhPFFmpMEh+IsnqYs4C1+215cFkRf21aEhMqwKRySTcHf35zitPfiuYF4Gft6Vb
Cor9JXlZGUN+dfhG48qcn+1NBEgha5r7JT2u7w+dPCXKvEn6OmpyAziUT3CYHMAc
IGeZLmBznhSZhJUvYjBmiy88YLORpWvPuGCE19AKJoi+VOGv8bSc2bnp+JCw+Ven
DB0GDWJgI2FVPNrRrLRW+dOdKwH/R8b9vE3ZtVHK8x7vowViDoGyFpndv30sL0HA
ssRvC24wAyRAcpXtAqQrFc2I8BMLzVsLzHLHriR9EnhMAspk4IJV5zkFv52ZtlxO
N6NabaD7se2ww7q3MSGuIe3+u9u3KcfKf1dsaq/E8cWFxvcJ07xnCCCYJ8DlGmZh
mS+Fkbof7NO0gbSiapzgjVtb+sfrkKqYTiIMldTzIGzmEcpK6SKXC6mAcrFAPojK
ecBq9BrLuAte4u6W1ohQoAW6rwjfz6yrAqIdzhzufGsN
=LgIW
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.9/fixes-for-rc-cycle' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Fixes for omaps for v4.9-rc cycle. Except for the omap3 fix for the SoC
features printed, all these are quite trivial and tiny. The omap5 jack
detection and gpadc patches are not strictly fixes, but I wanted to get
binding document typo fixed before it pops up on other boards. The
gpadc one liner was in the same series and I applied and pushed it out
already before noticing it could have waited. The list of changes is:
- Fix omap3 SoC features printed
- Make sure OMAP_INTERCONNECT is selected for am43xx only configurations
- Add missing memory node for torpedo
- Initialize uart4_mask properly to avoid writing garbage to PRM registers
- Fix NULL pointer dereference for omap4 volt_data
- Add alias for omap5 gpadc needed by iio drivers
- Enable omap5 jack headset jack detection and fix it's binding typo
- Add missing memory node for logicpd-som-lv
- Fix wrong SMPS6 voltage for VDD-DDR3 for omap5
* tag 'omap-for-v4.9/fixes-for-rc-cycle' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage
ARM: omap3: Add missing memory node in SOM-LV
ASoC: omap-abe-twl6040: fix typo in bindings documentation
dts: omap5: board-common: enable twl6040 headset jack detection
dts: omap5: board-common: add phandle to reference Palmas gpadc
ARM: OMAP2+: avoid NULL pointer dereference
ARM: OMAP2+: PRM: initialize en_uart4_mask and grpsel_uart4_mask
ARM: dts: omap3: Fix memory node in Torpedo board
ARM: AM43XX: Select OMAP_INTERCONNECT in Kconfig
ARM: OMAP3: Fix formatting of features printed
Signed-off-by: Olof Johansson <olof@lixom.net>
All of them are fixes for arm64 device tree
- 2 for the SPI node on the Armada 7K/8K
- 1 for the clock node on the Armada 37xx
-----BEGIN PGP SIGNATURE-----
iGoEABECACoFAlgk6sUjHGdyZWdvcnkuY2xlbWVudEBmcmVlLWVsZWN0cm9ucy5j
b20ACgkQCwYYjhRyO9VwEgCdGuixX9TYgWna2/PdhtVs5JXdW98Amwb054ygu7dw
2ONd6XGynL1PpVhQ
=qm28
-----END PGP SIGNATURE-----
Merge tag 'mvebu-fixes-4.9-1' of git://git.infradead.org/linux-mvebu into fixes
mvebu fixes for 4.9 (part 1)
All of them are fixes for arm64 device tree
- 2 for the SPI node on the Armada 7K/8K
- 1 for the clock node on the Armada 37xx
* tag 'mvebu-fixes-4.9-1' of git://git.infradead.org/linux-mvebu:
arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
arm64: dts: marvell: fix clocksource for CP110 slave SPI0
arm64: dts: marvell: Fix typo in label name on Armada 37xx
Signed-off-by: Olof Johansson <olof@lixom.net>
i915 misc fixes.
* tag 'drm-intel-fixes-2016-11-17' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
drm/i915: Refresh that status of MST capable connectors in ->detect()
drm/i915: Grab the rotation from the passed plane state for VLV sprites
drm/i915: Mark CPU cache as dirty when used for rendering
The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
other is H8S/2168 compliant.
The current ipmi/bt-bmc driver implements the IPMI version and we
should reflect its nature in the compatible node name using
'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
latter should be used for a H8S interface driver if it is implemented
one day.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Pull block fixes from Jens Axboe:
"A set of fixes, one for NVMe from Keith, and a set for nvme-{rdma,t,f}
from the usual suspects, fixing actual problems that would be a shame
to release 4.9 with"
* 'for-linus' of git://git.kernel.dk/linux-block:
nvme/pci: Don't free queues on error
nvmet-rdma: drain the queue-pair just before freeing it
nvme-rdma: stop and free io queues on connect failure
nvmet-rdma: don't forget to delete a queue from the list of connection failed
nvmet: Don't queue fatal error work if csts.cfs is set
nvme-rdma: reject non-connect commands before the queue is live
nvmet-rdma: Fix possible NULL deref when handling rdma cm events
- Misc Intel hfi1 fixes
- Misc Mellanox mlx4, mlx5, and rxe fixes
- A couple cxgb4 fixes
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYLQfQAAoJELgmozMOVy/doFMQAI96k4C9TJhtSNywdUhmqEDP
09IZFWVPuVFdgB//eFnUlqQackHn70RGNJfM+wDLRuNvyDaIJ21pSTqLeVkPJPaN
7kHmNo2OiYqo5evq2rFV0Jaaf9mj+zkmQBWE5vLLuNqoYWNBuPrNMY5O88o09TPQ
umN04md9VYoTjg0eya9ESTE+RUsYO1QL16VEXLZt8HonDGQUe+Z8nGh6VtKBQV+t
34li0vPRj2DGaWuZXWjgKTSxniHtKrds5uEzTxucNYXfz0NrfLTTlADDgPwHQ7qW
Utbv18/C8j6hTQgogiUTASSyJCDnYC6g1Ovn9vY8bgu6Vo2FjHCaQyuubQQKGCtl
IzX8ahf5z+pAm88hU6e6I0Hi+wPMtc8VT8XBJnhKjxC8qxH+OZNCBlNH3NWroIYo
uC0mV0pzhh/FERHK/cDujeecu4n8V2WiOs59Ta3R6ys8nO5CxwVGup0OOXK2ZG2X
Qfm+aj3xf0Dk06n03Y77l/iofKnxtEECPm6BqjL6JKUymFbqOZhkCUWO84sKEBbQ
egqwpBuHkrqQLcVBWPabkkBLtHS5H+7AHKxxCJq8NJQflDgu7t+q+PT4A4YXq6Mb
jNKdlTvz8ov+SniH8A7KHIiAGgSAzTBQKsTDLYAJdMuzj7HnNXO3oubd1CoAa05H
8KhN0XDWVB01LeVW7rts
=qeYK
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull rmda fixes from Doug Ledford.
"First round of -rc fixes.
Due to various issues, I've been away and couldn't send a pull request
for about three weeks. There were a number of -rc patches that built
up in the meantime (some where there already from the early -rc
stages). Obviously, there were way too many to send now, so I tried to
pare the list down to the more important patches for the -rc cycle.
Most of the code has had plenty of soak time at the various vendor's
testing setups, so I doubt there will be another -rc pull request this
cycle. I also tried to limit the patches to those with smaller
footprints, so even though a shortlog is longer than I would like, the
actual diffstat is mostly very small with the exception of just three
files that had more changes, and a couple files with pure removals.
Summary:
- Misc Intel hfi1 fixes
- Misc Mellanox mlx4, mlx5, and rxe fixes
- A couple cxgb4 fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (34 commits)
iw_cxgb4: invalidate the mr when posting a read_w_inv wr
iw_cxgb4: set *bad_wr for post_send/post_recv errors
IB/rxe: Update qp state for user query
IB/rxe: Clear queue buffer when modifying QP to reset
IB/rxe: Fix handling of erroneous WR
IB/rxe: Fix kernel panic in UDP tunnel with GRO and RX checksum
IB/mlx4: Fix create CQ error flow
IB/mlx4: Check gid_index return value
IB/mlx5: Fix NULL pointer dereference on debug print
IB/mlx5: Fix fatal error dispatching
IB/mlx5: Resolve soft lock on massive reg MRs
IB/mlx5: Use cache line size to select CQE stride
IB/mlx5: Validate requested RQT size
IB/mlx5: Fix memory leak in query device
IB/core: Avoid unsigned int overflow in sg_alloc_table
IB/core: Add missing check for addr_resolve callback return value
IB/core: Set routable RoCE gid type for ipv4/ipv6 networks
IB/cm: Mark stale CM id's whenever the mad agent was unregistered
IB/uverbs: Fix leak of XRC target QPs
IB/hfi1: Remove incorrect IS_ERR check
...
Pull vfs fixes from Al Viro:
"A couple of regression fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fix iov_iter_advance() for ITER_PIPE
xattr: Fix setting security xattrs on sockfs
Without ".owner = THIS_MODULE" it is possible to crash the kernel
by unloading the Orangefs module while someone is reading debugfs
files.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYLfvEAAoJEM9EDqnrzg2+sHEQAJo4jn/sAQvO04ujaMrViLmy
5+V93F7jwGFeLvAwjMvPAeBb+UmlgqjVi0VT85RzEe6eNOKN9qlj9ZNDutOfnbhr
H6qu8AQsbO0znSTQuJA1M2Hca9h66EnN0pT8xW4wat1cCdAf6X6HcFcr1lZIRKZd
E17EygXi+IW0c0evIq4UBsD0DfTZgtC4ONrR9N7+zprlg2PVX35So6Lr0ODceJQs
StWHrZW9hDZ6KR8WocupuHPR8brOe+P5PU14fPzR1+EH7BsTf8uxWK7CfTE5ov0C
UNkNeh81BOkwIQDFoPCJ5asaipdi5RRNTIQekhhQ2GnaaCdmCKln8OLjqDZZOmDj
KRGB4mdPcCb3XlvMH3SaXNmyhmjt2cTS0/TQPexrTqjSNmbXmnzJOCguweoTIJ5w
CgEnsrNp8GwlZo12Z8JkFGxC39ifjH4F+KFetU+eUNjw9Tce+zHwgEvsAMqDhWw8
FJQWy+snG7m8ooytRObWPepchnd2XHkrJv4yu8uw3GirM+YTlxvuWnB54hVH17FQ
0vKYhdAXBUmeeyyNKApBSGQezPWD9hfAY5Di7JGJlaTiai3pVxgXd8YY4DGXHj3t
ebPpxEnlWrRLC5Cazd0yC9CoR8azQp9zvRgfPuPEM4wJSjUFVfmasmFg7s99h3Zq
vnTqfV/uQwLm9f+3CfNB
=s21f
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.9-rc5-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux
Pull orangefs fix from Mike Marshall:
"orangefs: add .owner to debugfs file_operations
Without ".owner = THIS_MODULE" it is possible to crash the kernel by
unloading the Orangefs module while someone is reading debugfs files"
* tag 'for-linus-4.9-rc5-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
orangefs: add .owner to debugfs file_operations
Userland client should be able to read an event, and reflect it back to
the kernel, therefore it needs to extract complete set of netlink flags.
For example, this will allow "tc monitor" to distinguish Add and Replace
operations.
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan says:
====================
RDS: TCP: HA/Failover fixes
This series contains a set of fixes for bugs exposed when
we ran the following in a loop between a test machine pair:
while (1); do
# modprobe rds-tcp on test nodes
# run rds-stress in bi-dir mode between test machine pair
# modprobe -r rds-tcp on test nodes
done
rds-stress in bi-dir mode will cause both nodes to initiate
RDS-TCP connections at almost the same instant, exposing the
bugs fixed in this series.
Without the fixes, rds-stress reports sporadic packet drops,
and packets arriving out of sequence. After the fixes,we have
been able to run the test overnight, without any issues.
Each patch has a detailed description of the root-cause fixed
by the patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When 2 RDS peers initiate an RDS-TCP connection simultaneously,
there is a potential for "duelling syns" on either/both sides.
See commit 241b271952 ("RDS-TCP: Reset tcp callbacks if re-using an
outgoing socket in rds_tcp_accept_one()") for a description of this
condition, and the arbitration logic which ensures that the
numerically large IP address in the TCP connection is bound to the
RDS_TCP_PORT ("canonical ordering").
The rds_connection should not be marked as RDS_CONN_UP until the
arbitration logic has converged for the following reason. The sender
may start transmitting RDS datagrams as soon as RDS_CONN_UP is set,
and since the sender removes all datagrams from the rds_connection's
cp_retrans queue based on TCP acks. If the TCP ack was sent from
a tcp socket that got reset as part of duel aribitration (but
before data was delivered to the receivers RDS socket layer),
the sender may end up prematurely freeing the datagram, and
the datagram is no longer reliably deliverable.
This patch remedies that condition by making sure that, upon
receipt of 3WH completion state change notification of TCP_ESTABLISHED
in rds_tcp_state_change, we mark the rds_connection as RDS_CONN_UP
if, and only if, the IP addresses and ports for the connection are
canonically ordered. In all other cases, rds_tcp_state_change will
force an rds_conn_path_drop(), and rds_queue_reconnect() on
both peers will restart the connection to ensure canonical ordering.
A side-effect of enforcing this condition in rds_tcp_state_change()
is that rds_tcp_accept_one_path() can now be refactored for simplicity.
It is also no longer possible to encounter an RDS_CONN_UP connection in
the arbitration logic in rds_tcp_accept_one().
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The RDS transport has to be able to distinguish between
two types of failure events:
(a) when the transport fails (e.g., TCP connection reset)
but the RDS socket/connection layer on both sides stays
the same
(b) when the peer's RDS layer itself resets (e.g., due to module
reload or machine reboot at the peer)
In case (a) both sides must reconnect and continue the RDS messaging
without any message loss or disruption to the message sequence numbers,
and this is achieved by rds_send_path_reset().
In case (b) we should reset all rds_connection state to the
new incarnation of the peer. Examples of state that needs to
be reset are next expected rx sequence number from, or messages to be
retransmitted to, the new incarnation of the peer.
To achieve this, the RDS handshake probe added as part of
commit 5916e2c155 ("RDS: TCP: Enable multipath RDS for TCP")
is enhanced so that sender and receiver of the RDS ping-probe
will add a generation number as part of the RDS_EXTHDR_GEN_NUM
extension header. Each peer stores local and remote generation
numbers as part of each rds_connection. Changes in generation
number will be detected via incoming handshake probe ping
request or response and will allow the receiver to reset rds_connection
state.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As noted in rds_recv_incoming() sequence numbers on data packets
can decreas for the failover case, and the Rx path is equipped
to recover from this, if the RDS_FLAG_RETRANSMITTED is set
on the rds header of an incoming message with a suspect sequence
number.
The RDS_FLAG_RETRANSMITTED is predicated on the RDS_FLAG_RETRANSMITTED
flag in the rds_message, so make sure the flag is set on messages
queued for retransmission.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As sugested by Joe Perches, we could replace all
if (netif_msg_type(priv)) dev_xxx(priv->devices, ...)
by the simpler macro netif_xxx(priv, hw, priv->dev, ...)
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some printing have the function name hardcoded.
It is better to use __func__ instead.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The stmmac driver use lots of pr_xxx functions to print information.
This is bad since we cannot know which device logs the information.
(moreover if two stmmac device are present)
Furthermore, it seems that it assumes wrongly that all logs will always
be subsequent by using a dev_xxx then some indented pr_xxx like this:
kernel: sun7i-dwmac 1c50000.ethernet: no reset control found
kernel: Ring mode enabled
kernel: No HW DMA feature register supported
kernel: Normal descriptors
kernel: TX Checksum insertion supported
So this patch replace all pr_xxx by their netdev_xxx counterpart.
Excepts for some printing where netdev "cause" unpretty output like:
sun7i-dwmac 1c50000.ethernet (unnamed net_device) (uninitialized): no reset control found
In those case, I keep dev_xxx.
In the same time I remove some "stmmac:" print since
this will be a duplicate with that dev_xxx displays.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When I wrote sch_fq.c, hash_ptr() on 64bit arches was awful,
and I chose hash_32().
Linus Torvalds and George Spelvin fixed this issue, so we can
use hash_ptr() to get more entropy on 64bit arches with Terabytes
of memory, and avoid the cast games.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Prior to 3.15, there was a race between zap_pte_range() and
page_mkclean() where writes to a page could be lost. Dave Hansen
discovered by inspection that there is a similar race between
move_ptes() and page_mkclean().
We've been able to reproduce the issue by enlarging the race window with
a msleep(), but have not been able to hit it without modifying the code.
So, we think it's a real issue, but is difficult or impossible to hit in
practice.
The zap_pte_range() issue is fixed by commit 1cf35d47712d("mm: split
'tlb_flush_mmu()' into tlb flushing and memory freeing parts"). And
this patch is to fix the race between page_mkclean() and mremap().
Here is one possible way to hit the race: suppose a process mmapped a
file with READ | WRITE and SHARED, it has two threads and they are bound
to 2 different CPUs, e.g. CPU1 and CPU2. mmap returned X, then thread
1 did a write to addr X so that CPU1 now has a writable TLB for addr X
on it. Thread 2 starts mremaping from addr X to Y while thread 1
cleaned the page and then did another write to the old addr X again.
The 2nd write from thread 1 could succeed but the value will get lost.
thread 1 thread 2
(bound to CPU1) (bound to CPU2)
1: write 1 to addr X to get a
writeable TLB on this CPU
2: mremap starts
3: move_ptes emptied PTE for addr X
and setup new PTE for addr Y and
then dropped PTL for X and Y
4: page laundering for N by doing
fadvise FADV_DONTNEED. When done,
pageframe N is deemed clean.
5: *write 2 to addr X
6: tlb flush for addr X
7: munmap (Y, pagesize) to make the
page unmapped
8: fadvise with FADV_DONTNEED again
to kick the page off the pagecache
9: pread the page from file to verify
the value. If 1 is there, it means
we have lost the written 2.
*the write may or may not cause segmentation fault, it depends on
if the TLB is still on the CPU.
Please note that this is only one specific way of how the race could
occur, it didn't mean that the race could only occur in exact the above
config, e.g. more than 2 threads could be involved and fadvise() could
be done in another thread, etc.
For anonymous pages, they could race between mremap() and page reclaim:
THP: a huge PMD is moved by mremap to a new huge PMD, then the new huge
PMD gets unmapped/splitted/pagedout before the flush tlb happened for
the old huge PMD in move_page_tables() and we could still write data to
it. The normal anonymous page has similar situation.
To fix this, check for any dirty PTE in move_ptes()/move_huge_pmd() and
if any, did the flush before dropping the PTL. If we did the flush for
every move_ptes()/move_huge_pmd() call then we do not need to do the
flush in move_pages_tables() for the whole range. But if we didn't, we
still need to do the whole range flush.
Alternatively, we can track which part of the range is flushed in
move_ptes()/move_huge_pmd() and which didn't to avoid flushing the whole
range in move_page_tables(). But that would require multiple tlb
flushes for the different sub-ranges and should be less efficient than
the single whole range flush.
KBuild test on my Sandybridge desktop doesn't show any noticeable change.
v4.9-rc4:
real 5m14.048s
user 32m19.800s
sys 4m50.320s
With this commit:
real 5m13.888s
user 32m19.330s
sys 4m51.200s
Reported-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If an ip6 tunnel is configured to inherit the traffic class from
the inner header, the dst_cache must be disabled or it will foul
the policy routing.
The issue is apprently there since at leat Linux-2.6.12-rc2.
Reported-by: Liam McBirnie <liam.mcbirnie@boeing.com>
Cc: Liam McBirnie <liam.mcbirnie@boeing.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Calling napi_hash_del() after netif_napi_del() is pointless.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold says:
====================
net: phy: fix of_node and device leaks
These patches fix a couple of of_node leaks in the fixed-link code and a
device reference leak in a phy helper.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the of_node reference taken in fixed_phy_register()
when deregistering a PHY.
Fixes: a759512174 ("net: phy: extend fixed driver with
fixed_phy_register()")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the reference taken by bus_find_device() before
returning NULL from of_phy_find_device() when the found device is not a
PHY.
Fixes: 6ed742363b ("of: of_mdio: Ensure mdio device is a PHY")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure to drop the of_node reference also on failure to parse the
speed property in of_phy_register_fixed_link().
Fixes: 3be2a49e5c ("of: provide a binding for fixed link PHYs")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrei reports we still allocate netns ID from idr after we destroy
it in cleanup_net().
cleanup_net():
...
idr_destroy(&net->netns_ids);
...
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_exit_list(ops, &net_exit_list);
-> rollback_registered_many()
-> rtmsg_ifinfo_build_skb()
-> rtnl_fill_ifinfo()
-> peernet2id_alloc()
After that point we should not even access net->netns_ids, we
should check the death of the current netns as early as we can in
peernet2id_alloc().
For net-next we can consider to avoid sending rtmsg totally,
it is a good optimization for netns teardown path.
Fixes: 0c7aecd4bd ("netns: add rtnl cmd to add and get peer netns ids")
Reported-by: Andrei Vagin <avagin@gmail.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Andrei Vagin <avagin@openvz.org>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no need calling napi_hash_del()+synchronize_rcu() before
calling netif_napi_del()
netif_napi_del() does this already.
Using napi_hash_del() in a driver is useful only when dealing with
a batch of NAPI structures, so that a single synchronize_rcu() can
be used. mlx4_en_deactivate_cq() is deactivating a single NAPI.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Building the caam driver on arm64 produces a harmless warning:
drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast
We can use min_t to tell the compiler which type we want it to use
here.
Fixes: 5ecf8ef910 ("crypto: caam - fix sg dump")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Fix use of u32 instead of int for checking for negative errors values
as pointed out by Dan Carpenter <dan.carpenter@oracle.com>.
And while testing the PM runtime error path by randomly returning
failed values in runtime resume, I noticed two more places that need
fixing:
- If pm_runtime_get_sync() fails in probe, we still need to do
pm_runtime_put_sync() to keep the use count happy. We could call
pm_runtime_put_noidle() on the error path, but we're just going
to call pm_runtime_disable() after that so pm_runtime_put_sync()
will do what we want
- We should print an error if pm_runtime_get_sync() fails in
cppi41_dma_alloc_chan_resources() so we know where it happens
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 740b4be3f7 ("dmaengine: cpp41: Fix handling of error path")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
iov_iter_advance() needs to decrement iter->count by the number of
bytes we'd moved beyond. Normal flavours do that, but ITER_PIPE
doesn't and ITER_PIPE generic_file_read_iter() for O_DIRECT files
ends up with a bogus fallback to page cache read, resulting in incorrect
values for file offset and bytes read.
Signed-off-by: Abhi Das <adas@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The IOP_XATTR flag is set on sockfs because sockfs supports getting the
"system.sockprotoname" xattr. Since commit 6c6ef9f2, this flag is checked for
setxattr support as well. This is wrong on sockfs because security xattr
support there is supposed to be provided by security_inode_setsecurity. The
smack security module relies on socket labels (xattrs).
Fix this by adding a security xattr handler on sockfs that returns
-EAGAIN, and by checking for -EAGAIN in setxattr.
We cannot simply check for -EOPNOTSUPP in setxattr because there are
filesystems that neither have direct security xattr support nor support
via security_inode_setsecurity. A more proper fix might be to move the
call to security_inode_setsecurity into sockfs, but it's not clear to me
if that is safe: we would end up calling security_inode_post_setxattr after
that as well.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Add a missing synchronize_net() call to avoid potential use after free,
since we explicitly call napi_hash_del() to factorize the RCU grace
period.
Fixes: c0c050c58d ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Acked-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
