OSDN Git Service
Chuck Lever [Wed, 19 Jun 2019 14:32:38 +0000 (10:32 -0400)]
xprtrdma: Fix use-after-free in rpcrdma_post_recvs
[ Upstream commit
2d0abe36cf13fb7b577949fd1539326adddcc9bc ]
Dereference wr->next /before/ the memory backing wr has been
released. This issue was found by code inspection. It is not
expected to be a significant problem because it is in an error
path that is almost never executed.
Fixes:
7c8d9e7c8863 ("xprtrdma: Move Receive posting to ... ")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Tue, 2 Jul 2019 14:55:28 +0000 (15:55 +0100)]
rxrpc: Fix uninitialized error code in rxrpc_send_data_packet()
[ Upstream commit
3427beb6375d04e9627c67343872e79341a684ea ]
With gcc 4.1:
net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’:
net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function
Indeed, if the first jump to the send_fragmentable label is made, and
the address family is not handled in the switch() statement, ret will be
used uninitialized.
Fix this by BUG()'ing as is done in other places in rxrpc where internal
support for future address families will need adding. It should not be
possible to reach this normally as the address families are checked
up-front.
Fixes:
5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Fri, 21 Jun 2019 12:56:31 +0000 (15:56 +0300)]
mfd: intel-lpss: Release IDA resources
[ Upstream commit
02f36911c1b41fcd8779fa0c135aab0554333fa5 ]
ida instances allocate some internal memory for ->free_bitmap
in addition to the base 'struct ida'. Use ida_destroy() to release
that memory at module_exit().
Fixes:
4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kevin Mitchell [Wed, 12 Jun 2019 21:52:03 +0000 (14:52 -0700)]
iommu/amd: Make iommu_disable safer
[ Upstream commit
3ddbe913e55516d3e2165d43d4d5570761769878 ]
Make it safe to call iommu_disable during early init error conditions
before mmio_base is set, but after the struct amd_iommu has been added
to the amd_iommu_list. For example, this happens if firmware fails to
fill in mmio_phys in the ACPI table leading to a NULL pointer
dereference in iommu_feature_disable.
Fixes:
2c0ae1720c09c ('iommu/amd: Convert iommu initialization to state machine')
Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Chan [Sat, 29 Jun 2019 15:16:48 +0000 (11:16 -0400)]
bnxt_en: Suppress error messages when querying DSCP DCB capabilities.
[ Upstream commit
4ca5fa39e1aea2f85eb9c4257075c4077c6531da ]
Some firmware versions do not support this so use the silent variant
to send the message to firmware to suppress the harmless error. This
error message is unnecessarily alarming the user.
Fixes:
afdc8a84844a ("bnxt_en: Add DCBNL DSCP application protocol support.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Chan [Sat, 29 Jun 2019 15:16:45 +0000 (11:16 -0400)]
bnxt_en: Fix ethtool selftest crash under error conditions.
[ Upstream commit
d27e2ca1166aefd54d9c48fb6647dee8115a5dfc ]
After ethtool loopback packet tests, we re-open the nic for the next
IRQ test. If the open fails, we must not proceed with the IRQ test
or we will crash with NULL pointer dereference. Fix it by checking
the bnxt_open_nic() return code before proceeding.
Reported-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
Fixes:
67fea463fd87 ("bnxt_en: Add interrupt test to ethtool -t selftest.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Arcangeli [Fri, 28 Jun 2019 19:07:14 +0000 (12:07 -0700)]
fork,memcg: alloc_thread_stack_node needs to set tsk->stack
[ Upstream commit
1bf4580e00a248a2c86269125390eb3648e1877c ]
Commit
5eed6f1dff87 ("fork,memcg: fix crash in free_thread_stack on
memcg charge fail") corrected two instances, but there was a third
instance of this bug.
Without setting tsk->stack, if memcg_charge_kernel_stack fails, it'll
execute free_thread_stack() on a dangling pointer.
Enterprise kernels are compiled with VMAP_STACK=y so this isn't
critical, but custom VMAP_STACK=n builds should have some performance
advantage, with the drawback of risking to fail fork because compaction
didn't succeed. So as long as VMAP_STACK=n is a supported option it's
worth fixing it upstream.
Link: http://lkml.kernel.org/r/20190619011450.28048-1-aarcange@redhat.com
Fixes:
9b6f7e163cd0 ("mm: rework memcg kernel stack accounting")
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Roman Gushchin <guro@fb.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Kaehlcke [Wed, 12 Jun 2019 18:00:03 +0000 (11:00 -0700)]
backlight: pwm_bl: Fix heuristic to determine number of brightness levels
[ Upstream commit
73fbfc499448455f1e1c77717040e09e25f1d976 ]
With commit
88ba95bedb79 ("backlight: pwm_bl: Compute brightness of
LED linearly to human eye") the number of set bits (aka hweight())
in the PWM period is used in the heuristic to determine the number
of brightness levels, when the brightness table isn't specified in
the DT. The number of set bits doesn't provide a reliable clue about
the length of the period, instead change the heuristic to:
nlevels = period / fls(period)
Also limit the maximum number of brightness levels to 4096 to avoid
excessively large tables.
With this the number of levels increases monotonically with the PWM
period, until the maximum of 4096 levels is reached:
period (ns) # levels
100 16
500 62
1000 111
5000 416
10000 769
50000 3333
100000 4096
Fixes:
88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human eye")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Tue, 25 Jun 2019 16:56:31 +0000 (09:56 -0700)]
tools: bpftool: use correct argument in cgroup errors
[ Upstream commit
6c6874f401e5a0caab3b6a0663169e1fb5e930bb ]
cgroup code tries to use argv[0] as the cgroup path,
but if it fails uses argv[1] to report errors.
Fixes:
5ccda64d38cc ("bpftool: implement cgroup bpf operations")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Roman Gushchin <guro@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bryan O'Donoghue [Wed, 26 Jun 2019 10:27:30 +0000 (11:27 +0100)]
nvmem: imx-ocotp: Change TIMING calculation to u-boot algorithm
[ Upstream commit
159dbaf57b2f4f67ecb59b2c87d071e45ed41d7e ]
The RELAX field of the OCOTP block is turning out as a zero on i.MX8MM.
This messes up the subsequent re-load of the fuse shadow registers.
After some discussion with people @ NXP its clear we have missed a trick
here in Linux.
The OCOTP fuse programming time has a physical minimum 'burn time' that is
not related to the ipg_clk.
We need to define the RELAX, STROBE_READ and STROBE_PROG fields in terms of
desired timings to allow for the burn-in to safely complete. Right now only
the RELAX field is calculated in terms of an absolute time and we are
ending up with a value of zero.
This patch inherits the u-boot timings for the OCOTP_TIMING calculation on
the i.MX6 and i.MX8. Those timings are known to work and critically specify
values such as STROBE_PROG as a minimum timing.
Fixes:
0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Suggested-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bryan O'Donoghue [Wed, 26 Jun 2019 10:27:29 +0000 (11:27 +0100)]
nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing
[ Upstream commit
0493c4792b4eb260441e57f52cc11a9ded48b5a7 ]
The i.MX6 and i.MX8 both have a bit-field spanning bits 27:22 called the
WAIT field.
The WAIT field according to the documentation for both parts "specifies
time interval between auto read and write access in one time program. It is
given in number of ipg_clk periods."
This patch ensures that the relevant field is read and written back to the
timing register.
Fixes:
0642bac7da42 ("nvmem: imx-ocotp: add write support")
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Huckleberry [Tue, 11 Jun 2019 21:11:34 +0000 (14:11 -0700)]
clk: qcom: Fix -Wunused-const-variable
[ Upstream commit
da642427bd7710ec4f4140f693f59aa8521a358c ]
Clang produces the following warning
drivers/clk/qcom/gcc-msm8996.c:133:32: warning: unused variable
'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map' [-Wunused-const-variable]
static const struct
parent_map gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div_map[] =
{ ^drivers/clk/qcom/gcc-msm8996.c:141:27: warning: unused variable
'gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div' [-Wunused-const-variable] static
const char * const gcc_xo_gpll0_gpll2_gpll3_gpll0_early_div[] = { ^
drivers/clk/qcom/gcc-msm8996.c:187:32: warning: unused variable
'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map'
[-Wunused-const-variable] static const struct parent_map
gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div_map[] = { ^
drivers/clk/qcom/gcc-msm8996.c:197:27: warning: unused variable
'gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div'
[-Wunused-const-variable] static const char * const
gcc_xo_gpll0_gpll2_gpll3_gpll1_gpll4_gpll0_early_div[] = {
It looks like these were never used.
Fixes:
b1e010c0730a ("clk: qcom: Add MSM8996 Global Clock Control (GCC) driver")
Cc: clang-built-linux@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/518
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Thu, 13 Jun 2019 13:32:32 +0000 (16:32 +0300)]
dmaengine: hsu: Revert "set HSU_CH_MTSR to memory width"
[ Upstream commit
c24a5c735f87d0549060de31367c095e8810b895 ]
The commit
080edf75d337 ("dmaengine: hsu: set HSU_CH_MTSR to memory width")
has been mistakenly submitted. The further investigations show that
the original code does better job since the memory side transfer size
has never been configured by DMA users.
As per latest revision of documentation: "Channel minimum transfer size
(CHnMTSR)... For IOSF UART, maximum value that can be programmed is 64 and
minimum value that can be programmed is 1."
This reverts commit
080edf75d337d35faa6fc3df99342b10d2848d16.
Fixes:
080edf75d337 ("dmaengine: hsu: set HSU_CH_MTSR to memory width")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ravi Bangoria [Tue, 4 Jun 2019 04:29:53 +0000 (09:59 +0530)]
perf/ioctl: Add check for the sample_period value
[ Upstream commit
913a90bc5a3a06b1f04c337320e9aeee2328dd77 ]
perf_event_open() limits the sample_period to 63 bits. See:
0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Make ioctl() consistent with it.
Also on PowerPC, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: maddy@linux.vnet.ibm.com
Cc: mpe@ellerman.id.au
Fixes:
0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Link: https://lkml.kernel.org/r/20190604042953.914-1-ravi.bangoria@linux.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefano Brivio [Fri, 21 Jun 2019 15:45:28 +0000 (17:45 +0200)]
ip6_fib: Don't discard nodes with valid routing information in fib6_locate_1()
[ Upstream commit
40cb35d5dc04e7f89cbc7b1fc9b4b48d9f1e5343 ]
When we perform an inexact match on FIB nodes via fib6_locate_1(), longer
prefixes will be preferred to shorter ones. However, it might happen that
a node, with higher fn_bit value than some other, has no valid routing
information.
In this case, we'll pick that node, but it will be discarded by the check
on RTN_RTINFO in fib6_locate(), and we might miss nodes with valid routing
information but with lower fn_bit value.
This is apparent when a routing exception is created for a default route:
# ip -6 route list
fc00:1::/64 dev veth_A-R1 proto kernel metric 256 pref medium
fc00:2::/64 dev veth_A-R2 proto kernel metric 256 pref medium
fc00:4::1 via fc00:2::2 dev veth_A-R2 metric 1024 pref medium
fe80::/64 dev veth_A-R1 proto kernel metric 256 pref medium
fe80::/64 dev veth_A-R2 proto kernel metric 256 pref medium
default via fc00:1::2 dev veth_A-R1 metric 1024 pref medium
# ip -6 route list cache
fc00:4::1 via fc00:2::2 dev veth_A-R2 metric 1024 expires 593sec mtu 1500 pref medium
fc00:3::1 via fc00:1::2 dev veth_A-R1 metric 1024 expires 593sec mtu 1500 pref medium
# ip -6 route flush cache # node for default route is discarded
Failed to send flush request: No such process
# ip -6 route list cache
fc00:3::1 via fc00:1::2 dev veth_A-R1 metric 1024 expires 586sec mtu 1500 pref medium
Check right away if the node has a RTN_RTINFO flag, before replacing the
'prev' pointer, that indicates the longest matching prefix found so far.
Fixes:
38fbeeeeccdb ("ipv6: prepare fib6_locate() for exception table")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rob Clark [Mon, 24 Jun 2019 16:09:47 +0000 (09:09 -0700)]
drm/msm/a3xx: remove TPL1 regs from snapshot
[ Upstream commit
f47bee2ba447bebc304111c16ef1e1a73a9744dd ]
These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang. It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.
Fixes:
7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen-Yu Tsai [Tue, 4 Jun 2019 04:23:37 +0000 (12:23 +0800)]
arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC
[ Upstream commit
0bb9d1876c0605815ea0452f68cb819a775a75f9 ]
The external PCF8563 RTC chip's interrupt line is connected to the NMI
line on the SoC.
Add the interrupt line to the device tree.
Fixes:
17ebc33afc35 ("arm64: allwinner: h6: add PCF8563 RTC on Pine H64 board")
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Fri, 21 Jun 2019 13:44:37 +0000 (21:44 +0800)]
net/sched: cbs: Fix error path of cbs_module_init
[ Upstream commit
45d5cb137c3638b3a310f41b31d8e79daf647f14 ]
If register_qdisc fails, we should unregister
netdevice notifier.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes:
e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabrizio Castro [Mon, 3 Jun 2019 09:53:51 +0000 (10:53 +0100)]
ARM: dts: iwg20d-q7-common: Fix SDHI1 VccQ regularor
[ Upstream commit
d211650a87edc7f4130651c0ccbc0a4583fd72d3 ]
SDR50 isn't working anymore because the GPIO regulator
driver is using descriptors since
commit
d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
which in turn causes the system to use the polarity of the
GPIOs (as specified in the DT) for selecting the states,
but the polarity specified in the DT is wrong.
This patch fixes the regulator DT definition, and that fixes
SDR50.
Fixes:
029efb3a03c5 ("ARM: dts: iwg20d-q7: Add SDHI1 support")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen-Yu Tsai [Tue, 4 Jun 2019 04:23:36 +0000 (12:23 +0800)]
rtc: pcf8563: Clear event flags and disable interrupts before requesting irq
[ Upstream commit
3572e8aea3bf925dac1dbf86127657c39fe5c254 ]
Besides the alarm, the PCF8563 also has a timer triggered interrupt.
In cases where the previous system left the timer and interrupts on,
or somehow the bits got enabled, the interrupt would keep triggering
as the kernel doesn't know about it.
Clear both the alarm and timer event flags, and disable the interrupts,
before requesting the interrupt line.
Fixes:
ede3e9d47cca ("drivers/rtc/rtc-pcf8563.c: add alarm support")
Fixes:
a45d528aab8b ("rtc: pcf8563: clear expired alarm at boot time")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen-Yu Tsai [Tue, 4 Jun 2019 04:23:35 +0000 (12:23 +0800)]
rtc: pcf8563: Fix interrupt trigger method
[ Upstream commit
65f662cbf829834fa4d94190eb7691e5a9cb92d8 ]
The PCF8563 datasheet says the interrupt line is active low and stays
active until the events are cleared, i.e. a level trigger interrupt.
Fix the flags used to request the interrupt.
Fixes:
ede3e9d47cca ("drivers/rtc/rtc-pcf8563.c: add alarm support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Ujfalusi [Thu, 20 Jun 2019 09:20:02 +0000 (12:20 +0300)]
ASoC: ti: davinci-mcasp: Fix slot mask settings when using multiple AXRs
[ Upstream commit
fd14f4436fd47d5418023c90e933e66d3645552e ]
If multiple serializers are connected in the system and the number of
channels will need to use more than one serializer the mask to enable the
serializers were left to 0 if tdm_mask is provided
Fixes:
dd55ff8346a97 ("ASoC: davinci-mcasp: Add set_tdm_slots() support")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Wiedmann [Tue, 18 Jun 2019 18:43:01 +0000 (20:43 +0200)]
net/af_iucv: always register net_device notifier
[ Upstream commit
06996c1d4088a0d5f3e7789d7f96b4653cc947cc ]
Even when running as VM guest (ie pr_iucv != NULL), af_iucv can still
open HiperTransport-based connections. For robust operation these
connections require the af_iucv_netdev_notifier, so register it
unconditionally.
Also handle any error that register_netdevice_notifier() returns.
Fixes:
9fbd87d41392 ("af_iucv: handle netdev events")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Wiedmann [Tue, 18 Jun 2019 18:43:00 +0000 (20:43 +0200)]
net/af_iucv: build proper skbs for HiperTransport
[ Upstream commit
238965b71b968dc5b3c0fe430e946f488322c4b5 ]
The HiperSockets-based transport path in af_iucv is still too closely
entangled with qeth.
With commit
a647a02512ca ("s390/qeth: speed-up L3 IQD xmit"), the
relevant xmit code in qeth has begun to use skb_cow_head(). So to avoid
unnecessary skb head expansions, af_iucv must learn to
1) respect dev->needed_headroom when allocating skbs, and
2) drop the header reference before cloning the skb.
While at it, also stop hard-coding the LL-header creation stage and just
use the appropriate helper.
Fixes:
a647a02512ca ("s390/qeth: speed-up L3 IQD xmit")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fred Klassen [Mon, 17 Jun 2019 19:05:07 +0000 (12:05 -0700)]
net/udp_gso: Allow TX timestamp with UDP GSO
[ Upstream commit
76e21533a48bb42d1fa894f93f6233bf4554f45e ]
Fixes an issue where TX Timestamps are not arriving on the error queue
when UDP_SEGMENT CMSG type is combined with CMSG type SO_TIMESTAMPING.
This can be illustrated with an updated updgso_bench_tx program which
includes the '-T' option to test for this condition. It also introduces
the '-P' option which will call poll() before reading the error queue.
./udpgso_bench_tx -4ucTPv -S 1472 -l2 -D 172.16.120.18
poll timeout
udp tx: 0 MB/s 1 calls/s 1 msg/s
The "poll timeout" message above indicates that TX timestamp never
arrived.
This patch preserves tx_flags for the first UDP GSO segment. Only the
first segment is timestamped, even though in some cases there may be
benefital in timestamping both the first and last segment.
Factors in deciding on first segment timestamp only:
- Timestamping both first and last segmented is not feasible. Hardware
can only have one outstanding TS request at a time.
- Timestamping last segment may under report network latency of the
previous segments. Even though the doorbell is suppressed, the ring
producer counter has been incremented.
- Timestamping the first segment has the upside in that it reports
timestamps from the application's view, e.g. RTT.
- Timestamping the first segment has the downside that it may
underreport tx host network latency. It appears that we have to pick
one or the other. And possibly follow-up with a config flag to choose
behavior.
v2: Remove tests as noted by Willem de Bruijn <willemb@google.com>
Moving tests from net to net-next
v3: Update only relevant tx_flag bits as per
Willem de Bruijn <willemb@google.com>
v4: Update comments and commit message as per
Willem de Bruijn <willemb@google.com>
Fixes:
ee80d1ebe5ba ("udp: add udp gso")
Signed-off-by: Fred Klassen <fklassen@appneta.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Mon, 17 Jun 2019 18:11:10 +0000 (11:11 -0700)]
net: netem: fix backlog accounting for corrupted GSO frames
[ Upstream commit
177b8007463c4f36c9a2c7ce7aa9875a4cad9bd5 ]
When GSO frame has to be corrupted netem uses skb_gso_segment()
to produce the list of frames, and re-enqueues the segments one
by one. The backlog length has to be adjusted to account for
new frames.
The current calculation is incorrect, leading to wrong backlog
lengths in the parent qdisc (both bytes and packets), and
incorrect packet backlog count in netem itself.
Parent backlog goes negative, netem's packet backlog counts
all non-first segments twice (thus remaining non-zero even
after qdisc is emptied).
Move the variables used to count the adjustment into local
scope to make 100% sure they aren't used at any stage in
backports.
Fixes:
6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeffrey Hugo [Tue, 21 May 2019 15:00:30 +0000 (08:00 -0700)]
drm/msm/mdp5: Fix mdp5_cfg_init error return
[ Upstream commit
fc19cbb785d7bbd1a1af26229b5240a3ab332744 ]
If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs. This is because the caller of init expects error
pointers, but init returns NULL on error. Fix this by returning the
expected values on error.
Fixes:
2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mike Marciniszyn [Fri, 14 Jun 2019 16:33:06 +0000 (12:33 -0400)]
IB/hfi1: Handle port down properly in pio
[ Upstream commit
942a899335707fc9cfc97cb382a60734b2ff4e03 ]
The call to sc_buffer_alloc currently returns NULL (no buffer) or
a buffer descriptor.
There is a third case when the port is down. Currently that
returns NULL and this prevents the caller from properly handling the
sc_buffer_alloc() failure. A verbs code link test after the call is
racy so the indication needs to come from the state check inside the allocation
routine to be valid.
Fix by encoding the ECOMM failure like SDMA. IS_ERR_OR_NULL() tests
are added at all call sites. For verbs send, this needs to treat any
error by returning a completion without any MMIO copy.
Fixes:
7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anton Protopopov [Sat, 15 Jun 2019 22:53:48 +0000 (22:53 +0000)]
bpf: fix the check that forwarding is enabled in bpf_ipv6_fib_lookup
[ Upstream commit
56f0f84e69c7a7f229dfa524b13b0ceb6ce9b09e ]
The bpf_ipv6_fib_lookup function should return BPF_FIB_LKUP_RET_FWD_DISABLED
when forwarding is disabled for the input device. However instead of checking
if forwarding is enabled on the input device, it checked the global
net->ipv6.devconf_all->forwarding flag. Change it to behave as expected.
Fixes:
87f5fc7e48dd ("bpf: Provide helper to do forwarding lookups in kernel FIB table")
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Lynch [Wed, 12 Jun 2019 04:45:06 +0000 (23:45 -0500)]
powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration
[ Upstream commit
e610a466d16a086e321f0bd421e2fc75cff28605 ]
It's common for the platform to replace the cache device nodes after a
migration. Since the cacheinfo code is never informed about this, it
never drops its references to the source system's cache nodes, causing
it to wind up in an inconsistent state resulting in warnings and oopses
as soon as CPU online/offline occurs after the migration, e.g.
cache for /cpus/l3-cache@3113(Unified) refers to cache for /cpus/l2-cache@200d(Unified)
WARNING: CPU: 15 PID: 86 at arch/powerpc/kernel/cacheinfo.c:176 release_cache+0x1bc/0x1d0
[...]
NIP release_cache+0x1bc/0x1d0
LR release_cache+0x1b8/0x1d0
Call Trace:
release_cache+0x1b8/0x1d0 (unreliable)
cacheinfo_cpu_offline+0x1c4/0x2c0
unregister_cpu_online+0x1b8/0x260
cpuhp_invoke_callback+0x114/0xf40
cpuhp_thread_fun+0x270/0x310
smpboot_thread_fn+0x2c8/0x390
kthread+0x1b8/0x1c0
ret_from_kernel_thread+0x5c/0x68
Using device tree notifiers won't work since we want to rebuild the
hierarchy only after all the removals and additions have occurred and
the device tree is in a consistent state. Call cacheinfo_teardown()
before processing device tree updates, and rebuild the hierarchy
afterward.
Fixes:
410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Lynch [Wed, 12 Jun 2019 04:45:04 +0000 (23:45 -0500)]
powerpc/cacheinfo: add cacheinfo_teardown, cacheinfo_rebuild
[ Upstream commit
d4aa219a074a5abaf95a756b9f0d190b5c03a945 ]
Allow external callers to force the cacheinfo code to release all its
references to cache nodes, e.g. before processing device tree updates
post-migration, and to rebuild the hierarchy afterward.
CPU online/offline must be blocked by callers; enforce this.
Fixes:
410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Kalderon [Thu, 13 Jun 2019 08:29:41 +0000 (11:29 +0300)]
qed: iWARP - fix uninitialized callback
[ Upstream commit
43cf40d93fadbb0d3edf0942a4612f8ff67478a1 ]
Fix uninitialized variable warning by static checker.
Fixes:
ae3488ff37dc ("qed: Add ll2 connection for processing unaligned MPA packets")
Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Kalderon [Thu, 13 Jun 2019 08:29:40 +0000 (11:29 +0300)]
qed: iWARP - Use READ_ONCE and smp_store_release to access ep->state
[ Upstream commit
6117561e1bb30b2fe7f51e1961f34dbedd0bec8a ]
Destroy QP waits for it's ep object state to be set to CLOSED
before proceeding. ep->state can be updated from a different
context. Add smp_store_release/READ_ONCE to synchronize.
Fixes:
fc4c6065e661 ("qed: iWARP implement disconnect flows")
Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Thu, 13 Jun 2019 11:42:31 +0000 (13:42 +0200)]
ASoC: meson: axg-tdmout: right_j is not supported
[ Upstream commit
7e0d7d0fbd06af0507611f85dba8daf24832abd9 ]
Right justified format is actually not supported by the amlogic tdm output
encoder.
Fixes:
c41c2a355b86 ("ASoC: meson: add tdm output driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Thu, 13 Jun 2019 11:42:30 +0000 (13:42 +0200)]
ASoC: meson: axg-tdmin: right_j is not supported
[ Upstream commit
47c317b786b6c1efc2cb3cdb894fd323422fe5ea ]
Right justified format is actually not supported by the amlogic tdm input
decoder.
Fixes:
13a22e6a98f8 ("ASoC: meson: add tdm input driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 25 Mar 2019 09:17:26 +0000 (12:17 +0300)]
ntb_hw_switchtec: potential shift wrapping bug in switchtec_ntb_init_sndev()
[ Upstream commit
ff148d8ac53e59802645bd3200c811620317eb9f ]
This code triggers a Smatch warning:
drivers/ntb/hw/mscc/ntb_hw_switchtec.c:884 switchtec_ntb_init_sndev()
warn: should '(1 << sndev->peer_partition)' be a 64 bit type?
The "part_map" and "tpart_vec" variables are u64 type so this seems like
a valid warning.
Fixes:
3df54c870f52 ("ntb_hw_switchtec: Allow using Switchtec NTB in multi-partition setups")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peng Fan [Wed, 22 May 2019 10:15:21 +0000 (10:15 +0000)]
firmware: arm_scmi: update rate_discrete in clock_describe_rates_get
[ Upstream commit
c0759b9b5d411ab27c479125cee9bae391a96436 ]
The boolean rate_discrete needs to be assigned to clk->rate_discrete,
so that clock driver can distinguish between the continuous range and
discrete rates. It uses this in scmi_clk_round_rate could get the
rounded value if it's a continuous range.
Fixes:
5f6c6430e904 ("firmware: arm_scmi: add initial support for clock protocol")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[sudeep.holla: updated commit message]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sudeep Holla [Tue, 14 May 2019 16:10:31 +0000 (17:10 +0100)]
firmware: arm_scmi: fix bitfield definitions for SENSOR_DESC attributes
[ Upstream commit
430daaf96ad133be5ce7c3a5c60e94247f7c6f71 ]
As per the SCMI specification the bitfields for SENSOR_DESC attributes
are as follows:
attributes_low [7:0] Number of trip points supported
attributes_high [15:11] The power-of-10 multiplier in 2's-complement
format that is applied to the sensor units
Looks like the code developed during the draft versions of the
specification slipped through and are wrong with respect to final
released version. Fix them by adjusting the bitfields appropriately.
Fixes:
5179c523c1ea ("firmware: arm_scmi: add initial support for sensor protocol")
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Wed, 22 May 2019 18:35:25 +0000 (11:35 -0700)]
phy: usb: phy-brcm-usb: Remove sysfs attributes upon driver removal
[ Upstream commit
d9e100829fca6cbd270d7e005b0c0bb2d14924b8 ]
We are not destroying the sysfs attribute groupe we registered during
the probe function which will make subsequent probe calls to that
driver fail. Correct that with adding a remove function which only
removes those attributes since the reference counting on clocks did its
job already.
Fixes:
415060b21f31 ("phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or device")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Auger [Mon, 3 Jun 2019 06:53:31 +0000 (08:53 +0200)]
iommu/vt-d: Duplicate iommu_resv_region objects per device list
[ Upstream commit
5f64ce5411b467f1cfea6c63e2494c22b773582b ]
intel_iommu_get_resv_regions() aims to return the list of
reserved regions accessible by a given @device. However several
devices can access the same reserved memory region and when
building the list it is not safe to use a single iommu_resv_region
object, whose container is the RMRR. This iommu_resv_region must
be duplicated per device reserved region list.
Let's remove the struct iommu_resv_region from the RMRR unit
and allocate the iommu_resv_region directly in
intel_iommu_get_resv_regions(). We hold the dmar_global_lock instead
of the rcu-lock to allow sleeping.
Fixes:
0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put callbacks")
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian Hewitt [Mon, 27 May 2019 13:21:52 +0000 (15:21 +0200)]
arm64: dts: meson-gxm-khadas-vim2: fix Bluetooth support
[ Upstream commit
33344e2111a3a07097a66f339ad213b047ccdfd2 ]
- Remove serial1 alias
- Add support for uart_A rts/cts
- Add bluetooth uart_A subnode qith shutdown gpio
Fixes:
b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2")
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian Hewitt [Mon, 27 May 2019 13:21:51 +0000 (15:21 +0200)]
arm64: dts: meson-gxm-khadas-vim2: fix gpio-keys-polled node
[ Upstream commit
0afd24c2fb61bd5163bab08ea1ee54d60d3ea37e ]
Fix DTC warnings:
meson-gxm-khadas-vim2.dtb: Warning (avoid_unnecessary_addr_size):
/gpio-keys-polled: unnecessary #address-cells/#size-cells
without "ranges" or child "reg" property
Fixes:
b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2")
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Borut Seljak [Fri, 7 Jun 2019 10:53:06 +0000 (12:53 +0200)]
serial: stm32: fix a recursive locking in stm32_config_rs485
[ Upstream commit
707aeea13a9c85520262e11899d86df3c4b48262 ]
Remove spin_lock_irqsave in stm32_config_rs485, it cause recursive locking.
Already locked in uart_set_rs485_config.
Fixes:
1bcda09d291081 ("serial: stm32: add support for RS485 hardware control mode")
Signed-off-by: Borut Seljak <borut.seljak@t-2.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
George Wilkie [Fri, 7 Jun 2019 10:49:41 +0000 (11:49 +0100)]
mpls: fix warning with multi-label encap
[ Upstream commit
2f3f7d1fa0d1039b24a55d127ed190f196fc3e79 ]
If you configure a route with multiple labels, e.g.
ip route add 10.10.3.0/24 encap mpls 16/100 via 10.10.2.2 dev ens4
A warning is logged:
kernel: [ 130.561819] netlink: 'ip': attribute type 1 has an invalid
length.
This happens because mpls_iptunnel_policy has set the type of
MPLS_IPTUNNEL_DST to fixed size NLA_U32.
Change it to a minimum size.
nla_get_labels() does the remaining validation.
Fixes:
e3e4712ec096 ("mpls: ip tunnel support")
Signed-off-by: George Wilkie <gwilkie@vyatta.att-mail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takeshi Kihara [Wed, 21 Nov 2018 16:08:08 +0000 (08:08 -0800)]
arm64: dts: renesas: ebisu: Remove renesas, no-ether-link property
[ Upstream commit
90d4fa39d028f2e46c57c3d0e1b759e5287d98b7 ]
It is incorrect to specify the no-ether-link property for the AVB device on
the Ebisu board. This is because the property should only be used when a
board does not provide a proper AVB_LINK signal. However, the Ebisu board
does provide this signal.
As per
87c059e9c39d ("arm64: dts: renesas: salvator-x: Remove renesas,
no-ether-link property") this fixes a bug:
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will have
impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since the
RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes:
8441ef643d7d ("arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB")
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[simon: updated changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Mon, 27 May 2019 14:51:02 +0000 (16:51 +0200)]
crypto: inside-secure - fix queued len computation
[ Upstream commit
ccd65a206a5025cf953a2e4f37e894921b131a5c ]
This patch fixes the queued len computation, which could theoretically
be wrong if req->len[1] - req->processed[1] > 1. Be future-proof here,
and fix it.
Fixes:
b460edb6230a ("crypto: inside-secure - sha512 support")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antoine Tenart [Mon, 27 May 2019 14:51:01 +0000 (16:51 +0200)]
crypto: inside-secure - fix zeroing of the request in ahash_exit_inv
[ Upstream commit
b926213d6fede9c9427d7c12eaf7d9f0895deb4e ]
A request is zeroed in safexcel_ahash_exit_inv(). This request total
size is EIP197_AHASH_REQ_SIZE while the memset zeroing it uses
sizeof(struct ahash_request), which happens to be less than
EIP197_AHASH_REQ_SIZE. This patch fixes it.
Fixes:
f6beaea30487 ("crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) support")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Tue, 4 Jun 2019 14:55:15 +0000 (10:55 -0400)]
media: vivid: fix incorrect assignment operation when setting video mode
[ Upstream commit
d4ec9550e4b2d2e357a46fdc65d8ef3d4d15984c ]
The assigment of FB_VMODE_NONINTERLACE to var->vmode should be a
bit-wise or of FB_VMODE_NONINTERLACE instead of an assignment,
otherwise the previous clearing of the FB_VMODE_MASK bits of
var->vmode makes no sense and is redundant.
Addresses-Coverity: ("Unused value")
Fixes:
ad4e02d5081d ("[media] vivid: add a simple framebuffer device for overlay testing")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ondrej Jirman [Tue, 4 Jun 2019 15:40:36 +0000 (17:40 +0200)]
clk: sunxi-ng: sun50i-h6-r: Fix incorrect W1 clock gate register
[ Upstream commit
f167675486c37b88620d344fbb12d06e34f11d47 ]
The current code defines W1 clock gate to be at 0x1cc, overlaying it
with the IR gate.
Clock gate for r-apb1-w1 is at 0x1ec. This fixes issues with IR receiver
causing interrupt floods on H6 (because interrupt flags can't be cleared,
due to IR module's bus being disabled).
Fixes:
b7c7b05065aa77ae ("clk: sunxi-ng: add support for H6 PRCM CCU")
Signed-off-by: Ondrej Jirman <megous@megous.com>
Acked-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Wed, 22 May 2019 18:45:47 +0000 (11:45 -0700)]
cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency
[ Upstream commit
4c5681fcc684c762b09435de3e82ffeee7769d21 ]
What we read back from the register is going to be capped at 32-bits,
and cpufreq_freq_table.frequency is an unsigned int. Avoid any possible
value truncation by using the appropriate return value.
Fixes:
de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Wed, 22 May 2019 18:45:46 +0000 (11:45 -0700)]
cpufreq: brcmstb-avs-cpufreq: Fix initial command check
[ Upstream commit
22a26cc6a51ef73dcfeb64c50513903f6b2d53d8 ]
There is a logical error in brcm_avs_is_firmware_loaded() whereby if the
firmware returns -EINVAL, we will be reporting this as an error. The
comment is correct, the code was not.
Fixes:
de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Fri, 31 May 2019 12:05:59 +0000 (13:05 +0100)]
phy: qcom-qusb2: fix missing assignment of ret when calling clk_prepare_enable
[ Upstream commit
d98010817a26eba8d4d1e8a639e0b7d7f042308a ]
The error return from the call to clk_prepare_enable is not being assigned
to variable ret even though ret is being used to check if the call failed.
Fix this by adding in the missing assignment.
Addresses-Coverity: ("Logically dead code")
Fixes:
891a96f65ac3 ("phy: qcom-qusb2: Add support for runtime PM")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Wed, 29 May 2019 23:33:23 +0000 (16:33 -0700)]
net: don't clear sock->sk early to avoid trouble in strparser
[ Upstream commit
2b81f8161dfeda4017cef4f2498ccb64b13f0d61 ]
af_inet sets sock->sk to NULL which trips strparser over:
BUG: kernel NULL pointer dereference, address:
0000000000000012
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 0 Comm: swapper/7 Not tainted
5.2.0-rc1-00139-g14629453a6d3 #21
RIP: 0010:tcp_peek_len+0x10/0x60
RSP: 0018:
ffffc02e41c54b98 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff9cf924c4e030 RCX:
0000000000000051
RDX:
0000000000000000 RSI:
000000000000000c RDI:
ffff9cf97128f480
RBP:
ffff9cf9365e0300 R08:
ffff9cf94fe7d2c0 R09:
0000000000000000
R10:
000000000000036b R11:
ffff9cf939735e00 R12:
ffff9cf91ad9ae40
R13:
ffff9cf924c4e000 R14:
ffff9cf9a8fcbaae R15:
0000000000000020
FS:
0000000000000000(0000) GS:
ffff9cf9af7c0000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000012 CR3:
000000013920a003 CR4:
00000000003606e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
<IRQ>
strp_data_ready+0x48/0x90
tls_data_ready+0x22/0xd0 [tls]
tcp_rcv_established+0x569/0x620
tcp_v4_do_rcv+0x127/0x1e0
tcp_v4_rcv+0xad7/0xbf0
ip_protocol_deliver_rcu+0x2c/0x1c0
ip_local_deliver_finish+0x41/0x50
ip_local_deliver+0x6b/0xe0
? ip_protocol_deliver_rcu+0x1c0/0x1c0
ip_rcv+0x52/0xd0
? ip_rcv_finish_core.isra.20+0x380/0x380
__netif_receive_skb_one_core+0x7e/0x90
netif_receive_skb_internal+0x42/0xf0
napi_gro_receive+0xed/0x150
nfp_net_poll+0x7a2/0xd30 [nfp]
? kmem_cache_free_bulk+0x286/0x310
net_rx_action+0x149/0x3b0
__do_softirq+0xe3/0x30a
? handle_irq_event_percpu+0x6a/0x80
irq_exit+0xe8/0xf0
do_IRQ+0x85/0xd0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0010:cpuidle_enter_state+0xbc/0x450
To avoid this issue set sock->sk after sk_prot->close.
My grepping and testing did not discover any code which
would depend on the current behaviour.
Fixes:
c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 30 May 2019 08:20:24 +0000 (11:20 +0300)]
RDMA/uverbs: check for allocation failure in uapi_add_elm()
[ Upstream commit
cac2a301c02a9b178842e22df34217da7854e588 ]
If the kzalloc() fails then we should return ERR_PTR(-ENOMEM). In the
current code it's possible that the kzalloc() fails and the
radix_tree_insert() inserts the NULL pointer successfully and we return
the NULL "elm" pointer to the caller. That results in a NULL pointer
dereference.
Fixes:
9ed3e5f44772 ("IB/uverbs: Build the specs into a radix tree at runtime")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Hemminger [Tue, 28 May 2019 18:47:31 +0000 (11:47 -0700)]
net: core: support XDP generic on stacked devices.
[ Upstream commit
458bf2f224f04a513b0be972f8708e78ee2c986e ]
When a device is stacked like (team, bonding, failsafe or netvsc) the
XDP generic program for the parent device was not called.
Move the call to XDP generic inside __netif_receive_skb_core where
it can be done multiple times for stacked case.
Fixes:
d445516966dc ("net: xdp: support xdp generic on virtual devices")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Hemminger [Tue, 28 May 2019 18:47:30 +0000 (11:47 -0700)]
netvsc: unshare skb in VF rx handler
[ Upstream commit
996ed04741467f6d1552440c92988b132a9487ec ]
The netvsc VF skb handler should make sure that skb is not
shared. Similar logic already exists in bonding and team device
drivers.
This is not an issue in practice because the VF devicex
does not send up shared skb's. But the netvsc driver
should do the right thing if it did.
Fixes:
0c195567a8f6 ("netvsc: transparent VF management")
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Tue, 21 May 2019 13:34:19 +0000 (13:34 +0000)]
crypto: talitos - fix AEAD processing.
[ Upstream commit
e345177ded17611e36c067751d63d64bf106cb54 ]
This driver is working well in 'simple cases', but as soon as
more exotic SG lists are provided (dst different from src,
auth part not in a single SG fragment, ...) there are
wrong results, overruns, etc ...
This patch cleans up the AEAD processing by:
- Simplifying the location of 'out of line' ICV
- Never using 'out of line' ICV on encryp
- Always using 'out of line' ICV on decrypt
- Forcing the generation of a SG table on decrypt
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Fixes:
aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Huazhong Tan [Tue, 28 May 2019 09:03:02 +0000 (17:03 +0800)]
net: hns3: fix a memory leak issue for hclge_map_unmap_ring_to_vf_vector
[ Upstream commit
49f971bd308571fe466687227130a7082b662d0e ]
When hclge_bind_ring_with_vector() fails,
hclge_map_unmap_ring_to_vf_vector() returns the error
directly, so nobody will free the memory allocated by
hclge_get_ring_chain_from_mbx().
So hclge_free_vector_ring_chain() should be called no matter
hclge_bind_ring_with_vector() fails or not.
Fixes:
84e095d64ed9 ("net: hns3: Change PF to add ring-vect binding & resetQ to mailbox")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Mon, 27 May 2019 23:56:48 +0000 (16:56 -0700)]
inet: frags: call inet_frags_fini() after unregister_pernet_subsys()
[ Upstream commit
ae7352d384a552d8c799c242e74a934809990a71 ]
Both IPv6 and 6lowpan are calling inet_frags_fini() too soon.
inet_frags_fini() is dismantling a kmem_cache, that might be needed
later when unregister_pernet_subsys() eventually has to remove
frags queues from hash tables and free them.
This fixes potential use-after-free, and is a prereq for the following patch.
Fixes:
d4ad4d22e7ac ("inet: frags: use kmem_cache for inet_frag_queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric W. Biederman [Wed, 15 May 2019 17:33:50 +0000 (12:33 -0500)]
signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig
[ Upstream commit
72abe3bcf0911d69b46c1e8bdb5612675e0ac42c ]
The locking in force_sig_info is not prepared to deal with a task that
exits or execs (as sighand may change). The is not a locking problem
in force_sig as force_sig is only built to handle synchronous
exceptions.
Further the function force_sig_info changes the signal state if the
signal is ignored, or blocked or if SIGNAL_UNKILLABLE will prevent the
delivery of the signal. The signal SIGKILL can not be ignored and can
not be blocked and SIGNAL_UNKILLABLE won't prevent it from being
delivered.
So using force_sig rather than send_sig for SIGKILL is confusing
and pointless.
Because it won't impact the sending of the signal and and because
using force_sig is wrong, replace force_sig with send_sig.
Cc: Namjae Jeon <namjae.jeon@samsung.com>
Cc: Jeff Layton <jlayton@primarydata.com>
Cc: Steve French <smfrench@gmail.com>
Fixes:
a5c3e1c725af ("Revert "cifs: No need to send SIGKILL to demux_thread during umount"")
Fixes:
e7ddee9037e7 ("cifs: disable sharing session and tcon and add new TCP sharing code")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric W. Biederman [Wed, 15 May 2019 17:23:03 +0000 (12:23 -0500)]
signal/bpfilter: Fix bpfilter_kernl to use send_sig not force_sig
[ Upstream commit
1dfd1711de2952fd1bfeea7152bd1687a4eea771 ]
The locking in force_sig_info is not prepared to deal with
a task that exits or execs (as sighand may change). As force_sig
is only built to handle synchronous exceptions.
Further the function force_sig_info changes the signal state if the
signal is ignored, or blocked or if SIGNAL_UNKILLABLE will prevent the
delivery of the signal. The signal SIGKILL can not be ignored and can
not be blocked and SIGNAL_UNKILLABLE won't prevent it from being
delivered.
So using force_sig rather than send_sig for SIGKILL is pointless.
Because it won't impact the sending of the signal and and because
using force_sig is wrong, replace force_sig with send_sig.
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Fixes:
d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Baolu [Tue, 21 May 2019 07:27:35 +0000 (15:27 +0800)]
iommu: Use right function to get group for device
[ Upstream commit
57274ea25736496ee019a5c40479855b21888839 ]
The iommu_group_get_for_dev() will allocate a group for a
device if it isn't in any group. This isn't the use case
in iommu_request_dm_for_dev(). Let's use iommu_group_get()
instead.
Fixes:
d290f1e70d85a ("iommu: Introduce iommu_request_dm_for_dev()")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Baolu [Fri, 24 May 2019 06:30:56 +0000 (14:30 +0800)]
iommu: Add missing new line for dma type
[ Upstream commit
24f307d8abf79486dd3c1b645037df7d91602aaa ]
So that all types are printed in the same format.
Fixes:
c52c72d3dee81 ("iommu: Add sysfs attribyte for domain type")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Fri, 24 May 2019 16:15:17 +0000 (09:15 -0700)]
misc: sgi-xp: Properly initialize buf in xpc_get_rsvd_page_pa
[ Upstream commit
b0576f9ecb5c51e9932531d23c447b2739261841 ]
Clang warns:
drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is
uninitialized when used within its own initialization [-Wuninitialized]
void *buf = buf;
~~~ ^~~
1 warning generated.
Arnd's explanation during review:
/*
* Returns the physical address of the partition's reserved page through
* an iterative number of calls.
*
* On first call, 'cookie' and 'len' should be set to 0, and 'addr'
* set to the nasid of the partition whose reserved page's address is
* being sought.
* On subsequent calls, pass the values, that were passed back on the
* previous call.
*
* While the return status equals SALRET_MORE_PASSES, keep calling
* this function after first copying 'len' bytes starting at 'addr'
* into 'buf'. Once the return status equals SALRET_OK, 'addr' will
* be the physical address of the partition's reserved page. If the
* return status equals neither of these, an error as occurred.
*/
static inline s64
sn_partition_reserved_page_pa(u64 buf, u64 *cookie, u64 *addr, u64 *len)
so *len is set to zero on the first call and tells the bios how many
bytes are accessible at 'buf', and it does get updated by the BIOS to
tell us how many bytes it needs, and then we allocate that and try again.
Fixes:
279290294662 ("[IA64-SGI] cleanup the way XPC locates the reserved page")
Link: https://github.com/ClangBuiltLinux/linux/issues/466
Suggested-by: Stephen Hines <srhines@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:46 +0000 (17:45 +0200)]
serial: stm32: fix wakeup source initialization
[ Upstream commit
5297f274e8b61ceb9676cba6649d3de9d03387ad ]
Fixes dedicated_irq_wakeup issue and deactivated uart as wakeup source by
default.
Fixes:
270e5a74fe4c ("serial: stm32: add wakeup mechanism")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:45 +0000 (17:45 +0200)]
serial: stm32: Add support of TC bit status check
[ Upstream commit
64c32eab660386f9904bb295a104c9c425e9f8b2 ]
Adds a check on the Transmission Complete bit status before closing the
com port. Prevents the port closure before the end of the transmission.
TC poll loop is moved from stm32_tx_dma_complete to stm32_shutdown
routine, in order to check TC before shutdown in both dma and
PIO tx modes.
TC clear is added in stm32_transmit_char routine, in order to be cleared
before transmitting in both dma and PIO tx modes.
Fixes:
3489187204eb ("serial: stm32: adding dma support")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:44 +0000 (17:45 +0200)]
serial: stm32: fix transmit_chars when tx is stopped
[ Upstream commit
b83b957c91f68e53f0dc596e129e8305761f2a32 ]
Disables the tx irq when the transmission is ended and updates stop_tx
conditions for code cleanup.
Fixes:
48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:43 +0000 (17:45 +0200)]
serial: stm32: fix rx data length when parity enabled
[ Upstream commit
6c5962f30bce147b1c83869085f3ddde3b34c9e3 ]
- Fixes a rx data error when data length < 8 bits and parity is enabled.
RDR register MSB is used for parity bit reception.
- Adds a mask to ignore MSB when data is get from RDR.
Fixes:
3489187204eb ("serial: stm32: adding dma support")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:42 +0000 (17:45 +0200)]
serial: stm32: fix rx error handling
[ Upstream commit
4f01d833fdcdd6f9b85d9e5d5d7568eb683626a7 ]
- Fixes parity and framing error bit by clearing parity and framing error
flag. The current implementation doesn't clear the error bits when an
error is detected.
- Fixes the incorrect name of framing error clearing flag in header file.
- Fixes misalignement between data frame and errors status. The status
read for "n" frame was the status of "n+1" frame".
- Fixes break detection was not triggered by the expected register.
Fixes:
48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erwan Le Ray [Tue, 21 May 2019 15:45:41 +0000 (17:45 +0200)]
serial: stm32: fix word length configuration
[ Upstream commit
c8a9d043947b4acb19a65f7fac2bd0893e581cd5 ]
STM32 supports either:
- 8 and 9 bits word length (including parity bit) for stm32f4 compatible
devices
- 7, 8 and 9 bits word length (including parity bit) for stm32f7 and
stm32h7 compatible devices.
As a consequence STM32 supports the following termios configurations:
- CS7 with parity bit, and CS8 (with or without parity bit) for stm32f4
compatible devices.
- CS6 with parity bit, CS7 and CS8 (with or without parity bit) for
stm32f7 and stm32h7 compatible devices.
This patch is fixing word length by configuring correctly the SoC with
supported configurations.
Fixes:
ada8618ff3bf ("serial: stm32: adding support for stm32f7")
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hook, Gary [Tue, 14 May 2019 21:53:30 +0000 (21:53 +0000)]
crypto: ccp - Fix 3DES complaint from ccp-crypto module
[ Upstream commit
89646fdda4cae203185444ac7988835f36a21ee1 ]
Crypto self-tests reveal an error:
alg: skcipher: cbc-des3-ccp encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
The offset value should not be recomputed when retrieving the context.
Also, a code path exists which makes decisions based on older (version 3)
hardware; a v3 device deosn't support 3DES so remove this check.
Fixes:
990672d48515 ('crypto: ccp - Enable 3DES function on v5 CCPs')
Signed-off-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hook, Gary [Tue, 14 May 2019 21:53:23 +0000 (21:53 +0000)]
crypto: ccp - fix AES CFB error exposed by new test vectors
[ Upstream commit
c3b359d6567c0b8f413e924feb37cf025067d55a ]
Updated testmgr will exhibit this error message when loading the
ccp-crypto module:
alg: skcipher: cfb-aes-ccp encryption failed with err -22 on test vector 3, cfg="in-place"
Update the CCP crypto driver to correctly treat CFB as a streaming mode
cipher (instead of block mode). Update the configuration for CFB to
specify the block size as a single byte;
Fixes:
2b789435d7f3 ('crypto: ccp - CCP AES crypto API support')
Signed-off-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Wed, 22 May 2019 11:00:36 +0000 (11:00 +0000)]
spi: spi-fsl-spi: call spi_finalize_current_message() at the end
[ Upstream commit
44a042182cb1e9f7916e015c836967bf638b33c4 ]
spi_finalize_current_message() shall be called once all
actions are finished, otherwise the last actions might
step over a newly started transfer.
Fixes:
c592becbe704 ("spi: fsl-(e)spi: migrate to generic master queueing")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sagiv Ozeri [Mon, 20 May 2019 09:33:20 +0000 (12:33 +0300)]
RDMA/qedr: Fix incorrect device rate.
[ Upstream commit
69054666df0a9b4e8331319f98b6b9a88bc3fcc4 ]
Use the correct enum value introduced in commit
12113a35ada6 ("IB/core:
Add HDR speed enum") Prior to this change a 50Gbps port would show 40Gbps.
This patch also cleaned up the redundant redefiniton of ib speeds for
qedr.
Fixes:
12113a35ada6 ("IB/core: Add HDR speed enum")
Signed-off-by: Sagiv Ozeri <sagiv.ozeri@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Thu, 18 Apr 2019 12:27:09 +0000 (14:27 +0200)]
arm64: dts: meson: libretech-cc: set eMMC as removable
[ Upstream commit
9f72e321d5506fe3e162a6308a4a295d7f10bb5d ]
The eMMC on this board is add-on module which is not mandatory. Removing
'non-removable' property should prevent some errors when booting a board
w/o an eMMC module present.
Fixes:
72fb2c852188 ("ARM64: dts: meson-gxl-s905x-libretech-cc: fixup board definition")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Martin Blumenstingl<martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jon Hunter [Thu, 16 May 2019 15:53:52 +0000 (16:53 +0100)]
dmaengine: tegra210-adma: Fix crash during probe
[ Upstream commit
b53611fb1ce9b1786bd18205473e0c1d6bfa8934 ]
Commit
f33e7bb3eb92 ("dmaengine: tegra210-adma: restore channel status")
added support to save and restore the DMA channel registers when runtime
suspending the ADMA. This change is causing the kernel to crash when
probing the ADMA, if the device is probed deferred when looking up the
channel interrupts. The crash occurs because not all of the channel base
addresses have been setup at this point and in the clean-up path of the
probe, pm_runtime_suspend() is called invoking its callback which
expects all the channel base addresses to be initialised.
Although this could be fixed by simply checking for a NULL address, on
further review of the driver it seems more appropriate that we only call
pm_runtime_get_sync() after all the channel interrupts and base
addresses have been configured. Therefore, fix this crash by moving the
calls to pm_runtime_enable(), pm_runtime_get_sync() and
tegra_adma_init() after the DMA channels have been initialised.
Fixes:
f33e7bb3eb92 ("dmaengine: tegra210-adma: restore channel status")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Mon, 13 May 2019 12:31:11 +0000 (14:31 +0200)]
clk: meson: axg: spread spectrum is on mpll2
[ Upstream commit
dc4e62d373f881cbf51513296a6db7806516a01a ]
After testing, it appears that the SSEN bit controls the spread
spectrum function on MPLL2, not MPLL0.
Fixes:
78b4af312f91 ("clk: meson-axg: add clock controller drivers")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerome Brunet [Mon, 13 May 2019 12:31:10 +0000 (14:31 +0200)]
clk: meson: gxbb: no spread spectrum on mpll0
[ Upstream commit
8925dbd03bb29b1b0de30ac4e02c18faf8ddc9db ]
The documentation says there is an SSEN bit on mpll0 but, after testing
it, no spread spectrum function appears to be enabled by this bit on any
of the MPLLs.
Let's remove it until we know more
Fixes:
1f737ffa13ef ("clk: meson: mpll: fix mpll0 fractional part ignored")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jernej Skrabec [Sat, 18 May 2019 15:40:14 +0000 (17:40 +0200)]
ARM: dts: sun8i-h3: Fix wifi in Beelink X2 DT
[ Upstream commit
ca0961011db57e39880df0b5708df8aa3339dc6f ]
mmc1 node where wifi module is connected doesn't have properly defined
power supplies so wifi module is never powered up. Fix that by
specifying additional power supplies.
Additionally, this STB may have either Realtek or Broadcom based wifi
module. One based on Broadcom module also needs external clock to work
properly. Fix that by adding clock property to wifi_pwrseq node.
Fixes:
e582b47a9252 ("ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Fri, 10 May 2019 22:14:41 +0000 (23:14 +0100)]
afs: Fix double inc of vnode->cb_break
[ Upstream commit
fd711586bb7d63f257da5eff234e68c446ac35ea ]
When __afs_break_callback() clears the CB_PROMISED flag, it increments
vnode->cb_break to trigger a future refetch of the status and callback -
however it also calls afs_clear_permits(), which also increments
vnode->cb_break.
Fix this by removing the increment from afs_clear_permits().
Whilst we're at it, fix the conditional call to afs_put_permits() as the
function checks to see if the argument is NULL, so the check is redundant.
Fixes:
be080a6f43c4 ("afs: Overhaul permit caching");
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Fri, 10 May 2019 22:03:31 +0000 (23:03 +0100)]
afs: Fix lock-wait/callback-break double locking
[ Upstream commit
c7226e407b6065d3bda8bd9dc627663d2c505ea3 ]
__afs_break_callback() holds vnode->lock around its call of
afs_lock_may_be_available() - which also takes that lock.
Fix this by not taking the lock in __afs_break_callback().
Also, there's no point checking the granted_locks and pending_locks queues;
it's sufficient to check lock_state, so move that check out of
afs_lock_may_be_available() into __afs_break_callback() to replace the
queue checks.
Fixes:
e8d6c554126b ("AFS: implement file locking")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Tue, 14 May 2019 10:52:03 +0000 (11:52 +0100)]
afs: Don't invalidate callback if AFS_VNODE_DIR_VALID not set
[ Upstream commit
d9052dda8a39069312218f913d22d99c48d90004 ]
Don't invalidate the callback promise on a directory if the
AFS_VNODE_DIR_VALID flag is not set (which indicates that the directory
contents are invalid, due to edit failure, callback break, page reclaim).
The directory will be reloaded next time the directory is accessed, so
clearing the callback flag at this point may race with a reload of the
directory and cancel it's recorded callback promise.
Fixes:
f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Wed, 15 May 2019 11:09:17 +0000 (12:09 +0100)]
afs: Fix key leak in afs_release() and afs_evict_inode()
[ Upstream commit
a1b879eefc2b34cd3f17187ef6fc1cf3960e9518 ]
Fix afs_release() to go through the cleanup part of the function if
FMODE_WRITE is set rather than exiting through vfs_fsync() (which skips the
cleanup). The cleanup involves discarding the refs on the key used for
file ops and the writeback key record.
Also fix afs_evict_inode() to clean up any left over wb keys attached to
the inode/vnode when it is removed.
Fixes:
5a8132761609 ("afs: Do better accretion of small writes on newly created content")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Richter [Tue, 14 May 2019 10:49:09 +0000 (10:49 +0000)]
EDAC/mc: Fix edac_mc_find() in case no device is found
[ Upstream commit
29a0c843973bc385918158c6976e4dbe891df969 ]
The function should return NULL in case no device is found, but it
always returns the last checked mc device from the list even if the
index did not match. Fix that.
I did some analysis why this did not raise any issues for about 3 years
and the reason is that edac_mc_find() is mostly used to search for
existing devices. Thus, the bug is not triggered.
[ bp: Drop the if (mci->mc_idx > idx) test in favor of readability. ]
Fixes:
c73e8833bec5 ("EDAC, mc: Fix locking around mc_devices list")
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Link: https://lkml.kernel.org/r/20190514104838.15065-1-rrichter@marvell.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Kaehlcke [Thu, 2 May 2019 18:32:38 +0000 (11:32 -0700)]
thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
[ Upstream commit
bf45ac18b78038e43af3c1a273cae4ab5704d2ce ]
The CPU load values passed to the thermal_power_cpu_get_power
tracepoint are zero for all CPUs, unless, unless the
thermal_power_cpu_limit tracepoint is enabled too:
irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
cpus=
0000000f freq=
1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
vs
irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
cpus=
0000000f freq=
1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
cpus=
0000000f freq=408000 cdev_state=10 power=416
There seems to be no good reason for omitting the CPU load information
depending on another tracepoint. My guess is that the intention was to
check whether thermal_power_cpu_get_power is (still) enabled, however
'load_cpu != NULL' already indicates that it was at least enabled when
cpufreq_get_requested_power() was entered, there seems little gain
from omitting the assignment if the tracepoint was just disabled, so
just remove the check.
Fixes:
6828a4711f99 ("thermal: add trace events to the power allocator governor")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Javi Merino <javi.merino@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiada Wang [Wed, 24 Apr 2019 05:11:44 +0000 (14:11 +0900)]
thermal: rcar_gen3_thermal: fix interrupt type
[ Upstream commit
2c0928c9e004589dc9e7672c40a38d6c4ca12701 ]
Currently IRQF_SHARED type interrupt line is allocated, but it
is not appropriate, as the interrupt line isn't shared between
different devices, instead IRQF_ONESHOT is the proper type.
By changing interrupt type to IRQF_ONESHOT, now irq handler is
no longer needed, as clear of interrupt status can be done in
threaded interrupt context.
Because IRQF_ONESHOT type interrupt line is kept disabled until
the threaded handler has been run, so there is no need to protect
read/write of REG_GEN3_IRQSTR with lock.
Fixes:
7d4b269776ec6 ("enable hardware interrupts for trip points")
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brian Masney [Wed, 24 Apr 2019 09:25:03 +0000 (05:25 -0400)]
backlight: lm3630a: Return 0 on success in update_status functions
[ Upstream commit
d3f48ec0954c6aac736ab21c34a35d7554409112 ]
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Fixes:
28e64a68a2ef ("backlight: lm3630: apply chip revision")
Signed-off-by: Brian Masney <masneyb@onstation.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Westphal [Sun, 12 May 2019 18:42:37 +0000 (20:42 +0200)]
netfilter: nf_tables: correct NFT_LOGLEVEL_MAX value
[ Upstream commit
92285a079eedfe104a773a7c4293f77a01f456fb ]
should be same as NFT_LOGLEVEL_AUDIT, so use -, not +.
Fixes:
7eced5ab5a73 ("netfilter: nf_tables: add NFT_LOGLEVEL_* enumeration and use it")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 6 May 2019 12:50:18 +0000 (15:50 +0300)]
kdb: do a sanity check on the cpu in kdb_per_cpu()
[ Upstream commit
b586627e10f57ee3aa8f0cfab0d6f7dc4ae63760 ]
The "whichcpu" comes from argv[3]. The cpu_online() macro looks up the
cpu in a bitmap of online cpus, but if the value is too high then it
could read beyond the end of the bitmap and possibly Oops.
Fixes:
5d5314d6795f ("kdb: core for kgdb back end (1 of 2)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiong Wang [Tue, 7 May 2019 16:41:30 +0000 (17:41 +0100)]
nfp: bpf: fix static check error through tightening shift amount adjustment
[ Upstream commit
69e168ebdcfcb87ce7252d4857d570f99996fa27 ]
NFP shift instruction has something special. If shift direction is left
then shift amount of 1 to 31 is specified as 32 minus the amount to shift.
But no need to do this for indirect shift which has shift amount be 0. Even
after we do this subtraction, shift amount 0 will be turned into 32 which
will eventually be encoded the same as 0 because only low 5 bits are
encoded, but shift amount be 32 will fail the FIELD_PREP check done later
on shift mask (0x1f), due to 32 is out of mask range. Such error has been
observed when compiling nfp/bpf/jit.c using gcc 8.3 + O3.
This issue has started when indirect shift support added after which the
incoming shift amount to __emit_shf could be 0, therefore it is at that
time shift amount adjustment inside __emit_shf should have been tightened.
Fixes:
991f5b3651f6 ("nfp: bpf: support logic indirect shifts (BPF_[L|R]SH | BPF_X)")
Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Reported-by: Pablo Cascón <pablo.cascon@netronome.com
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Russell King [Sat, 27 Apr 2019 21:43:49 +0000 (22:43 +0100)]
ARM: riscpc: fix lack of keyboard interrupts after irq conversion
[ Upstream commit
63a0666bca9311f35017be454587f3ba903644b8 ]
Fix lack of keyboard interrupts for RiscPC due to incorrect conversion.
Fixes:
e8d36d5dbb6a ("ARM: kill off set_irq_flags usage")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bichao Zheng [Mon, 1 Apr 2019 18:18:17 +0000 (20:18 +0200)]
pwm: meson: Don't disable PWM when setting duty repeatedly
[ Upstream commit
a279345807e1e0ae79567a52cfdd9d30c9174a3c ]
There is an abnormally low about 20ms,when setting duty repeatedly.
Because setting the duty will disable PWM and then enable. Delete
this operation now.
Fixes:
211ed630753d2f ("pwm: Add support for Meson PWM Controller")
Signed-off-by: Bichao Zheng <bichao.zheng@amlogic.com>
[ Dropped code instead of hiding it behind a comment ]
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Mon, 1 Apr 2019 18:18:16 +0000 (20:18 +0200)]
pwm: meson: Consider 128 a valid pre-divider
[ Upstream commit
51496e4446875726d50a5617a6e0e0dabbc2e6da ]
The pre-divider allows configuring longer PWM periods compared to using
the input clock directly. The pre-divider is 7 bit wide, meaning it's
maximum value is 128 (the register value is off-by-one: 0x7f or 127).
Change the loop to also allow for the maximum possible value to be
considered valid.
Fixes:
211ed630753d2f ("pwm: Add support for Meson PWM Controller")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Westphal [Sun, 5 May 2019 16:47:33 +0000 (18:47 +0200)]
netfilter: ebtables: CONFIG_COMPAT: reject trailing data after last rule
[ Upstream commit
680f6af5337c98d116e4f127cea7845339dba8da ]
If userspace provides a rule blob with trailing data after last target,
we trigger a splat, then convert ruleset to 64bit format (with trailing
data), then pass that to do_replace_finish() which then returns -EINVAL.
Erroring out right away avoids the splat plus unneeded translation and
error unwind.
Fixes:
81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support")
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Iuliana Prodan [Tue, 7 May 2019 13:37:03 +0000 (16:37 +0300)]
crypto: caam - fix caam_dump_sg that iterates through scatterlist
[ Upstream commit
8c65d35435e8cbfdf953cafe5ebe3648ee9276a2 ]
Fix caam_dump_sg by correctly determining the next scatterlist
entry in the list.
Fixes:
5ecf8ef9103c ("crypto: caam - fix sg dump")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 24 Apr 2019 09:44:18 +0000 (12:44 +0300)]
platform/x86: alienware-wmi: printing the wrong error code
[ Upstream commit
6d1f8b3d75419a8659ac916a1e9543bb3513a882 ]
The "out_data" variable is uninitialized at the point. Originally, this
used to print "status" instead and that seems like the correct thing to
print.
Fixes:
bc2ef884320b ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 24 Apr 2019 09:46:27 +0000 (05:46 -0400)]
media: davinci/vpbe: array underflow in vpbe_enum_outputs()
[ Upstream commit
b72845ee5577b227131b1fef23f9d9a296621d7b ]
In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but
the problem is that "temp_index" can be negative. This patch changes
the types to unsigned to address this array underflow bug.
Fixes:
66715cdc3224 ("[media] davinci vpbe: VPBE display driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 11 Apr 2019 09:01:57 +0000 (05:01 -0400)]
media: omap_vout: potential buffer overflow in vidioc_dqbuf()
[ Upstream commit
dd6e2a981bfe83aa4a493143fd8cf1edcda6c091 ]
The "b->index" is a u32 the comes from the user in the ioctl. It hasn't
been checked. We aren't supposed to use it but we're instead supposed
to use the value that gets written to it when we call videobuf_dqbuf().
The videobuf_dqbuf() first memsets it to zero and then re-initializes it
inside the videobuf_status() function. It's this final value which we
want.
Hans Verkuil pointed out that we need to check the return from
videobuf_dqbuf(). I ended up doing a little cleanup related to that as
well.
Fixes:
72915e851da9 ("[media] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Wed, 8 May 2019 12:45:38 +0000 (14:45 +0200)]
ALSA: aica: Fix a long-time build breakage
[ Upstream commit
534420c6ff87d3052540f1fd346e0adcff440819 ]
The build of aica sound driver has been broken since the timer API
conversion and some code rewrite. This patch fixes the breakage by
using the common substream field, as well as a bit cleaning up wrt the
timer handling in the code.
Fixes:
d522bb6a105f ("ALSA: sh: aica: Convert timers to use timer_setup()")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Mon, 6 May 2019 14:44:04 +0000 (22:44 +0800)]
l2tp: Fix possible NULL pointer dereference
[ Upstream commit
638a3a1e349ddf5b82f222ff5cb3b4f266e7c278 ]
BUG: unable to handle kernel NULL pointer dereference at
0000000000000128
PGD 0 P4D 0
Oops: 0000 [#1
CPU: 0 PID: 5697 Comm: modprobe Tainted: G W 5.1.0-rc7+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:__lock_acquire+0x53/0x10b0
Code: 8b 1c 25 40 5e 01 00 4c 8b 6d 10 45 85 e4 0f 84 bd 06 00 00 44 8b 1d 7c d2 09 02 49 89 fe 41 89 d2 45 85 db 0f 84 47 02 00 00 <48> 81 3f a0 05 70 83 b8 00 00 00 00 44 0f 44 c0 83 fe 01 0f 86 3a
RSP: 0018:
ffffc90001c07a28 EFLAGS:
00010002
RAX:
0000000000000000 RBX:
ffff88822f038440 RCX:
0000000000000000
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000000000128
RBP:
ffffc90001c07a88 R08:
0000000000000001 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000001 R12:
0000000000000001
R13:
0000000000000000 R14:
0000000000000128 R15:
0000000000000000
FS:
00007fead0811540(0000) GS:
ffff888237a00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000128 CR3:
00000002310da000 CR4:
00000000000006f0
Call Trace:
? __lock_acquire+0x24e/0x10b0
lock_acquire+0xdf/0x230
? flush_workqueue+0x71/0x530
flush_workqueue+0x97/0x530
? flush_workqueue+0x71/0x530
l2tp_exit_net+0x170/0x2b0 [l2tp_core
? l2tp_exit_net+0x93/0x2b0 [l2tp_core
ops_exit_list.isra.6+0x36/0x60
unregister_pernet_operations+0xb8/0x110
unregister_pernet_device+0x25/0x40
l2tp_init+0x55/0x1000 [l2tp_core
? 0xffffffffa018d000
do_one_initcall+0x6c/0x3cc
? do_init_module+0x22/0x1f1
? rcu_read_lock_sched_held+0x97/0xb0
? kmem_cache_alloc_trace+0x325/0x3b0
do_init_module+0x5b/0x1f1
load_module+0x1db1/0x2690
? m_show+0x1d0/0x1d0
__do_sys_finit_module+0xc5/0xd0
__x64_sys_finit_module+0x15/0x20
do_syscall_64+0x6b/0x1d0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fead031a839
Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
RSP: 002b:
00007ffe8d9acca8 EFLAGS:
00000246 ORIG_RAX:
0000000000000139
RAX:
ffffffffffffffda RBX:
0000560078398b80 RCX:
00007fead031a839
RDX:
0000000000000000 RSI:
000056007659dc2e RDI:
0000000000000003
RBP:
000056007659dc2e R08:
0000000000000000 R09:
0000560078398b80
R10:
0000000000000003 R11:
0000000000000246 R12:
0000000000000000
R13:
00005600783a04a0 R14:
0000000000040000 R15:
0000560078398b80
Modules linked in: l2tp_core(+) e1000 ip_tables ipv6 [last unloaded: l2tp_core
CR2:
0000000000000128
---[ end trace
8322b2b8bf83f8e1
If alloc_workqueue fails in l2tp_init, l2tp_net_ops
is unregistered on failure path. Then l2tp_exit_net
is called which will flush NULL workqueue, this patch
add a NULL check to fix it.
Fixes:
67e04c29ec0d ("l2tp: unregister l2tp_net_ops on failure path")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>