Jonathan McDowell [Thu, 21 May 2020 11:49:34 +0000 (12:49 +0100)]
net: ethernet: stmmac: Enable interface clocks on probe for IPQ806x
[ Upstream commit
a96ac8a0045e3cbe3e5af6d1b3c78c6c2065dec5 ]
The ipq806x_gmac_probe() function enables the PTP clock but not the
appropriate interface clocks. This means that if the bootloader hasn't
done so attempting to bring up the interface will fail with an error
like:
[ 59.028131] ipq806x-gmac-dwmac
37600000.ethernet: Failed to reset the dma
[ 59.028196] ipq806x-gmac-dwmac
37600000.ethernet eth1: stmmac_hw_setup: DMA engine initialization failed
[ 59.034056] ipq806x-gmac-dwmac
37600000.ethernet eth1: stmmac_open: Hw setup failed
This patch, a slightly cleaned up version of one posted by Sergey
Sergeev in:
https://forum.openwrt.org/t/support-for-mikrotik-rb3011uias-rm/4064/257
correctly enables the clock; we have already configured the source just
before this.
Tested on a MikroTik RB3011.
Signed-off-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Valentin Longchamp [Wed, 20 May 2020 15:53:50 +0000 (17:53 +0200)]
net/ethernet/freescale: rework quiesce/activate for ucc_geth
[ Upstream commit
79dde73cf9bcf1dd317a2667f78b758e9fe139ed ]
ugeth_quiesce/activate are used to halt the controller when there is a
link change that requires to reconfigure the mac.
The previous implementation called netif_device_detach(). This however
causes the initial activation of the netdevice to fail precisely because
it's detached. For details, see [1].
A possible workaround was the revert of commit
net: linkwatch: add check for netdevice being present to linkwatch_do_dev
However, the check introduced in the above commit is correct and shall be
kept.
The netif_device_detach() is thus replaced with
netif_tx_stop_all_queues() that prevents any tranmission. This allows to
perform mac config change required by the link change, without detaching
the corresponding netdevice and thus not preventing its initial
activation.
[1] https://lists.openwall.net/netdev/2020/01/08/201
Signed-off-by: Valentin Longchamp <valentin@longchamp.me>
Acked-by: Matteo Ghidoni <matteo.ghidoni@ch.abb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeremy Kerr [Tue, 19 May 2020 01:05:58 +0000 (09:05 +0800)]
net: bmac: Fix read of MAC address from ROM
[ Upstream commit
ef01cee2ee1b369c57a936166483d40942bcc3e3 ]
In bmac_get_station_address, We're reading two bytes at a time from ROM,
but we do that six times, resulting in 12 bytes of read & writes. This
means we will write off the end of the six-byte destination buffer.
This change fixes the for-loop to only read/write six bytes.
Based on a proposed fix from Finn Thain <fthain@telegraphics.com.au>.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reported-by: Stan Johnson <userm57@yahoo.com>
Tested-by: Stan Johnson <userm57@yahoo.com>
Reported-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 8 Apr 2020 20:53:23 +0000 (13:53 -0700)]
x86/mmiotrace: Use cpumask_available() for cpumask_var_t variables
[ Upstream commit
d7110a26e5905ec2fe3fc88bc6a538901accb72b ]
When building with Clang + -Wtautological-compare and
CONFIG_CPUMASK_OFFSTACK unset:
arch/x86/mm/mmio-mod.c:375:6: warning: comparison of array 'downed_cpus'
equal to a null pointer is always false [-Wtautological-pointer-compare]
if (downed_cpus == NULL &&
^~~~~~~~~~~ ~~~~
arch/x86/mm/mmio-mod.c:405:6: warning: comparison of array 'downed_cpus'
equal to a null pointer is always false [-Wtautological-pointer-compare]
if (downed_cpus == NULL || cpumask_weight(downed_cpus) == 0)
^~~~~~~~~~~ ~~~~
2 warnings generated.
Commit
f7e30f01a9e2 ("cpumask: Add helper cpumask_available()")
added cpumask_available() to fix warnings of this nature. Use that here
so that clang does not warn regardless of CONFIG_CPUMASK_OFFSTACK's
value.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/982
Link: https://lkml.kernel.org/r/20200408205323.44490-1-natechancellor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eugeniy Paltsev [Thu, 2 Apr 2020 17:54:28 +0000 (20:54 +0300)]
ARC: Fix ICCM & DCCM runtime size checks
[ Upstream commit
43900edf67d7ef3ac8909854d75b8a1fba2d570c ]
As of today the ICCM and DCCM size checks are incorrectly using
mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ
and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in
runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes.
Fix that.
Reported-by: Paul Greco <pmgreco@us.ibm.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vasily Gorbik [Tue, 10 Dec 2019 12:50:23 +0000 (13:50 +0100)]
s390/ftrace: save traced function caller
[ Upstream commit
b4adfe55915d8363e244e42386d69567db1719b9 ]
A typical backtrace acquired from ftraced function currently looks like
the following (e.g. for "path_openat"):
arch_stack_walk+0x15c/0x2d8
stack_trace_save+0x50/0x68
stack_trace_call+0x15a/0x3b8
ftrace_graph_caller+0x0/0x1c
0x3e0007e3c98 <- ftraced function caller (should be do_filp_open+0x7c/0xe8)
do_open_execat+0x70/0x1b8
__do_execve_file.isra.0+0x7d8/0x860
__s390x_sys_execve+0x56/0x68
system_call+0xdc/0x2d8
Note random "0x3e0007e3c98" stack value as ftraced function caller. This
value causes either imprecise unwinder result or unwinding failure.
That "0x3e0007e3c98" comes from r14 of ftraced function stack frame, which
it haven't had a chance to initialize since the very first instruction
calls ftrace code ("ftrace_caller"). (ftraced function might never
save r14 as well). Nevertheless according to s390 ABI any function
is called with stack frame allocated for it and r14 contains return
address. "ftrace_caller" itself is called with "brasl %r0,ftrace_caller".
So, to fix this issue simply always save traced function caller onto
ftraced function stack frame.
Reported-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xinwei Kong [Fri, 3 Jan 2020 02:52:10 +0000 (10:52 +0800)]
spi: dw: use "smp_mb()" to avoid sending spi data error
[ Upstream commit
bfda044533b213985bc62bd7ca96f2b984d21b80 ]
Because of out-of-order execution about some CPU architecture,
In this debug stage we find Completing spi interrupt enable ->
prodrucing TXEI interrupt -> running "interrupt_transfer" function
will prior to set "dw->rx and dws->rx_end" data, so this patch add
memory barrier to enable dw->rx and dw->rx_end to be visible and
solve to send SPI data error.
eg:
it will fix to this following low possibility error in testing environment
which using SPI control to connect TPM Modules
kernel: tpm tpm0: Operation Timed out
kernel: tpm tpm0: tpm_relinquish_locality: : error -1
Signed-off-by: fengsheng <fengsheng5@huawei.com>
Signed-off-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Link: https://lore.kernel.org/r/1578019930-55858-1-git-send-email-kong.kongxinwei@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Wed, 27 Jun 2018 03:49:28 +0000 (11:49 +0800)]
esp6: fix memleak on error path in esp6_input
commit
7284fdf39a912322ce97de2d30def3c6068a418c upstream.
This ought to be an omission in
e6194923237 ("esp: Fix memleaks on error
paths."). The memleak on error path in esp6_input is similar to esp_input
of esp4.
Fixes:
e6194923237 ("esp: Fix memleaks on error paths.")
Fixes:
3f29770723f ("ipsec: check return value of skb_to_sgvec always")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eugeniu Rosca [Thu, 21 Jun 2018 15:22:46 +0000 (17:22 +0200)]
usb: gadget: f_uac2: fix error handling in afunc_bind (again)
commit
e87581fe0509020f77ebf0b7c4c1c338c6a4bcf6 upstream.
If usb_ep_autoconfig() fails (i.e. returns a null endpoint descriptor),
we expect afunc_bind() to fail (i.e. return a negative error code).
However, due to v4.10-rc1 commit
f1d3861d63a5 ("usb: gadget: f_uac2: fix
error handling at afunc_bind"), afunc_bind() returns zero, telling the
caller that it succeeded. This then generates NULL pointer dereference
in below scenario on Rcar H3-ES20-Salvator-X target:
rcar-gen3:/home/root# modprobe g_audio
[ 626.521155] g_audio gadget: afunc_bind:565 Error!
[ 626.526319] g_audio gadget: Linux USB Audio Gadget, version: Feb 2, 2012
[ 626.533405] g_audio gadget: g_audio ready
rcar-gen3:/home/root#
rcar-gen3:/home/root# modprobe -r g_audio
[ 728.256707] ==================================================================
[ 728.264293] BUG: KASAN: null-ptr-deref in u_audio_stop_capture+0x70/0x268 [u_audio]
[ 728.272244] Read of size 8 at addr
00000000000000a0 by task modprobe/2545
[ 728.279309]
[ 728.280849] CPU: 0 PID: 2545 Comm: modprobe Tainted: G WC 4.14.47+ #152
[ 728.288778] Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ (DT)
[ 728.296454] Call trace:
[ 728.299151] [<
ffff2000080925ac>] dump_backtrace+0x0/0x364
[ 728.304808] [<
ffff200008092924>] show_stack+0x14/0x1c
[ 728.310081] [<
ffff200008f8d5cc>] dump_stack+0x108/0x174
[ 728.315522] [<
ffff2000083c77c8>] kasan_report+0x1fc/0x354
[ 728.321134] [<
ffff2000083c611c>] __asan_load8+0x24/0x94
[ 728.326600] [<
ffff2000021e1618>] u_audio_stop_capture+0x70/0x268 [u_audio]
[ 728.333735] [<
ffff2000021f8b7c>] afunc_disable+0x44/0x60 [usb_f_uac2]
[ 728.340503] [<
ffff20000218177c>] usb_remove_function+0x9c/0x210 [libcomposite]
[ 728.348060] [<
ffff200002183320>] remove_config.isra.2+0x1d8/0x218 [libcomposite]
[ 728.355788] [<
ffff200002186c54>] __composite_unbind+0x104/0x1f8 [libcomposite]
[ 728.363339] [<
ffff200002186d58>] composite_unbind+0x10/0x18 [libcomposite]
[ 728.370536] [<
ffff20000152f158>] usb_gadget_remove_driver+0xc0/0x170 [udc_core]
[ 728.378172] [<
ffff20000153154c>] usb_gadget_unregister_driver+0x1cc/0x258 [udc_core]
[ 728.386274] [<
ffff200002180de8>] usb_composite_unregister+0x10/0x18 [libcomposite]
[ 728.394116] [<
ffff2000021d035c>] audio_driver_exit+0x14/0x28 [g_audio]
[ 728.400878] [<
ffff200008213ed4>] SyS_delete_module+0x288/0x32c
[ 728.406935] Exception stack(0xffff8006cf6c7ec0 to 0xffff8006cf6c8000)
[ 728.413624] 7ec0:
0000000006136428 0000000000000800 0000000000000000 0000ffffd706efe8
[ 728.421718] 7ee0:
0000ffffd706efe9 000000000000000a 1999999999999999 0000000000000000
[ 728.429792] 7f00:
000000000000006a 000000000042c078 0000000000000000 0000000000000005
[ 728.437870] 7f20:
0000000000000000 0000000000000000 0000000000000004 0000000000000000
[ 728.445952] 7f40:
000000000042bfc8 0000ffffbc7c8f40 0000000000000000 00000000061363c0
[ 728.454035] 7f60:
0000000006136428 0000000000000000 0000000000000000 0000000006136428
[ 728.462114] 7f80:
000000000042c000 0000ffffd7071448 000000000042c000 0000000000000000
[ 728.470190] 7fa0:
00000000061350c0 0000ffffd7070010 000000000041129c 0000ffffd7070010
[ 728.478281] 7fc0:
0000ffffbc7c8f48 0000000060000000 0000000006136428 000000000000006a
[ 728.486351] 7fe0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 728.494434] [<
ffff200008084780>] el0_svc_naked+0x34/0x38
[ 728.499957] ==================================================================
[ 728.507801] Unable to handle kernel NULL pointer dereference at virtual address
000000a0
[ 728.517742] Mem abort info:
[ 728.520993] Exception class = DABT (current EL), IL = 32 bits
[ 728.527375] SET = 0, FnV = 0
[ 728.530731] EA = 0, S1PTW = 0
[ 728.534361] Data abort info:
[ 728.537650] ISV = 0, ISS = 0x00000006
[ 728.541863] CM = 0, WnR = 0
[ 728.545167] user pgtable: 4k pages, 48-bit VAs, pgd =
ffff8006c6100000
[ 728.552156] [
00000000000000a0] *pgd=
0000000716a8d003
[ 728.557519] , *pud=
00000007116fc003
[ 728.561259] , *pmd=
0000000000000000
[ 728.564985] Internal error: Oops:
96000006 [#1] PREEMPT SMP
[ 728.570815] Modules linked in:
[ 728.574023] usb_f_uac2
[ 728.576560] u_audio
[ 728.578827] g_audio(-)
[ 728.581361] libcomposite
[ 728.584071] configfs
[ 728.586428] aes_ce_blk
[ 728.588960] sata_rcar
[ 728.591421] crypto_simd
[ 728.594039] cryptd
[ 728.596217] libata
[ 728.598396] aes_ce_cipher
[ 728.601188] crc32_ce
[ 728.603542] ghash_ce
[ 728.605896] gf128mul
[ 728.608250] aes_arm64
[ 728.610692] scsi_mod
[ 728.613046] sha2_ce
[ 728.615313] xhci_plat_hcd
[ 728.618106] sha256_arm64
[ 728.620811] sha1_ce
[ 728.623077] renesas_usbhs
[ 728.625869] xhci_hcd
[ 728.628243] renesas_usb3
[ 728.630948] sha1_generic
[ 728.633670] ravb_streaming(C)
[ 728.636814] udc_core
[ 728.639168] cpufreq_dt
[ 728.641697] rcar_gen3_thermal
[ 728.644840] usb_dmac
[ 728.647194] pwm_rcar
[ 728.649548] thermal_sys
[ 728.652165] virt_dma
[ 728.654519] mch_core(C)
[ 728.657137] pwm_bl
[ 728.659315] snd_soc_rcar
[ 728.662020] snd_aloop
[ 728.664462] snd_soc_generic_card
[ 728.667869] snd_soc_ak4613
[ 728.670749] ipv6
[ 728.672768] autofs4
[ 728.675052] CPU: 0 PID: 2545 Comm: modprobe Tainted: G B WC 4.14.47+ #152
[ 728.682973] Hardware name: Renesas Salvator-X board based on r8a7795 ES2.0+ (DT)
[ 728.690637] task:
ffff8006ced38000 task.stack:
ffff8006cf6c0000
[ 728.696814] PC is at u_audio_stop_capture+0x70/0x268 [u_audio]
[ 728.702896] LR is at u_audio_stop_capture+0x70/0x268 [u_audio]
[ 728.708964] pc : [<
ffff2000021e1618>] lr : [<
ffff2000021e1618>] pstate:
60000145
[ 728.716620] sp :
ffff8006cf6c7a50
[ 728.720154] x29:
ffff8006cf6c7a50
[ 728.723760] x28:
ffff8006ced38000
[ 728.727272] x27:
ffff200008fd7000
[ 728.730857] x26:
ffff2000021d2340
[ 728.734361] x25:
0000000000000000
[ 728.737948] x24:
ffff200009e94b08
[ 728.741452] x23:
00000000000000a0
[ 728.745052] x22:
00000000000000a8
[ 728.748558] x21:
1ffff000d9ed8f7c
[ 728.752142] x20:
ffff8006d671a800
[ 728.755646] x19:
0000000000000000
[ 728.759231] x18:
0000000000000000
[ 728.762736] x17:
0000ffffbc7c8f40
[ 728.766320] x16:
ffff200008213c4c
[ 728.769823] x15:
0000000000000000
[ 728.773408] x14:
0720072007200720
[ 728.776912] x13:
0720072007200720
[ 728.780497] x12:
ffffffffffffffff
[ 728.784001] x11:
0000000000000040
[ 728.787598] x10:
0000000000001600
[ 728.791103] x9 :
ffff8006cf6c77a0
[ 728.794689] x8 :
ffff8006ced39660
[ 728.798193] x7 :
ffff20000811c738
[ 728.801794] x6 :
0000000000000000
[ 728.805299] x5 :
dfff200000000000
[ 728.808885] x4 :
ffff8006ced38000
[ 728.812390] x3 :
ffff200008fb46e8
[ 728.815976] x2 :
0000000000000007
[ 728.819480] x1 :
3ba68643e7431500
[ 728.823066] x0 :
0000000000000000
[ 728.826574] Process modprobe (pid: 2545, stack limit = 0xffff8006cf6c0000)
[ 728.833704] Call trace:
[ 728.836292] Exception stack(0xffff8006cf6c7910 to 0xffff8006cf6c7a50)
[ 728.842987] 7900:
0000000000000000 3ba68643e7431500
[ 728.851084] 7920:
0000000000000007 ffff200008fb46e8 ffff8006ced38000 dfff200000000000
[ 728.859173] 7940:
0000000000000000 ffff20000811c738 ffff8006ced39660 ffff8006cf6c77a0
[ 728.867248] 7960:
0000000000001600 0000000000000040 ffffffffffffffff 0720072007200720
[ 728.875323] 7980:
0720072007200720 0000000000000000 ffff200008213c4c 0000ffffbc7c8f40
[ 728.883412] 79a0:
0000000000000000 0000000000000000 ffff8006d671a800 1ffff000d9ed8f7c
[ 728.891485] 79c0:
00000000000000a8 00000000000000a0 ffff200009e94b08 0000000000000000
[ 728.899561] 79e0:
ffff2000021d2340 ffff200008fd7000 ffff8006ced38000 ffff8006cf6c7a50
[ 728.907636] 7a00:
ffff2000021e1618 ffff8006cf6c7a50 ffff2000021e1618 0000000060000145
[ 728.915710] 7a20:
0000000000000008 0000000000000000 0000ffffffffffff 3ba68643e7431500
[ 728.923780] 7a40:
ffff8006cf6c7a50 ffff2000021e1618
[ 728.928880] [<
ffff2000021e1618>] u_audio_stop_capture+0x70/0x268 [u_audio]
[ 728.936032] [<
ffff2000021f8b7c>] afunc_disable+0x44/0x60 [usb_f_uac2]
[ 728.942822] [<
ffff20000218177c>] usb_remove_function+0x9c/0x210 [libcomposite]
[ 728.950385] [<
ffff200002183320>] remove_config.isra.2+0x1d8/0x218 [libcomposite]
[ 728.958134] [<
ffff200002186c54>] __composite_unbind+0x104/0x1f8 [libcomposite]
[ 728.965689] [<
ffff200002186d58>] composite_unbind+0x10/0x18 [libcomposite]
[ 728.972882] [<
ffff20000152f158>] usb_gadget_remove_driver+0xc0/0x170 [udc_core]
[ 728.980522] [<
ffff20000153154c>] usb_gadget_unregister_driver+0x1cc/0x258 [udc_core]
[ 728.988638] [<
ffff200002180de8>] usb_composite_unregister+0x10/0x18 [libcomposite]
[ 728.996472] [<
ffff2000021d035c>] audio_driver_exit+0x14/0x28 [g_audio]
[ 729.003231] [<
ffff200008213ed4>] SyS_delete_module+0x288/0x32c
[ 729.009278] Exception stack(0xffff8006cf6c7ec0 to 0xffff8006cf6c8000)
[ 729.015946] 7ec0:
0000000006136428 0000000000000800 0000000000000000 0000ffffd706efe8
[ 729.024022] 7ee0:
0000ffffd706efe9 000000000000000a 1999999999999999 0000000000000000
[ 729.032099] 7f00:
000000000000006a 000000000042c078 0000000000000000 0000000000000005
[ 729.040172] 7f20:
0000000000000000 0000000000000000 0000000000000004 0000000000000000
[ 729.048263] 7f40:
000000000042bfc8 0000ffffbc7c8f40 0000000000000000 00000000061363c0
[ 729.056337] 7f60:
0000000006136428 0000000000000000 0000000000000000 0000000006136428
[ 729.064411] 7f80:
000000000042c000 0000ffffd7071448 000000000042c000 0000000000000000
[ 729.072484] 7fa0:
00000000061350c0 0000ffffd7070010 000000000041129c 0000ffffd7070010
[ 729.080563] 7fc0:
0000ffffbc7c8f48 0000000060000000 0000000006136428 000000000000006a
[ 729.088636] 7fe0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 729.096733] [<
ffff200008084780>] el0_svc_naked+0x34/0x38
[ 729.102259] Code:
9597d1b3 aa1703e0 9102a276 958792b9 (
f9405275)
[ 729.108617] ---[ end trace
7560c5fa3d100243 ]---
After this patch is applied, the issue is fixed:
rcar-gen3:/home/root# modprobe g_audio
[ 59.217127] g_audio gadget: afunc_bind:565 Error!
[ 59.222329] g_audio
ee020000.usb: failed to start g_audio: -19
modprobe: ERROR: could not insert 'g_audio': No such device
rcar-gen3:/home/root# modprobe -r g_audio
rcar-gen3:/home/root#
Fixes:
f1d3861d63a5 ("usb: gadget: f_uac2: fix error handling at afunc_bind")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Reinecke [Mon, 2 Oct 2017 14:26:37 +0000 (16:26 +0200)]
scsi: scsi_devinfo: fixup string compare
commit
b8018b973c7cefa5eb386540130fa47315b8e337 upstream.
When checking the model and vendor string we need to use the minimum
value of either string, otherwise we'll miss out on wildcard matches.
And we should take care when matching with zero size strings; results
might be unpredictable. With this patch the rules for matching devinfo
strings are as follows:
- Vendor strings must match exactly
- Empty Model strings will only match if the devinfo model
is also empty
- Model strings shorter than the devinfo model string will
not match
Fixes: 5e7ff2c ("SCSI: fix new bug in scsi_dev_info_list string matching")
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 3 Jun 2020 06:16:48 +0000 (08:16 +0200)]
Linux 4.9.226
Benjamin Block [Tue, 2 Jul 2019 21:02:01 +0000 (23:02 +0200)]
scsi: zfcp: fix request object use-after-free in send path causing wrong traces
[ Upstream commit
106d45f350c7cac876844dc685845cba4ffdb70b ]
When tracing instances where we open and close WKA ports, we also pass the
request-ID of the respective FSF command.
But after successfully sending the FSF command we must not use the
request-object anymore, as this might result in an use-after-free (see
"zfcp: fix request object use-after-free in send path causing seqno
errors" ).
To fix this add a new variable that caches the request-ID before sending
the request. This won't change during the hand-off to the FCP channel,
and so it's safe to trace this cached request-ID later, instead of using
the request object.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Fixes:
d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Salil Mehta [Mon, 18 Feb 2019 17:40:32 +0000 (17:40 +0000)]
net: hns: Fixes the missing put_device in positive leg for roce reset
commit
4d96e13ee9cd1f7f801e8c7f4b12f09d1da4a5d8 upstream.
This patch fixes the missing device reference release-after-use in
the positive leg of the roce reset API of the HNS DSAF.
Fixes:
c969c6e7ab8c ("net: hns: Fix object reference leaks in hns_dsaf_roce_reset()")
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guoqing Jiang [Tue, 9 Apr 2019 08:16:38 +0000 (16:16 +0800)]
sc16is7xx: move label 'err_spi' to correct section
commit
e00164a0f000de893944981f41a568c981aca658 upstream.
err_spi is used when SERIAL_SC16IS7XX_SPI is enabled, so make
the label only available under SERIAL_SC16IS7XX_SPI option.
Otherwise, the below warning appears.
drivers/tty/serial/sc16is7xx.c:1523:1: warning: label ‘err_spi’ defined but not used [-Wunused-label]
err_spi:
^~~~~~~
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Fixes:
ac0cdb3d9901 ("sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liviu Dudau [Tue, 5 Mar 2019 23:42:54 +0000 (15:42 -0800)]
mm/vmalloc.c: don't dereference possible NULL pointer in __vunmap()
commit
6ade20327dbb808882888ed8ccded71e93067cf9 upstream.
find_vmap_area() can return a NULL pointer and we're going to
dereference it without checking it first. Use the existing
find_vm_area() function which does exactly what we want and checks for
the NULL pointer.
Link: http://lkml.kernel.org/r/20181228171009.22269-1-liviu@dudau.co.uk
Fixes:
f3c01d2f3ade ("mm: vmalloc: avoid racy handling of debugobjects in vunmap")
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roopa Prabhu [Wed, 12 Sep 2018 20:21:48 +0000 (13:21 -0700)]
net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags
commit
56a49d7048703f5ffdb84d3a0ee034108fba6850 upstream.
This fix addresses https://bugzilla.kernel.org/show_bug.cgi?id=201071
Commit
5025f7f7d506 wrongly relied on __dev_change_flags to notify users of
dev flag changes in the case when dev->rtnl_link_state = RTNL_LINK_INITIALIZED.
Fix it by indicating flag changes explicitly to __dev_notify_flags.
Fixes:
5025f7f7d506 ("rtnetlink: add rtnl_link_state check in rtnl_configure_link")
Reported-By: Liam mcbirnie <liam.mcbirnie@boeing.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Mon, 4 Jun 2018 15:33:54 +0000 (17:33 +0200)]
genirq/generic_pending: Do not lose pending affinity update
commit
a33a5d2d16cb84bea8d5f5510f3a41aa48b5c467 upstream.
The generic pending interrupt mechanism moves interrupts from the interrupt
handler on the original target CPU to the new destination CPU. This is
required for x86 and ia64 due to the way the interrupt delivery and
acknowledge works if the interrupts are not remapped.
However that update can fail for various reasons. Some of them are valid
reasons to discard the pending update, but the case, when the previous move
has not been fully cleaned up is not a legit reason to fail.
Check the return value of irq_do_set_affinity() for -EBUSY, which indicates
a pending cleanup, and rearm the pending move in the irq dexcriptor so it's
tried again when the next interrupt arrives.
Fixes:
996c591227d9 ("x86/irq: Plug vector cleanup race")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Song Liu <songliubraving@fb.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <liu.song.a23@gmail.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: stable@vger.kernel.org
Cc: Mike Travis <mike.travis@hpe.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Tariq Toukan <tariqt@mellanox.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Link: https://lkml.kernel.org/r/20180604162224.386544292@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira Ayuso [Wed, 27 May 2020 10:24:10 +0000 (12:24 +0200)]
netfilter: nf_conntrack_pptp: fix compilation warning with W=1 build
commit
4946ea5c1237036155c3b3a24f049fd5f849f8f6 upstream.
>> include/linux/netfilter/nf_conntrack_pptp.h:13:20: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
extern const char *const pptp_msg_name(u_int16_t msg);
^~~~~~
Reported-by: kbuild test robot <lkp@intel.com>
Fixes:
4c559f15efcc ("netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiushi Wu [Thu, 28 May 2020 03:10:29 +0000 (22:10 -0500)]
bonding: Fix reference count leak in bond_sysfs_slave_add.
commit
a068aab42258e25094bc2c159948d263ed7d7a77 upstream.
kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object. Previous
commit "
b8eb718348b8" fixed a similar problem.
Fixes:
07699f9a7c8d ("bonding: add sysfs /slave dir for bond slave devices.")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiushi Wu [Mon, 25 May 2020 08:24:39 +0000 (03:24 -0500)]
qlcnic: fix missing release in qlcnic_83xx_interrupt_test.
commit
15c973858903009e995b2037683de29dfe968621 upstream.
In function qlcnic_83xx_interrupt_test(), function
qlcnic_83xx_diag_alloc_res() is not handled by function
qlcnic_83xx_diag_free_res() after a call of the function
qlcnic_alloc_mbx_args() failed. Fix this issue by adding
a jump target "fail_mbx_args", and jump to this new target
when qlcnic_alloc_mbx_args() failed.
Fixes:
b6b4316c8b2f ("qlcnic: Handle qlcnic_alloc_mbx_args() failure")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira Ayuso [Thu, 14 May 2020 12:14:23 +0000 (14:14 +0200)]
netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code
commit
4c559f15efcc43b996f4da528cd7f9483aaca36d upstream.
Dan Carpenter says: "Smatch complains that the value for "cmd" comes
from the network and can't be trusted."
Add pptp_msg_name() helper function that checks for the array boundary.
Fixes:
f09943fefe6b ("[NETFILTER]: nf_conntrack/nf_nat: add PPTP helper port")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phil Sutter [Thu, 14 May 2020 11:31:21 +0000 (13:31 +0200)]
netfilter: ipset: Fix subcounter update skip
commit
a164b95ad6055c50612795882f35e0efda1f1390 upstream.
If IPSET_FLAG_SKIP_SUBCOUNTER_UPDATE is set, user requested to not
update counters in sub sets. Therefore IPSET_FLAG_SKIP_COUNTER_UPDATE
must be set, not unset.
Fixes:
6e01781d1c80e ("netfilter: ipset: set match: add support to match the counters")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Braun [Wed, 6 May 2020 09:46:25 +0000 (11:46 +0200)]
netfilter: nft_reject_bridge: enable reject with bridge vlan
commit
e9c284ec4b41c827f4369973d2792992849e4fa5 upstream.
Currently, using the bridge reject target with tagged packets
results in untagged packets being sent back.
Fix this by mirroring the vlan id as well.
Fixes:
85f5b3086a04 ("netfilter: bridge: add reject support")
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Tue, 21 Apr 2020 12:46:11 +0000 (20:46 +0800)]
ip_vti: receive ipip packet by calling ip_tunnel_rcv
commit
976eba8ab596bab94b9714cd46d38d5c6a2c660d upstream.
In Commit
dd9ee3444014 ("vti4: Fix a ipip packet processing bug in
'IPCOMP' virtual tunnel"), it tries to receive IPIP packets in vti
by calling xfrm_input(). This case happens when a small packet or
frag sent by peer is too small to get compressed.
However, xfrm_input() will still get to the IPCOMP path where skb
sec_path is set, but never dropped while it should have been done
in vti_ipcomp4_protocol.cb_handler(vti_rcv_cb), as it's not an
ipcomp4 packet. This will cause that the packet can never pass
xfrm4_policy_check() in the upper protocol rcv functions.
So this patch is to call ip_tunnel_rcv() to process IPIP packets
instead.
Fixes:
dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeremy Sowden [Sat, 23 Mar 2019 14:43:02 +0000 (14:43 +0000)]
vti4: eliminated some duplicate code.
commit
f981c57ffd2d7cf2dd4b6d6f8fcb3965df42f54c upstream.
The ipip tunnel introduced in commit
dd9ee3444014 ("vti4: Fix a ipip
packet processing bug in 'IPCOMP' virtual tunnel") largely duplicated
the existing vti_input and vti_recv functions. Refactored to
deduplicate the common code.
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Tue, 26 May 2020 09:41:46 +0000 (17:41 +0800)]
xfrm: fix a NULL-ptr deref in xfrm_local_error
commit
f6a23d85d078c2ffde79c66ca81d0a1dde451649 upstream.
This patch is to fix a crash:
[ ] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ ] general protection fault: 0000 [#1] SMP KASAN PTI
[ ] RIP: 0010:ipv6_local_error+0xac/0x7a0
[ ] Call Trace:
[ ] xfrm6_local_error+0x1eb/0x300
[ ] xfrm_local_error+0x95/0x130
[ ] __xfrm6_output+0x65f/0xb50
[ ] xfrm6_output+0x106/0x46f
[ ] udp_tunnel6_xmit_skb+0x618/0xbf0 [ip6_udp_tunnel]
[ ] vxlan_xmit_one+0xbc6/0x2c60 [vxlan]
[ ] vxlan_xmit+0x6a0/0x4276 [vxlan]
[ ] dev_hard_start_xmit+0x165/0x820
[ ] __dev_queue_xmit+0x1ff0/0x2b90
[ ] ip_finish_output2+0xd3e/0x1480
[ ] ip_do_fragment+0x182d/0x2210
[ ] ip_output+0x1d0/0x510
[ ] ip_send_skb+0x37/0xa0
[ ] raw_sendmsg+0x1b4c/0x2b80
[ ] sock_sendmsg+0xc0/0x110
This occurred when sending a v4 skb over vxlan6 over ipsec, in which case
skb->protocol == htons(ETH_P_IPV6) while skb->sk->sk_family == AF_INET in
xfrm_local_error(). Then it will go to xfrm6_local_error() where it tries
to get ipv6 info from a ipv4 sk.
This issue was actually fixed by Commit
628e341f319f ("xfrm: make local
error reporting more robust"), but brought back by Commit
844d48746e4b
("xfrm: choose protocol family by skb protocol").
So to fix it, we should call xfrm6_local_error() only when skb->protocol
is htons(ETH_P_IPV6) and skb->sk->sk_family is AF_INET6.
Fixes:
844d48746e4b ("xfrm: choose protocol family by skb protocol")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Mon, 25 May 2020 05:53:37 +0000 (13:53 +0800)]
xfrm: fix a warning in xfrm_policy_insert_list
commit
ed17b8d377eaf6b4a01d46942b4c647378a79bdd upstream.
This waring can be triggered simply by:
# ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \
priority 1 mark 0 mask 0x10 #[1]
# ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \
priority 2 mark 0 mask 0x1 #[2]
# ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \
priority 2 mark 0 mask 0x10 #[3]
Then dmesg shows:
[ ] WARNING: CPU: 1 PID: 7265 at net/xfrm/xfrm_policy.c:1548
[ ] RIP: 0010:xfrm_policy_insert_list+0x2f2/0x1030
[ ] Call Trace:
[ ] xfrm_policy_inexact_insert+0x85/0xe50
[ ] xfrm_policy_insert+0x4ba/0x680
[ ] xfrm_add_policy+0x246/0x4d0
[ ] xfrm_user_rcv_msg+0x331/0x5c0
[ ] netlink_rcv_skb+0x121/0x350
[ ] xfrm_netlink_rcv+0x66/0x80
[ ] netlink_unicast+0x439/0x630
[ ] netlink_sendmsg+0x714/0xbf0
[ ] sock_sendmsg+0xe2/0x110
The issue was introduced by Commit
7cb8a93968e3 ("xfrm: Allow inserting
policies with matching mark and different priorities"). After that, the
policies [1] and [2] would be able to be added with different priorities.
However, policy [3] will actually match both [1] and [2]. Policy [1]
was matched due to the 1st 'return true' in xfrm_policy_mark_match(),
and policy [2] was matched due to the 2nd 'return true' in there. It
caused WARN_ON() in xfrm_policy_insert_list().
This patch is to fix it by only (the same value and priority) as the
same policy in xfrm_policy_mark_match().
Thanks to Yuehaibing, we could make this fix better.
v1->v2:
- check policy->mark.v == pol->mark.v only without mask.
Fixes:
7cb8a93968e3 ("xfrm: Allow inserting policies with matching mark and different priorities")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Fri, 10 Apr 2020 09:06:01 +0000 (17:06 +0800)]
xfrm: allow to accept packets with ipv6 NEXTHDR_HOP in xfrm_input
commit
afcaf61be9d1dbdee5ec186d1dcc67b6b692180f upstream.
For beet mode, when it's ipv6 inner address with nexthdrs set,
the packet format might be:
----------------------------------------------------
| outer | | dest | | | ESP | ESP |
| IP hdr | ESP | opts.| TCP | Data | Trailer | ICV |
----------------------------------------------------
The nexthdr from ESP could be NEXTHDR_HOP(0), so it should
continue processing the packet when nexthdr returns 0 in
xfrm_input(). Otherwise, when ipv6 nexthdr is set, the
packet will be dropped.
I don't see any error cases that nexthdr may return 0. So
fix it by removing the check for nexthdr == 0.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Dahl [Tue, 26 May 2020 17:57:49 +0000 (19:57 +0200)]
x86/dma: Fix max PFN arithmetic overflow on 32 bit systems
commit
88743470668ef5eb6b7ba9e0f99888e5999bf172 upstream.
The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is
4 294 967 296 or 0x100000000 which is no problem on 64 bit systems.
The patch does not change the later overall result of 0x100000 for
MAX_DMA32_PFN (after it has been shifted by PAGE_SHIFT). The new
calculation yields the same result, but does not require 64 bit
arithmetic.
On 32 bit systems the old calculation suffers from an arithmetic
overflow in that intermediate term in braces: 4UL aka unsigned long int
is 4 byte wide and an arithmetic overflow happens (the 0x100000000 does
not fit in 4 bytes), the in braces result is truncated to zero, the
following right shift does not alter that, so MAX_DMA32_PFN evaluates to
0 on 32 bit systems.
That wrong value is a problem in a comparision against MAX_DMA32_PFN in
the init code for swiotlb in pci_swiotlb_detect_4gb() to decide if
swiotlb should be active. That comparison yields the opposite result,
when compiling on 32 bit systems.
This was not possible before
1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too")
when that MAX_DMA32_PFN was first made visible to x86_32 (and which
landed in v3.0).
In practice this wasn't a problem, unless CONFIG_SWIOTLB is active on
x86-32.
However if one has set CONFIG_IOMMU_INTEL, since
c5a5dc4cbbf4 ("iommu/vt-d: Don't switch off swiotlb if bounce page is used")
there's a dependency on CONFIG_SWIOTLB, which was not necessarily
active before. That landed in v5.4, where we noticed it in the fli4l
Linux distribution. We have CONFIG_IOMMU_INTEL active on both 32 and 64
bit kernel configs there (I could not find out why, so let's just say
historical reasons).
The effect is at boot time 64 MiB (default size) were allocated for
bounce buffers now, which is a noticeable amount of memory on small
systems like pcengines ALIX 2D3 with 256 MiB memory, which are still
frequently used as home routers.
We noticed this effect when migrating from kernel v4.19 (LTS) to v5.4
(LTS) in fli4l and got that kernel messages for example:
Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018
…
Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem)
…
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB)
The initial analysis and the suggested fix was done by user 'sourcejedi'
at stackoverflow and explicitly marked as GPLv2 for inclusion in the
Linux kernel:
https://unix.stackexchange.com/a/520525/50007
The new calculation, which does not suffer from that overflow, is the
same as for arch/mips now as suggested by Robin Murphy.
The fix was tested by fli4l users on round about two dozen different
systems, including both 32 and 64 bit archs, bare metal and virtualized
machines.
[ bp: Massage commit message. ]
Fixes:
1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too")
Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Alexander Dahl <post@lespocky.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Link: https://unix.stackexchange.com/q/520065/50007
Link: https://web.nettworks.org/bugs/browse/FFL-2560
Link: https://lkml.kernel.org/r/20200526175749.20742-1-post@lespocky.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Lüssing [Fri, 22 May 2020 17:04:13 +0000 (19:04 +0200)]
mac80211: mesh: fix discovery timer re-arming issue / crash
commit
e2d4a80f93fcfaf72e2e20daf6a28e39c3b90677 upstream.
On a non-forwarding 802.11s link between two fairly busy
neighboring nodes (iperf with -P 16 at ~850MBit/s TCP;
1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4), so with
frequent PREQ retries, usually after around 30-40 seconds the
following crash would occur:
[ 1110.822428] Unable to handle kernel read from unreadable memory at virtual address
00000000
[ 1110.830786] Mem abort info:
[ 1110.833573] Exception class = IABT (current EL), IL = 32 bits
[ 1110.839494] SET = 0, FnV = 0
[ 1110.842546] EA = 0, S1PTW = 0
[ 1110.845678] user pgtable: 4k pages, 48-bit VAs, pgd =
ffff800076386000
[ 1110.852204] [
0000000000000000] *pgd=
00000000f6322003, *pud=
00000000f62de003, *pmd=
0000000000000000
[ 1110.861167] Internal error: Oops:
86000004 [#1] PREEMPT SMP
[ 1110.866730] Modules linked in: pppoe ppp_async batman_adv ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 usb_storage xhci_plat_hcd xhci_pci xhci_hcd dwc3 usbcore usb_common
[ 1110.932190] Process swapper/3 (pid: 0, stack limit = 0xffff0000090c8000)
[ 1110.938884] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.162 #0
[ 1110.944965] Hardware name: LS1043A RGW Board (DT)
[ 1110.949658] task:
ffff8000787a81c0 task.stack:
ffff0000090c8000
[ 1110.955568] PC is at 0x0
[ 1110.958097] LR is at call_timer_fn.isra.27+0x24/0x78
[ 1110.963055] pc : [<
0000000000000000>] lr : [<
ffff0000080ff29c>] pstate:
00400145
[ 1110.970440] sp :
ffff00000801be10
[ 1110.973744] x29:
ffff00000801be10 x28:
ffff000008bf7018
[ 1110.979047] x27:
ffff000008bf87c8 x26:
ffff000008c160c0
[ 1110.984352] x25:
0000000000000000 x24:
0000000000000000
[ 1110.989657] x23:
dead000000000200 x22:
0000000000000000
[ 1110.994959] x21:
0000000000000000 x20:
0000000000000101
[ 1111.000262] x19:
ffff8000787a81c0 x18:
0000000000000000
[ 1111.005565] x17:
ffff0000089167b0 x16:
0000000000000058
[ 1111.010868] x15:
ffff0000089167b0 x14:
0000000000000000
[ 1111.016172] x13:
ffff000008916788 x12:
0000000000000040
[ 1111.021475] x11:
ffff80007fda9af0 x10:
0000000000000001
[ 1111.026777] x9 :
ffff00000801bea0 x8 :
0000000000000004
[ 1111.032080] x7 :
0000000000000000 x6 :
ffff80007fda9aa8
[ 1111.037383] x5 :
ffff00000801bea0 x4 :
0000000000000010
[ 1111.042685] x3 :
ffff00000801be98 x2 :
0000000000000614
[ 1111.047988] x1 :
0000000000000000 x0 :
0000000000000000
[ 1111.053290] Call trace:
[ 1111.055728] Exception stack(0xffff00000801bcd0 to 0xffff00000801be10)
[ 1111.062158] bcc0:
0000000000000000 0000000000000000
[ 1111.069978] bce0:
0000000000000614 ffff00000801be98 0000000000000010 ffff00000801bea0
[ 1111.077798] bd00:
ffff80007fda9aa8 0000000000000000 0000000000000004 ffff00000801bea0
[ 1111.085618] bd20:
0000000000000001 ffff80007fda9af0 0000000000000040 ffff000008916788
[ 1111.093437] bd40:
0000000000000000 ffff0000089167b0 0000000000000058 ffff0000089167b0
[ 1111.101256] bd60:
0000000000000000 ffff8000787a81c0 0000000000000101 0000000000000000
[ 1111.109075] bd80:
0000000000000000 dead000000000200 0000000000000000 0000000000000000
[ 1111.116895] bda0:
ffff000008c160c0 ffff000008bf87c8 ffff000008bf7018 ffff00000801be10
[ 1111.124715] bdc0:
ffff0000080ff29c ffff00000801be10 0000000000000000 0000000000400145
[ 1111.132534] bde0:
ffff8000787a81c0 ffff00000801bde8 0000ffffffffffff 000001029eb19be8
[ 1111.140353] be00:
ffff00000801be10 0000000000000000
[ 1111.145220] [< (null)>] (null)
[ 1111.149917] [<
ffff0000080ff77c>] run_timer_softirq+0x184/0x398
[ 1111.155741] [<
ffff000008081938>] __do_softirq+0x100/0x1fc
[ 1111.161130] [<
ffff0000080a2e28>] irq_exit+0x80/0xd8
[ 1111.166002] [<
ffff0000080ea708>] __handle_domain_irq+0x88/0xb0
[ 1111.171825] [<
ffff000008081678>] gic_handle_irq+0x68/0xb0
[ 1111.177213] Exception stack(0xffff0000090cbe30 to 0xffff0000090cbf70)
[ 1111.183642] be20:
0000000000000020 0000000000000000
[ 1111.191461] be40:
0000000000000001 0000000000000000 00008000771af000 0000000000000000
[ 1111.199281] be60:
ffff000008c95180 0000000000000000 ffff000008c19360 ffff0000090cbef0
[ 1111.207101] be80:
0000000000000810 0000000000000400 0000000000000098 ffff000000000000
[ 1111.214920] bea0:
0000000000000001 ffff0000089167b0 0000000000000000 ffff0000089167b0
[ 1111.222740] bec0:
0000000000000000 ffff000008c198e8 ffff000008bf7018 ffff000008c19000
[ 1111.230559] bee0:
0000000000000000 0000000000000000 ffff8000787a81c0 ffff000008018000
[ 1111.238380] bf00:
ffff00000801c000 ffff00000913ba34 ffff8000787a81c0 ffff0000090cbf70
[ 1111.246199] bf20:
ffff0000080857cc ffff0000090cbf70 ffff0000080857d0 0000000000400145
[ 1111.254020] bf40:
ffff000008018000 ffff00000801c000 ffffffffffffffff ffff0000080fa574
[ 1111.261838] bf60:
ffff0000090cbf70 ffff0000080857d0
[ 1111.266706] [<
ffff0000080832e8>] el1_irq+0xe8/0x18c
[ 1111.271576] [<
ffff0000080857d0>] arch_cpu_idle+0x10/0x18
[ 1111.276880] [<
ffff0000080d7de4>] do_idle+0xec/0x1b8
[ 1111.281748] [<
ffff0000080d8020>] cpu_startup_entry+0x20/0x28
[ 1111.287399] [<
ffff00000808f81c>] secondary_start_kernel+0x104/0x110
[ 1111.293662] Code: bad PC value
[ 1111.296710] ---[ end trace
555b6ca4363c3edd ]---
[ 1111.301318] Kernel panic - not syncing: Fatal exception in interrupt
[ 1111.307661] SMP: stopping secondary CPUs
[ 1111.311574] Kernel Offset: disabled
[ 1111.315053] CPU features: 0x0002000
[ 1111.318530] Memory Limit: none
[ 1111.321575] Rebooting in 3 seconds..
With some added debug output / delays we were able to push the crash from
the timer callback runner into the callback function and by that shedding
some light on which object holding the timer gets corrupted:
[ 401.720899] Unable to handle kernel read from unreadable memory at virtual address
00000868
[...]
[ 402.335836] [<
ffff0000088fafa4>] _raw_spin_lock_bh+0x14/0x48
[ 402.341548] [<
ffff000000dbe684>] mesh_path_timer+0x10c/0x248 [mac80211]
[ 402.348154] [<
ffff0000080ff29c>] call_timer_fn.isra.27+0x24/0x78
[ 402.354150] [<
ffff0000080ff77c>] run_timer_softirq+0x184/0x398
[ 402.359974] [<
ffff000008081938>] __do_softirq+0x100/0x1fc
[ 402.365362] [<
ffff0000080a2e28>] irq_exit+0x80/0xd8
[ 402.370231] [<
ffff0000080ea708>] __handle_domain_irq+0x88/0xb0
[ 402.376053] [<
ffff000008081678>] gic_handle_irq+0x68/0xb0
The issue happens due to the following sequence of events:
1) mesh_path_start_discovery():
-> spin_unlock_bh(&mpath->state_lock) before mesh_path_sel_frame_tx()
2) mesh_path_free_rcu()
-> del_timer_sync(&mpath->timer)
[...]
-> kfree_rcu(mpath)
3) mesh_path_start_discovery():
-> mod_timer(&mpath->timer, ...)
[...]
-> rcu_read_unlock()
4) mesh_path_free_rcu()'s kfree_rcu():
-> kfree(mpath)
5) mesh_path_timer() starts after timeout, using freed mpath object
So a use-after-free issue due to a timer re-arming bug caused by an
early spin-unlocking.
This patch fixes this issue by re-checking if mpath is about to be
free'd and if so bails out of re-arming the timer.
Cc: stable@vger.kernel.org
Fixes:
050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol")
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
Link: https://lore.kernel.org/r/20200522170413.14973-1-linus.luessing@c0d3.blue
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Thu, 28 May 2020 20:29:25 +0000 (22:29 +0200)]
parisc: Fix kernel panic in mem_init()
commit
bf71bc16e02162388808949b179d59d0b571b965 upstream.
The Debian kernel v5.6 triggers this kernel panic:
Kernel panic - not syncing: Bad Address (null pointer deref?)
Bad Address (null pointer deref?): Code=26 (Data memory access rights trap) at addr
0000000000000000
CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-parisc64 #1 Debian 5.6.14-1
IAOQ[0]: mem_init+0xb0/0x150
IAOQ[1]: mem_init+0xb4/0x150
RP(r2): start_kernel+0x6c8/0x1190
Backtrace:
[<
0000000040101ab4>] start_kernel+0x6c8/0x1190
[<
0000000040108574>] start_parisc+0x158/0x1b8
on a HP-PARISC rp3440 machine with this memory layout:
Memory Ranges:
0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB
1) Start 0x0000004040000000 End 0x00000040ffdfffff Size 3070 MB
Fix the crash by avoiding virt_to_page() and similar functions in
mem_init() until the memory zones have been fully set up.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiushi Wu [Wed, 27 May 2020 21:00:19 +0000 (16:00 -0500)]
iommu: Fix reference count leak in iommu_group_alloc.
[ Upstream commit
7cc31613734c4870ae32f5265d576ef296621343 ]
kobject_init_and_add() takes reference even when it fails.
Thus, when kobject_init_and_add() returns an error,
kobject_put() must be called to properly clean up the kobject.
Fixes:
d72e31c93746 ("iommu: IOMMU Groups")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Link: https://lore.kernel.org/r/20200527210020.6522-1-wu000273@umn.edu
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Thu, 28 May 2020 05:20:55 +0000 (22:20 -0700)]
include/asm-generic/topology.h: guard cpumask_of_node() macro argument
[ Upstream commit
4377748c7b5187c3342a60fa2ceb60c8a57a8488 ]
drivers/hwmon/amd_energy.c:195:15: error: invalid operands to binary expression ('void' and 'int')
(channel - data->nr_cpus));
~~~~~~~~~^~~~~~~~~~~~~~~~~
include/asm-generic/topology.h:51:42: note: expanded from macro 'cpumask_of_node'
#define cpumask_of_node(node) ((void)node, cpu_online_mask)
^~~~
include/linux/cpumask.h:618:72: note: expanded from macro 'cpumask_first_and'
#define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p))
^~~~~
Fixes:
f0b848ce6fe9 ("cpumask: Introduce cpumask_of_{node,pcibus} to replace {node,pcibus}_to_cpumask")
Fixes:
8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: http://lkml.kernel.org/r/20200527134623.930247-1-arnd@arndb.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Potapenko [Thu, 28 May 2020 05:20:52 +0000 (22:20 -0700)]
fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()
[ Upstream commit
1d605416fb7175e1adf094251466caa52093b413 ]
KMSAN reported uninitialized data being written to disk when dumping
core. As a result, several kilobytes of kmalloc memory may be written
to the core file and then read by a non-privileged user.
Reported-by: sam <sunhaoyl@outlook.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com
Link: https://github.com/google/kmsan/issues/76
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Konstantin Khlebnikov [Thu, 28 May 2020 05:20:47 +0000 (22:20 -0700)]
mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()
[ Upstream commit
6988f31d558aa8c744464a7f6d91d34ada48ad12 ]
Replace superfluous VM_BUG_ON() with comment about correct usage.
Technically reverts commit
1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to
page_mapcount()"), but context lines have changed.
Function isolate_migratepages_block() runs some checks out of lru_lock
when choose pages for migration. After checking PageLRU() it checks
extra page references by comparing page_count() and page_mapcount().
Between these two checks page could be removed from lru, freed and taken
by slab.
As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount().
Race window is tiny. For certain workload this happens around once a
year.
page:
ffffea0105ca9380 count:1 mapcount:0 mapping:
ffff88ff7712c180 index:0x0 compound_mapcount: 0
flags: 0x500000000008100(slab|head)
raw:
0500000000008100 dead000000000100 dead000000000200 ffff88ff7712c180
raw:
0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(PageSlab(page))
------------[ cut here ]------------
kernel BUG at ./include/linux/mm.h:628!
invalid opcode: 0000 [#1] SMP NOPTI
CPU: 77 PID: 504 Comm: kcompactd1 Tainted: G W 4.19.109-27 #1
Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019
RIP: 0010:isolate_migratepages_block+0x986/0x9b0
The code in isolate_migratepages_block() was added in commit
119d6d59dcc0 ("mm, compaction: avoid isolating pinned pages") before
adding VM_BUG_ON into page_mapcount().
This race has been predicted in 2015 by Vlastimil Babka (see link
below).
[akpm@linux-foundation.org: comment tweaks, per Hugh]
Fixes:
1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/159032779896.957378.7852761411265662220.stgit@buzz
Link: https://lore.kernel.org/lkml/557710E1.6060103@suse.cz/
Link: https://lore.kernel.org/linux-mm/158937872515.474360.5066096871639561424.stgit@buzz/T/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerry Lee [Mon, 18 May 2020 08:03:09 +0000 (16:03 +0800)]
libceph: ignore pool overlay and cache logic on redirects
[ Upstream commit
890bd0f8997ae6ac0a367dd5146154a3963306dd ]
OSD client should ignore cache/overlay flag if got redirect reply.
Otherwise, the client hangs when the cache tier is in forward mode.
[ idryomov: Redirects are effectively deprecated and no longer
used or tested. The original tiering modes based on redirects
are inherently flawed because redirects can race and reorder,
potentially resulting in data corruption. The new proxy and
readproxy tiering modes should be used instead of forward and
readforward. Still marking for stable as obviously correct,
though. ]
Cc: stable@vger.kernel.org
URL: https://tracker.ceph.com/issues/23296
URL: https://tracker.ceph.com/issues/36406
Signed-off-by: Jerry Lee <leisurelysw24@gmail.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric W. Biederman [Mon, 25 May 2020 17:56:15 +0000 (12:56 -0500)]
exec: Always set cap_ambient in cap_bprm_set_creds
[ Upstream commit
a4ae32c71fe90794127b32d26d7ad795813b502e ]
An invariant of cap_bprm_set_creds is that every field in the new cred
structure that cap_bprm_set_creds might set, needs to be set every
time to ensure the fields does not get a stale value.
The field cap_ambient is not set every time cap_bprm_set_creds is
called, which means that if there is a suid or sgid script with an
interpreter that has neither the suid nor the sgid bits set the
interpreter should be able to accept ambient credentials.
Unfortuantely because cap_ambient is not reset to it's original value
the interpreter can not accept ambient credentials.
Given that the ambient capability set is expected to be controlled by
the caller, I don't think this is particularly serious. But it is
definitely worth fixing so the code works correctly.
I have tested to verify my reading of the code is correct and the
interpreter of a sgid can receive ambient capabilities with this
change and cannot receive ambient capabilities without this change.
Cc: stable@vger.kernel.org
Cc: Andy Lutomirski <luto@kernel.org>
Fixes:
58319057b784 ("capabilities: ambient capabilities")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chris Chiu [Tue, 26 May 2020 06:26:13 +0000 (14:26 +0800)]
ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC
[ Upstream commit
4020d1ccbe55bdf67b31d718d2400506eaf4b43f ]
The Asus USB DAC is a USB type-C audio dongle for connecting to
the headset and headphone. The volume minimum value -23040 which
is 0xa600 in hexadecimal with the resolution value 1 indicates
this should be endianness issue caused by the firmware bug. Add
a volume quirk to fix the volume control problem.
Also fixes this warning:
Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
[5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1
Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
[7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200526062613.55401-1-chiu@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changming Liu [Tue, 26 May 2020 00:39:21 +0000 (00:39 +0000)]
ALSA: hwdep: fix a left shifting 1 by 31 UB bug
[ Upstream commit
fb8cd6481ffd126f35e9e146a0dcf0c4e8899f2e ]
The "info.index" variable can be 31 in "1 << info.index".
This might trigger an undefined behavior since 1 is signed.
Fix this by casting 1 to 1u just to be sure "1u << 31" is defined.
Signed-off-by: Changming Liu <liu.changm@northeastern.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Beckett [Thu, 14 May 2020 17:02:37 +0000 (19:02 +0200)]
ARM: dts/imx6q-bx50v3: Set display interface clock parents
[ Upstream commit
665e7c73a7724a393b4ec92d1ae1e029925ef2b7 ]
Avoid LDB and IPU DI clocks both using the same parent. LDB requires
pasthrough clock to avoid breaking timing while IPU DI does not.
Force IPU DI clocks to use IMX6QDL_CLK_PLL2_PFD0_352M as parent
and LDB to use IMX6QDL_CLK_PLL5_VIDEO_DIV.
This fixes an issue where attempting atomic modeset while using
HDMI and display port at the same time causes LDB clock programming
to destroy the programming of HDMI that was done during the same
modeset.
Cc: stable@vger.kernel.org
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
[Use IMX6QDL_CLK_PLL2_PFD0_352M instead of IMX6QDL_CLK_PLL2_PFD2_396M
originally chosen by Robert Beckett to avoid affecting eMMC clock
by DRM atomic updates]
Signed-off-by: Ian Ray <ian.ray@ge.com>
[Squash Robert's and Ian's commits for bisectability, update patch
description and add stable tag]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Reichel [Tue, 23 Jan 2018 15:03:47 +0000 (16:03 +0100)]
ARM: dts: imx6q-bx50v3: Add internal switch
[ Upstream commit
e26dead442689a861358f33126210b0f8de615a9 ]
B850v3, B650v3 and B450v3 all have a GPIO bit banged MDIO bus to
communicate with a Marvell switch. On all devices the switch is
connected to a PCI based network card, which needs to be referenced
by DT, so this also adds the common PCI root node.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martyn Welch [Fri, 30 Jun 2017 13:43:37 +0000 (15:43 +0200)]
ARM: dts: imx: Correct B850v3 clock assignment
[ Upstream commit
1d0c7bb20c083a6e810d2142545b5606f8131080 ]
The IPU that drives HDMI must have its pre_sel set to pll2_pfd_396m
to avoid stepping on the LVDS output's toes, as the PLL can't be clocked
to the pixel clock and to the LVDS serial clock (3.5*pixel clock) at the
same time.
As we are using ipu1_di0 and ipu2_di0, ensure both are switched to
to pll2_pfd2_396m to avoid issues. The LDB driver will switch the
required IPU to ldb_di1 when it uses it to drive LVDS.
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kaike Wan [Tue, 12 May 2020 03:13:28 +0000 (23:13 -0400)]
IB/qib: Call kobject_put() when kobject_init_and_add() fails
[ Upstream commit
a35cd6447effd5c239b564c80fa109d05ff3d114 ]
When kobject_init_and_add() returns an error in the function
qib_create_port_files(), the function kobject_put() is not called for the
corresponding kobject, which potentially leads to memory leak.
This patch fixes the issue by calling kobject_put() even if
kobject_init_and_add() fails. In addition, the ppd->diagc_kobj is released
along with other kobjects when the sysfs is unregistered.
Fixes:
f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
Link: https://lore.kernel.org/r/20200512031328.189865.48627.stgit@awfm-01.aw.intel.com
Cc: <stable@vger.kernel.org>
Suggested-by: Lin Yi <teroincn@gmail.com>
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Tue, 28 Apr 2020 23:09:53 +0000 (16:09 -0700)]
Input: synaptics-rmi4 - fix error return code in rmi_driver_probe()
[ Upstream commit
5caab2da63207d6d631007f592f5219459e3454d ]
Fix to return a negative error code from the input_register_device()
error handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kevin Locke [Tue, 28 Apr 2020 01:07:20 +0000 (18:07 -0700)]
Input: i8042 - add ThinkPad S230u to i8042 reset list
[ Upstream commit
2712c91a54a1058d55c284152b4d93c979b67be6 ]
On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version
"GDETC1WW (1.81 ) 06/27/2019", the keyboard, Synaptics TouchPad, and
TrackPoint either do not function or stop functioning a few minutes
after boot. This problem has been noted before, perhaps only occurring
with BIOS 1.57 and later.[1][2][3][4][5]
Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago
and although the [BIOS changelog] notes "Fixed an issue of UEFI
touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be
insufficient.
Setting i8042.reset=1 or adding 33474HU to the reset list avoids the
issue on my system from either warm or cold boot.
[1]: https://bugs.launchpad.net/bugs/1210748
[2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425
[3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200
[4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115
[5]: https://forums.lenovo.com/topic/findpost/27/1337119
[BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txt
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.name
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Łukasz Patron [Wed, 22 Apr 2020 21:13:09 +0000 (14:13 -0700)]
Input: xpad - add custom init packet for Xbox One S controllers
[ Upstream commit
764f7f911bf72450c51eb74cbb262ad9933741d8 ]
Sending [ 0x05, 0x20, 0x00, 0x0f, 0x06 ] packet for Xbox One S controllers
fixes an issue where controller is stuck in Bluetooth mode and not sending
any inputs.
Signed-off-by: Łukasz Patron <priv.luk@gmail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brendan Shanks [Wed, 22 Apr 2020 20:45:12 +0000 (13:45 -0700)]
Input: evdev - call input_flush_device() on release(), not flush()
[ Upstream commit
09264098ff153f60866039d60b31d39b66f55a31 ]
input_flush_device() should only be called once the struct file is being
released and no open descriptors remain, but evdev_flush() was calling
it whenever a file descriptor was closed.
This caused uploaded force-feedback effects to be erased when a process
did a dup()/close() on the event FD, called system(), etc.
Call input_flush_device() from evdev_release() instead.
Reported-by: Mathieu Maret <mathieu.maret@gmail.com>
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Hilliard [Sun, 19 Apr 2020 04:17:12 +0000 (21:17 -0700)]
Input: usbtouchscreen - add support for BonXeon TP
[ Upstream commit
e3b4f94ef52ae1592cbe199bd38dbdc0d58b2217 ]
Based on available information this uses the singletouch irtouch
protocol. This is tested and confirmed to be fully functional on
the BonXeon TP hardware I have.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://lore.kernel.org/r/20200413184217.55700-1-james.hilliard1@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steve French [Wed, 13 May 2020 15:27:16 +0000 (10:27 -0500)]
cifs: Fix null pointer check in cifs_read
[ Upstream commit
9bd21d4b1a767c3abebec203342f3820dcb84662 ]
Coverity scan noted a redundant null check
Coverity-id: 728517
Reported-by: Coverity <scan-admin@coverity.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masahiro Yamada [Fri, 3 Apr 2020 13:16:51 +0000 (22:16 +0900)]
usb: gadget: legacy: fix redundant initialization warnings
[ Upstream commit
d13cce757954fa663c69845611957396843ed87a ]
Fix the following cppcheck warnings:
drivers/usb/gadget/legacy/inode.c:1364:8: style: Redundant initialization for 'value'. The initialized value is overwritten$
value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1331:15: note: value is initialized
int value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1364:8: note: value is overwritten
value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1817:8: style: Redundant initialization for 'value'. The initialized value is overwritten$
value = -EINVAL;
^
drivers/usb/gadget/legacy/inode.c:1787:18: note: value is initialized
ssize_t value = len, length = len;
^
drivers/usb/gadget/legacy/inode.c:1817:8: note: value is overwritten
value = -EINVAL;
^
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lei Xue [Thu, 7 May 2020 12:50:22 +0000 (08:50 -0400)]
cachefiles: Fix race between read_waiter and read_copier involving op->to_do
[ Upstream commit
7bb0c5338436dae953622470d52689265867f032 ]
There is a potential race in fscache operation enqueuing for reading and
copying multiple pages from cachefiles to netfs. The problem can be seen
easily on a heavy loaded system (for example many processes reading files
continually on an NFS share covered by fscache triggered this problem within
a few minutes).
The race is due to cachefiles_read_waiter() adding the op to the monitor
to_do list and then then drop the object->work_lock spinlock before
completing fscache_enqueue_operation(). Once the lock is dropped,
cachefiles_read_copier() grabs the op, completes processing it, and
makes it through fscache_retrieval_complete() which sets the op->state to
the final state of FSCACHE_OP_ST_COMPLETE(4). When cachefiles_read_waiter()
finally gets through the remainder of fscache_enqueue_operation()
it sees the invalid state, and hits the ASSERTCMP and the following
oops is seen:
[ 2259.612361] FS-Cache:
[ 2259.614785] FS-Cache: Assertion failed
[ 2259.618639] FS-Cache: 4 == 5 is false
[ 2259.622456] ------------[ cut here ]------------
[ 2259.627190] kernel BUG at fs/fscache/operation.c:70!
...
[ 2259.791675] RIP: 0010:[<
ffffffffc061b4cf>] [<
ffffffffc061b4cf>] fscache_enqueue_operation+0xff/0x170 [fscache]
[ 2259.802059] RSP: 0000:
ffffa0263d543be0 EFLAGS:
00010046
[ 2259.807521] RAX:
0000000000000019 RBX:
ffffa01a4d390480 RCX:
0000000000000006
[ 2259.814847] RDX:
0000000000000000 RSI:
0000000000000046 RDI:
ffffa0263d553890
[ 2259.822176] RBP:
ffffa0263d543be8 R08:
0000000000000000 R09:
ffffa0263c2d8708
[ 2259.829502] R10:
0000000000001e7f R11:
0000000000000000 R12:
ffffa01a4d390480
[ 2259.844483] R13:
ffff9fa9546c5920 R14:
ffffa0263d543c80 R15:
ffffa0293ff9bf10
[ 2259.859554] FS:
00007f4b6efbd700(0000) GS:
ffffa0263d540000(0000) knlGS:
0000000000000000
[ 2259.875571] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 2259.889117] CR2:
00007f49e1624ff0 CR3:
0000012b38b38000 CR4:
00000000007607e0
[ 2259.904015] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 2259.918764] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 2259.933449] PKRU:
55555554
[ 2259.943654] Call Trace:
[ 2259.953592] <IRQ>
[ 2259.955577] [<
ffffffffc03a7c12>] cachefiles_read_waiter+0x92/0xf0 [cachefiles]
[ 2259.978039] [<
ffffffffa34d3942>] __wake_up_common+0x82/0x120
[ 2259.991392] [<
ffffffffa34d3a63>] __wake_up_common_lock+0x83/0xc0
[ 2260.004930] [<
ffffffffa34d3510>] ? task_rq_unlock+0x20/0x20
[ 2260.017863] [<
ffffffffa34d3ab3>] __wake_up+0x13/0x20
[ 2260.030230] [<
ffffffffa34c72a0>] __wake_up_bit+0x50/0x70
[ 2260.042535] [<
ffffffffa35bdcdb>] unlock_page+0x2b/0x30
[ 2260.054495] [<
ffffffffa35bdd09>] page_endio+0x29/0x90
[ 2260.066184] [<
ffffffffa368fc81>] mpage_end_io+0x51/0x80
CPU1
cachefiles_read_waiter()
20 static int cachefiles_read_waiter(wait_queue_entry_t *wait, unsigned mode,
21 int sync, void *_key)
22 {
...
61 spin_lock(&object->work_lock);
62 list_add_tail(&monitor->op_link, &op->to_do);
63 spin_unlock(&object->work_lock);
<begin race window>
64
65 fscache_enqueue_retrieval(op);
182 static inline void fscache_enqueue_retrieval(struct fscache_retrieval *op)
183 {
184 fscache_enqueue_operation(&op->op);
185 }
58 void fscache_enqueue_operation(struct fscache_operation *op)
59 {
60 struct fscache_cookie *cookie = op->object->cookie;
61
62 _enter("{OBJ%x OP%x,%u}",
63 op->object->debug_id, op->debug_id, atomic_read(&op->usage));
64
65 ASSERT(list_empty(&op->pend_link));
66 ASSERT(op->processor != NULL);
67 ASSERT(fscache_object_is_available(op->object));
68 ASSERTCMP(atomic_read(&op->usage), >, 0);
<end race window>
CPU2
cachefiles_read_copier()
168 while (!list_empty(&op->to_do)) {
...
202 fscache_end_io(op, monitor->netfs_page, error);
203 put_page(monitor->netfs_page);
204 fscache_retrieval_complete(op, 1);
CPU1
58 void fscache_enqueue_operation(struct fscache_operation *op)
59 {
...
69 ASSERTIFCMP(op->state != FSCACHE_OP_ST_IN_PROGRESS,
70 op->state, ==, FSCACHE_OP_ST_CANCELLED);
Signed-off-by: Lei Xue <carmark.dlut@gmail.com>
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Peterson [Tue, 5 May 2020 16:53:21 +0000 (11:53 -0500)]
gfs2: move privileged user check to gfs2_quota_lock_check
[ Upstream commit
4ed0c30811cb4d30ef89850b787a53a84d5d2bcb ]
Before this patch, function gfs2_quota_lock checked if it was called
from a privileged user, and if so, it bypassed the quota check:
superuser can operate outside the quotas.
That's the wrong place for the check because the lock/unlock functions
are separate from the lock_check function, and you can do lock and
unlock without actually checking the quotas.
This patch moves the check to gfs2_quota_lock_check.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Thu, 7 May 2020 15:13:20 +0000 (23:13 +0800)]
net: microchip: encx24j600: add missed kthread_stop
[ Upstream commit
ff8ce319e9c25e920d994cc35236f0bb32dfc8f3 ]
This driver calls kthread_run() in probe, but forgets to call
kthread_stop() in probe failure and remove.
Add the missed kthread_stop() to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Warren [Mon, 27 Apr 2020 23:26:05 +0000 (17:26 -0600)]
gpio: tegra: mask GPIO IRQs during IRQ shutdown
[ Upstream commit
0cf253eed5d2bdf7bb3152457b38f39b012955f7 ]
The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ
client has released the GPIO IRQ. This allows the HW to raise IRQs, and
SW to process them, after shutdown. Fix this by masking the IRQ when it's
shut down. This is usually taken care of by the irqchip core, but since
this driver has a custom irq_shutdown implementation, it must do this
explicitly itself.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kalderon, Michal [Thu, 6 Jul 2017 20:22:11 +0000 (23:22 +0300)]
IB/cma: Fix reference count leak when no ipv4 addresses are set
commit
963916fdb3e5ad4af57ac959b5a03bf23f7568ca upstream.
Once in_dev_get is called to receive in_device pointer, the
in_device reference counter is increased, but if there are
no ipv4 addresses configured on the net-device the ifa_list
will be null, resulting in a flow that doesn't call in_dev_put
to decrease the ref_cnt.
This was exposed when running RoCE over ipv6 without any ipv4
addresses configured
Fixes: commit
8e3867310c90 ("IB/cma: Fix a race condition in iboe_addr_get_sgid()")
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry V. Levin [Wed, 15 Feb 2017 02:23:26 +0000 (05:23 +0300)]
uapi: fix linux/if_pppol2tp.h userspace compilation errors
commit
a725eb15db80643a160310ed6bcfd6c5a6c907f2 upstream.
Because of <linux/libc-compat.h> interface limitations, <netinet/in.h>
provided by libc cannot be included after <linux/in.h>, therefore any
header that includes <netinet/in.h> cannot be included after <linux/in.h>.
Change uapi/linux/l2tp.h, the last uapi header that includes
<netinet/in.h>, to include <linux/in.h> and <linux/in6.h> instead of
<netinet/in.h> and use __SOCK_SIZE__ instead of sizeof(struct sockaddr)
the same way as uapi/linux/in.h does, to fix linux/if_pppol2tp.h userspace
compilation errors like this:
In file included from /usr/include/linux/l2tp.h:12:0,
from /usr/include/linux/if_pppol2tp.h:21,
/usr/include/netinet/in.h:31:8: error: redefinition of 'struct in_addr'
Fixes:
47c3e7783be4 ("net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*")
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiushi Wu [Fri, 22 May 2020 19:07:15 +0000 (14:07 -0500)]
net/mlx4_core: fix a memory leak bug.
commit
febfd9d3c7f74063e8e630b15413ca91b567f963 upstream.
In function mlx4_opreq_action(), pointer "mailbox" is not released,
when mlx4_cmd_box() return and error, causing a memory leak bug.
Fix this issue by going to "out" label, mlx4_free_cmd_mailbox() can
free this pointer.
Fixes:
fe6f700d6cbb ("net/mlx4_core: Respond to operation request by firmware")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiushi Wu [Fri, 22 May 2020 21:50:27 +0000 (16:50 -0500)]
net: sun: fix missing release regions in cas_init_one().
commit
5a730153984dd13f82ffae93d7170d76eba204e9 upstream.
In cas_init_one(), "pdev" is requested by "pci_request_regions", but it
was not released after a call of the function “pci_write_config_byte”
failed. Thus replace the jump target “err_write_cacheline” by
"err_out_free_res".
Fixes:
1f26dac32057 ("[NET]: Add Sun Cassini driver.")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moshe Shemesh [Fri, 27 Dec 2019 05:01:53 +0000 (07:01 +0200)]
net/mlx5: Add command entry handling completion
[ Upstream commit
17d00e839d3b592da9659c1977d45f85b77f986a ]
When FW response to commands is very slow and all command entries in
use are waiting for completion we can have a race where commands can get
timeout before they get out of the queue and handled. Timeout
completion on uninitialized command will cause releasing command's
buffers before accessing it for initialization and then we will get NULL
pointer exception while trying access it. It may also cause releasing
buffers of another command since we may have timeout completion before
even allocating entry index for this command.
Add entry handling completion to avoid this race.
Fixes:
e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manivannan Sadhasivam [Tue, 19 May 2020 18:14:16 +0000 (23:44 +0530)]
net: qrtr: Fix passing invalid reference to qrtr_local_enqueue()
[ Upstream commit
d28ea1fbbf437054ef339afec241019f2c4e2bb6 ]
Once the traversal of the list is completed with list_for_each_entry(),
the iterator (node) will point to an invalid object. So passing this to
qrtr_local_enqueue() which is outside of the iterator block is erroneous
eventhough the object is not used.
So fix this by passing NULL to qrtr_local_enqueue().
Fixes:
bdabad3e363d ("net: Add Qualcomm IPC router")
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moshe Shemesh [Tue, 7 Apr 2020 14:38:28 +0000 (17:38 +0300)]
net/mlx5e: Update netdev txq on completions during closure
[ Upstream commit
5e911e2c06bd8c17df29147a5e2d4b17fafda024 ]
On sq closure when we free its descriptors, we should also update netdev
txq on completions which would not arrive. Otherwise if we reopen sqs
and attach them back, for example on fw fatal recovery flow, we may get
tx timeout.
Fixes:
29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close")
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jere Leppänen [Wed, 20 May 2020 15:15:31 +0000 (18:15 +0300)]
sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed
[ Upstream commit
d3e8e4c11870413789f029a71e72ae6e971fe678 ]
Commit
bdf6fa52f01b ("sctp: handle association restarts when the
socket is closed.") starts shutdown when an association is restarted,
if in SHUTDOWN-PENDING state and the socket is closed. However, the
rationale stated in that commit applies also when in SHUTDOWN-SENT
state - we don't want to move an association to ESTABLISHED state when
the socket has been closed, because that results in an association
that is unreachable from user space.
The problem scenario:
1. Client crashes and/or restarts.
2. Server (using one-to-one socket) calls close(). SHUTDOWN is lost.
3. Client reconnects using the same addresses and ports.
4. Server's association is restarted. The association and the socket
move to ESTABLISHED state, even though the server process has
closed its descriptor.
Also, after step 4 when the server process exits, some resources are
leaked in an attempt to release the underlying inet sock structure in
ESTABLISHED state:
IPv4: Attempt to release TCP socket in state 1
00000000377288c7
Fix by acting the same way as in SHUTDOWN-PENDING state. That is, if
an association is restarted in SHUTDOWN-SENT state and the socket is
closed, then start shutdown and don't move the association or the
socket to ESTABLISHED state.
Fixes:
bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.")
Signed-off-by: Jere Leppänen <jere.leppanen@nokia.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roman Mashak [Sun, 17 May 2020 12:46:31 +0000 (08:46 -0400)]
net sched: fix reporting the first-time use timestamp
[ Upstream commit
b15e62631c5f19fea9895f7632dae9c1b27fe0cd ]
When a new action is installed, firstuse field of 'tcf_t' is explicitly set
to 0. Value of zero means "new action, not yet used"; as a packet hits the
action, 'firstuse' is stamped with the current jiffies value.
tcf_tm_dump() should return 0 for firstuse if action has not yet been hit.
Fixes:
48d8ee1694dd ("net sched actions: aggregate dumping of actions timeinfo")
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuqi Jin [Sat, 16 May 2020 03:46:49 +0000 (11:46 +0800)]
net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()"
[ Upstream commit
a6211caa634da39d861a47437ffcda8b38ef421b ]
Commit
adb03115f459 ("net: get rid of an signed integer overflow in ip_idents_reserve()")
used atomic_cmpxchg to replace "atomic_add_return" inside the function
"ip_idents_reserve". The reason was to avoid UBSAN warning.
However, this change has caused performance degrade and in GCC-8,
fno-strict-overflow is now mapped to -fwrapv -fwrapv-pointer
and signed integer overflow is now undefined by default at all
optimization levels[1]. Moreover, it was a bug in UBSAN vs -fwrapv
/-fno-strict-overflow, so Let's revert it safely.
[1] https://gcc.gnu.org/gcc-8/changes.html
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Eric Dumazet <edumazet@google.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jiong Wang <jiongwang@huawei.com>
Signed-off-by: Yuqi Jin <jinyuqi@huawei.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vadim Fedorenko [Wed, 20 May 2020 08:50:48 +0000 (11:50 +0300)]
net: ipip: fix wrong address family in init error path
[ Upstream commit
57ebc8f08504f176eb0f25b3e0fde517dec61a4f ]
In case of error with MPLS support the code is misusing AF_INET
instead of AF_MPLS.
Fixes:
1b69e7e6c4da ("ipip: support MPLS over IPv4")
Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 20 May 2020 01:24:43 +0000 (18:24 -0700)]
ax25: fix setsockopt(SO_BINDTODEVICE)
[ Upstream commit
687775cec056b38a4c8f3291e0dd7a9145f7b667 ]
syzbot was able to trigger this trace [1], probably by using
a zero optlen.
While we are at it, cap optlen to IFNAMSIZ - 1 instead of IFNAMSIZ.
[1]
BUG: KMSAN: uninit-value in strnlen+0xf9/0x170 lib/string.c:569
CPU: 0 PID: 8807 Comm: syz-executor483 Not tainted 5.7.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
strnlen+0xf9/0x170 lib/string.c:569
dev_name_hash net/core/dev.c:207 [inline]
netdev_name_node_lookup net/core/dev.c:277 [inline]
__dev_get_by_name+0x75/0x2b0 net/core/dev.c:778
ax25_setsockopt+0xfa3/0x1170 net/ax25/af_ax25.c:654
__compat_sys_setsockopt+0x4ed/0x910 net/compat.c:403
__do_compat_sys_setsockopt net/compat.c:413 [inline]
__se_compat_sys_setsockopt+0xdd/0x100 net/compat.c:410
__ia32_compat_sys_setsockopt+0x62/0x80 net/compat.c:410
do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline]
do_fast_syscall_32+0x3bf/0x6d0 arch/x86/entry/common.c:398
entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f57dd9
Code: 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 89 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:
00000000ffae8c1c EFLAGS:
00000217 ORIG_RAX:
000000000000016e
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
0000000000000101
RDX:
0000000000000019 RSI:
0000000020000000 RDI:
0000000000000004
RBP:
0000000000000012 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000000
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000000
Local variable ----devname@ax25_setsockopt created at:
ax25_setsockopt+0xe6/0x1170 net/ax25/af_ax25.c:536
ax25_setsockopt+0xe6/0x1170 net/ax25/af_ax25.c:536
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 27 May 2020 14:42:03 +0000 (16:42 +0200)]
Linux 4.9.225
Christophe JAILLET [Wed, 6 May 2020 03:52:06 +0000 (05:52 +0200)]
iio: sca3000: Remove an erroneous 'get_device()'
[ Upstream commit
928edefbc18cd8433f7df235c6e09a9306e7d580 ]
This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.
While at it add a missing \n at the end of the message.
Fixes:
574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Hubbard [Sat, 23 May 2020 05:22:48 +0000 (22:22 -0700)]
rapidio: fix an error in get_user_pages_fast() error handling
commit
ffca476a0a8d26de767cc41d62b8ca7f540ecfdd upstream.
In the case of get_user_pages_fast() returning fewer pages than
requested, rio_dma_transfer() does not quite do the right thing. It
attempts to release all the pages that were requested, rather than just
the pages that were pinned.
Fix the error handling so that only the pages that were successfully
pinned are released.
Fixes:
e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200517235620.205225-2-jhubbard@nvidia.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Usyskin [Tue, 12 May 2020 22:31:40 +0000 (01:31 +0300)]
mei: release me_cl object reference
commit
fc9c03ce30f79b71807961bfcb42be191af79873 upstream.
Allow me_cl object to be freed by releasing the reference
that was acquired by one of the search functions:
__mei_me_cl_by_uuid_id() or __mei_me_cl_by_uuid()
Cc: <stable@vger.kernel.org>
Reported-by: 亿一 <teroincn@gmail.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200512223140.32186-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Sun, 26 Apr 2020 19:44:03 +0000 (21:44 +0200)]
iio: dac: vf610: Fix an error handling path in 'vf610_dac_probe()'
commit
aad4742fbf0a560c25827adb58695a4497ffc204 upstream.
A call to 'vf610_dac_exit()' is missing in an error handling path.
Fixes:
1b983bf42fad ("iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oscar Carter [Sun, 10 May 2020 10:14:26 +0000 (12:14 +0200)]
staging: greybus: Fix uninitialized scalar variable
commit
34625c1931f8204c234c532b446b9f53c69f4b68 upstream.
In the "gb_tty_set_termios" function the "newline" variable is declared
but not initialized. So the "flow_control" member is not initialized and
the OR / AND operations with itself results in an undefined value in
this member.
The purpose of the code is to set the flow control type, so remove the
OR / AND self operator and set the value directly.
Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable")
Fixes:
e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios")
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dragos Bogdan [Wed, 29 Apr 2020 07:21:29 +0000 (10:21 +0300)]
staging: iio: ad2s1210: Fix SPI reading
commit
5e4f99a6b788047b0b8a7496c2e0c8f372f6edf2 upstream.
If the serial interface is used, the 8-bit address should be latched using
the rising edge of the WR/FSYNC signal.
This basically means that a CS change is required between the first byte
sent, and the second one.
This change splits the single-transfer transfer of 2 bytes into 2 transfers
with a single byte, and CS change in-between.
Note fixes tag is not accurate, but reflects a point beyond which there
are too many refactors to make backporting straight forward.
Fixes:
b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.")
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bob Peterson [Fri, 8 May 2020 20:01:25 +0000 (15:01 -0500)]
Revert "gfs2: Don't demote a glock until its revokes are written"
[ Upstream commit
b14c94908b1b884276a6608dea3d0b1b510338b7 ]
This reverts commit
df5db5f9ee112e76b5202fbc331f990a0fc316d6.
This patch fixes a regression: patch
df5db5f9ee112 allowed function
run_queue() to bypass its call to do_xmote() if revokes were queued for
the glock. That's wrong because its call to do_xmote() is what is
responsible for calling the go_sync() glops functions to sync both
the ail list and any revokes queued for it. By bypassing the call,
gfs2 could get into a stand-off where the glock could not be demoted
until its revokes are written back, but the revokes would not be
written back because do_xmote() was never called.
It "sort of" works, however, because there are other mechanisms like
the log flush daemon (logd) that can sync the ail items and revokes,
if it deems it necessary. The problem is: without file system pressure,
it might never deem it necessary.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arjun Vynipadath [Tue, 20 Nov 2018 06:41:39 +0000 (12:11 +0530)]
cxgb4/cxgb4vf: Fix mac_hlist initialization and free
[ Upstream commit
b539ea60f5043b9acd7562f04fa2117f18776cbb ]
Null pointer dereference seen when cxgb4vf driver is unloaded
without bringing up any interfaces, moving mac_hlist initialization
to driver probe and free the mac_hlist in remove to fix the issue.
Fixes:
24357e06ba51 ("cxgb4vf: fix memleak in mac_hlist initialization")
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arjun Vynipadath [Fri, 9 Nov 2018 09:20:25 +0000 (14:50 +0530)]
cxgb4: free mac_hlist properly
[ Upstream commit
2a8d84bf513823ba398f4b2dec41b8decf4041af ]
The locally maintained list for tracking hash mac table was
not freed during driver remove.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vishal Verma [Thu, 28 Feb 2019 00:06:26 +0000 (17:06 -0700)]
libnvdimm/btt: Remove unnecessary code in btt_freelist_init
[ Upstream commit
2f8c9011151337d0bc106693f272f9bddbccfab2 ]
We call btt_log_read() twice, once to get the 'old' log entry, and again
to get the 'new' entry. However, we have no use for the 'old' entry, so
remove it.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Sat, 30 Mar 2019 00:17:12 +0000 (00:17 +0000)]
platform/x86: alienware-wmi: fix kfree on potentially uninitialized pointer
commit
98e2630284ab741804bd0713e932e725466f2f84 upstream.
Currently the kfree of output.pointer can be potentially freeing
an uninitalized pointer in the case where out_data is NULL. Fix this
by reworking the case where out_data is not-null to perform the
ACPI status check and also the kfree of outpoint.pointer in one block
and hence ensuring the pointer is only freed when it has been used.
Also replace the if (ptr != NULL) idiom with just if (ptr).
Fixes:
ff0e9f26288d ("platform/x86: alienware-wmi: Correct a memory leak")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Sat, 3 Aug 2019 04:48:58 +0000 (21:48 -0700)]
ubsan: build ubsan.c more conservatively
commit
af700eaed0564d5d3963a7a51cb0843629d7fe3d upstream.
objtool points out several conditions that it does not like, depending
on the combination with other configuration options and compiler
variants:
stack protector:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to __stack_chk_fail() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbe: call to __stack_chk_fail() with UACCESS enabled
stackleak plugin:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled
kasan:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x25: call to memcpy() with UACCESS enabled
The stackleak and kasan options just need to be disabled for this file
as we do for other files already. For the stack protector, we already
attempt to disable it, but this fails on clang because the check is
mixed with the gcc specific -fno-conserve-stack option. According to
Andrey Ryabinin, that option is not even needed, dropping it here fixes
the stackprotector issue.
Link: http://lkml.kernel.org/r/20190722125139.1335385-1-arnd@arndb.de
Link: https://lore.kernel.org/lkml/20190617123109.667090-1-arnd@arndb.de/t/
Link: https://lore.kernel.org/lkml/20190722091050.2188664-1-arnd@arndb.de/t/
Fixes:
d08965a27e84 ("x86/uaccess, ubsan: Fix UBSAN vs. SMAP")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Wed, 3 Apr 2019 07:40:16 +0000 (09:40 +0200)]
x86/uaccess, ubsan: Fix UBSAN vs. SMAP
commit
d08965a27e84ca090b504844d50c24fc98587b11 upstream.
UBSAN can insert extra code in random locations; including AC=1
sections. Typically this code is not safe and needs wrapping.
So far, only __ubsan_handle_type_mismatch* have been observed in AC=1
sections and therefore only those are annotated.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[stable backport: only take the lib/Makefile change to resolve gcc-10
build issues]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
R. Parameswaran [Thu, 13 Apr 2017 01:31:04 +0000 (18:31 -0700)]
l2tp: device MTU setup, tunnel socket needs a lock
commit
57240d007816486131bee88cd474c2a71f0fe224 upstream.
The MTU overhead calculation in L2TP device set-up
merged via commit
b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff
needs to be adjusted to lock the tunnel socket while
referencing the sub-data structures to derive the
socket's IP overhead.
Reported-by: Guillaume Nault <g.nault@alphalink.fr>
Tested-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: R. Parameswaran <rparames@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Sat, 16 May 2020 21:42:05 +0000 (23:42 +0200)]
dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()'
commit
3a5fd0dbd87853f8bd2ea275a5b3b41d6686e761 upstream.
Commit
b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
has moved some code in the probe function and reordered the error handling
path accordingly.
However, a goto has been missed.
Fix it and goto the right label if 'dma_async_device_register()' fails, so
that all resources are released.
Fixes:
b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brent Lu [Mon, 18 May 2020 04:30:38 +0000 (12:30 +0800)]
ALSA: pcm: fix incorrect hw_base increase
commit
e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream.
There is a corner case that ALSA keeps increasing the hw_ptr but DMA
already stop working/updating the position for a long time.
In following log we can see the position returned from DMA driver does
not move at all but the hw_ptr got increased at some point of time so
snd_pcm_avail() will return a large number which seems to be a buffer
underrun event from user space program point of view. The program
thinks there is space in the buffer and fill more data.
[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
...
[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
This is because the hw_base will be increased by runtime->buffer_size
frames unconditionally if the hw_ptr is not updated for over half of
buffer time. As the hw_base increases, so does the hw_ptr increased
by the same number.
The avail value returned from snd_pcm_avail() could exceed the limit
(buffer_size) easily becase the hw_ptr itself got increased by same
buffer_size samples when the corner case happens. In following log,
the buffer_size is 16368 samples but the avail is 21810 samples so
CRAS server complains about it.
[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
cras_server[1907]: pcm_avail returned frames larger than buf_size:
sof-glkda7219max: :0,5: 21810 > 16368
By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
the hw_base will keep the same when buffer stall happens at long as
the interval between each HWSYNC call is shorter than half of buffer
time.
Following is a log captured by a patched kernel. The hw_base/hw_ptr
value is fixed in this corner case and user space program should be
aware of the buffer stall and handle it.
[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
...
[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:37 +0000 (00:39 +0100)]
l2tp: initialise PPP sessions before registering them
commit
f98be6c6359e7e4a61aaefb9964c1db31cb9ec0c upstream.
pppol2tp_connect() initialises L2TP sessions after they've been exposed
to the rest of the system by l2tp_session_register(). This puts
sessions into transient states that are the source of several races, in
particular with session's deletion path.
This patch centralises the initialisation code into
pppol2tp_session_init(), which is called before the registration phase.
The only field that can't be set before session registration is the
pppol2tp socket pointer, which has already been converted to RCU. So
pppol2tp_connect() should now be race-free.
The session's .session_close() callback is now set before registration.
Therefore, it's always called when l2tp_core deletes the session, even
if it was created by pppol2tp_session_create() and hasn't been plugged
to a pppol2tp socket yet. That'd prevent session free because the extra
reference taken by pppol2tp_session_close() wouldn't be dropped by the
socket's ->sk_destruct() callback (pppol2tp_session_destruct()).
We could set .session_close() only while connecting a session to its
pppol2tp socket, or teach pppol2tp_session_close() to avoid grabbing a
reference when the session isn't connected, but that'd require adding
some form of synchronisation to be race free.
Instead of that, we can just let the pppol2tp socket hold a reference
on the session as soon as it starts depending on it (that is, in
pppol2tp_connect()). Then we don't need to utilise
pppol2tp_session_close() to hold a reference at the last moment to
prevent l2tp_core from dropping it.
When releasing the socket, pppol2tp_release() now deletes the session
using the standard l2tp_session_delete() function, instead of merely
removing it from hash tables. l2tp_session_delete() drops the reference
the sessions holds on itself, but also makes sure it doesn't remove a
session twice. So it can safely be called, even if l2tp_core already
tried, or is concurrently trying, to remove the session.
Finally, pppol2tp_session_destruct() drops the reference held by the
socket.
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:36 +0000 (00:39 +0100)]
l2tp: protect sock pointer of struct pppol2tp_session with RCU
commit
ee40fb2e1eb5bc0ddd3f2f83c6e39a454ef5a741 upstream.
pppol2tp_session_create() registers sessions that can't have their
corresponding socket initialised. This socket has to be created by
userspace, then connected to the session by pppol2tp_connect().
Therefore, we need to protect the pppol2tp socket pointer of L2TP
sessions, so that it can safely be updated when userspace is connecting
or closing the socket. This will eventually allow pppol2tp_connect()
to avoid generating transient states while initialising its parts of the
session.
To this end, this patch protects the pppol2tp socket pointer using RCU.
The pppol2tp socket pointer is still set in pppol2tp_connect(), but
only once we know the function isn't going to fail. It's eventually
reset by pppol2tp_release(), which now has to wait for a grace period
to elapse before it can drop the last reference on the socket. This
ensures that pppol2tp_session_get_sock() can safely grab a reference
on the socket, even after ps->sk is reset to NULL but before this
operation actually gets visible from pppol2tp_session_get_sock().
The rest is standard RCU conversion: pppol2tp_recv(), which already
runs in atomic context, is simply enclosed by rcu_read_lock() and
rcu_read_unlock(), while other functions are converted to use
pppol2tp_session_get_sock() followed by sock_put().
pppol2tp_session_setsockopt() is a special case. It used to retrieve
the pppol2tp socket from the L2TP session, which itself was retrieved
from the pppol2tp socket. Therefore we can just avoid dereferencing
ps->sk and directly use the original socket pointer instead.
With all users of ps->sk now handling NULL and concurrent updates, the
L2TP ->ref() and ->deref() callbacks aren't needed anymore. Therefore,
rather than converting pppol2tp_session_sock_hold() and
pppol2tp_session_sock_put(), we can just drop them.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:35 +0000 (00:39 +0100)]
l2tp: initialise l2tp_eth sessions before registering them
commit
ee28de6bbd78c2e18111a0aef43ea746f28d2073 upstream.
Sessions must be initialised before being made externally visible by
l2tp_session_register(). Otherwise the session may be concurrently
deleted before being initialised, which can confuse the deletion path
and eventually lead to kernel oops.
Therefore, we need to move l2tp_session_register() down in
l2tp_eth_create(), but also handle the intermediate step where only the
session or the netdevice has been registered.
We can't just call l2tp_session_register() in ->ndo_init() because
we'd have no way to properly undo this operation in ->ndo_uninit().
Instead, let's register the session and the netdevice in two different
steps and protect the session's device pointer with RCU.
And now that we allow the session's .dev field to be NULL, we don't
need to prevent the netdevice from being removed anymore. So we can
drop the dev_hold() and dev_put() calls in l2tp_eth_create() and
l2tp_eth_dev_uninit().
Backporting Notes
l2tp_eth.c: In l2tp_eth_create the "out" label was renamed to "err".
There was one extra occurrence of "goto out" to update.
Fixes:
d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:34 +0000 (00:39 +0100)]
l2tp: don't register sessions in l2tp_session_create()
commit
3953ae7b218df4d1e544b98a393666f9ae58a78c upstream.
Sessions created by l2tp_session_create() aren't fully initialised:
some pseudo-wire specific operations need to be done before making the
session usable. Therefore the PPP and Ethernet pseudo-wires continue
working on the returned l2tp session while it's already been exposed to
the rest of the system.
This can lead to various issues. In particular, the session may enter
the deletion process before having been fully initialised, which will
confuse the session removal code.
This patch moves session registration out of l2tp_session_create(), so
that callers can control when the session is exposed to the rest of the
system. This is done by the new l2tp_session_register() function.
Only pppol2tp_session_create() can be easily converted to avoid
modifying its session after registration (the debug message is dropped
in order to avoid the need for holding a reference on the session).
For pppol2tp_connect() and l2tp_eth_create()), more work is needed.
That'll be done in followup patches. For now, let's just register the
session right after its creation, like it was done before. The only
difference is that we can easily take a reference on the session before
registering it, so, at least, we're sure it's not going to be freed
while we're working on it.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:33 +0000 (00:39 +0100)]
l2tp: fix l2tp_eth module loading
commit
9f775ead5e570e7e19015b9e4e2f3dd6e71a5935 upstream.
The l2tp_eth module crashes if its netlink callbacks are run when the
pernet data aren't initialised.
We should normally register_pernet_device() before the genl callbacks.
However, the pernet data only maintain a list of l2tpeth interfaces,
and this list is never used. So let's just drop pernet handling
instead.
Fixes:
d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:32 +0000 (00:39 +0100)]
l2tp: pass tunnel pointer to ->session_create()
commit
f026bc29a8e093edfbb2a77700454b285c97e8ad upstream.
Using l2tp_tunnel_find() in pppol2tp_session_create() and
l2tp_eth_create() is racy, because no reference is held on the
returned session. These functions are only used to implement the
->session_create callback which is run by l2tp_nl_cmd_session_create().
Therefore searching for the parent tunnel isn't necessary because
l2tp_nl_cmd_session_create() already has a pointer to it and holds a
reference.
This patch modifies ->session_create()'s prototype to directly pass the
the parent tunnel as parameter, thus avoiding searching for it in
pppol2tp_session_create() and l2tp_eth_create().
Since we have to touch the ->session_create() call in
l2tp_nl_cmd_session_create(), let's also remove the useless conditional:
we know that ->session_create isn't NULL at this point because it's
already been checked earlier in this same function.
Finally, one might be tempted to think that the removed
l2tp_tunnel_find() calls were harmless because they would return the
same tunnel as the one held by l2tp_nl_cmd_session_create() anyway.
But that tunnel might be removed and a new one created with same tunnel
Id before the l2tp_tunnel_find() call. In this case l2tp_tunnel_find()
would return the new tunnel which wouldn't be protected by the
reference held by l2tp_nl_cmd_session_create().
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Fixes:
d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:31 +0000 (00:39 +0100)]
l2tp: prevent creation of sessions on terminated tunnels
commit
f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb upstream.
l2tp_tunnel_destruct() sets tunnel->sock to NULL, then removes the
tunnel from the pernet list and finally closes all its sessions.
Therefore, it's possible to add a session to a tunnel that is still
reachable, but for which tunnel->sock has already been reset. This can
make l2tp_session_create() dereference a NULL pointer when calling
sock_hold(tunnel->sock).
This patch adds the .acpt_newsess field to struct l2tp_tunnel, which is
used by l2tp_tunnel_closeall() to prevent addition of new sessions to
tunnels. Resetting tunnel->sock is done after l2tp_tunnel_closeall()
returned, so that l2tp_session_add_to_tunnel() can safely take a
reference on it when .acpt_newsess is true.
The .acpt_newsess field is modified in l2tp_tunnel_closeall(), rather
than in l2tp_tunnel_destruct(), so that it benefits all tunnel removal
mechanisms. E.g. on UDP tunnels, a session could be added to a tunnel
after l2tp_udp_encap_destroy() proceeded. This would prevent the tunnel
from being removed because of the references held by this new session
on the tunnel and its socket. Even though the session could be removed
manually later on, this defeats the purpose of
commit
9980d001cec8 ("l2tp: add udp encap socket destroy handler").
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:30 +0000 (00:39 +0100)]
l2tp: hold tunnel used while creating sessions with netlink
commit
e702c1204eb57788ef189c839c8c779368267d70 upstream.
Use l2tp_tunnel_get() to retrieve tunnel, so that it can't go away on
us. Otherwise l2tp_tunnel_destruct() might release the last reference
count concurrently, thus freeing the tunnel while we're using it.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:29 +0000 (00:39 +0100)]
l2tp: hold tunnel while handling genl TUNNEL_GET commands
commit
4e4b21da3acc68a7ea55f850cacc13706b7480e9 upstream.
Use l2tp_tunnel_get() instead of l2tp_tunnel_find() so that we get
a reference on the tunnel, preventing l2tp_tunnel_destruct() from
freeing it from under us.
Also move l2tp_tunnel_get() below nlmsg_new() so that we only take
the reference when needed.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:28 +0000 (00:39 +0100)]
l2tp: hold tunnel while handling genl tunnel updates
commit
8c0e421525c9eb50d68e8f633f703ca31680b746 upstream.
We need to make sure the tunnel is not going to be destroyed by
l2tp_tunnel_destruct() concurrently.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:27 +0000 (00:39 +0100)]
l2tp: hold tunnel while processing genl delete command
commit
bb0a32ce4389e17e47e198d2cddaf141561581ad upstream.
l2tp_nl_cmd_tunnel_delete() needs to take a reference on the tunnel, to
prevent it from being concurrently freed by l2tp_tunnel_destruct().
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:26 +0000 (00:39 +0100)]
l2tp: hold tunnel while looking up sessions in l2tp_netlink
commit
54652eb12c1b72e9602d09cb2821d5760939190f upstream.
l2tp_tunnel_find() doesn't take a reference on the returned tunnel.
Therefore, it's unsafe to use it because the returned tunnel can go
away on us anytime.
Fix this by defining l2tp_tunnel_get(), which works like
l2tp_tunnel_find(), but takes a reference on the returned tunnel.
Caller then has to drop this reference using l2tp_tunnel_dec_refcount().
As l2tp_tunnel_dec_refcount() needs to be moved to l2tp_core.h, let's
simplify the patch and not move the L2TP_REFCNT_DEBUG part. This code
has been broken (not even compiling) in May 2012 by
commit
a4ca44fa578c ("net: l2tp: Standardize logging styles")
and fixed more than two years later by
commit
29abe2fda54f ("l2tp: fix missing line continuation"). So it
doesn't appear to be used by anyone.
Same thing for l2tp_tunnel_free(); instead of moving it to l2tp_core.h,
let's just simplify things and call kfree_rcu() directly in
l2tp_tunnel_dec_refcount(). Extra assertions and debugging code
provided by l2tp_tunnel_free() didn't help catching any of the
reference counting and socket handling issues found while working on
this series.
Backporting Notes
l2tp_core.c: This patch deletes some code / moves some code to
l2tp_core.h and follows the patch (not including in this series) that
switched from atomic to refcount_t. Moved code changed back to atomic.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:25 +0000 (00:39 +0100)]
l2tp: initialise session's refcount before making it reachable
commit
9ee369a405c57613d7c83a3967780c3e30c52ecc upstream.
Sessions must be fully initialised before calling
l2tp_session_add_to_tunnel(). Otherwise, there's a short time frame
where partially initialised sessions can be accessed by external users.
Backporting Notes
l2tp_core.c: moving code that had been converted from atomic to
refcount_t by an earlier change (which isn't being included in this
patch series).
Fixes:
dbdbc73b4478 ("l2tp: fix duplicate session creation")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:24 +0000 (00:39 +0100)]
l2tp: define parameters of l2tp_tunnel_find*() as "const"
commit
2f858b928bf5a8174911aaec76b8b72a9ca0533d upstream.
l2tp_tunnel_find() and l2tp_tunnel_find_nth() don't modify "net".
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:23 +0000 (00:39 +0100)]
l2tp: define parameters of l2tp_session_get*() as "const"
commit
9aaef50c44f132e040dcd7686c8e78a3390037c5 upstream.
Make l2tp_pernet()'s parameter constant, so that l2tp_session_get*() can
declare their "net" variable as "const".
Also constify "ifname" in l2tp_session_get_by_ifname().
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:22 +0000 (00:39 +0100)]
l2tp: remove l2tp_session_find()
commit
55a3ce3b9d98f752df9e2cfb1cba7e715522428a upstream.
This function isn't used anymore.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Thu, 21 May 2020 23:39:21 +0000 (00:39 +0100)]
l2tp: remove useless duplicate session detection in l2tp_netlink
commit
af87ae465abdc070de0dc35d6c6a9e7a8cd82987 upstream.
There's no point in checking for duplicate sessions at the beginning of
l2tp_nl_cmd_session_create(); the ->session_create() callbacks already
return -EEXIST when the session already exists.
Furthermore, even if l2tp_session_find() returns NULL, a new session
might be created right after the test. So relying on ->session_create()
to avoid duplicate session is the only sane behaviour.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>