Age | Commit message (Collapse) | Author | Files | Lines |
|
DNV's iTCO is slightly different with SMBCTRL sitting at a different
offset when compared to all other devices. Let's fix so that we can
properly use iTCO watchdog.
Fixes: 84d7f2ebd70d ("i2c: i801: Add support for Intel DNV")
Cc: <[email protected]> # v4.4+
Signed-off-by: Felipe Balbi <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
Since commit d1ac3ff008fb ("dm verity: switch to using asynchronous hash
crypto API") dm-verity uses asynchronous crypto calls for verification,
so that it can use hardware with asynchronous processing of crypto
operations.
These asynchronous calls don't support vmalloc memory, but the buffer data
can be allocated with vmalloc if dm-bufio is short of memory and uses a
reserved buffer that was preallocated in dm_bufio_client_create().
Fix verity_hash_update() so that it deals with vmalloc'd memory
correctly.
Reported-by: "Xiao, Jin" <[email protected]>
Signed-off-by: Mikulas Patocka <[email protected]>
Fixes: d1ac3ff008fb ("dm verity: switch to using asynchronous hash crypto API")
Cc: [email protected] # 4.12+
Signed-off-by: Mike Snitzer <[email protected]>
|
|
after unbinding mmc I get things like this:
[ 185.294067] mmc1: card 0001 removed
[ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
The wakeirq stays in /proc-interrupts
rebinding shows this:
[ 289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup)
[ 289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ
[ 289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling
That bug seems to be introduced by switching from devm_request_irq()
to generic wakeirq handling.
So let us cleanup at removal.
Signed-off-by: Andreas Kemnade <[email protected]>
Fixes: 5b83b2234be6 ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq")
Cc: [email protected] # v4.2+
Signed-off-by: Ulf Hansson <[email protected]>
|
|
Handle guest mm access life cycle properly with mmget()/mmput().
As noted by Linus, use_mm() depends on valid live page table but
KVM's mmgrab() doesn't guarantee that. As vGPU usage depends on
guest VM life cycle, need to make sure to use mmget()/mmput() to
guarantee VM address access.
v3: fix build
v2: v1 caused a weird dependence issue which failed for vfio
device release, which result invalid mdev vgpu and kvm state
without proper release taken. This trys to put right reference
around VM address space access instead.
Cc: Linus Torvalds <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Zhi Wang <[email protected]>
Reviewed-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Here are quite a large number of fixes, notably:
* various A-MSDU building fixes (currently only affects mt76)
* syzkaller & spectre fixes in hwsim
* TXQ vs. teardown fix that was causing crashes
* embed WMM info in reg rule, bad code here had been causing crashes
* one compilation issue with fix from Arnd (rfkill-gpio includes)
* fixes for a race and bad data during/after channel switch
* nl80211: a validation fix, attribute type & unit fixes
along with other small fixes.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently, the driver adjusts the bp->hw_resc.max_cp_rings by the number
of MSIX vectors used by RDMA. There is one code path in open that needs
to check the true max_cp_rings including any used by RDMA. This code
is now checking for the reduced max_cp_rings which will fail when the
number of cp rings is very small.
To fix this in a clean way, we don't adjust max_cp_rings anymore.
Instead, we add a helper bnxt_get_max_func_cp_rings_for_en() to get the
reduced max_cp_rings when appropriate.
Fixes: ec86f14ea506 ("bnxt_en: Add ULP calls to stop and restart IRQs.")
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Remove unused bnxt_subtract_ulp_resources(). Change
bnxt_get_max_func_irqs() to static since it is only locally used.
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When the driver detects that resources have changed during open, it
should reset the rx and tx rings to 0. This will properly setup the
init sequence to initialize the default rings again. We also need
to signal the RDMA driver to stop and clear its interrupts. We then
call the RoCE driver to restart if a new set of default rings is
successfully reserved.
Fixes: 25e1acd6b92b ("bnxt_en: Notify firmware about IF state changes.")
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
__emac_calc_base_mr1 was used instead of __emac4_calc_base_mr1
by copy-paste mistake for emac4syn.
Fixes: 45d6e545505fd32edb812f085be7de45b6a5c0af ("net/ibm/emac: add 8192 rx/tx fifo size")
Signed-off-by: Ivan Mikhaylov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
inadvertently stopped enabling the pipe clock for any DP-MST stream
after the first one. It also rearranged the pipe clock enabling wrt.
initial MST payload allocation step (which may or may not be a
problem, but it's contrary to the spec.).
Fix things by making the above commit truly a non-functional change.
Fixes: afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
Reported-by: Lyude Paul <[email protected]>
Reported-by: [email protected]
Tested-by: [email protected]
Tested-by: Lyude Paul <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: [email protected]
Cc: Ville Syrjälä <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 2b5cf4ef541f1b2facaca58cae5e8e0b5f19ad4c)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
This patch fixes the PPS4 and PPS5 register definition macros that were
resulting into an incorect MMIO address.
Fixes: 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register definitions")
Cc: Anusha Srivatsa <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Anusha Srivatsa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 5df52391ddbed869c7d67b00fbb013bd64334115)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
pulse"
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
DP link retraining into the ->post_hotplug() hook")
Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook")
[Cleaned up commit message, added stable cc]
Signed-off-by: Lyude Paul <[email protected]>
Signed-off-by: Jan-Marek Glogowski <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
drm-intel-fixes
gvt-fixes-2018-09-04
- two BXT virtual display emulation fixes (Colin)
- gen9 dbuf guest warning fix (Xiaolin)
- vgpu close pm warning fix (Hang)
- dmabuf format_mod fix (Zhenyu)
- multiple VM guest failure fix for scheduling (Zhenyu)
Signed-off-by: Rodrigo Vivi <[email protected]>
From: Zhenyu Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This card identifies itself as:
Ethernet controller [0200]: NCube Device [10ff:8168] (rev 06)
Subsystem: TP-LINK Technologies Co., Ltd. Device [7470:3468]
Adding a new entry to rtl8169_pci_tbl makes the card work.
Link: http://launchpad.net/bugs/1788730
Signed-off-by: Anthony Wong <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This trys to give new born vGPU with higher scheduling chance
not only with adding to sched list head and also have higher
priority for workload sched for 2 seconds after starting to
schedule it. In order for fast GPU execution during VM boot,
and ensure guest driver setup with required state given in time.
This fixes recent failure seen on one VM with multiple linux VMs
running on kernel with commit 2621cefaa42b3("drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup"),
which had shorter setup timeout that caused context state init failed.
v2: change to 2s for higher scheduling period
Cc: Yuan Hang <[email protected]>
Reviewed-by: Hang Yuan <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
Pull dma-mapping fixes from Christoph Hellwig:
"A few fixes for the fallout of being a little more pedantic about dma
masks"
* tag 'dma-mapping-4.19-2' of git://git.infradead.org/users/hch/dma-mapping:
of/platform: initialise AMBA default DMA masks
sparc: set a default 32-bit dma mask for OF devices
kernel/dma/direct: take DMA offset into account in dma_direct_supported
|
|
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] usleep_range
drivers/net/ethernet/cadence/macb_main.c, 648:
usleep_range in macb_halt_tx
drivers/net/ethernet/cadence/macb_main.c, 730:
macb_halt_tx in macb_tx_error_task
drivers/net/ethernet/cadence/macb_main.c, 721:
_raw_spin_lock_irqsave in macb_tx_error_task
To fix this bug, usleep_range() is replaced with udelay().
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
mx8dv never entered into production and there is no other place
in the kernel referring to this SoC, so remove it from the
driver's compatible entry.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
This driver currently emits a STOP if the next message is not
I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
ioctl, where read/write transactions are combined without STOP
between.
Issue STOP only when the message is the last one _or_ flagged with
I2C_M_STOP.
Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
This driver currently emits a STOP if the next message is not
I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
ioctl, where read/write transactions are combined without STOP
between.
Issue STOP only when the message is the last one _or_ flagged with
I2C_M_STOP.
Fixes: dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
The cpsw-phy-sel device is not a child of the cpsw interconnect target
module. It lives in the system control module.
Let's fix this issue by trying to use cpsw-phy-sel phandle first if it
exists and if not fall back to current usage of trying to find the
cpsw-phy-sel child. That way the phy sel driver can be a child of the
system control module where it belongs in the device tree.
Without this fix, we cannot have a proper interconnect target module
hierarchy in device tree for things like genpd.
Note that deferred probe is mostly not supported by cpsw and this patch
does not attempt to fix that. In case deferred probe support is needed,
this could be added to cpsw_slave_open() and phy_connect() so they start
handling and returning errors.
For documenting it, looks like the cpsw-phy-sel is used for all cpsw device
tree nodes. It's missing the related binding documentation, so let's also
update the binding documentation accordingly.
Cc: [email protected]
Cc: Andrew Lunn <[email protected]>
Cc: Grygorii Strashko <[email protected]>
Cc: Ivan Khoronzhuk <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Murali Karicheri <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Take into account hw timer samples in pattern length computation done
in st_lsm6dsx_update_watermark routine for watermark configuration.
Moreover use samples in pattern (sip) already computed in
st_lsm6dsx_update_decimators routine
Fixes: 213451076bd3 ("iio: imu: st_lsm6dsx: add hw timestamp support")
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree updates from Rob Herring:
"A couple of new helper functions in preparation for some tree wide
clean-ups.
I'm sending these new helpers now for rc2 in order to simplify the
dependencies on subsequent cleanups across the tree in 4.20"
* tag 'devicetree-fixes-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
of: Add device_type access helper functions
of: add node name compare helper functions
of: add helper to lookup compatible child node
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"First batch of fixes post-merge window:
- A handful of devicetree changes for i.MX2{3,8} to change over to
new panel bindings. The platforms were moved from legacy
framebuffers to DRM and some development board panels hadn't yet
been converted.
- OMAP fixes related to ti-sysc driver conversion fallout, fixing
some register offsets, no_console_suspend fixes, etc.
- Droid4 changes to fix flaky eMMC probing and vibrator DTS mismerge.
- Fixed 0755->0644 permissions on a newly added file.
- Defconfig changes to make ARM Versatile more useful with QEMU
(helps testing).
- Enable defconfig options for new TI SoC platform that was merged
this window (AM6)"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arm64: defconfig: Enable TI's AM6 SoC platform
ARM: defconfig: Update the ARM Versatile defconfig
ARM: dts: omap4-droid4: Fix emmc errors seen on some devices
ARM: dts: Fix file permission for am335x-osd3358-sm-red.dts
ARM: imx_v6_v7_defconfig: Select CONFIG_DRM_PANEL_SEIKO_43WVF1G
ARM: mxs_defconfig: Select CONFIG_DRM_PANEL_SEIKO_43WVF1G
ARM: dts: imx23-evk: Convert to the new display bindings
ARM: dts: imx23-evk: Move regulators outside simple-bus
ARM: dts: imx28-evk: Convert to the new display bindings
ARM: dts: imx28-evk: Move regulators outside simple-bus
Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
arm: dts: am4372: setup rtc as system-power-controller
ARM: dts: omap4-droid4: fix vibrations on Droid 4
bus: ti-sysc: Fix no_console_suspend handling
bus: ti-sysc: Fix module register ioremap for larger offsets
ARM: OMAP2+: Fix module address for modules using mpu_rt_idx
ARM: OMAP2+: Fix null hwmod for ti-sysc debug
|
|
This reverts commit 535fba29b3e1afef4ba201b3c69a6992583ec0bd.
Seems the submitter (er me, hang head in shame) didn't look at the datasheet
enough to see that the registers are quite different.
This needs to be reverted because a) would never work b) to open it be added
to a Maxim RTDs (Resistance Temperature Detectors) under development by author
Signed-off-by: Matt Ranostay <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
|
|
This addresses a v4.19-rc1 regression in the PL111 DRM driver in
drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some point call
down to dma_alloc_attrs() to allocate a chunk of contigous DMA memory
for the framebuffer.
It appears that in v4.18, it was OK that this (and other DMA mastering
AMBA devices) left dev->coherent_dma_mask blank (zero).
In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask) in
dma_alloc_attrs() in include/linux/dma-mapping.h is triggered. The
allocation later fails when get_coherent_dma_mask() is called from
__dma_alloc() and __dma_alloc() returns NULL:
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
Failed to set fbdev configuration
It turns out that in commit 4d8bde883bfb ("OF: Don't set default
coherent DMA mask") the OF core stops setting the default DMA mask on
new devices, especially those lines of the patch:
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
Robin Murphy solved a similar problem in a5516219b102 ("of/platform:
Initialise default DMA masks") by simply assigning dev.coherent_dma_mask
and the dev.dma_mask to point to the same when creating devices from the
device tree, and introducing the same code into the code path creating
AMBA/PrimeCell devices solved my problem, graphics now come up.
The code simply assumes that the device can access all of the system
memory by setting the coherent DMA mask to 0xffffffff when creating a
device from the device tree, which is crude, but seems to be what kernel
v4.18 assumed.
The AMBA PrimeCells do not differ between coherent and streaming DMA so
we can just assign the same to any DMA mask.
Possibly drivers should augment their coherent DMA mask in accordance
with "dma-ranges" from the device tree if more finegranular masking is
needed.
Reported-by: Russell King <[email protected]>
Fixes: 4d8bde883bfb ("OF: Don't set default coherent DMA mask")
Cc: Russell King <[email protected]>
Cc: Robin Murphy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"Two small fixes, one for the x86 Stoney SoC to get a more accurate clk
frequency and the other to fix a bad allocation in the Nuvoton NPCM7XX
driver"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: x86: Set default parent to 48Mhz
clk: npcm7xx: fix memory allocation
|
|
Instead of forcing a distro or other system builder to choose
at build time whether the CPU is trusted for CRNG seeding via
CONFIG_RANDOM_TRUST_CPU, provide a boot-time parameter for end users to
control the choice. The CONFIG will set the default state instead.
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
|
|
Check the return codes of these functions and halt reset
in case of failure. The driver will remain in a dormant state
until the next reset event, when device initialization will be
re-attempted.
Signed-off-by: Thomas Falcon <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch fixes the race between netvsc_probe() and
rndis_set_subchannel(), which can cause a deadlock.
These are the related 3 paths which show the deadlock:
path #1:
Workqueue: hv_vmbus_con vmbus_onmessage_work [hv_vmbus]
Call Trace:
schedule
schedule_preempt_disabled
__mutex_lock
__device_attach
bus_probe_device
device_add
vmbus_device_register
vmbus_onoffer
vmbus_onmessage_work
process_one_work
worker_thread
kthread
ret_from_fork
path #2:
schedule
schedule_preempt_disabled
__mutex_lock
netvsc_probe
vmbus_probe
really_probe
__driver_attach
bus_for_each_dev
driver_attach_async
async_run_entry_fn
process_one_work
worker_thread
kthread
ret_from_fork
path #3:
Workqueue: events netvsc_subchan_work [hv_netvsc]
Call Trace:
schedule
rndis_set_subchannel
netvsc_subchan_work
process_one_work
worker_thread
kthread
ret_from_fork
Before path #1 finishes, path #2 can start to run, because just before
the "bus_probe_device(dev);" in device_add() in path #1, there is a line
"object_uevent(&dev->kobj, KOBJ_ADD);", so systemd-udevd can
immediately try to load hv_netvsc and hence path #2 can start to run.
Next, path #2 offloads the subchannal's initialization to a workqueue,
i.e. path #3, so we can end up in a deadlock situation like this:
Path #2 gets the device lock, and is trying to get the rtnl lock;
Path #3 gets the rtnl lock and is waiting for all the subchannel messages
to be processed;
Path #1 is trying to get the device lock, but since #2 is not releasing
the device lock, path #1 has to sleep; since the VMBus messages are
processed one by one, this means the sub-channel messages can't be
procedded, so #3 has to sleep with the rtnl lock held, and finally #2
has to sleep... Now all the 3 paths are sleeping and we hit the deadlock.
With the patch, we can make sure #2 gets both the device lock and the
rtnl lock together, gets its job done, and releases the locks, so #1
and #3 will not be blocked for ever.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Signed-off-by: Dexuan Cui <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: K. Y. Srinivasan <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
To avoid leaking a running timer we need to wait for the
posted reconfigs after netdev is unregistered. In common
case the process of deinitializing the device will perform
synchronous reconfigs which wait for posted requests, but
especially with VXLAN ports being actively added and removed
there can be a race condition leaving a timer running after
adapter structure is freed leading to a crash.
Add an explicit flush after deregistering and for a good
measure a warning to check if timer is running just before
structures are freed.
Fixes: 3d780b926a12 ("nfp: add async reconfiguration mechanism")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Dirk van der Merwe <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
All the RESYNC messages are sent with resync lock held, the only
exception is resync_finish which releases resync_lockres before
send the last resync message, this should be changed as well.
Otherwise, we can see deadlock issue as follows:
clustermd2-gqjiang2:~ # cat /proc/mdstat
Personalities : [raid10] [raid1]
md0 : active raid1 sdg[0] sdf[1]
134144 blocks super 1.2 [2/2] [UU]
[===================>.] resync = 99.6% (134144/134144) finish=0.0min speed=26K/sec
bitmap: 1/1 pages [4KB], 65536KB chunk
unused devices: <none>
clustermd2-gqjiang2:~ # ps aux|grep md|grep D
root 20497 0.0 0.0 0 0 ? D 16:00 0:00 [md0_raid1]
clustermd2-gqjiang2:~ # cat /proc/20497/stack
[<ffffffffc05ff51e>] dlm_lock_sync+0x8e/0xc0 [md_cluster]
[<ffffffffc05ff7e8>] __sendmsg+0x98/0x130 [md_cluster]
[<ffffffffc05ff900>] sendmsg+0x20/0x30 [md_cluster]
[<ffffffffc05ffc35>] resync_info_update+0xb5/0xc0 [md_cluster]
[<ffffffffc0593e84>] md_reap_sync_thread+0x134/0x170 [md_mod]
[<ffffffffc059514c>] md_check_recovery+0x28c/0x510 [md_mod]
[<ffffffffc060c882>] raid1d+0x42/0x800 [raid1]
[<ffffffffc058ab61>] md_thread+0x121/0x150 [md_mod]
[<ffffffff9a0a5b3f>] kthread+0xff/0x140
[<ffffffff9a800235>] ret_from_fork+0x35/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
clustermd-gqjiang1:~ # ps aux|grep md|grep D
root 20531 0.0 0.0 0 0 ? D 16:00 0:00 [md0_raid1]
root 20537 0.0 0.0 0 0 ? D 16:00 0:00 [md0_cluster_rec]
root 20676 0.0 0.0 0 0 ? D 16:01 0:00 [md0_resync]
clustermd-gqjiang1:~ # cat /proc/mdstat
Personalities : [raid10] [raid1]
md0 : active raid1 sdf[1] sdg[0]
134144 blocks super 1.2 [2/2] [UU]
[===================>.] resync = 97.3% (131072/134144) finish=8076.8min speed=0K/sec
bitmap: 1/1 pages [4KB], 65536KB chunk
unused devices: <none>
clustermd-gqjiang1:~ # cat /proc/20531/stack
[<ffffffffc080974d>] metadata_update_start+0xcd/0xd0 [md_cluster]
[<ffffffffc079c897>] md_update_sb.part.61+0x97/0x820 [md_mod]
[<ffffffffc079f15b>] md_check_recovery+0x29b/0x510 [md_mod]
[<ffffffffc0816882>] raid1d+0x42/0x800 [raid1]
[<ffffffffc0794b61>] md_thread+0x121/0x150 [md_mod]
[<ffffffff9e0a5b3f>] kthread+0xff/0x140
[<ffffffff9e800235>] ret_from_fork+0x35/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
clustermd-gqjiang1:~ # cat /proc/20537/stack
[<ffffffffc0813222>] freeze_array+0xf2/0x140 [raid1]
[<ffffffffc080a56e>] recv_daemon+0x41e/0x580 [md_cluster]
[<ffffffffc0794b61>] md_thread+0x121/0x150 [md_mod]
[<ffffffff9e0a5b3f>] kthread+0xff/0x140
[<ffffffff9e800235>] ret_from_fork+0x35/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
clustermd-gqjiang1:~ # cat /proc/20676/stack
[<ffffffffc080951e>] dlm_lock_sync+0x8e/0xc0 [md_cluster]
[<ffffffffc080957f>] lock_token+0x2f/0xa0 [md_cluster]
[<ffffffffc0809622>] lock_comm+0x32/0x90 [md_cluster]
[<ffffffffc08098f5>] sendmsg+0x15/0x30 [md_cluster]
[<ffffffffc0809c0a>] resync_info_update+0x8a/0xc0 [md_cluster]
[<ffffffffc08130ba>] raid1_sync_request+0xa9a/0xb10 [raid1]
[<ffffffffc079b8ea>] md_do_sync+0xbaa/0xf90 [md_mod]
[<ffffffffc0794b61>] md_thread+0x121/0x150 [md_mod]
[<ffffffff9e0a5b3f>] kthread+0xff/0x140
[<ffffffff9e800235>] ret_from_fork+0x35/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
Reviewed-by: NeilBrown <[email protected]>
Signed-off-by: Guoqing Jiang <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
|
|
In raid10 reshape_request it gets max_sectors in read_balance. If the underlayer disks
have bad blocks, the max_sectors is less than last. It will call goto read_more many
times. It calls raise_barrier(conf, sectors_done != 0) every time. In this condition
sectors_done is not 0. So the value passed to the argument force of raise_barrier is
true.
In raise_barrier it checks conf->barrier when force is true. If force is true and
conf->barrier is 0, it panic. In this case reshape_request submits bio to under layer
disks. And in the callback function of the bio it calls lower_barrier. If the bio
finishes before calling raise_barrier again, it can trigger the BUG_ON.
Add one pair of raise_barrier/lower_barrier to fix this bug.
Signed-off-by: Xiao Ni <[email protected]>
Suggested-by: Neil Brown <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
|
|
We don't support reshape yet if an array supports log device. Previously we
determine the fact by checking ->log. However, ->log could be NULL after a log
device is removed, but the array is still marked to support log device. Don't
allow reshape in this case too. User can disable log device support by setting
'consistency_policy' to 'resync' then do reshape.
Reported-by: Xiao Ni <[email protected]>
Tested-by: Xiao Ni <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
|
|
There is a potential execution path in which function ssif_info_find()
returns NULL, hence there is a NULL pointer dereference when accessing
pointer *addr_info*
Fix this by null checking *addr_info* before dereferencing it.
Addresses-Coverity-ID: 1473145 ("Explicit null dereferenced")
Fixes: e333054a91d1 ("ipmi: Fix I2C client removal in the SSIF driver")
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
- minor cleanup avoiding a warning when building with new gcc
- a patch to add a new sysfs node for Xen frontend/backend drivers to
make it easier to obtain the state of a pv device
- two fixes for 32-bit pv-guests to avoid intermediate L1TF vulnerable
PTEs
* tag 'for-linus-4.19b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: remove redundant variable save_pud
xen: export device state to sysfs
x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear
x86/xen: don't write ptes directly in 32-bit PV guests
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- regression fixes for i801 and designware
- better API and leak fix for releasing DMA safe buffers
- better greppable strings for the bitbang algorithm
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: sh_mobile: fix leak when using DMA bounce buffer
i2c: sh_mobile: define start_ch() void as it only returns 0 anyhow
i2c: refactor function to release a DMA safe buffer
i2c: algos: bit: make the error messages grepable
i2c: designware: Re-init controllers with pm_disabled set on resume
i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus
|
|
The SSIF driver was removing any client that came in through the
platform interface, but it should only remove clients that it
added. On a failure in the probe function, this could result
in the following oops when the driver is removed and the
client gets unregistered twice:
CPU: 107 PID: 30266 Comm: rmmod Not tainted 4.18.0+ #80
Hardware name: Cavium Inc. Saber/Saber, BIOS Cavium reference firmware version 7.0 08/04/2018
pstate: 60400009 (nZCv daif +PAN -UAO)
pc : kernfs_find_ns+0x28/0x120
lr : kernfs_find_and_get_ns+0x40/0x60
sp : ffff00002310fb50
x29: ffff00002310fb50 x28: ffff800a8240f800
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000056000000 x24: ffff000009073000
x23: ffff000008998b38 x22: 0000000000000000
x21: ffff800ed86de820 x20: 0000000000000000
x19: ffff00000913a1d8 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 5300737265766972
x13: 643d4d4554535953 x12: 0000000000000030
x11: 0000000000000030 x10: 0101010101010101
x9 : ffff800ea06cc3f9 x8 : 0000000000000000
x7 : 0000000000000141 x6 : ffff000009073000
x5 : ffff800adb706b00 x4 : 0000000000000000
x3 : 00000000ffffffff x2 : 0000000000000000
x1 : ffff000008998b38 x0 : ffff000008356760
Process rmmod (pid: 30266, stack limit = 0x00000000e218418d)
Call trace:
kernfs_find_ns+0x28/0x120
kernfs_find_and_get_ns+0x40/0x60
sysfs_unmerge_group+0x2c/0x6c
dpm_sysfs_remove+0x34/0x70
device_del+0x58/0x30c
device_unregister+0x30/0x7c
i2c_unregister_device+0x84/0x90 [i2c_core]
ssif_platform_remove+0x38/0x98 [ipmi_ssif]
platform_drv_remove+0x2c/0x6c
device_release_driver_internal+0x168/0x1f8
driver_detach+0x50/0xbc
bus_remove_driver+0x74/0xe8
driver_unregister+0x34/0x5c
platform_driver_unregister+0x20/0x2c
cleanup_ipmi_ssif+0x50/0xd82c [ipmi_ssif]
__arm64_sys_delete_module+0x1b4/0x220
el0_svc_handler+0x104/0x160
el0_svc+0x8/0xc
Code: aa1e03e0 aa0203f6 aa0103f7 d503201f (7940e280)
---[ end trace 09f0e34cce8e2d8c ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x23800c38
So track the clients that the SSIF driver adds and only remove
those.
Reported-by: George Cherian <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Tested-by: George Cherian <[email protected]>
Cc: <[email protected]> # 4.14.x
|
|
The capabilities detection was being done as part of the normal
state machine, but it was possible for it to be running while
the upper layers of the IPMI driver were initializing the
device, resulting in error and failure to initialize.
Move the capabilities detection to the the detect function,
so it's done before anything else runs on the device. This also
simplifies the state machine and removes some code, as a bonus.
Signed-off-by: Corey Minyard <[email protected]>
Reported-by: Andrew Banman <[email protected]>
Tested-by: Andrew Banman <[email protected]>
Cc: <[email protected]>
|
|
There were certain situations where ipmi_register_smi() would
return a failure, but the interface would still be registered
and would need to be unregistered. This is obviously a bad
design and resulted in an oops in certain failure cases.
If the interface is started up in ipmi_register_smi(), then
an error occurs, shut down the interface there so the
cleanup can be done properly.
Fix the various smi users, too.
Signed-off-by: Corey Minyard <[email protected]>
Reported-by: Justin Ernst <[email protected]>
Tested-by: Justin Ernst <[email protected]>
Cc: Andrew Banman <[email protected]>
Cc: Russ Anderson <[email protected]>
Cc: <[email protected]> # 4.18.x
|
|
gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list
before of_gpiochip_add() is called, but it's only the latter which sets
the ->of_xlate function pointer. gpiochip_find() can be called by
someone else between these two actions, and it can find the chip and
call of_gpiochip_match_node_and_xlate() which leads to the following
crash due to a NULL ->of_xlate().
Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000
Modules linked in: leds_gpio(+) gpio_generic(+)
CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43
Hardware name: ARM-Versatile Express
PC is at (null)
LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38
Process insmod (pid: 830, stack limit = 0x(ptrval))
(of_gpiochip_match_node_and_xlate) from (gpiochip_find+0x48/0x84)
(gpiochip_find) from (of_get_named_gpiod_flags+0xa8/0x238)
(of_get_named_gpiod_flags) from (gpiod_get_from_of_node+0x2c/0xc8)
(gpiod_get_from_of_node) from (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144)
(devm_fwnode_get_index_gpiod_from_child) from (gpio_led_probe+0x208/0x3c4 [leds_gpio])
(gpio_led_probe [leds_gpio]) from (platform_drv_probe+0x48/0x9c)
(platform_drv_probe) from (really_probe+0x1d0/0x3d4)
(really_probe) from (driver_probe_device+0x78/0x1c0)
(driver_probe_device) from (__driver_attach+0x120/0x13c)
(__driver_attach) from (bus_for_each_dev+0x68/0xb4)
(bus_for_each_dev) from (bus_add_driver+0x1a8/0x268)
(bus_add_driver) from (driver_register+0x78/0x10c)
(driver_register) from (do_one_initcall+0x54/0x1fc)
(do_one_initcall) from (do_init_module+0x64/0x1f4)
(do_init_module) from (load_module+0x2198/0x26ac)
(load_module) from (sys_finit_module+0xe0/0x110)
(sys_finit_module) from (ret_fast_syscall+0x0/0x54)
One way to fix this would be to rework the hairy registration sequence
in gpiochip_add_data_with_key(), but since I'd probably introduce a
couple of new bugs if I attempted that, simply add a check for a
non-NULL of_xlate function pointer in
of_gpiochip_match_node_and_xlate(). This works since the driver looking
for the gpio will simply fail to find the gpio and defer its probe and
be reprobed when the driver which is registering the gpiochip has fully
completed its probe.
Signed-off-by: Vincent Whitchurch <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Pull drm fixes from Dave Airlie:
"Regular fixes pull:
- Mediatek has a bunch of fixes to their RDMA and Overlay engines.
- i915 has some Cannonlake/Geminilake watermark workarounds, LSPCON
fix, HDCP free fix, audio fix and a ppgtt reference counting fix.
- amdgpu has some SRIOV, Kasan, memory leaks and other misc fixes"
* tag 'drm-fixes-2018-08-31' of git://anongit.freedesktop.org/drm/drm: (35 commits)
drm/i915/audio: Hook up component bindings even if displays are disabled
drm/i915: Increase LSPCON timeout
drm/i915: Stop holding a ref to the ppgtt from each vma
drm/i915: Free write_buf that we allocated with kzalloc.
drm/i915: Fix glk/cnl display w/a #1175
drm/amdgpu: Need to set moved to true when evict bo
drm/amdgpu: Remove duplicated power source update
drm/amd/display: Fix memory leak caused by missed dc_sink_release
drm/amdgpu: fix holding mn_lock while allocating memory
drm/amdgpu: Power on uvd block when hw_fini
drm/amdgpu: Update power state at the end of smu hw_init.
drm/amdgpu: Fix vce initialize failed on Kaveri/Mullins
drm/amdgpu: Enable/disable gfx PG feature in rlc safe mode
drm/amdgpu: Adjust the VM size based on system memory size v2
drm/mediatek: fix connection from RDMA2 to DSI1
drm/mediatek: update some variable name from ovl to comp
drm/mediatek: use layer_nr function to get layer number to init plane
drm/mediatek: add function to return RDMA layer number
drm/mediatek: add function to return OVL layer number
drm/mediatek: add function to get layer number for component
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These address a corner case in the menu cpuidle governor and fix error
handling in the PM core's generic clock management code.
Specifics:
- Make the menu cpuidle governor avoid stopping the scheduler tick if
the predicted idle duration exceeds the tick period length, but the
selected idle state is shallow and deeper idle states with high
target residencies are available (Rafael Wysocki).
- Make the PM core's generic clock management code use a proper data
type for one variable to make error handling work (Dan Carpenter)"
* tag 'pm-4.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpuidle: menu: Retain tick when shallow state is selected
PM / clk: signedness bug in of_pm_clk_add_clks()
|
|
Merge a generic clock management fix for 4.19-rc2.
* pm-core:
PM / clk: signedness bug in of_pm_clk_add_clks()
|
|
System clk provided in ST soc can be set to:
48Mhz, non-spread
25Mhz, spread
To get accurate rate, we need it to set it at non-spread
option which is 48Mhz.
Signed-off-by: Akshu Agrawal <[email protected]>
Reviewed-by: Daniel Kurtz <[email protected]>
Fixes: 421bf6a1f061 ("clk: x86: Add ST oscout platform clock")
Signed-off-by: Stephen Boyd <[email protected]>
|
|
We only freed the bounce buffer after successful DMA, missing the cases
where DMA setup may have gone wrong. Use a better location which always
gets called after each message and use 'stop_after_dma' as a flag for a
successful transfer.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
After various refactoring over the years, start_ch() doesn't return
errno anymore, so make the function return void. This saves the error
handling when calling it which in turn eases cleanup of resources of a
future patch.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
a) rename to 'put' instead of 'release' to match 'get' when obtaining
the buffer
b) change the argument order to have the buffer as first argument
c) add a new argument telling the function if the message was
transferred. This allows the function to be used also in cases
where setting up DMA failed, so the buffer needs to be freed without
syncing to the message buffer.
Also convert the only user.
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
Yep, I went looking for one of these, and I wasn't able to find it
easily. That's worse than a line which is 82-chars long, IMHO.
Signed-off-by: Jan Kundrát <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C
busses which the OS shares with the PUNIT as these need special handling.
Until now we called dev_pm_syscore_device(dev, true) for I2C controllers
with this flag set to keep these I2C controllers always on.
After commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and
resume from hibernation"), this no longer works. This commit modifies
lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran
before it, so that it does not run on a resume from hibernate (or from S3).
On these systems the conditions for lpss_iosf_enter_d3_state() to run
never become true, so lpss_iosf_exit_d3_state() never gets called and
the 2 LPSS DMA controllers never get forced into D0 mode, instead they
are left in their default automatic power-on when needed mode.
The not forcing of D0 mode for the DMA controllers enables these systems
to properly enter S0ix modes, which is a good thing.
But after entering S0ix modes the I2C controller connected to the PMIC
no longer works, leading to e.g. broken battery monitoring.
The _PS3 method for this I2C controller looks like this:
Method (_PS3, 0, NotSerialized) // _PS3: Power State 3
{
If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06)))
{
Return (Zero)
}
PSAT |= 0x03
Local0 = PSAT /* \_SB_.I2C5.PSAT */
}
Where PMID = 0x05, so we enter the Return (Zero) path on these systems.
So even if we were to not call dev_pm_syscore_device(dev, true) the
I2C controller will be left in D0 rather then be switched to D3.
Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all*
I2C controllers are in D3 mode. This combined with the I2C controller no
longer working now that we reach S0ix states on these systems leads to me
believing that the PUNIT itself puts the I2C controller in D3 when all
other conditions for entering S0ix states are true.
Since now the I2C controller is put in D3 over a suspend/resume we must
re-initialize it afterwards and that does indeed fix it no longer working.
This commit implements this fix by:
1) Making the suspend_late callback a no-op if pm_disabled is set and
making the resume_early callback skip the clock re-enable (since it now was
not disabled) while still doing the necessary I2C controller re-init.
2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend
and resume callbacks are actually called. Normally this would cause the
ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc
since it is shared with the PUNIT, but in this special case the _PS3 method
is a no-op so we can safely allow a "fake" suspend / resume.
Fixes: 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861
Cc: 4.15+ <[email protected]> # 4.15+
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Jarkko Nikula <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|