Bixuan Cui [Wed, 1 Dec 2021 08:58:54 +0000 (16:58 +0800)]
ALSA: oss: fix compile error when OSS_DEBUG is enabled
[ Upstream commit
8e7daf318d97f25e18b2fc7eb5909e34cd903575 ]
Fix compile error when OSS_DEBUG is enabled:
sound/core/oss/pcm_oss.c: In function 'snd_pcm_oss_set_trigger':
sound/core/oss/pcm_oss.c:2055:10: error: 'substream' undeclared (first
use in this function); did you mean 'csubstream'?
pcm_dbg(substream->pcm, "pcm_oss: trigger = 0x%x\n", trigger);
^
Fixes:
61efcee8608c ("ALSA: oss: Use standard printk helpers")
Signed-off-by: Bixuan Cui <cuibixuan@linux.alibaba.com>
Link: https://lore.kernel.org/r/1638349134-110369-1-git-send-email-cuibixuan@linux.alibaba.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Waiman Long [Thu, 18 Nov 2021 19:14:36 +0000 (14:14 -0500)]
clocksource: Avoid accidental unstable marking of clocksources
[ Upstream commit
c86ff8c55b8ae68837b2fa59dc0c203907e9a15f ]
Since commit
db3a34e17433 ("clocksource: Retry clock read if long delays
detected") and commit
2e27e793e280 ("clocksource: Reduce clocksource-skew
threshold"), it is found that tsc clocksource fallback to hpet can
sometimes happen on both Intel and AMD systems especially when they are
running stressful benchmarking workloads. Of the 23 systems tested with
a v5.14 kernel, 10 of them have switched to hpet clock source during
the test run.
The result of falling back to hpet is a drastic reduction of performance
when running benchmarks. For example, the fio performance tests can
drop up to 70% whereas the iperf3 performance can drop up to 80%.
4 hpet fallbacks happened during bootup. They were:
[ 8.749399] clocksource: timekeeping watchdog on CPU13: hpet read-back delay of 263750ns, attempt 4, marking unstable
[ 12.044610] clocksource: timekeeping watchdog on CPU19: hpet read-back delay of 186166ns, attempt 4, marking unstable
[ 17.336941] clocksource: timekeeping watchdog on CPU28: hpet read-back delay of 182291ns, attempt 4, marking unstable
[ 17.518565] clocksource: timekeeping watchdog on CPU34: hpet read-back delay of 252196ns, attempt 4, marking unstable
Other fallbacks happen when the systems were running stressful
benchmarks. For example:
[ 2685.867873] clocksource: timekeeping watchdog on CPU117: hpet read-back delay of 57269ns, attempt 4, marking unstable
[46215.471228] clocksource: timekeeping watchdog on CPU8: hpet read-back delay of 61460ns, attempt 4, marking unstable
Commit
2e27e793e280 ("clocksource: Reduce clocksource-skew threshold"),
changed the skew margin from 100us to 50us. I think this is too small
and can easily be exceeded when running some stressful workloads on a
thermally stressed system. So it is switched back to 100us.
Even a maximum skew margin of 100us may be too small in for some systems
when booting up especially if those systems are under thermal stress. To
eliminate the case that the large skew is due to the system being too
busy slowing down the reading of both the watchdog and the clocksource,
an extra consecutive read of watchdog clock is being done to check this.
The consecutive watchdog read delay is compared against
WATCHDOG_MAX_SKEW/2. If the delay exceeds the limit, we assume that
the system is just too busy. A warning will be printed to the console
and the clock skew check is skipped for this round.
Fixes:
db3a34e17433 ("clocksource: Retry clock read if long delays detected")
Fixes:
2e27e793e280 ("clocksource: Reduce clocksource-skew threshold")
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Thu, 27 May 2021 19:01:22 +0000 (12:01 -0700)]
clocksource: Reduce clocksource-skew threshold
[ Upstream commit
2e27e793e280ff12cb5c202a1214c08b0d3a0f26 ]
Currently, WATCHDOG_THRESHOLD is set to detect a 62.5-millisecond skew in
a 500-millisecond WATCHDOG_INTERVAL. This requires that clocks be skewed
by more than 12.5% in order to be marked unstable. Except that a clock
that is skewed by that much is probably destroying unsuspecting software
right and left. And given that there are now checks for false-positive
skews due to delays between reading the two clocks, it should be possible
to greatly decrease WATCHDOG_THRESHOLD, at least for fine-grained clocks
such as TSC.
Therefore, add a new uncertainty_margin field to the clocksource structure
that contains the maximum uncertainty in nanoseconds for the corresponding
clock. This field may be initialized manually, as it is for
clocksource_tsc_early and clocksource_jiffies, which is copied to
refined_jiffies. If the field is not initialized manually, it will be
computed at clock-registry time as the period of the clock in question
based on the scale and freq parameters to __clocksource_update_freq_scale()
function. If either of those two parameters are zero, the
tens-of-milliseconds WATCHDOG_THRESHOLD is used as a cowardly alternative
to dividing by zero. No matter how the uncertainty_margin field is
calculated, it is bounded below by twice WATCHDOG_MAX_SKEW, that is, by 100
microseconds.
Note that manually initialized uncertainty_margin fields are not adjusted,
but there is a WARN_ON_ONCE() that triggers if any such field is less than
twice WATCHDOG_MAX_SKEW. This WARN_ON_ONCE() is intended to discourage
production use of the one-nanosecond uncertainty_margin values that are
used to test the clock-skew code itself.
The actual clock-skew check uses the sum of the uncertainty_margin fields
of the two clocksource structures being compared. Integer overflow is
avoided because the largest computed value of the uncertainty_margin
fields is one billion (10^9), and double that value fits into an
unsigned int. However, if someone manually specifies (say) UINT_MAX,
they will get what they deserve.
Note that the refined_jiffies uncertainty_margin field is initialized to
TICK_NSEC, which means that skew checks involving this clocksource will
be sufficently forgiving. In a similar vein, the clocksource_tsc_early
uncertainty_margin field is initialized to 32*NSEC_PER_MSEC, which
replicates the current behavior and allows custom setting if needed
in order to address the rare skews detected for this clocksource in
current mainline.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Feng Tang <feng.tang@intel.com>
Link: https://lore.kernel.org/r/20210527190124.440372-4-paulmck@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Tue, 30 Nov 2021 08:42:37 +0000 (09:42 +0100)]
powerpc/32s: Fix shift-out-of-bounds in KASAN init
[ Upstream commit
af11dee4361b3519981fa04d014873f9d9edd6ac ]
================================================================================
UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23
shift exponent -1 is negative
CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.5-gentoo-PowerMacG4 #9
Call Trace:
[
c214be60] [
c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable)
[
c214be80] [
c0b99288] ubsan_epilogue+0x10/0x5c
[
c214be90] [
c0b98fe0] __ubsan_handle_shift_out_of_bounds+0x94/0x138
[
c214bf00] [
c1c0f010] kasan_init_region+0xd8/0x26c
[
c214bf30] [
c1c0ed84] kasan_init+0xc0/0x198
[
c214bf70] [
c1c08024] setup_arch+0x18/0x54c
[
c214bfc0] [
c1c037f0] start_kernel+0x90/0x33c
[
c214bff0] [
00003610] 0x3610
================================================================================
This happens when the directly mapped memory is a power of 2.
Fix it by checking the shift and set the result to 0 when shift is -1
Fixes:
7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()")
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215169
Link: https://lore.kernel.org/r/15cbc3439d4ad988b225e2119ec99502a5cc6ad3.1638261744.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Athira Rajeev [Wed, 21 Jul 2021 05:48:29 +0000 (01:48 -0400)]
powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC
[ Upstream commit
2c9ac51b850d84ee496b0a5d832ce66d411ae552 ]
Running perf fuzzer showed below in dmesg logs:
"Can't find PMC that caused IRQ"
This means a PMU exception happened, but none of the PMC's (Performance
Monitor Counter) were found to be overflown. There are some corner cases
that clears the PMCs after PMI gets masked. In such cases, the perf
interrupt handler will not find the active PMC values that had caused
the overflow and thus leads to this message while replaying.
Case 1: PMU Interrupt happens during replay of other interrupts and
counter values gets cleared by PMU callbacks before replay:
During replay of interrupts like timer, __do_irq() and doorbell
exception, we conditionally enable interrupts via may_hard_irq_enable().
This could potentially create a window to generate a PMI. Since irq soft
mask is set to ALL_DISABLED, the PMI will get masked here. We could get
IPIs run before perf interrupt is replayed and the PMU events could
be deleted or stopped. This will change the PMU SPR values and resets
the counters. Snippet of ftrace log showing PMU callbacks invoked in
__do_irq():
<idle>-0 [051] dns.
132025441306354: __do_irq <-call_do_irq
<idle>-0 [051] dns.
132025441306430: irq_enter <-__do_irq
<idle>-0 [051] dns.
132025441306503: irq_enter_rcu <-__do_irq
<idle>-0 [051] dnH.
132025441306599: xive_get_irq <-__do_irq
<<>>
<idle>-0 [051] dnH.
132025441307770: generic_smp_call_function_single_interrupt <-smp_ipi_demux_relaxed
<idle>-0 [051] dnH.
132025441307839: flush_smp_call_function_queue <-smp_ipi_demux_relaxed
<idle>-0 [051] dnH.
132025441308057: _raw_spin_lock <-event_function
<idle>-0 [051] dnH.
132025441308206: power_pmu_disable <-perf_pmu_disable
<idle>-0 [051] dnH.
132025441308337: power_pmu_del <-event_sched_out
<idle>-0 [051] dnH.
132025441308407: power_pmu_read <-power_pmu_del
<idle>-0 [051] dnH.
132025441308477: read_pmc <-power_pmu_read
<idle>-0 [051] dnH.
132025441308590: isa207_disable_pmc <-power_pmu_del
<idle>-0 [051] dnH.
132025441308663: write_pmc <-power_pmu_del
<idle>-0 [051] dnH.
132025441308787: power_pmu_event_idx <-perf_event_update_userpage
<idle>-0 [051] dnH.
132025441308859: rcu_read_unlock_strict <-perf_event_update_userpage
<idle>-0 [051] dnH.
132025441308975: power_pmu_enable <-perf_pmu_enable
<<>>
<idle>-0 [051] dnH.
132025441311108: irq_exit <-__do_irq
<idle>-0 [051] dns.
132025441311319: performance_monitor_exception <-replay_soft_interrupts
Case 2: PMI's masked during local_* operations, example local_add(). If
the local_add() operation happens within a local_irq_save(), replay of
PMI will be during local_irq_restore(). Similar to case 1, this could
also create a window before replay where PMU events gets deleted or
stopped.
Fix it by updating the PMU callback function power_pmu_disable() to
check for pending perf interrupt. If there is an overflown PMC and
pending perf interrupt indicated in paca, clear the PMI bit in paca to
drop that sample. Clearing of PMI bit is done in power_pmu_disable()
since disable is invoked before any event gets deleted/stopped. With
this fix, if there are more than one event running in the PMU, there is
a chance that we clear the PMI bit for the event which is not getting
deleted/stopped. The other events may still remain active. Hence to make
sure we don't drop valid sample in such cases, another check is added in
power_pmu_enable. This checks if there is an overflown PMC found among
the active events and if so enable back the PMI bit. Two new helper
functions are introduced to clear/set the PMI, ie
clear_pmi_irq_pending() and set_pmi_irq_pending(). Helper function
pmi_irq_pending() is introduced to give a warning if there is pending
PMI bit in paca, but no PMC is overflown.
Also there are corner cases which result in performance monitor
interrupts being triggered during power_pmu_disable(). This happens
since PMXE bit is not cleared along with disabling of other MMCR0 bits
in the pmu_disable. Such PMI's could leave the PMU running and could
trigger PMI again which will set MMCR0 PMAO bit. This could lead to
spurious interrupts in some corner cases. Example, a timer after
power_pmu_del() which will re-enable interrupts and triggers a PMI again
since PMAO bit is still set. But fails to find valid overflow since PMC
was cleared in power_pmu_del(). Fix that by disabling PMXE along with
disabling of other MMCR0 bits in power_pmu_disable().
We can't just replay PMI any time. Hence this approach is preferred
rather than replaying PMI before resetting overflown PMC. Patch also
documents core-book3s on a race condition which can trigger these PMC
messages during idle path in PowerNV.
Fixes:
f442d004806e ("powerpc/64s: Add support to mask perf interrupts and replay them")
Reported-by: Nageswara R Sastry <nasastry@in.ibm.com>
Suggested-by: Nicholas Piggin <npiggin@gmail.com>
Suggested-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Make pmi_irq_pending() return bool, reflow/reword some comments]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1626846509-1350-2-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Mon, 8 Feb 2021 15:10:24 +0000 (15:10 +0000)]
powerpc/irq: Add helper to set regs->softe
[ Upstream commit
fb5608fd117a8b48752d2b5a7e70847c1ed33d33 ]
regs->softe doesn't exist on PPC32.
Add irq_soft_mask_regs_set_state() helper to set regs->softe.
This helper will void on PPC32.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/5f37d1177a751fdbca79df461d283850ca3a34a2.1612796617.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Piggin [Sat, 30 Jan 2021 13:08:29 +0000 (23:08 +1000)]
powerpc/perf: move perf irq/nmi handling details into traps.c
[ Upstream commit
156b5371a9c2482a9ad23ec82d1a4f89a3ab430d ]
This is required in order to allow more significant differences between
NMI type interrupt handlers and regular asynchronous handlers.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210130130852.2952424-20-npiggin@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Athira Rajeev [Thu, 26 Nov 2020 16:54:44 +0000 (11:54 -0500)]
powerpc/perf: MMCR0 control for PMU registers under PMCC=00
[ Upstream commit
91668ab7db4bcfae332e561df1de2401f3f18553 ]
PowerISA v3.1 introduces new control bit (PMCCEXT) for restricting
access to group B PMU registers in problem state when
MMCR0 PMCC=0b00. In problem state and when MMCR0 PMCC=0b00,
setting the Monitor Mode Control Register bit 54 (MMCR0 PMCCEXT),
will restrict read permission on Group B Performance Monitor
Registers (SIER, SIAR, SDAR and MMCR1). When this bit is set to zero,
group B registers will be readable. In other platforms (like power9),
the older behaviour is retained where group B PMU SPRs are readable.
Patch adds support for MMCR0 PMCCEXT bit in power10 by enabling
this bit during boot and during the PMU event enable/disable callback
functions.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1606409684-1589-8-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jordan Niethe [Wed, 14 Oct 2020 07:28:37 +0000 (18:28 +1100)]
powerpc/64s: Convert some cpu_setup() and cpu_restore() functions to C
[ Upstream commit
344fbab991a568dc33ad90711b489d870e18d26d ]
The only thing keeping the cpu_setup() and cpu_restore() functions
used in the cputable entries for Power7, Power8, Power9 and Power10 in
assembly was cpu_restore() being called before there was a stack in
generic_secondary_smp_init(). Commit ("powerpc/64: Set up a kernel
stack for secondaries before cpu_restore()") means that it is now
possible to use C.
Rewrite the functions in C so they are a little bit easier to read.
This is not changing their functionality.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
[mpe: Tweak copyright and authorship notes]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201014072837.24539-2-jniethe5@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Niklas Söderlund [Tue, 9 Nov 2021 10:30:45 +0000 (11:30 +0100)]
dt-bindings: thermal: Fix definition of cooling-maps contribution property
[ Upstream commit
49bcb1506f2e095262c01bda7fd1c0db524c91e2 ]
When converting the thermal-zones bindings to yaml the definition of the
contribution property changed. The intention is the same, an integer
value expressing a ratio of a sum on how much cooling is provided by the
device to the zone. But after the conversion the integer value is
limited to the range 0 to 100 and expressed as a percentage.
This is problematic for two reasons.
- This do not match how the binding is used. Out of the 18 files that
make use of the property only two (ste-dbx5x0.dtsi and
ste-hrefv60plus.dtsi) sets it at a value that satisfy the binding,
100. The remaining 16 files set the value higher and fail to validate.
- Expressing the value as a percentage instead of a ratio of the sum is
confusing as there is nothing to enforce the sum in the zone is not
greater then 100.
This patch restore the pre yaml conversion description and removes the
value limitation allowing the usage of the bindings to validate.
Fixes:
1202a442a31fd2e5 ("dt-bindings: thermal: Add yaml bindings for thermal zones")
Reported-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/20211109103045.1403686-1-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Bulwahn [Thu, 25 Nov 2021 09:51:57 +0000 (10:51 +0100)]
ASoC: uniphier: drop selecting non-existing SND_SOC_UNIPHIER_AIO_DMA
[ Upstream commit
49f893253ab43566e34332a969324531fea463f6 ]
Commit
f37fe2f9987b ("ASoC: uniphier: add support for UniPhier AIO common
driver") adds configs SND_SOC_UNIPHIER_{LD11,PXS2}, which select the
non-existing config SND_SOC_UNIPHIER_AIO_DMA.
Hence, ./scripts/checkkconfigsymbols.py warns:
SND_SOC_UNIPHIER_AIO_DMA
Referencing files: sound/soc/uniphier/Kconfig
Probably, there is actually no further config intended to be selected
here. So, just drop selecting the non-existing config.
Fixes:
f37fe2f9987b ("ASoC: uniphier: add support for UniPhier AIO common driver")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20211125095158.8394-2-lukas.bulwahn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peiwei Hu [Fri, 19 Nov 2021 09:12:18 +0000 (17:12 +0800)]
powerpc/prom_init: Fix improper check of prom_getprop()
[ Upstream commit
869fb7e5aecbc163003f93f36dcc26d0554319f6 ]
prom_getprop() can return PROM_ERROR. Binary operator can not identify
it.
Fixes:
94d2dde738a5 ("[POWERPC] Efika: prune fixups and make them more carefull")
Signed-off-by: Peiwei Hu <jlu.hpw@foxmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/tencent_BA28CC6897B7C95A92EB8C580B5D18589105@qq.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Adam Ford [Wed, 17 Nov 2021 13:32:02 +0000 (07:32 -0600)]
clk: imx8mn: Fix imx8mn_clko1_sels
[ Upstream commit
570727e9acfac1c2330a01dd5e1272e9c3acec08 ]
When attempting to use sys_pll1_80m as the parent for clko1, the
system hangs. This is due to the fact that the source select
for sys_pll1_80m was incorrectly pointing to m7_alt_pll_clk, which
doesn't yet exist.
According to Rev 3 of the TRM, The imx8mn_clko1_sels also incorrectly
references an osc_27m which does not exist, nor does an entry for
source select bits 010b. Fix both by inserting a dummy clock into
the missing space in the table and renaming the incorrectly name clock
with dummy.
Fixes:
96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20211117133202.775633-1-aford173@gmail.com
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Igor Pylypiv [Mon, 1 Nov 2021 23:28:24 +0000 (16:28 -0700)]
scsi: pm80xx: Update WARN_ON check in pm8001_mpi_build_cmd()
[ Upstream commit
606c54ae975ad3af540b505b46b55a687501711f ]
Starting from commit
05c6c029a44d ("scsi: pm80xx: Increase number of
supported queues") driver initializes only max_q_num queues. Do not use an
invalid queue if the WARN_ON condition is true.
Link: https://lore.kernel.org/r/20211101232825.2350233-4-ipylypiv@google.com
Fixes:
7640e1eb8c5d ("scsi: pm80xx: Make mpi_build_cmd locking consistent")
Reviewed-by: Vishakha Channapattan <vishakhavc@google.com>
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kamal Heib [Wed, 17 Nov 2021 14:59:54 +0000 (16:59 +0200)]
RDMA/hns: Validate the pkey index
[ Upstream commit
2a67fcfa0db6b4075515bd23497750849b88850f ]
Before query pkey, make sure that the queried index is valid.
Fixes:
9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
Link: https://lore.kernel.org/r/20211117145954.123893-1-kamalheib1@gmail.com
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Fri, 12 Nov 2021 08:59:04 +0000 (09:59 +0100)]
RDMA/bnxt_re: Scan the whole bitmap when checking if "disabling RCFW with pending cmd-bit"
[ Upstream commit
a917dfb66c0a1fa1caacf3d71edcafcab48e6ff0 ]
The 'cmdq->cmdq_bitmap' bitmap is 'rcfw->cmdq_depth' bits long. The size
stored in 'cmdq->bmap_size' is the size of the bitmap in bytes.
Remove this erroneous 'bmap_size' and use 'rcfw->cmdq_depth' directly in
'bnxt_qplib_disable_rcfw_channel()'. Otherwise some error messages may be
missing.
Other uses of 'cmdq_bitmap' already take into account 'rcfw->cmdq_depth'
directly.
Fixes:
1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
Link: https://lore.kernel.org/r/47ed717c3070a1d0f53e7b4c768a4fd11caf365d.1636707421.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Tue, 16 Nov 2021 07:13:14 +0000 (08:13 +0100)]
ALSA: hda: Add missing rwsem around snd_ctl_remove() calls
[ Upstream commit
80bd64af75b4bb11c0329bc66c35da2ddfb66d88 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when
called after the card instantiation). This patch add the missing
rwsem calls around it.
Fixes:
d13bd412dce2 ("ALSA: hda - Manage kcontrol lists")
Link: https://lore.kernel.org/r/20211116071314.15065-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Tue, 16 Nov 2021 07:13:13 +0000 (08:13 +0100)]
ALSA: PCM: Add missing rwsem around snd_ctl_remove() calls
[ Upstream commit
5471e9762e1af4b7df057a96bfd46cc250979b88 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when
called after the card instantiation). This patch add the missing
rwsem calls around it.
Fixes:
a8ff48cb7083 ("ALSA: pcm: Free chmap at PCM free callback, too")
Link: https://lore.kernel.org/r/20211116071314.15065-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Tue, 16 Nov 2021 07:13:12 +0000 (08:13 +0100)]
ALSA: jack: Add missing rwsem around snd_ctl_remove() calls
[ Upstream commit
06764dc931848c3a9bc01a63bbf76a605408bb54 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when
called after the card instantiation). This patch add the missing
rwsem calls around it.
Fixes:
9058cbe1eed2 ("ALSA: jack: implement kctl creating for jack devices")
Link: https://lore.kernel.org/r/20211116071314.15065-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Kara [Fri, 12 Nov 2021 15:22:02 +0000 (16:22 +0100)]
ext4: avoid trim error on fs with small groups
[ Upstream commit
173b6e383d2a204c9921ffc1eca3b87aa2106c33 ]
A user reported FITRIM ioctl failing for him on ext4 on some devices
without apparent reason. After some debugging we've found out that
these devices (being LVM volumes) report rather large discard
granularity of 42MB and the filesystem had 1k blocksize and thus group
size of 8MB. Because ext4 FITRIM implementation puts discard
granularity into minlen, ext4_trim_fs() declared the trim request as
invalid. However just silently doing nothing seems to be a more
appropriate reaction to such combination of parameters since user did
not specify anything wrong.
CC: Lukas Czerner <lczerner@redhat.com>
Fixes:
5c2ed62fd447 ("ext4: Adjust minlen with discard_granularity in the FITRIM ioctl")
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20211112152202.26614-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Thu, 6 Jan 2022 22:57:16 +0000 (01:57 +0300)]
net: mcs7830: handle usb read errors properly
[ Upstream commit
d668769eb9c52b150753f1653f7f5a0aeb8239d2 ]
Syzbot reported uninit value in mcs7830_bind(). The problem was in
missing validation check for bytes read via usbnet_read_cmd().
usbnet_read_cmd() internally calls usb_control_msg(), that returns
number of bytes read. Code should validate that requested number of bytes
was actually read.
So, this patch adds missing size validation check inside
mcs7830_get_reg() to prevent uninit value bugs
Reported-and-tested-by: syzbot+003c0a286b9af5412510@syzkaller.appspotmail.com
Fixes:
2a36d7083438 ("USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20220106225716.7425-1-paskripkin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Mon, 27 Dec 2021 19:17:57 +0000 (12:17 -0700)]
iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_ftm_rtt_smoothing()
[ Upstream commit
4ccdcc8ffd955490feec05380223db6a48961eb5 ]
When building ARCH=arm allmodconfig:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’:
./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror]
222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
| ^~
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’
1070 | do_div(rtt_avg, 100);
| ^~~~~~
do_div() has to be used with an unsigned 64-bit integer dividend but
rtt_avg is a signed 64-bit integer.
div_s64() expects a signed 64-bit integer dividend and signed 32-bit
divisor, which fits this scenario, so use that function here to fix the
warning.
Fixes:
8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dominik Brodowski [Sun, 9 Jan 2022 09:02:51 +0000 (10:02 +0100)]
pcmcia: fix setting of kthread task states
[ Upstream commit
fbb3485f1f931102d8ba606f1c28123f5b48afa3 ]
We need to set TASK_INTERRUPTIBLE before calling kthread_should_stop().
Otherwise, kthread_stop() might see that the pccardd thread is still
in TASK_RUNNING state and fail to wake it up.
Additionally, we only need to set the state back to TASK_RUNNING if
kthread_should_stop() breaks the loop.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Fixes:
d3046ba809ce ("pcmcia: fix a boot time warning in pcmcia cs code")
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Fri, 24 Dec 2021 02:13:24 +0000 (10:13 +0800)]
can: xilinx_can: xcan_probe(): check for error irq
[ Upstream commit
c6564c13dae25cd7f8e1de5127b4da4500ee5844 ]
For the possible failure of the platform_get_irq(), the returned irq
could be error number and will finally cause the failure of the
request_irq().
Consider that platform_get_irq() can now in certain cases return
-EPROBE_DEFER, and the consequences of letting request_irq()
effectively convert that into -EINVAL, even at probe time rather than
later on. So it might be better to check just now.
Fixes:
b1201e44f50b ("can: xilinx CAN controller support")
Link: https://lore.kernel.org/all/20211224021324.1447494-1-jiasheng@iscas.ac.cn
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Kleine-Budde [Sat, 8 Jan 2022 20:57:51 +0000 (21:57 +0100)]
can: softing: softing_startstop(): fix set but not used variable warning
[ Upstream commit
370d988cc529598ebaec6487d4f84c2115dc696b ]
In the function softing_startstop() the variable error_reporting is
assigned but not used. The code that uses this variable is commented
out. Its stated that the functionality is not finally verified.
To fix the warning:
| drivers/net/can/softing/softing_fw.c:424:9: error: variable 'error_reporting' set but not used [-Werror,-Wunused-but-set-variable]
remove the comment, activate the code, but add a "0 &&" to the if
expression and rely on the optimizer rather than the preprocessor to
remove the code.
Link: https://lore.kernel.org/all/20220109103126.1872833-1-mkl@pengutronix.de
Fixes:
03fd3cf5a179 ("can: add driver for Softing card")
Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Jaillet [Sat, 6 Nov 2021 16:42:04 +0000 (17:42 +0100)]
tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'
[ Upstream commit
e96d52822f5ac0a25de78f95cd23421bcbc93584 ]
Commit
79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent
queries") has moved some code around without updating the error handling
path.
This is now pointless to 'goto out_err' when neither 'clk_enable()' nor
'ioremap()' have been called yet.
Make a direct return instead to avoid undoing things that have not been
done.
Fixes:
79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries")
Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Jun [Wed, 13 Oct 2021 06:25:56 +0000 (06:25 +0000)]
tpm: add request_locality before write TPM_INT_ENABLE
[ Upstream commit
0ef333f5ba7f24f5d8478425c163d3097f1c7afd ]
Locality is not appropriately requested before writing the int mask.
Add the missing boilerplate.
Fixes:
e6aef069b6e9 ("tpm_tis: convert to using locality callbacks")
Signed-off-by: Chen Jun <chenjun102@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Kleine-Budde [Tue, 19 Oct 2021 15:05:25 +0000 (17:05 +0200)]
can: mcp251xfd: add missing newline to printed strings
[ Upstream commit
3bd9d8ce6f8c5c43ee2f1106021db0f98882cc75 ]
This patch adds the missing newline to printed strings.
Fixes:
55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
Link: https://lore.kernel.org/all/20220105154300.1258636-4-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabio Estevam [Fri, 7 Jan 2022 16:33:07 +0000 (13:33 -0300)]
regmap: Call regmap_debugfs_exit() prior to _init()
[ Upstream commit
530792efa6cb86f5612ff093333fec735793b582 ]
Since commit
cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when
calling regmap_attach_dev"), the following debugfs error is seen
on i.MX boards:
debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
In the attempt to fix the memory leak, the above commit added a NULL check
for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL
and then the new name is allocated via kasprintf().
For the second debugfs entry, map->debugfs_name() is no longer NULL, so
it will keep using the old entry name and the duplicate name error is seen.
Quoting Mark Brown:
"That means that if the device gets freed we'll end up with the old debugfs
file hanging around pointing at nothing.
...
To be more explicit this means we need a call to regmap_debugfs_exit()
which will clean up all the existing debugfs stuff before we loose
references to it."
Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix
the problem.
Tested on i.MX6Q and i.MX6SX boards.
Fixes:
cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 7 Jan 2022 07:12:10 +0000 (10:12 +0300)]
netrom: fix api breakage in nr_setsockopt()
[ Upstream commit
dc35616e6c2907b0c0c391a205802d8880f7fd85 ]
This needs to copy an unsigned int from user space instead of a long to
avoid breaking user space with an API change.
I have updated all the integer overflow checks from ULONG to UINT as
well. This is a slight API change but I do not expect it to affect
anything in real life.
Fixes:
3087a6f36ee0 ("netrom: fix copying in user data in nr_setsockopt")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 7 Jan 2022 07:13:12 +0000 (10:13 +0300)]
ax25: uninitialized variable in ax25_setsockopt()
[ Upstream commit
9371937092d5fd502032c1bb4475b36b39b1f1b3 ]
The "opt" variable is unsigned long but we only copy 4 bytes from
the user so the lower 4 bytes are uninitialized.
I have changed the integer overflow checks from ULONG to UINT as well.
This is a slight API change but I don't expect it to break anything.
Fixes:
a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miaoqian Lin [Fri, 7 Jan 2022 07:54:24 +0000 (07:54 +0000)]
spi: spi-meson-spifc: Add missing pm_runtime_disable() in meson_spifc_probe
[ Upstream commit
69c1b87516e327a60b39f96b778fe683259408bf ]
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable().
Add missing pm_runtime_disable() for meson_spifc_probe.
Fixes:
c3e4bc5434d2 ("spi: meson: Add support for Amlogic Meson SPIFC")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220107075424.7774-1-linmq006@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 7 Jan 2022 07:16:44 +0000 (10:16 +0300)]
Bluetooth: L2CAP: uninitialized variables in l2cap_sock_setsockopt()
[ Upstream commit
2b70d4f9b20635ac328836e50d183632e1930f94 ]
The "opt" variable is a u32, but on some paths only the top bytes
were initialized and the others contained random stack data.
Fixes:
a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zizhuang Deng [Thu, 30 Dec 2021 07:03:31 +0000 (15:03 +0800)]
lib/mpi: Add the return value check of kcalloc()
[ Upstream commit
dd827abe296fe4249b2f8c9b95f72f814ea8348c ]
Add the return value check of kcalloc() to avoid potential
NULL ptr dereference.
Fixes:
a8ea8bdd9df9 ("lib/mpi: Extend the MPI library")
Signed-off-by: Zizhuang Deng <sunsetdzz@gmail.com>
Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Moshe Shemesh [Sun, 5 Dec 2021 10:07:49 +0000 (12:07 +0200)]
net/mlx5: Set command entry semaphore up once got index free
[ Upstream commit
8e715cd613a1e872b9d918e912d90b399785761a ]
Avoid a race where command work handler may fail to allocate command
entry index, by holding the command semaphore down till command entry
index is being freed.
Fixes:
410bd754cd73 ("net/mlx5: Add retry mechanism to the command entry index allocation")
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aya Levin [Sun, 24 Oct 2021 08:47:41 +0000 (11:47 +0300)]
Revert "net/mlx5e: Block offload of outer header csum for UDP tunnels"
[ Upstream commit
64050cdad0983ad8060e33c3f4b5aee2366bcebd ]
This reverts commit
6d6727dddc7f93fcc155cb8d0c49c29ae0e71122.
Although the NIC doesn't support offload of outer header CSUM, using
gso_partial_features allows offloading the tunnel's segmentation. The
driver relies on the stack CSUM calculation of the outer header. For
this, NETIF_F_GSO_UDP_TUNNEL_CSUM must be a member of the device's
features.
Fixes:
6d6727dddc7f ("net/mlx5e: Block offload of outer header csum for UDP tunnels")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Gal Pressman <gal@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maor Dickman [Thu, 30 Dec 2021 09:20:10 +0000 (11:20 +0200)]
net/mlx5e: Don't block routes with nexthop objects in SW
[ Upstream commit
9e72a55a3c9d54b38a704bb7292d984574a81d9d ]
Routes with nexthop objects is currently not supported by multipath offload
and any attempts to use it is blocked, however this also block adding SW
routes with nexthop.
Resolve this by returning NOTIFY_DONE instead of an error which will allow such
a route to be created in SW but not offloaded.
This fix also solve an issue which block adding such routes on different devices
due to missing check if the route FIB device is one of multipath devices.
Fixes:
6a87afc072c3 ("mlx5: Fail attempts to use routes with nexthop objects")
Signed-off-by: Maor Dickman <maord@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aya Levin [Thu, 23 Dec 2021 12:38:28 +0000 (14:38 +0200)]
net/mlx5e: Fix page DMA map/unmap attributes
[ Upstream commit
0b7cfa4082fbf550595bc0e40f05614bd83bf0cd ]
Driver initiates DMA sync, hence it may skip CPU sync. Add
DMA_ATTR_SKIP_CPU_SYNC as input attribute both to dma_map_page and
dma_unmap_page to avoid redundant sync with the CPU.
When forcing the device to work with SWIOTLB, the extra sync might cause
data corruption. The driver unmaps the whole page while the hardware
used just a part of the bounce buffer. So syncing overrides the entire
page with bounce buffer that only partially contains real data.
Fixes:
bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE")
Fixes:
db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Gal Pressman <gal@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Suchanek [Tue, 4 Jan 2022 17:05:05 +0000 (18:05 +0100)]
debugfs: lockdown: Allow reading debugfs files that are not world readable
[ Upstream commit
358fcf5ddbec4e6706405847d6a666f5933a6c25 ]
When the kernel is locked down the kernel allows reading only debugfs
files with mode 444. Mode 400 is also valid but is not allowed.
Make the 444 into a mask.
Fixes:
5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Link: https://lore.kernel.org/r/20220104170505.10248-1-msuchanek@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Wed, 5 Jan 2022 17:29:15 +0000 (18:29 +0100)]
HID: hid-uclogic-params: Invalid parameter check in uclogic_params_frame_init_v1_buttonpad
[ Upstream commit
aa320fdbbbb482c19100f51461bd0069753ce3d7 ]
The function performs a check on the hdev input parameters, however, it
is used before the check.
Initialize the udev variable after the sanity check to avoid a
possible NULL pointer dereference.
Fixes:
9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443763 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Wed, 5 Jan 2022 17:29:14 +0000 (18:29 +0100)]
HID: hid-uclogic-params: Invalid parameter check in uclogic_params_huion_init
[ Upstream commit
ff6b548afe4d9d1ff3a0f6ef79e8cbca25d8f905 ]
The function performs a check on its input parameters, however, the
hdev parameter is used before the check.
Initialize the stack variables after checking the input parameters to
avoid a possible NULL pointer dereference.
Fixes:
9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443804 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Wed, 5 Jan 2022 17:29:13 +0000 (18:29 +0100)]
HID: hid-uclogic-params: Invalid parameter check in uclogic_params_get_str_desc
[ Upstream commit
0a94131d6920916ccb6a357037c535533af08819 ]
The function performs a check on the hdev input parameters, however, it
is used before the check.
Initialize the udev variable after the sanity check to avoid a
possible NULL pointer dereference.
Fixes:
9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443827 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Wed, 5 Jan 2022 17:29:12 +0000 (18:29 +0100)]
HID: hid-uclogic-params: Invalid parameter check in uclogic_params_init
[ Upstream commit
f364c571a5c77e96de2d32062ff019d6b8d2e2bc ]
The function performs a check on its input parameters, however, the
hdev parameter is used before the check.
Initialize the stack variables after checking the input parameters to
avoid a possible NULL pointer dereference.
Fixes:
9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443831 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miaoqian Lin [Wed, 22 Dec 2021 11:18:23 +0000 (11:18 +0000)]
usb: dwc3: qcom: Fix NULL vs IS_ERR checking in dwc3_qcom_probe
[ Upstream commit
b52fe2dbb3e655eb1483000adfab68a219549e13 ]
Since the acpi_create_platform_device() function may return error
pointers, dwc3_qcom_create_urs_usb_platdev() function may return error
pointers too. Using IS_ERR_OR_NULL() to check the return value to fix this.
Fixes:
c25c210f590e ("usb: dwc3: qcom: add URS Host support for sdm845 ACPI boot")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211222111823.22887-1-linmq006@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miaoqian Lin [Fri, 24 Dec 2021 08:02:49 +0000 (08:02 +0000)]
Bluetooth: hci_qca: Fix NULL vs IS_ERR_OR_NULL check in qca_serdev_probe
[ Upstream commit
6845667146a28c09b5dfc401c1ad112374087944 ]
The function devm_gpiod_get_index() return error pointers on error.
Thus devm_gpiod_get_index_optional() could return NULL and error pointers.
The same as devm_gpiod_get_optional() function. Using IS_ERR_OR_NULL()
check to catch error pointers.
Fixes:
77131dfe ("Bluetooth: hci_qca: Replace devm_gpiod_get() with devm_gpiod_get_optional()")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Fri, 24 Dec 2021 02:53:18 +0000 (10:53 +0800)]
Bluetooth: hci_bcm: Check for error irq
[ Upstream commit
b38cd3b42fba66cc538edb9cf77e07881f43f8e2 ]
For the possible failure of the platform_get_irq(), the returned irq
could be error number and will finally cause the failure of the
request_irq().
Consider that platform_get_irq() can now in certain cases return
-EPROBE_DEFER, and the consequences of letting request_irq() effectively
convert that into -EINVAL, even at probe time rather than later on.
So it might be better to check just now.
Fixes:
0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Thu, 6 Jan 2022 10:04:10 +0000 (18:04 +0800)]
fsl/fman: Check for null pointer after calling devm_ioremap
[ Upstream commit
d5a73ec96cc57cf67e51b12820fc2354e7ca46f8 ]
As the possible failure of the allocation, the devm_ioremap() may return
NULL pointer.
Take tgec_initialization() as an example.
If allocation fails, the params->base_addr will be NULL pointer and will
be assigned to tgec->regs in tgec_config().
Then it will cause the dereference of NULL pointer in set_mac_address(),
which is called by tgec_init().
Therefore, it should be better to add the sanity check after the calling
of the devm_ioremap().
Fixes:
3933961682a3 ("fsl/fman: Add FMan MAC driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Tue, 4 Jan 2022 15:06:28 +0000 (23:06 +0800)]
staging: greybus: audio: Check null pointer
[ Upstream commit
2e81948177d769106754085c3e03534e6cc1f623 ]
As the possible alloc failure of devm_kcalloc(), it could return null
pointer.
Therefore, 'strings' should be checked and return NULL if alloc fails to
prevent the dereference of the NULL pointer.
Also, the caller should also deal with the return value of the
gb_generate_enum_strings() and return -ENOMEM if returns NULL.
Moreover, because the memory allocated with devm_kzalloc() will be
freed automatically when the last reference to the device is dropped,
the 'gbe' in gbaudio_tplg_create_enum_kctl() and
gbaudio_tplg_create_enum_ctl() do not need to free manually.
But the 'control' in gbaudio_tplg_create_widget() and
gbaudio_tplg_process_kcontrols() has a specially error handle to
cleanup.
So it should be better to cleanup 'control' when fails.
Fixes:
e65579e335da ("greybus: audio: topology: Enable enumerated control support")
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20220104150628.1987906-1-jiasheng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 6 Jan 2022 11:57:54 +0000 (14:57 +0300)]
rocker: fix a sleeping in atomic bug
[ Upstream commit
43d012123122cc69feacab55b71369f386c19566 ]
This code is holding the &ofdpa->flow_tbl_lock spinlock so it is not
allowed to sleep. That means we have to pass the OFDPA_OP_FLAG_NOWAIT
flag to ofdpa_flow_tbl_del().
Fixes:
936bd486564a ("rocker: use FIB notifications instead of switchdev calls")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Wed, 5 Jan 2022 11:48:42 +0000 (03:48 -0800)]
ppp: ensure minimum packet size in ppp_write()
[ Upstream commit
44073187990d5629804ce0627525f6ea5cfef171 ]
It seems pretty clear ppp layer assumed user space
would always be kind to provide enough data
in their write() to a ppp device.
This patch makes sure user provides at least
2 bytes.
It adds PPP_PROTO_LEN macro that could replace
in net-next many occurrences of hard-coded 2 value.
I replaced only one occurrence to ease backports
to stable kernels.
The bug manifests in the following report:
BUG: KMSAN: uninit-value in ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740
ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740
__ppp_xmit_process+0x23e/0x4b0 drivers/net/ppp/ppp_generic.c:1640
ppp_xmit_process+0x1fe/0x480 drivers/net/ppp/ppp_generic.c:1661
ppp_write+0x5cb/0x5e0 drivers/net/ppp/ppp_generic.c:513
do_iter_write+0xb0c/0x1500 fs/read_write.c:853
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
ppp_write+0x11d/0x5e0 drivers/net/ppp/ppp_generic.c:501
do_iter_write+0xb0c/0x1500 fs/read_write.c:853
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-ppp@vger.kernel.org
Reported-by: syzbot <syzkaller@googlegroups.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>
Florian Westphal [Wed, 5 Jan 2022 13:19:54 +0000 (14:19 +0100)]
netfilter: nft_set_pipapo: allocate pcpu scratch maps on clone
[ Upstream commit
23c54263efd7cb605e2f7af72717a2a951999217 ]
This is needed in case a new transaction is made that doesn't insert any
new elements into an already existing set.
Else, after second 'nft -f ruleset.txt', lookups in such a set will fail
because ->lookup() encounters raw_cpu_ptr(m->scratch) == NULL.
For the initial rule load, insertion of elements takes care of the
allocation, but for rule reloads this isn't guaranteed: we might not
have additions to the set.
Fixes:
3c4287f62044a90e ("nf_tables: Add set type for arbitrary concatenation of ranges")
Reported-by: etkaar <lists.netfilter.org@prvy.eu>
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kuniyuki Iwashima [Tue, 4 Jan 2022 01:31:48 +0000 (10:31 +0900)]
bpf: Fix SO_RCVBUF/SO_SNDBUF handling in _bpf_setsockopt().
[ Upstream commit
04c350b1ae6bdb12b84009a4d0bf5ab4e621c47b ]
The commit
4057765f2dee ("sock: consistent handling of extreme
SO_SNDBUF/SO_RCVBUF values") added a change to prevent underflow
in setsockopt() around SO_SNDBUF/SO_RCVBUF.
This patch adds the same change to _bpf_setsockopt().
Fixes:
4057765f2dee ("sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20220104013153.97906-2-kuniyu@amazon.co.jp
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Borkmann [Wed, 5 Jan 2022 19:35:13 +0000 (11:35 -0800)]
bpf: Don't promote bogus looking registers after null check.
[ Upstream commit
e60b0d12a95dcf16a63225cead4541567f5cb517 ]
If we ever get to a point again where we convert a bogus looking <ptr>_or_null
typed register containing a non-zero fixed or variable offset, then lets not
reset these bounds to zero since they are not and also don't promote the register
to a <ptr> type, but instead leave it as <ptr>_or_null. Converting to a unknown
register could be an avenue as well, but then if we run into this case it would
allow to leak a kernel pointer this way.
Fixes:
f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Xiong [Thu, 23 Dec 2021 02:48:12 +0000 (10:48 +0800)]
netfilter: ipt_CLUSTERIP: fix refcount leak in clusterip_tg_check()
[ Upstream commit
d94a69cb2cfa77294921aae9afcfb866e723a2da ]
The issue takes place in one error path of clusterip_tg_check(). When
memcmp() returns nonzero, the function simply returns the error code,
forgetting to decrease the reference count of a clusterip_config
object, which is bumped earlier by clusterip_config_find_get(). This
may incur reference count leak.
Fix this issue by decrementing the refcount of the object in specific
error path.
Fixes:
06aa151ad1fc74 ("netfilter: ipt_CLUSTERIP: check MAC address when duplicate config is set")
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Mon, 20 Dec 2021 08:38:11 +0000 (16:38 +0800)]
power: reset: mt6397: Check for null res pointer
[ Upstream commit
1c1348bf056dee665760a3bd1cd30b0be7554fc2 ]
The return value of platform_get_resource() needs to be checked.
To avoid use of error pointer in case that there is no suitable
resource.
Fixes:
d28c74c10751 ("power: reset: add driver for mt6323 poweroff")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhou Qingyang [Tue, 30 Nov 2021 18:11:40 +0000 (02:11 +0800)]
pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in nonstatic_find_mem_region()
[ Upstream commit
977d2e7c63c3d04d07ba340b39987742e3241554 ]
In nonstatic_find_mem_region(), pcmcia_make_resource() is assigned to
res and used in pci_bus_alloc_resource(). There a dereference of res
in pci_bus_alloc_resource(), which could lead to a NULL pointer
dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings,
and our static analyzer no longer warns about this code.
Fixes:
49b1153adfe1 ("pcmcia: move all pcmcia_resource_ops providers into one module")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhou Qingyang [Tue, 30 Nov 2021 16:59:23 +0000 (00:59 +0800)]
pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in __nonstatic_find_io_region()
[ Upstream commit
ca0fe0d7c35c97528bdf621fdca75f13157c27af ]
In __nonstatic_find_io_region(), pcmcia_make_resource() is assigned to
res and used in pci_bus_alloc_resource(). There is a dereference of res
in pci_bus_alloc_resource(), which could lead to a NULL pointer
dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings,
and our static analyzer no longer warns about this code.
Fixes:
49b1153adfe1 ("pcmcia: move all pcmcia_resource_ops providers into one module")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
[linux@dominikbrodowski.net: Fix typo in commit message]
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Thu, 30 Dec 2021 11:57:47 +0000 (12:57 +0100)]
ACPI: scan: Create platform device for BCM4752 and LNV4752 ACPI nodes
[ Upstream commit
f85196bdd5a50da74670250564740fc852b3c239 ]
BCM4752 and LNV4752 ACPI nodes describe a Broadcom 4752 GPS module
attached to an UART of the system.
The GPS modules talk a custom protocol which only works with a closed-
source Android gpsd daemon which knows this protocol.
The ACPI nodes also describe GPIOs to turn the GPS on/off these are
handled by the net/rfkill/rfkill-gpio.c code. This handling predates the
addition of enumeration of ACPI instantiated serdevs to the kernel and
was broken by that addition, because the ACPI scan code now no longer
instantiates platform_device-s for these nodes.
Rename the i2c_multi_instantiate_ids HID list to ignore_serial_bus_ids
and add the BCM4752 and LNV4752 HIDs, so that rfkill-gpio gets
a platform_device to bind to again; and so that a tty cdev for gpsd
gets created for these.
Fixes:
e361d1f85855 ("ACPI / scan: Fix enumeration for special UART devices")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Zixun [Mon, 27 Dec 2021 21:02:49 +0000 (22:02 +0100)]
x86/mce/inject: Avoid out-of-bounds write when setting flags
[ Upstream commit
de768416b203ac84e02a757b782a32efb388476f ]
A contrived zero-length write, for example, by using write(2):
...
ret = write(fd, str, 0);
...
to the "flags" file causes:
BUG: KASAN: stack-out-of-bounds in flags_write
Write of size 1 at addr
ffff888019be7ddf by task writefile/3787
CPU: 4 PID: 3787 Comm: writefile Not tainted 5.16.0-rc7+ #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
due to accessing buf one char before its start.
Prevent such out-of-bounds access.
[ bp: Productize into a proper patch. Link below is the next best
thing because the original mail didn't get archived on lore. ]
Fixes:
0451d14d0561 ("EDAC, mce_amd_inj: Modify flags attribute to use string arguments")
Signed-off-by: Zhang Zixun <zhang133010@icloud.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/linux-edac/YcnePfF1OOqoQwrX@zn.tnic/
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arseny Demidov [Sun, 19 Dec 2021 10:22:39 +0000 (13:22 +0300)]
hwmon: (mr75203) fix wrong power-up delay value
[ Upstream commit
a8d6d4992ad9d92356619ac372906bd29687bb46 ]
In the file mr75203.c we have a macro named POWER_DELAY_CYCLE_256,
the correct value should be 0x100. The register ip_tmr is expressed
in units of IP clk cycles, in accordance with the datasheet.
Typical power-up delays for Temperature Sensor are 256 cycles i.e. 0x100.
Fixes:
9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller")
Signed-off-by: Arseny Demidov <a.demidov@yadro.com>
Link: https://lore.kernel.org/r/20211219102239.1112-1-a.demidov@yadro.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Wed, 22 Dec 2021 16:30:41 +0000 (09:30 -0700)]
x86/boot/compressed: Move CLANG_FLAGS to beginning of KBUILD_CFLAGS
[ Upstream commit
5fe392ff9d1f7254a1fbb3f72d9893088e4d23eb ]
When cross compiling i386_defconfig on an arm64 host with clang, there
are a few instances of '-Waddress-of-packed-member' and
'-Wgnu-variable-sized-type-not-at-end' in arch/x86/boot/compressed/,
which should both be disabled with the cc-disable-warning calls in that
directory's Makefile, which indicates that cc-disable-warning is failing
at the point of testing these flags.
The cc-disable-warning calls fail because at the point that the flags
are tested, KBUILD_CFLAGS has '-march=i386' without $(CLANG_FLAGS),
which has the '--target=' flag to tell clang what architecture it is
targeting. Without the '--target=' flag, the host architecture (arm64)
is used and i386 is not a valid value for '-march=' in that case. This
error can be seen by adding some logging to try-run:
clang-14: error: the clang compiler does not support '-march=i386'
Invoking the compiler has to succeed prior to calling cc-option or
cc-disable-warning in order to accurately test whether or not the flag
is supported; if it doesn't, the requested flag can never be added to
the compiler flags. Move $(CLANG_FLAGS) to the beginning of KBUILD_FLAGS
so that any new flags that might be added in the future can be
accurately tested.
Fixes:
d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211222163040.1961481-1-nathan@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Panicker Harish [Wed, 22 Dec 2021 07:29:05 +0000 (12:59 +0530)]
Bluetooth: hci_qca: Stop IBS timer during BT OFF
[ Upstream commit
df1e5c51492fd93ffc293acdcc6f00698d19fedc ]
The IBS timers are not stopped properly once BT OFF is triggered.
we could see IBS commands being sent along with version command,
so stopped IBS timers while Bluetooth is off.
Fixes:
3e4be65eb82c ("Bluetooth: hci_qca: Add poweroff support during hci down for wcn3990")
Signed-off-by: Panicker Harish <quic_pharish@quicinc.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Clément Léger [Mon, 20 Dec 2021 21:05:33 +0000 (22:05 +0100)]
software node: fix wrong node passed to find nargs_prop
[ Upstream commit
c5fc5ba8b6b7bebc05e45036a33405b4c5036c2f ]
nargs_prop refers to a property located in the reference that is found
within the nargs property. Use the correct reference node in call to
property_entry_read_int_array() to retrieve the correct nargs value.
Fixes:
b06184acf751 ("software node: Add software_node_get_reference_args()")
Signed-off-by: Clément Léger <clement.leger@bootlin.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Daniel Scally <djrscally@gmail.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:59 +0000 (21:34 +0100)]
backlight: qcom-wled: Respect enabled-strings in set_brightness
[ Upstream commit
ec961cf3241153e0f27d850f1bf0f172e7d27a21 ]
The hardware is capable of controlling any non-contiguous sequence of
LEDs specified in the DT using qcom,enabled-strings as u32
array, and this also follows from the DT-bindings documentation. The
numbers specified in this array represent indices of the LED strings
that are to be enabled and disabled.
Its value is appropriately used to setup and enable string modules, but
completely disregarded in the set_brightness paths which only iterate
over the number of strings linearly.
Take an example where only string 2 is enabled with
qcom,enabled_strings=<2>: this string is appropriately enabled but
subsequent brightness changes would have only touched the zero'th
brightness register because num_strings is 1 here. This is simply
addressed by looking up the string for this index in the enabled_strings
array just like the other codepaths that iterate over num_strings.
Likewise enabled_strings is now also used in the autodetection path for
consistent behaviour: when a list of strings is specified in DT only
those strings will be probed for autodetection, analogous to how the
number of strings that need to be probed is already bound by
qcom,num-strings. After all autodetection uses the set_brightness
helpers to set an initial value, which could otherwise end up changing
brightness on a different set of strings.
Fixes:
775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Fixes:
03b2b5e86986 ("backlight: qcom-wled: Add support for WLED4 peripheral")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-10-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:53 +0000 (21:34 +0100)]
backlight: qcom-wled: Use cpu_to_le16 macro to perform conversion
[ Upstream commit
0a139358548968b2ff308257b4fbeec7badcc3e1 ]
The kernel already provides appropriate primitives to perform endianness
conversion which should be used in favour of manual bit-wrangling.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-4-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:55 +0000 (21:34 +0100)]
backlight: qcom-wled: Override default length with qcom,enabled-strings
[ Upstream commit
2b4b49602f9feca7b7a84eaa33ad9e666c8aa695 ]
The length of qcom,enabled-strings as property array is enough to
determine the number of strings to be enabled, without needing to set
qcom,num-strings to override the default number of strings when less
than the default (which is also the maximum) is provided in DT.
This also introduces an extra warning when qcom,num-strings is set,
denoting that it is not necessary to set both anymore. It is usually
more concise to set just qcom,num-length when a zero-based, contiguous
range of strings is needed (the majority of the cases), or to only set
qcom,enabled-strings when a specific set of indices is desired.
Fixes:
775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-6-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:54 +0000 (21:34 +0100)]
backlight: qcom-wled: Fix off-by-one maximum with default num_strings
[ Upstream commit
5ada78b26f935f8751852dffa24f6b545b1d2517 ]
When not specifying num-strings in the DT the default is used, but +1 is
added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
of 3 and 4 respectively, causing out-of-bounds reads and register
read/writes. This +1 exists for a deficiency in the DT parsing code,
and is simply omitted entirely - solving this oob issue - by parsing the
property separately much like qcom,enabled-strings.
This also enables more stringent checks on the maximum value when
qcom,enabled-strings is provided in the DT, by parsing num-strings after
enabled-strings to allow it to check against (and in a subsequent patch
override) the length of enabled-strings: it is invalid to set
num-strings higher than that.
The DT currently utilizes it to get around an incorrect fixed read of
four elements from that array (has been addressed in a prior patch) by
setting a lower num-strings where desired.
Fixes:
93c64f1ea1e8 ("leds: add Qualcomm PM8941 WLED driver")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-5-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:52 +0000 (21:34 +0100)]
backlight: qcom-wled: Pass number of elements to read to read_u32_array
[ Upstream commit
e29e24bdabfeddbf8b1a4ecac1af439a85150438 ]
of_property_read_u32_array takes the number of elements to read as last
argument. This does not always need to be 4 (sizeof(u32)) but should
instead be the size of the array in DT as read just above with
of_property_count_elems_of_size.
To not make such an error go unnoticed again the driver now bails
accordingly when of_property_read_u32_array returns an error.
Surprisingly the indentation of newlined arguments is lining up again
after prepending `rc = `.
Fixes:
775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-3-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 15 Nov 2021 20:34:51 +0000 (21:34 +0100)]
backlight: qcom-wled: Validate enabled string indices in DT
[ Upstream commit
c05b21ebc5bce3ecc78c2c71afd76d92c790a2ac ]
The strings passed in DT may possibly cause out-of-bounds register
accesses and should be validated before use.
Fixes:
775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20211115203459.1634079-2-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Chaignon [Mon, 20 Dec 2021 21:45:28 +0000 (22:45 +0100)]
bpftool: Enable line buffering for stdout
[ Upstream commit
1a1a0b0364ad291bd8e509da104ac8b5b1afec5d ]
The output of bpftool prog tracelog is currently buffered, which is
inconvenient when piping the output into other commands. A simple
tracelog | grep will typically not display anything. This patch fixes it
by enabling line buffering on stdout for the whole bpftool binary.
Fixes:
30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe")
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Paul Chaignon <paul@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20211220214528.GA11706@Mem
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Wed, 8 Dec 2021 23:35:48 +0000 (15:35 -0800)]
Bluetooth: L2CAP: Fix using wrong mode
[ Upstream commit
30d57722732d9736554f85f75f9d7ad5402d192e ]
If user has a set to use SOCK_STREAM the socket would default to
L2CAP_MODE_ERTM which later needs to be adjusted if the destination
address is LE which doesn't support such mode.
Fixes:
15f02b9105625 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Thu, 16 Sep 2021 11:09:22 +0000 (13:09 +0200)]
um: virtio_uml: Fix time-travel external time propagation
[ Upstream commit
85e73968a040c642fd38f6cba5b73b61f5d0f052 ]
When creating an external event, the current time needs to
be propagated to other participants of a simulation. This
is done in the places here where we kick a virtq etc.
However, it must be done for _all_ external events, and
that includes making the initial socket connection and
later closing it. Call time_travel_propagate_time() to do
this before making or closing the socket connection.
Apparently, at least for the initial connection creation,
due to the remote side in my use cases using microseconds
(rather than nanoseconds), this wasn't a problem yet; only
started failing between 5.14-rc1 and 5.15-rc1 (didn't test
others much), or possibly depending on the configuration,
where more delays happen before the virtio devices are
initialized.
Fixes:
88ce64249233 ("um: Implement time-travel=ext")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Tue, 31 Aug 2021 07:27:53 +0000 (09:27 +0200)]
um: fix ndelay/udelay defines
[ Upstream commit
5f8539e2ff962e25b57742ca7106456403abbc94 ]
Many places in the kernel use 'udelay' as an identifier, and
are broken with the current "#define udelay um_udelay". Fix
this by adding an argument to the macro, and do the same to
'ndelay' as well, just in case.
Fixes:
0bc8fb4dda2b ("um: Implement ndelay/udelay in time-travel mode")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bernard Zhao [Fri, 10 Dec 2021 12:03:58 +0000 (04:03 -0800)]
selinux: fix potential memleak in selinux_add_opt()
[ Upstream commit
2e08df3c7c4e4e74e3dd5104c100f0bf6288aaa8 ]
This patch try to fix potential memleak in error branch.
Fixes:
ba6418623385 ("selinux: new helper - selinux_add_opt()")
Signed-off-by: Bernard Zhao <bernard@vivo.com>
[PM: tweak the subject line, add Fixes tag]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Shtylyov [Fri, 17 Dec 2021 20:27:17 +0000 (23:27 +0300)]
mmc: meson-mx-sdio: add IRQ check
[ Upstream commit
8fc9a77bc64e1f23d07953439817d8402ac9706f ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes:
ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-3-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Shtylyov [Fri, 17 Dec 2021 20:27:16 +0000 (23:27 +0300)]
mmc: meson-mx-sdhc: add IRQ check
[ Upstream commit
77bed755e0f06135faccdd3948863703f9a6e640 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes:
e4bf1b0970ef ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-2-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Errera [Sun, 19 Dec 2021 10:18:15 +0000 (12:18 +0200)]
iwlwifi: mvm: test roc running status bits before removing the sta
[ Upstream commit
998e1aba6e5eb35370eaf30ccc1823426ec11f90 ]
In some cases the sta is being removed twice since we do not test the
roc aux running before removing it. Start looking at the bit before
removing the sta.
Signed-off-by: Nathan Errera <nathan.errera@intel.com>
Fixes:
2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sun, 19 Dec 2021 09:14:18 +0000 (11:14 +0200)]
iwlwifi: mvm: fix 32-bit build in FTM
[ Upstream commit
8b0f92549f2c2458200935c12a2e2a6e80234cf5 ]
On a 32-bit build, the division here needs to be done
using do_div(), otherwise the compiler will try to call
a function that doesn't exist, thus failing to build.
Fixes:
b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Behún [Tue, 9 Nov 2021 16:46:04 +0000 (17:46 +0100)]
ARM: dts: armada-38x: Add generic compatible to UART nodes
[ Upstream commit
62480772263ab6b52e758f2346c70a526abd1d28 ]
Add generic compatible string "ns16550a" to serial port nodes of Armada
38x.
This makes it possible to use earlycon.
Fixes:
0d3d96ab0059 ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Marko [Fri, 12 Nov 2021 13:44:03 +0000 (14:44 +0100)]
arm64: dts: marvell: cn9130: enable CP0 GPIO controllers
[ Upstream commit
0734f8311ce72c9041e5142769eff2083889c172 ]
CN9130 has a built-in CP115 which has 2 GPIO controllers, but unlike in
Armada 7k and 8k both are left disabled by the SoC DTSI.
This first of all makes no sense as they are always present due to being
SoC built-in and its an issue as boards like CN9130-CRB use the CPO GPIO2
pins for regulators and SD card support without enabling them first.
So, enable both of them like Armada 7k and 8k do.
Fixes:
6b8970bd8d7a ("arm64: dts: marvell: Add support for Marvell CN9130 SoC support")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Marko [Fri, 12 Nov 2021 13:44:02 +0000 (14:44 +0100)]
arm64: dts: marvell: cn9130: add GPIO and SPI aliases
[ Upstream commit
effd42600b987c1e95f946b14fefc1c7639e7439 ]
CN9130 has one CP115 built in, which like the CP110 has 2 GPIO and 2 SPI
controllers built-in.
However, unlike the Armada 7k and 8k the SoC DTSI doesn't add the required
aliases as both the Orion SPI driver and MVEBU GPIO drivers require the
aliases to be present.
So add the required aliases for GPIO and SPI controllers.
Fixes:
6b8970bd8d7a ("arm64: dts: marvell: Add support for Marvell CN9130 SoC support")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wei Yongjun [Fri, 17 Dec 2021 08:34:28 +0000 (16:34 +0800)]
usb: ftdi-elan: fix memory leak on device disconnect
[ Upstream commit
1646566b5e0c556f779180a8514e521ac735de1e ]
'ftdi' is alloced when probe device, but not free on device disconnect,
this cause a memory leak as follows:
unreferenced object 0xffff88800d584000 (size 8400):
comm "kworker/0:2", pid 3809, jiffies
4295453055 (age 13.784s)
hex dump (first 32 bytes):
00 40 58 0d 80 88 ff ff 00 40 58 0d 80 88 ff ff .@X......@X.....
00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N..
backtrace:
[<
000000000d47f947>] kmalloc_order_trace+0x19/0x110 mm/slab_common.c:960
[<
000000008548ac68>] ftdi_elan_probe+0x8c/0x880 drivers/usb/misc/ftdi-elan.c:2647
[<
000000007f73e422>] usb_probe_interface+0x31b/0x800 drivers/usb/core/driver.c:396
[<
00000000fe8d07fc>] really_probe+0x299/0xc30 drivers/base/dd.c:517
[<
0000000005da7d32>] __driver_probe_device+0x357/0x500 drivers/base/dd.c:751
[<
000000003c2c9579>] driver_probe_device+0x4e/0x140 drivers/base/dd.c:781
Fix it by freeing 'ftdi' after nobody use it.
Fixes:
a5c66e4b2418 ("USB: ftdi-elan: client driver for ELAN Uxxx adapters")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20211217083428.2441-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andre Przywara [Mon, 22 Nov 2021 15:28:43 +0000 (16:28 +0100)]
ARM: 9159/1: decompressor: Avoid UNPREDICTABLE NOP encoding
[ Upstream commit
a92882a4d270fbcc021ee6848de5e48b7f0d27f3 ]
In the decompressor's head.S we need to start with an instruction that
is some kind of NOP, but also mimics as the PE/COFF header, when the
kernel is linked as an UEFI application. The clever solution here is
"tstne r0, #0x4d000", which in the worst case just clobbers the
condition flags, and bears the magic "MZ" signature in the lowest 16 bits.
However the encoding used (0x13105a4d) is actually not valid, since bits
[15:12] are supposed to be 0 (written as "(0)" in the ARM ARM).
Violating this is UNPREDICTABLE, and *can* trigger an UNDEFINED
exception. Common Cortex cores seem to ignore those bits, but QEMU
chooses to trap, so the code goes fishing because of a missing exception
handler at this point. We are just saved by the fact that commonly (with
-kernel or when running from U-Boot) the "Z" bit is set, so the
instruction is never executed. See [0] for more details.
To make things more robust and avoid UNPREDICTABLE behaviour in the
kernel code, lets replace this with a "two-instruction NOP":
The first instruction is an exclusive OR, the effect of which the second
instruction reverts. This does not leave any trace, neither in a
register nor in the condition flags. Also it's a perfectly valid
encoding. Kudos to Peter Maydell for coming up with this gem.
[0] https://lore.kernel.org/qemu-devel/YTPIdbUCmwagL5%2FD@os.inf.tu-dresden.de/T/
Link: https://lore.kernel.org/linux-arm-kernel/20210908162617.104962-1-andre.przywara@arm.com/T/
Fixes:
81a0bc39ea19 ("ARM: add UEFI stub support")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Adam Lackorzynski <adam@l4re.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antony Antony [Sun, 12 Dec 2021 10:35:00 +0000 (11:35 +0100)]
xfrm: state and policy should fail if XFRMA_IF_ID 0
[ Upstream commit
68ac0f3810e76a853b5f7b90601a05c3048b8b54 ]
xfrm ineterface does not allow xfrm if_id = 0
fail to create or update xfrm state and policy.
With this commit:
ip xfrm policy add src 192.0.2.1 dst 192.0.2.2 dir out if_id 0
RTNETLINK answers: Invalid argument
ip xfrm state add src 192.0.2.1 dst 192.0.2.2 proto esp spi 1 \
reqid 1 mode tunnel aead 'rfc4106(gcm(aes))' \
0x1111111111111111111111111111111111111111 96 if_id 0
RTNETLINK answers: Invalid argument
v1->v2 change:
- add Fixes: tag
Fixes:
9f8550e4bd9d ("xfrm: fix disable_xfrm sysctl when used on xfrm interfaces")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Antony Antony [Sun, 12 Dec 2021 10:34:30 +0000 (11:34 +0100)]
xfrm: interface with if_id 0 should return error
[ Upstream commit
8dce43919566f06e865f7e8949f5c10d8c2493f5 ]
xfrm interface if_id = 0 would cause xfrm policy lookup errors since
Commit
9f8550e4bd9d.
Now explicitly fail to create an xfrm interface when if_id = 0
With this commit:
ip link add ipsec0 type xfrm dev lo if_id 0
Error: if_id must be non zero.
v1->v2 change:
- add Fixes: tag
Fixes:
9f8550e4bd9d ("xfrm: fix disable_xfrm sysctl when used on xfrm interfaces")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jernej Skrabec [Mon, 29 Nov 2021 18:26:25 +0000 (19:26 +0100)]
media: hantro: Fix probe func error path
[ Upstream commit
37af43b250fda6162005d47bf7c959c70d52b107 ]
If clocks for some reason couldn't be enabled, probe function returns
immediately, without disabling PM. This obviously leaves PM ref counters
unbalanced.
Fix that by jumping to appropriate error path, so effects of PM functions
are reversed.
Fixes:
775fec69008d ("media: add Rockchip VPU JPEG encoder driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robin Murphy [Fri, 10 Dec 2021 17:54:44 +0000 (17:54 +0000)]
drm/tegra: vic: Fix DMA API misuse
[ Upstream commit
5566174cb10a5167d59b0793871cab7990b149b8 ]
Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.
Also include the correct header, because the fragile transitive
inclusion currently providing it is going to break soon.
Fixes:
20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding <thierry.reding@gmail.com>
CC: Mikko Perttunen <mperttunen@nvidia.com>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephen Boyd [Wed, 15 Dec 2021 00:25:29 +0000 (16:25 -0800)]
drm/bridge: ti-sn65dsi86: Set max register for regmap
[ Upstream commit
0b665d4af35837f0a0ae63135b84a3c187c1db3b ]
Set the maximum register to 0xff so we can dump the registers for this
device in debugfs.
Fixes:
a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Cc: Rob Clark <robdclark@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215002529.382383-1-swboyd@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Baryshkov [Wed, 1 Dec 2021 22:26:27 +0000 (01:26 +0300)]
drm/msm/dpu: fix safe status debugfs file
[ Upstream commit
f31b0e24d31e18b4503eeaf0032baeacc0beaff6 ]
Make safe_status debugfs fs file actually return safe status rather than
danger status data.
Fixes:
25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Link: https://lore.kernel.org/r/20211201222633.2476780-3-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Baruch Siach [Tue, 7 Dec 2021 07:27:10 +0000 (09:27 +0200)]
arm64: dts: qcom: ipq6018: Fix gpio-ranges property
[ Upstream commit
72cb4c48a46a7cfa58eb5842c0d3672ddd5bd9ad ]
There must be three parameters in gpio-ranges property. Fixes this not
very helpful error message:
OF: /soc/pinctrl@1000000: (null) = 3 found 3
Fixes:
1e8277854b49 ("arm64: dts: Add ipq6018 SoC and CP01 board support")
Cc: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/8a744cfd96aff5754bfdcf7298d208ddca5b319a.1638862030.git.baruch@tkos.co.il
Signed-off-by: Sasha Levin <sashal@kernel.org>
Srinivas Kandagatla [Thu, 9 Dec 2021 17:53:41 +0000 (17:53 +0000)]
arm64: dts: qcom: c630: Fix soundcard setup
[ Upstream commit
c02b360ca67ebeb9de07b47b2fe53f964c2561d1 ]
Currently Soundcard has 1 rx device for headset and SoundWire Speaker Playback.
This setup has issues, ex if we try to play on headset the audio stream is
also sent to SoundWire Speakers and we will hear sound in both headsets and speakers.
Make a separate device for Speakers and Headset so that the streams are
different and handled properly.
Fixes:
45021d35fcb2 ("arm64: dts: qcom: c630: Enable audio support")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211209175342.20386-2-srinivas.kandagatla@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhou Qingyang [Mon, 13 Dec 2021 09:53:07 +0000 (11:53 +0200)]
ath11k: Fix a NULL pointer dereference in ath11k_mac_op_hw_scan()
[ Upstream commit
eccd25136386a04ebf46a64f3a34e8e0fab6d9e1 ]
In ath11k_mac_op_hw_scan(), the return value of kzalloc() is directly
used in memcpy(), which may lead to a NULL pointer dereference on
failure of kzalloc().
Fix this bug by adding a check of arg.extraie.ptr.
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_ATH11K=m show no new warnings, and our static
analyzer no longer warns about this code.
Fixes:
d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211202155348.71315-1-zhou1615@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Mon, 6 Dec 2021 02:22:01 +0000 (03:22 +0100)]
media: coda/imx-vdoa: Handle dma_set_coherent_mask error codes
[ Upstream commit
43f0633f89947df57fe0b5025bdd741768007708 ]
The return value of dma_set_coherent_mask() is not always 0.
To catch the exception in case that dma is not support the mask.
Link: https://lore.kernel.org/linux-media/20211206022201.1639460-1-jiasheng@iscas.ac.cn
Fixes:
b0444f18e0b1 ("[media] coda: add i.MX6 VDOA driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Tue, 26 Oct 2021 11:23:48 +0000 (13:23 +0200)]
media: msi001: fix possible null-ptr-deref in msi001_probe()
[ Upstream commit
3d5831a40d3464eea158180eb12cbd81c5edfb6a ]
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address:
0000000000000060
...
RIP: 0010:v4l2_ctrl_auto_cluster+0x57/0x270
...
Call Trace:
msi001_probe+0x13b/0x24b [msi001]
spi_probe+0xeb/0x130
...
do_syscall_64+0x35/0xb0
In msi001_probe(), if the creation of control for bandwidth_auto
fails, there will be a null-ptr-deref issue when it is used in
v4l2_ctrl_auto_cluster().
Check dev->hdl.error before v4l2_ctrl_auto_cluster() to fix this bug.
Link: https://lore.kernel.org/linux-media/20211026112348.2878040-1-wanghai38@huawei.com
Fixes:
93203dd6c7c4 ("[media] msi001: Mirics MSi001 silicon tuner driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anton Vasilyev [Thu, 22 Aug 2019 10:41:47 +0000 (12:41 +0200)]
media: dw2102: Fix use after free
[ Upstream commit
589a9f0eb799f77de2c09583bf5bad221fa5d685 ]
dvb_usb_device_init stores parts of properties at d->props
and d->desc and uses it on dvb_usb_device_exit.
Free of properties on module probe leads to use after free.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204597
The patch makes properties static instead of allocated on heap to prevent
memleak and use after free.
Also fixes s421_properties.devices initialization to have 2 element
instead of 6 copied from p7500_properties.
[mchehab: fix function call alignments]
Link: https://lore.kernel.org/linux-media/20190822104147.4420-1-vasilyev@ispras.ru
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Fixes:
299c7007e936 ("media: dw2102: Fix memleak on sequence of probes")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian Lamparter [Mon, 6 Dec 2021 00:43:34 +0000 (01:43 +0100)]
ARM: dts: gemini: NAS4220-B: fis-index-block with 128 KiB sectors
[ Upstream commit
4754eab7e5a78bdefe7a960c5c260c95ebbb5fa6 ]
Steven Maddox reported in the OpenWrt bugzilla, that his
RaidSonic IB-NAS4220-B was no longer booting with the new
OpenWrt 21.02 (uses linux 5.10's device-tree). However, it was
working with the previous OpenWrt 19.07 series (uses 4.14).
|[ 5.548038] No RedBoot partition table detected in
30000000.flash
|[ 5.618553] Searching for RedBoot partition table in
30000000.flash at offset 0x0
|[ 5.739093] No RedBoot partition table detected in
30000000.flash
|...
|[ 7.039504] Waiting for root device /dev/mtdblock3...
The provided bootlog shows that the RedBoot partition parser was
looking for the partition table "at offset 0x0". Which is strange
since the comment in the device-tree says it should be at 0xfe0000.
Further digging on the internet led to a review site that took
some useful PCB pictures of their review unit back in February 2009.
Their picture shows a Spansion S29GL128N11TFI01 flash chip.
>From Spansion's Datasheet:
"S29GL128N: One hundred twenty-eight 64 Kword (128 Kbyte) sectors"
Steven also provided a "cat /sys/class/mtd/mtd0/erasesize" from his
unit: "131072".
With the 128 KiB Sector/Erasesize in mind. This patch changes the
fis-index-block property to (0xfe0000 / 0x20000) = 0x7f.
Fixes:
b5a923f8c739 ("ARM: dts: gemini: Switch to redboot partition parsing")
Reported-by: Steven Maddox <s.maddox@lantizia.me.uk>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Steven Maddox <s.maddox@lantizia.me.uk>
Link: https://lore.kernel.org/r/20211206004334.4169408-1-linus.walleij@linaro.org'
Bugzilla: https://bugs.openwrt.org/index.php?do=details&task_id=4137
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rameshkumar Sundaram [Thu, 9 Dec 2021 17:37:01 +0000 (23:07 +0530)]
ath11k: Fix deleting uninitialized kernel timer during fragment cache flush
[ Upstream commit
ba53ee7f7f38cf0592b8be1dcdabaf8f7535f8c1 ]
frag_timer will be created & initialized for stations when
they associate and will be deleted during every key installation
while flushing old fragments.
For AP interface self peer will be created and Group keys
will be installed for this peer, but there will be no real
Station entry & hence frag_timer won't be created and
initialized, deleting such uninitialized kernel timers causes below
warnings and backtraces printed with CONFIG_DEBUG_OBJECTS_TIMERS
enabled.
[ 177.828008] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0
[ 177.836833] WARNING: CPU: 3 PID: 188 at lib/debugobjects.c:508 debug_print_object+0xb0/0xf0
[ 177.845185] Modules linked in: ath11k_pci ath11k qmi_helpers qrtr_mhi qrtr ns mhi
[ 177.852679] CPU: 3 PID: 188 Comm: hostapd Not tainted 5.14.0-rc3-32919-g4034139e1838-dirty #14
[ 177.865805] pstate:
60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[ 177.871804] pc : debug_print_object+0xb0/0xf0
[ 177.876155] lr : debug_print_object+0xb0/0xf0
[ 177.880505] sp :
ffffffc01169b5a0
[ 177.883810] x29:
ffffffc01169b5a0 x28:
ffffff80081c2320 x27:
ffffff80081c4078
[ 177.890942] x26:
ffffff8003fe8f28 x25:
ffffff8003de9890 x24:
ffffffc01134d738
[ 177.898075] x23:
ffffffc010948f20 x22:
ffffffc010b2d2e0 x21:
ffffffc01169b628
[ 177.905206] x20:
ffffffc01134d700 x19:
ffffffc010c80d98 x18:
00000000000003f6
[ 177.912339] x17:
203a657079742074 x16:
63656a626f202930 x15:
0000000000000152
[ 177.919471] x14:
0000000000000152 x13:
00000000ffffffea x12:
ffffffc010d732e0
[ 177.926603] x11:
0000000000000003 x10:
ffffffc010d432a0 x9 :
ffffffc010d432f8
[ 177.933735] x8 :
000000000002ffe8 x7 :
c0000000ffffdfff x6 :
0000000000000001
[ 177.940866] x5 :
0000000000000000 x4 :
0000000000000000 x3 :
00000000ffffffff
[ 177.947997] x2 :
ffffffc010c93240 x1 :
ffffff80023624c0 x0 :
0000000000000054
[ 177.955130] Call trace:
[ 177.957567] debug_print_object+0xb0/0xf0
[ 177.961570] debug_object_assert_init+0x124/0x178
[ 177.966269] try_to_del_timer_sync+0x1c/0x70
[ 177.970536] del_timer_sync+0x30/0x50
[ 177.974192] ath11k_peer_frags_flush+0x34/0x68 [ath11k]
[ 177.979439] ath11k_mac_op_set_key+0x1e4/0x338 [ath11k]
[ 177.984673] ieee80211_key_enable_hw_accel+0xc8/0x3d0
[ 177.989722] ieee80211_key_replace+0x360/0x740
[ 177.994160] ieee80211_key_link+0x16c/0x210
[ 177.998337] ieee80211_add_key+0x138/0x338
[ 178.002426] nl80211_new_key+0xfc/0x258
[ 178.006257] genl_family_rcv_msg_doit.isra.17+0xd8/0x120
[ 178.011565] genl_rcv_msg+0xd8/0x1c8
[ 178.015134] netlink_rcv_skb+0x38/0xf8
[ 178.018877] genl_rcv+0x34/0x48
[ 178.022012] netlink_unicast+0x174/0x230
[ 178.025928] netlink_sendmsg+0x188/0x388
[ 178.029845] ____sys_sendmsg+0x218/0x250
[ 178.033763] ___sys_sendmsg+0x68/0x90
[ 178.037418] __sys_sendmsg+0x44/0x88
[ 178.040988] __arm64_sys_sendmsg+0x20/0x28
[ 178.045077] invoke_syscall.constprop.5+0x54/0xe0
[ 178.049776] do_el0_svc+0x74/0xc0
[ 178.053084] el0_svc+0x10/0x18
[ 178.056133] el0t_64_sync_handler+0x88/0xb0
[ 178.060310] el0t_64_sync+0x148/0x14c
[ 178.063966] ---[ end trace
8a5cf0bf9d34a058 ]---
Add changes to not to delete frag timer for peers during
group key installation.
Tested on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01092-QCAHKSWPL_SILICONZ-1
Fixes:
c3944a562102 ("ath11k: Clear the fragment cache during key install")
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1639071421-25078-1-git-send-email-quic_ramess@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Herbert Xu [Wed, 1 Dec 2021 06:30:41 +0000 (17:30 +1100)]
crypto: stm32 - Revert broken pm_runtime_resume_and_get changes
[ Upstream commit
3d6b661330a7954d8136df98160d525eb04dcd6a ]
We should not call pm_runtime_resume_and_get where the reference
count is expected to be incremented unconditionally. This patch
reverts these calls to the original unconditional get_sync call.
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Fixes:
747bf30fd944 ("crypto: stm32/cryp - Fix PM reference leak...")
Fixes:
1cb3ad701970 ("crypto: stm32/hash - Fix PM reference leak...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicolas Toromanoff [Tue, 30 Nov 2021 07:55:00 +0000 (08:55 +0100)]
crypto: stm32/cryp - fix bugs and crash in tests
[ Upstream commit
4b898d5cfa4d9a0ad5bc82cb5eafdc092394c6a9 ]
Extra crypto manager auto test were crashing or failling due
to 2 reasons:
- block in a dead loop (dues to issues in cipher end process management)
- crash due to read/write unmapped memory (this crash was also reported
when using openssl afalg engine)
Rework interrupt management, interrupts are masked as soon as they are
no more used: if input buffer is fully consumed, "Input FIFO not full"
interrupt is masked and if output buffer is full, "Output FIFO not
empty" interrupt is masked.
And crypto request finish when input *and* outpout buffer are fully
read/write.
About the crash due to unmapped memory, using scatterwalk_copychunks()
that will map and copy each block fix the issue.
Using this api and copying full block will also fix unaligned data
access, avoid early copy of in/out buffer, and make useless the extra
alignment constraint.
Fixes:
9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")
Reported-by: Marek Vasut <marex@denx.de>
Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@foss.st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicolas Toromanoff [Tue, 30 Nov 2021 07:54:59 +0000 (08:54 +0100)]
crypto: stm32/cryp - fix lrw chaining mode
[ Upstream commit
fa97dc2d48b476ea98199d808d3248d285987e99 ]
This fixes the lrw autotest if lrw uses the CRYP as the AES block cipher
provider (as ecb(aes)). At end of request, CRYP should not update the IV
in case of ECB chaining mode. Indeed the ECB chaining mode never uses
the IV, but the software LRW chaining mode uses the IV field as
a counter and due to the (unexpected) update done by CRYP while the AES
block process, the counter get a wrong value when the IV overflow.
Fixes:
5f49f18d27cd ("crypto: stm32/cryp - update to return iv_out")
Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@foss.st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>