09 Jan, 2017
14 commits
-
commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream.
The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.
Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.Signed-off-by: Adrian Hunter
Tested-by: Dan O'Donovan
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream.
This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit d1f1c0e289e1bc46cd6873ba6dd6c627f459e7fa upstream.
Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:===============================
[ INFO: suspicious RCU usage. ]
4.9.0-rc8 #11 Not tainted
-------------------------------
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/7/0:
#0:
(
rcu_read_lock
){......}
, at:
[] ath_tx_edma_tasklet+0x0/0x450 [ath9k]stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
Call Trace:
[] dump_stack+0x68/0x93
[] lockdep_rcu_suspicious+0xd7/0x110
[] rcu_eqs_enter_common.constprop.85+0x154/0x200
[] rcu_irq_exit+0x44/0xa0
[] irq_exit+0x61/0xd0
[] do_IRQ+0x65/0x110
[] common_interrupt+0x89/0x89
[] ? cpuidle_enter_state+0x151/0x200
[] cpuidle_enter+0x12/0x20
[] call_cpuidle+0x1e/0x40
[] cpu_startup_entry+0x146/0x220
[] start_secondary+0x148/0x170Signed-off-by: Tobias Klausmann
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Acked-by: Felix Fietkau
Acked-by: Paul E. McKenney
Tested-by: Gabriel Craciunescu
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream.
The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
Signed-off-by: Vittorio Gambaletta
[kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 91851cc7a939039bd401adb6ca3da4402bec1d0c upstream.
Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the
moment, but should be fixed anyway.Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Signed-off-by: Matthias Schiffer
[kvalo@qca.qualcomm.com: mention that doesn't fix any known bug]
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream.
When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit c59f13bbead475096bdfebc7ef59c12e180858de upstream.
The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
8723bu devices not being able to reconnect.Reported-by: Barry Day
Signed-off-by: Jes Sorensen
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream.
If the pmu registration fails the registered hotplug callbacks are not
removed. Wrong in any case, but fatal in case of a modular driver.Replace the nonsensical state names with proper ones while at it.
Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug state machine")
Signed-off-by: Thomas Gleixner
Cc: Sebastian Siewior
Cc: Peter Zijlstra
Signed-off-by: Greg Kroah-Hartman -
commit edee44be59190bf22d5c6e521f3852b7ff16862f upstream.
'perf report --tui' exits with error when it finds a sample of zero
length symbol (i.e. addr == sym->start == sym->end). Actually these are
valid samples. Don't exit TUI and show report with such symbols.Reported-and-Tested-by: Anton Blanchard
Link: https://lkml.org/lkml/2016/10/8/189
Signed-off-by: Ravi Bangoria
Cc: Alexander Shishkin
Cc: Benjamin Herrenschmidt
Cc: Chris Riyder
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Masami Hiramatsu
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1479804050-5028-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream.
An earlier patch allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.Signed-off-by: Andi Kleen
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: alexander.shishkin@intel.com
Cc: kan.liang@intel.com
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
Link: http://lkml.kernel.org/r/20161209001417.4713-1-andi@firstfloor.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.
In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
to use work queue"), an error was introduced in the power-save routines
due to the fact that leaving PS was delayed by the use of a work queue.This problem is fixed by detecting if the enter or leave routines are
in interrupt mode. If so, the workqueue is used to place the request.
If in normal mode, the enter or leave routines are called directly.Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
Reported-by: Ping-Ke Shih
Signed-off-by: Larry Finger
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream.
During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream.
When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.Signed-off-by: Larry Finger
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman
06 Jan, 2017
26 commits
-
commit 334bb773876403eae3457d81be0b8ea70f8e4ccc upstream.
Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.Signed-off-by: Adam Borowski
Tested-by: Kalle Valo
Acked-by: Nicholas Piggin
Tested-by: Peter Wu
Tested-by: Oliver Hartkopp
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit 152b695d74376bfe55cd2a6265ccc75b0d39dd19 upstream.
Both Debian and kernel archs are "arm64" but UTS_MACHINE and gcc say
"aarch64". Recognizing just the latter should be enough but let's
accept both in case something regresses again or an user sets
UTS_MACHINE=arm64.Regressed in cfa88c7: arm64: Set UTS_MACHINE in the Makefile.
Signed-off-by: Adam Borowski
Acked-by: Riku Voipio
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit 6b10b23ca94451fae153a5cc8d62fd721bec2019 upstream.
xlog_recover_clear_agi_bucket didn't set the
type to XFS_BLFT_AGI_BUF, so we got a warning during log
replay (or an ASSERT on a debug build).XFS (md0): Unknown buffer type 0!
XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1Fix this, as was done in f19b872b for 2 other locations
with the same problem.Signed-off-by: Eric Sandeen
Reviewed-by: Brian Foster
Reviewed-by: Christoph Hellwig
Signed-off-by: Dave Chinner
Signed-off-by: Greg Kroah-Hartman -
commit 4dfce57db6354603641132fac3c887614e3ebe81 upstream.
There have been several reports over the years of NULL pointer
dereferences in xfs_trans_log_inode during xfs_fsr processes,
when the process is doing an fput and tearing down extents
on the temporary inode, something like:BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
PID: 29439 TASK: ffff880550584fa0 CPU: 6 COMMAND: "xfs_fsr"
[exception RIP: xfs_trans_log_inode+0x10]
#9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs]
#10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs]
#11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs]
#12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs]
#13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs]
#14 [ffff8800a57bbe00] evict at ffffffff811e1b67
#15 [ffff8800a57bbe28] iput at ffffffff811e23a5
#16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8
#17 [ffff8800a57bbe88] dput at ffffffff811dd06c
#18 [ffff8800a57bbea8] __fput at ffffffff811c823b
#19 [ffff8800a57bbef0] ____fput at ffffffff811c846e
#20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27
#21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c
#22 [ffff8800a57bbf50] int_signal at ffffffff8161405dAs it turns out, this is because the i_itemp pointer, along
with the d_ops pointer, has been overwritten with zeros
when we tear down the extents during truncate. When the in-core
inode fork on the temporary inode used by xfs_fsr was originally
set up during the extent swap, we mistakenly looked at di_nextents
to determine whether all extents fit inline, but this misses extents
generated by speculative preallocation; we should be using if_bytes
instead.This mistake corrupts the in-memory inode, and code in
xfs_iext_remove_inline eventually gets bad inputs, causing
it to memmove and memset incorrect ranges; this became apparent
because the two values in ifp->if_u2.if_inline_ext[1] contained
what should have been in d_ops and i_itemp; they were memmoved due
to incorrect array indexing and then the original locations
were zeroed with memset, again due to an array overrun.Fix this by properly using i_df.if_bytes to determine the number
of extents, not di_nextents.Thanks to dchinner for looking at this with me and spotting the
root cause.Signed-off-by: Eric Sandeen
Reviewed-by: Brian Foster
Signed-off-by: Dave Chinner
Signed-off-by: Greg Kroah-Hartman -
commit 24d5373dda7c00a438d26016bce140299fae675e upstream.
The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.[1]
[ 0.023921] illegal size (48) or align (48) for percpu allocation
[ 0.024167] ------------[ cut here ]------------
[ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[ 0.024584] Modules linked in:
[ 0.024708]
[ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[ 0.025012] Hardware name: Foundation-v8A (DT)
[ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[ 0.025351] PC is at pcpu_alloc+0x88/0x6c0
[ 0.025490] LR is at pcpu_alloc+0x88/0x6c0
[ 0.025624] pc : [] lr : []
pstate: 60000045
[ 0.025830] sp : ffff80003d847cd0
[ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[ 0.026147] x27: 0000000000000000 x26: 0000000000000000
[ 0.026348] x25: 0000000000000000 x24: 0000000000000000
[ 0.026549] x23: 0000000000000000 x22: 00000000024000c0
[ 0.026752] x21: ffff000008e97000 x20: 0000000000000000
[ 0.026953] x19: 0000000000000030 x18: 0000000000000010
[ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[ 0.027782] x11: 0000000000000006 x10: 0000000000000042
[ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[ 0.029056]
[ 0.029152] ---[ end trace 0000000000000000 ]---
[ 0.029297] Call trace:
[ 0.029403] Exception stack(0xffff80003d847b00 to
0xffff80003d847c30)
[ 0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[ 0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[ 0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[ 0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[ 0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[ 0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[ 0.032051] [] pcpu_alloc+0x88/0x6c0
[ 0.032229] [] __alloc_percpu+0x18/0x20
[ 0.032409] [] xen_guest_init+0x174/0x2f4
[ 0.032591] [] do_one_initcall+0x38/0x130
[ 0.032783] [] kernel_init_freeable+0xe0/0x248
[ 0.032995] [] kernel_init+0x10/0x100
[ 0.033172] [] ret_from_fork+0x10/0x50Reported-by: Wei Chen
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.
Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb(which can happen if guest's vdisk has direct-io-safe option).
To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().Reported-by: Olaf Hering
Suggested-by: Hugh Dickins
Signed-off-by: Boris Ostrovsky
Acked-by: Hugh Dickins
Tested-by: Olaf Hering
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman -
commit 1f0f30e404b3d8f4597a2d9b77fba55452f8fd0e upstream.
tpm_chip_unregister can only be called after tpm_chip_register.
devm manages the allocation so no unwind is needed here.Fixes: afb5abc262e96 ("tpm: two-phase chip management functions")
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 2d13bb6494c807bcf3f78af0e96c0b8615a94385 upstream.
We've got a delay loop waiting for secondary CPUs. That loop uses
loops_per_jiffy. However, loops_per_jiffy doesn't actually mean how
many tight loops make up a jiffy on all architectures. It is quite
common to see things like this in the boot log:Calibrating delay loop (skipped), value calculated using timer
frequency.. 48.00 BogoMIPS (lpj=24000)In my case I was seeing lots of cases where other CPUs timed out
entering the debugger only to print their stack crawls shortly after the
kdb> prompt was written.Elsewhere in kgdb we already use udelay(), so that should be safe enough
to use to implement our timeout. We'll delay 1 ms for 1000 times, which
should give us a full second of delay (just like the old code wanted)
but allow us to notice that we're done every 1 ms.[akpm@linux-foundation.org: simplifications, per Daniel]
Link: http://lkml.kernel.org/r/1477091361-2039-1-git-send-email-dianders@chromium.org
Signed-off-by: Douglas Anderson
Reviewed-by: Daniel Thompson
Cc: Jason Wessel
Cc: Brian Norris
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit f06f35c66fdbd5ac38901a3305ce763a0cd59375 upstream.
This patch fixes a off-by-one in the "watchdog: qcom: add option for
standalone watchdog not in timer block" patch that causes the
following panic on boot:> Unhandled fault: external abort on non-linefetch (0x1008) at 0xc8874002
> pgd = c0204000
> [c8874002] *pgd=87806811, *pte=0b017653, *ppte=0b017453
> Internal error: : 1008 [#1] SMP ARM
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.6 #0
> Hardware name: Generic DT based system
> PC is at 0xc02222f4
> LR is at 0x1
> pc : [] lr : [] psr: 00000113
> sp : c782fc98 ip : 00000003 fp : 00000000
> r10: 00000004 r9 : c782e000 r8 : c04ab98c
> r7 : 00000001 r6 : c8874002 r5 : c782fe00 r4 : 00000002
> r3 : 00000000 r2 : c782fe00 r1 : 00100000 r0 : c8874002
> Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 8020406a DAC: 00000051
> Process swapper/0 (pid: 1, stack limit = 0xc782e210)
> Stack: (0xc782fc98 to 0xc7830000)
> [...]The WDT_STS (status) needs to be translated via wdt_addr as well.
fixes: f0d9d0f4b44a ("watchdog: qcom: add option for standalone watchdog not in timer block")
Signed-off-by: Christian Lamparter
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 9eff1140a82db8c5520f76e51c21827b4af670b3 upstream.
Systemd on reboot enables shutdown watchdog that leaves the watchdog
device open to ensure that even if power down process get stuck the
platform reboots nonetheless.
The iamt_wdt is an alarm-only watchdog and can't reboot system, but the
FW will generate an alarm event reboot was completed in time, as the
watchdog is not automatically disabled during power cycle.
So we should request stop watchdog on reboot to eliminate wrong alarm
from the FW.Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Reviewed-by: Guenter Roeck
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 4d1f0fb096aedea7bb5489af93498a82e467c480 upstream.
NMI handler doesn't call set_irq_regs(), it's set only by normal IRQ.
Thus get_irq_regs() returns NULL or stale registers snapshot with IP/SP
pointing to the code interrupted by IRQ which was interrupted by NMI.
NULL isn't a problem: in this case watchdog calls dump_stack() and
prints full stack trace including NMI. But if we're stuck in IRQ
handler then NMI watchlog will print stack trace without IRQ part at
all.This patch uses registers snapshot passed into NMI handler as arguments:
these registers point exactly to the instruction interrupted by NMI.Fixes: 55537871ef66 ("kernel/watchdog.c: perform all-CPU backtrace in case of hard lockup")
Link: http://lkml.kernel.org/r/146771764784.86724.6006627197118544150.stgit@buzz
Signed-off-by: Konstantin Khlebnikov
Cc: Jiri Kosina
Cc: Ulrich Obergfell
Cc: Aaron Tomlin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e3d240e9d505fc67f8f8735836df97a794bbd946 upstream.
If maxBuf is not 0 but less than a size of SMB2 lock structure
we can end up with a memory corruption.Signed-off-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit b0a752b5ce76bd1d8b733a53757c3263511dcb69 upstream.
Reviewed-by: Aurelien Aptel
Acked-by: Sachin Prabhu
Signed-off-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit 96a988ffeb90dba33a71c3826086fe67c897a183 upstream.
With the current code it is possible to lock a mutex twice when
a subsequent reconnects are triggered. On the 1st reconnect we
reconnect sessions and tcons and then persistent file handles.
If the 2nd reconnect happens during the reconnecting of persistent
file handles then the following sequence of calls is observed:cifs_reopen_file -> SMB2_open -> small_smb2_init -> smb2_reconnect
-> cifs_reopen_persistent_file_handles -> cifs_reopen_file (again!).So, we are trying to acquire the same cfile->fh_mutex twice which
is wrong. Fix this by moving reconnecting of persistent handles to
the delayed work (smb2_reconnect_server) and submitting this work
every time we reconnect tcon in SMB2 commands handling codepath.This can also lead to corruption of a temporary file list in
cifs_reopen_persistent_file_handles() because we can recursively
call this function twice.Signed-off-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit 4772c79599564bd08ee6682715a7d3516f67433f upstream.
Acked-by: Sachin Prabhu
Signed-off-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit 53e0e11efe9289535b060a51d4cf37c25e0d0f2b upstream.
We can not unlock/lock cifs_tcp_ses_lock while walking through ses
and tcon lists because it can corrupt list iterator pointers and
a tcon structure can be released if we don't hold an extra reference.
Fix it by moving a reconnect process to a separate delayed work
and acquiring a reference to every tcon that needs to be reconnected.
Also do not send an echo request on newly established connections.Signed-off-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit 06deeec77a5a689cc94b21a8a91a76e42176685d upstream.
smbencrypt() points a scatterlist to the stack, which is breaks if
CONFIG_VMAP_STACK=y.Fix it by switching to crypto_cipher_encrypt_one(). The new code
should be considerably faster as an added benefit.This code is nearly identical to some code that Eric Biggers
suggested.Reported-by: Eric Biggers
Signed-off-by: Andy Lutomirski
Acked-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 2fc995a87f2efcd803438f07bfecd35cc3d90d32 upstream.
When ASoC Intel SST Medfield driver is probed but without codec / card
assigned, it causes an Oops and freezes the kernel at suspend/resume,PM: Suspending system (freeze)
Suspending console(s) (use no_console_suspend to debug)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
IP: [] sst_soc_prepare+0x19/0xa0 [snd_soc_sst_mfld_platform]
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 1552 Comm: systemd-sleep Tainted: G W 4.9.0-rc6-1.g5f5c2ad-default #1
Call Trace:
[] dpm_prepare+0x209/0x460
[] dpm_suspend_start+0x11/0x60
[] suspend_devices_and_enter+0xb2/0x710
[] pm_suspend+0x30e/0x390
[] state_store+0x8a/0x90
[] kobj_attr_store+0xf/0x20
[] sysfs_kf_write+0x37/0x40
[] kernfs_fop_write+0x11c/0x1b0
[] __vfs_write+0x28/0x140
[] ? apparmor_file_permission+0x18/0x20
[] ? security_file_permission+0x3b/0xc0
[] vfs_write+0xb5/0x1a0
[] SyS_write+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x1e/0xadAdd proper NULL checks in the PM code of mdfld driver.
Signed-off-by: Takashi Iwai
Acked-by: Vinod Koul
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 314c25c56c1ee5026cf99c570bdfe01847927acb upstream.
In dm_sm_metadata_create() we temporarily change the dm_space_map
operations from 'ops' (whose .destroy function deallocates the
sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't).If dm_sm_metadata_create() fails in sm_ll_new_metadata() or
sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls
dm_sm_destroy() with the intention of freeing the sm_metadata, but it
doesn't (because the dm_space_map operations is still set to
'bootstrap_ops').Fix this by setting the dm_space_map operations back to 'ops' if
dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'.Signed-off-by: Benjamin Marzinski
Acked-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 11e2968478edc07a75ee1efb45011b3033c621c2 upstream.
Commit ecbfb9f118 ("dm raid: add raid level takeover support") moved the
configure_discard_support() call from raid_ctr() to raid_preresume().Enabling/disabling discard _must_ happen during table load (through the
.ctr hook). Fix this regression by moving the
configure_discard_support() call back to raid_ctr().Fixes: ecbfb9f118 ("dm raid: add raid level takeover support")
Signed-off-by: Heinz Mauelshagen
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit d15bb3a6467e102e60d954aadda5fb19ce6fd8ec upstream.
It is required to hold the queue lock when calling blk_run_queue_async()
to avoid that a race between blk_run_queue_async() and
blk_cleanup_queue() is triggered.Signed-off-by: Bart Van Assche
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 265e9098bac02bc5e36cda21fdbad34cb5b2f48d upstream.
In crypt_set_key(), if a failure occurs while replacing the old key
(e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag
set. Otherwise, the crypto layer would have an invalid key that still
has DM_CRYPT_KEY_VALID flag set.Signed-off-by: Ondrej Kozina
Reviewed-by: Mikulas Patocka
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit bff7e067ee518f9ed7e1cbc63e4c9e01670d0b71 upstream.
Fix to return error code -EINVAL instead of 0, as is done elsewhere in
this function.Fixes: e80d1c805a3b ("dm: do not override error code returned from dm_get_device()")
Signed-off-by: Wei Yongjun
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 301fc3f5efb98633115bd887655b19f42c6dfaa8 upstream.
When dm_table_set_type() is used by a target to establish a DM table's
type (e.g. DM_TYPE_MQ_REQUEST_BASED in the case of DM multipath) the
DM core must go on to verify that the devices in the table are
compatible with the established type.Fixes: e83068a5 ("dm mpath: add optional "queue_mode" feature")
Signed-off-by: Bart Van Assche
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 6936c12cf809850180b24947271b8f068fdb15e9 upstream.
An earlier DM multipath table could have been build ontop of underlying
devices that were all using blk-mq. In that case, if that active
multipath table is replaced with an empty DM multipath table (that
reflects all paths have failed) then it is important that the
'all_blk_mq' state of the active table is transfered to the new empty DM
table. Otherwise dm-rq.c:dm_old_prep_tio() will incorrectly clone a
request that isn't needed by the DM multipath target when it is to issue
IO to an underlying blk-mq device.Fixes: e83068a5 ("dm mpath: add optional "queue_mode" feature")
Reported-by: Bart Van Assche
Tested-by: Bart Van Assche
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
