4.6.2-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainercover 4.6.2-stable review
This is the start of the stable review cycle for the 4.6.2 release. There are 121 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Jun 7 21:43:16 UTC 2016. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.2-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.6.2-rc1
Mike Marciniszyn <[email protected]>
IB/hfi1: Fix hard lockup due to not using save/restore spin lock
Arnd Bergmann <[email protected]>
drm: msm: remove unused variable
Dave Chinner <[email protected]>
xfs: skip stale inodes in xfs_iflush_cluster
Dave Chinner <[email protected]>
xfs: fix inode validity check in xfs_iflush_cluster
Dave Chinner <[email protected]>
xfs: xfs_iflush_cluster fails to abort on error
Dave Chinner <[email protected]>
xfs: remove xfs_fs_evict_inode()
Dave Chinner <[email protected]>
xfs: Don't wrap growfs AGFL indexes
Eric Sandeen <[email protected]>
xfs: disallow rw remount on fs with unknown ro-compat features
Arnd Bergmann <[email protected]>
gcov: disable tree-loop-im to reduce stack usage
Kirill A. Shutemov <[email protected]>
mm: thp: avoid false positive VM_BUG_ON_PAGE in page_move_anon_rmap()
Srinivas Pandruvada <[email protected]>
scripts/package/Makefile: rpmbuild add support of RPMOPTS
Ville Syrjälä <[email protected]>
dma-debug: avoid spinlock recursion when disabling dma-debug
Rafael J. Wysocki <[email protected]>
PM / sleep: Handle failures in device_suspend_late() consistently
Weston Andros Adamson <[email protected]>
nfs: avoid race that crashes nfs_init_commit
Nicolai Stange <[email protected]>
ext4: silence UBSAN in ext4_mb_init()
Nicolai Stange <[email protected]>
ext4: address UBSAN warning in mb_find_order_for_block()
Jan Kara <[email protected]>
ext4: fix oops on corrupted filesystem
Seth Forshee <[email protected]>
ext4: fix check of dqget() return value in ext4_ioctl_setproject()
Theodore Ts'o <[email protected]>
ext4: clean up error handling when orphan list is corrupted
Theodore Ts'o <[email protected]>
ext4: fix hang when processing corrupted orphaned inode list
Jan Kara <[email protected]>
ext4: fix data exposure after a crash
Ville Syrjälä <[email protected]>
drm/i915: Pass the correct crtc state to .update_plane()
Philipp Zabel <[email protected]>
drm/imx: Match imx-ipuv3-crtc components using device node in platform data
Ville Syrjälä <[email protected]>
drm: Add helper for DP++ adaptors
Ville Syrjälä <[email protected]>
drm/i915: Fix watermarks for VLV/CHV
Ville Syrjälä <[email protected]>
drm/i915: Don't leave old junk in ilk active watermarks on readout
Ville Syrjälä <[email protected]>
drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed
Ville Syrjälä <[email protected]>
drm/i915: Respect DP++ adaptor TMDS clock limit
Daniel Vetter <[email protected]>
drm/i915/psr: Try to program link training times correctly
Glenn Ruben Bakke <[email protected]>
Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address
Lyude <[email protected]>
drm/atomic: Verify connector->funcs != NULL when clearing states
Lyude <[email protected]>
drm/i915: Discard previous atomic state on resume if connectors change
Lyude <[email protected]>
drm/fb_helper: Fix references to dev->mode_config.num_connector
Lyude <[email protected]>
drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()
Mario Kleiner <[email protected]>
drm/amdgpu: Fix hdmi deep color support.
Alex Deucher <[email protected]>
drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh
Thomas Hellstrom <[email protected]>
drm/vmwgfx: Kill some lockdep warnings
Itai Handler <[email protected]>
drm/gma500: Fix possible out of bounds read
Tomáš Trnka <[email protected]>
sunrpc: fix stripping of padded MIC tokens
Juergen Gross <[email protected]>
xen: use same main loop for counting and remapping pages
Ross Lagerwall <[email protected]>
xen/events: Don't move disabled irqs
Gavin Shan <[email protected]>
powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()
Guilherme G. Piccoli <[email protected]>
Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"
Gavin Shan <[email protected]>
powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()
Hari Bathini <[email protected]>
powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel
Sven Eckelmann <[email protected]>
batman-adv: Fix double neigh_node_put in batadv_v_ogm_route_update
Zhao Qiang <[email protected]>
QE-UART: add "fsl,t1040-ucc-uart" to of_device_id
Oleg Nesterov <[email protected]>
wait/ptrace: assume __WALL if the child is traced
Chen Feng <[email protected]>
mm/compaction.c: fix zoneindex in kcompactd()
Stefan Bader <[email protected]>
mm: use phys_addr_t for reserve_bootmem_region() arguments
Colin Ian King <[email protected]>
PKCS#7: fix missing break on OID_sha224 case
Tiffany Lin <[email protected]>
media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32
Prarit Bhargava <[email protected]>
PCI: Disable all BAR sizing for devices with non-compliant BARs
Andrew Jeffery <[email protected]>
pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range
Martin Sperl <[email protected]>
clk: bcm2835: correctly enable fractional clock support
Martin Sperl <[email protected]>
clk: bcm2835: divider value has to be 1 or more
Martin Sperl <[email protected]>
clk: bcm2835: pll_off should only update CM_PLL_ANARST
Vladimir Zapolskiy <[email protected]>
clk: at91: fix check of clk_register() returned value
Eric Anholt <[email protected]>
clk: bcm2835: Fix PLL poweron
Daniel Lezcano <[email protected]>
cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()
Dave Gerlach <[email protected]>
cpuidle: Indicate when a device has been unregistered
Ulf Hansson <[email protected]>
PM / Runtime: Fix error path in pm_runtime_force_resume()
Ville Syrjälä <[email protected]>
mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
Heikki Krogerus <[email protected]>
mfd: intel-lpss: Save register context on suspend
Andy Shevchenko <[email protected]>
mfd: intel_quark_i2c_gpio: Remove clock tree on error path
Akshay Bhat <[email protected]>
hwmon: (ads7828) Enable internal reference
Javier Martinez Canillas <[email protected]>
regulator: Try to resolve regulators supplies on registration
Raghava Aditya Renukunta <[email protected]>
aacraid: Fix for KDUMP driver hang
Raghava Aditya Renukunta <[email protected]>
aacraid: Fix for aac_command_thread hang
Raghava Aditya Renukunta <[email protected]>
aacraid: Relinquish CPU during timeout wait
Raghava Aditya Renukunta <[email protected]>
aacraid: Start adapter after updating number of MSIX vectors
Martin K. Petersen <[email protected]>
Revert "lpfc: Delete unnecessary checks before the function call mempool_destroy"
wang yanqing <[email protected]>
rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
wang yanqing <[email protected]>
rtlwifi: Fix logic error in enter/exit power-save mode
Larry Finger <[email protected]>
rtlwifi: btcoexist: Implement antenna selection
Larry Finger <[email protected]>
rtlwifi: rtl8723be: Add antenna select module parameter
Krzysztof Kozlowski <[email protected]>
hwrng: exynos - Fix unbalanced PM runtime put on timeout error path
Joseph Salisbury <[email protected]>
ath5k: Change led pin configuration for compaq c700 laptop
Anilkumar Kolli <[email protected]>
ath10k: fix kernel panic, move arvifs list head init before htt init
Rajkumar Manoharan <[email protected]>
ath10k: fix rx_channel during hw reconfigure
Rajkumar Manoharan <[email protected]>
ath10k: fix firmware assert in monitor mode
Anilkumar Kolli <[email protected]>
ath10k: fix debugfs pktlog_filter write
Vittorio Gambaletta (VittGam) <[email protected]>
ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
Vittorio Gambaletta (VittGam) <[email protected]>
ath9k: Add a module parameter to invert LED polarity.
Alexander Kurz <[email protected]>
ARM: dts: imx35: restore existing used clock enumeration
Marek Szyprowski <[email protected]>
ARM: dts: exynos: Add interrupt line to MAX8997 PMIC on exynos4210-trats
Florian Vallee <[email protected]>
ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description
Imre Kaloz <[email protected]>
ARM: mvebu: fix GPIO config on the Linksys boards
Priit Laes <[email protected]>
ARM: sun7i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output
Priit Laes <[email protected]>
ARM: sun4i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output
Cameron Gutman <[email protected]>
Input: xpad - prevent spurious input from wired Xbox 360 controllers
Pavel Rojtberg <[email protected]>
Input: xpad - move pending clear to the correct location
Ricky Liang <[email protected]>
Input: uinput - handle compat ioctl for UI_SET_PHYS
Mark Brown <[email protected]>
ASoC: ak4642: Enable cache usage to fix crashes on resume
Mikulas Patocka <[email protected]>
affs: fix remount failure when there are no options changed
Maciej W. Rozycki <[email protected]>
MIPS: VDSO: Build with `-fno-strict-aliasing'
Harvey Hunt <[email protected]>
MIPS: lib: Mark intrinsics notrace
James Hogan <[email protected]>
MIPS: Build microMIPS VDSO for microMIPS kernels
James Hogan <[email protected]>
MIPS: Fix sigreturn via VDSO on microMIPS kernel
Maciej W. Rozycki <[email protected]>
MIPS: ptrace: Prevent writes to read-only FCSR bits
Maciej W. Rozycki <[email protected]>
MIPS: ptrace: Fix FP context restoration FCSR regression
Paul Burton <[email protected]>
MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...)
Paul Burton <[email protected]>
MIPS: Prevent "restoration" of MSA context in non-MSA kernels
Paul Burton <[email protected]>
MIPS: Force CPUs to lose FP context during mode switches
James Hogan <[email protected]>
MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU
Paul Burton <[email protected]>
MIPS: Use copy_s.fmt rather than copy_u.fmt
Huacai Chen <[email protected]>
MIPS: Loongson-3: Reserve 32MB for RS780E integrated GPU
Huacai Chen <[email protected]>
MIPS: Reserve nosave data for hibernation
Matthias Schiffer <[email protected]>
MIPS: ath79: make bootconsole wait for both THRE and TEMT
Huacai Chen <[email protected]>
MIPS: Loongson-3: Fix build error after ld-version.sh modification
Paul Burton <[email protected]>
MIPS: Sync icache & dcache in set_pte_at
Paul Burton <[email protected]>
MIPS: Handle highmem pages in __update_cache
James Hogan <[email protected]>
MIPS: Fix watchpoint restoration
James Hogan <[email protected]>
MIPS: Fix uapi include in exported asm/siginfo.h
James Hogan <[email protected]>
MIPS: Fix siginfo.h to use strict posix types
James Hogan <[email protected]>
MIPS: Avoid using unwind_stack() with usermode
James Hogan <[email protected]>
MIPS: Don't unwind to user mode with EVA
Maciej W. Rozycki <[email protected]>
MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC
Paul Burton <[email protected]>
MIPS: math-emu: Fix jalr emulation when rd == $0
Leonid Yegoshin <[email protected]>
MIPS64: R6: R2 emulation bugfix
Chao Yu <[email protected]>
f2fs: fix deadlock when flush inline data
-------------
Diffstat:
Documentation/DocBook/gpu.tmpl | 6 + .../devicetree/bindings/clock/imx35-clock.txt | 1 + Makefile | 6 +- arch/arm/boot/dts/armada-385-linksys.dtsi | 6 +- arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 4 +- arch/arm/boot/dts/exynos4210-trats.dts | 2 + arch/arm/boot/dts/sama5d2-pinfunc.h | 4 +- arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- arch/arm/boot/dts/sun7i-a20.dtsi | 5 +- arch/mips/ath79/early_printk.c | 6 +- arch/mips/include/asm/asmmacro.h | 40 +-- arch/mips/include/asm/cacheflush.h | 6 - arch/mips/include/asm/msa.h | 13 + arch/mips/include/asm/pgtable.h | 26 +- arch/mips/include/asm/switch_to.h | 2 +- arch/mips/include/asm/watch.h | 10 +- arch/mips/include/uapi/asm/siginfo.h | 22 +- arch/mips/kernel/mips-r2-to-r6-emul.c | 105 +++--- arch/mips/kernel/pm.c | 2 +- arch/mips/kernel/process.c | 46 ++- arch/mips/kernel/ptrace.c | 27 +- arch/mips/kernel/r4k_fpu.S | 10 +- arch/mips/kernel/setup.c | 3 + arch/mips/kernel/signal.c | 15 +- arch/mips/kernel/traps.c | 8 +- arch/mips/kernel/watch.c | 5 +- arch/mips/lib/ashldi3.c | 2 +- arch/mips/lib/ashrdi3.c | 2 +- arch/mips/lib/bswapdi.c | 2 +- arch/mips/lib/bswapsi.c | 2 +- arch/mips/lib/cmpdi2.c | 2 +- arch/mips/lib/lshrdi3.c | 2 +- arch/mips/lib/ucmpdi2.c | 2 +- arch/mips/loongson64/Platform | 2 +- arch/mips/loongson64/loongson-3/numa.c | 6 +- arch/mips/math-emu/cp1emu.c | 8 +- arch/mips/mm/cache.c | 29 +- arch/mips/vdso/Makefile | 4 +- arch/powerpc/kernel/eeh.c | 2 +- arch/powerpc/kernel/eeh_driver.c | 26 +- arch/powerpc/kernel/exceptions-64s.S | 16 +- arch/x86/xen/setup.c | 65 ++-- crypto/asymmetric_keys/pkcs7_parser.c | 1 + drivers/base/power/main.c | 5 +- drivers/base/power/runtime.c | 9 +- drivers/char/hw_random/exynos-rng.c | 10 +- drivers/clk/at91/clk-h32mx.c | 2 +- drivers/clk/bcm/clk-bcm2835.c | 58 +++- drivers/clk/imx/clk-imx35.c | 4 +- drivers/cpuidle/cpuidle.c | 4 +- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +- drivers/gpu/drm/drm_atomic.c | 2 +- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 366 +++++++++++++++++++++ drivers/gpu/drm/drm_fb_helper.c | 5 +- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 2 +- drivers/gpu/drm/i915/intel_atomic.c | 3 +- drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +- drivers/gpu/drm/i915/intel_ddi.c | 12 + drivers/gpu/drm/i915/intel_display.c | 37 ++- drivers/gpu/drm/i915/intel_drv.h | 8 +- drivers/gpu/drm/i915/intel_fbdev.c | 6 +- drivers/gpu/drm/i915/intel_hdmi.c | 78 ++++- drivers/gpu/drm/i915/intel_pm.c | 2 + drivers/gpu/drm/i915/intel_psr.c | 55 +++- drivers/gpu/drm/imx/imx-drm-core.c | 8 + drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 27 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 3 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 3 + drivers/gpu/ipu-v3/ipu-common.c | 5 +- drivers/hwmon/ads7828.c | 10 + drivers/input/joystick/xpad.c | 6 +- drivers/input/misc/uinput.c | 6 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 +- drivers/mfd/intel-lpss.c | 19 +- drivers/mfd/intel_quark_i2c_gpio.c | 25 +- drivers/mfd/intel_soc_pmic_core.c | 1 + drivers/net/wireless/ath/ath10k/core.c | 8 +- drivers/net/wireless/ath/ath10k/debug.c | 7 +- drivers/net/wireless/ath/ath10k/mac.c | 13 +- drivers/net/wireless/ath/ath5k/led.c | 2 +- drivers/net/wireless/ath/ath9k/init.c | 7 + drivers/net/wireless/ath/ath9k/pci.c | 10 + drivers/net/wireless/realtek/rtlwifi/base.c | 4 +- .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 9 +- .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 27 +- .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 2 +- .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 5 +- drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +- .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 5 + .../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 3 + drivers/net/wireless/realtek/rtlwifi/wifi.h | 3 + drivers/pci/probe.c | 6 +- drivers/pinctrl/samsung/pinctrl-exynos5440.c | 15 +- drivers/regulator/core.c | 9 + drivers/scsi/aacraid/aacraid.h | 1 + drivers/scsi/aacraid/comminit.c | 24 ++ drivers/scsi/aacraid/commsup.c | 12 +- drivers/scsi/aacraid/linit.c | 2 +- drivers/scsi/lpfc/lpfc_mem.c | 6 +- drivers/staging/rdma/hfi1/qp.c | 5 +- drivers/tty/serial/ucc_uart.c | 3 + drivers/xen/events/events_base.c | 6 +- fs/affs/super.c | 5 +- fs/ext4/ialloc.c | 59 ++-- fs/ext4/inode.c | 24 +- fs/ext4/ioctl.c | 2 +- fs/ext4/mballoc.c | 10 +- fs/ext4/namei.c | 2 +- fs/f2fs/data.c | 3 +- fs/nfs/pnfs_nfs.c | 28 ++ fs/nfs/write.c | 4 + fs/xfs/xfs_fsops.c | 4 +- fs/xfs/xfs_inode.c | 26 +- fs/xfs/xfs_super.c | 38 +-- include/drm/drm_dp_dual_mode_helper.h | 92 ++++++ include/linux/mm.h | 2 +- include/video/imx-ipu-v3.h | 2 + kernel/exit.c | 29 +- lib/dma-debug.c | 2 +- mm/compaction.c | 4 +- mm/page_alloc.c | 2 +- mm/rmap.c | 2 + net/batman-adv/bat_v_ogm.c | 4 +- net/bluetooth/6lowpan.c | 11 +- net/sunrpc/auth_gss/svcauth_gss.c | 4 +- scripts/package/Makefile | 4 +- sound/soc/codecs/ak4642.c | 3 + 133 files changed, 1440 insertions(+), 484 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/121 f2fs: fix deadlock when flush inline data
4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chao Yu <[email protected]>
commit ab47036d8f7227361cad7894adee8e66ab6f95b2 upstream.
Below backtrace info was reported by Yunlei He:
Call Trace: [<ffffffff817a9395>] schedule+0x35/0x80 [<ffffffff817abb7d>] rwsem_down_read_failed+0xed/0x130 [<ffffffff813c12a8>] call_rwsem_down_read_failed+0x18/0x [<ffffffff817ab1d0>] down_read+0x20/0x30 [<ffffffffa02a1a12>] f2fs_evict_inode+0x242/0x3a0 [f2fs] [<ffffffff81217057>] evict+0xc7/0x1a0 [<ffffffff81217cd6>] iput+0x196/0x200 [<ffffffff812134f9>] __dentry_kill+0x179/0x1e0 [<ffffffff812136f9>] dput+0x199/0x1f0 [<ffffffff811fe77b>] __fput+0x18b/0x220 [<ffffffff811fe84e>] ____fput+0xe/0x10 [<ffffffff81097427>] task_work_run+0x77/0x90 [<ffffffff81074d62>] exit_to_usermode_loop+0x73/0xa2 [<ffffffff81003b7a>] do_syscall_64+0xfa/0x110 [<ffffffff817acf65>] entry_SYSCALL64_slow_path+0x25/0x25 Call Trace: [<ffffffff817a9395>] schedule+0x35/0x80 [<ffffffff81216dc3>] __wait_on_freeing_inode+0xa3/0xd0 [<ffffffff810bc300>] ? autoremove_wake_function+0x40/0x4 [<ffffffff8121771d>] find_inode_fast+0x7d/0xb0 [<ffffffff8121794a>] ilookup+0x6a/0xd0 [<ffffffffa02bc740>] sync_node_pages+0x210/0x650 [f2fs] [<ffffffff8122e690>] ? do_fsync+0x70/0x70 [<ffffffffa02b085e>] block_operations+0x9e/0xf0 [f2fs] [<ffffffff8137b795>] ? bio_endio+0x55/0x60 [<ffffffffa02b0942>] write_checkpoint+0x92/0xba0 [f2fs] [<ffffffff8117da57>] ? mempool_free_slab+0x17/0x20 [<ffffffff8117de8b>] ? mempool_free+0x2b/0x80 [<ffffffff8122e690>] ? do_fsync+0x70/0x70 [<ffffffffa02a53e3>] f2fs_sync_fs+0x63/0xd0 [f2fs] [<ffffffff8129630f>] ? ext4_sync_fs+0xbf/0x190 [<ffffffff8122e6b0>] sync_fs_one_sb+0x20/0x30 [<ffffffff812002e9>] iterate_supers+0xb9/0x110 [<ffffffff8122e7b5>] sys_sync+0x55/0x90 [<ffffffff81003ae9>] do_syscall_64+0x69/0x110 [<ffffffff817acf65>] entry_SYSCALL64_slow_path+0x25/0x25
With following excuting serials, we will set inline_node in inode page after inode was unlinked, result in a deadloop described as below:
1. open file
2. write file
3. unlink file
4. write file
5. close file
Thread A Thread B
- dput
- iput_final
- inode->i_state |= I_FREEING
- evict
- f2fs_evict_inode
- f2fs_sync_fs
- write_checkpoint
- block_operations
- f2fs_lock_all (down_write(cp_rwsem))
- f2fs_lock_op (down_read(cp_rwsem))
- sync_node_pages
- ilookup
- find_inode_fast
- __wait_on_freeing_inode (wait on I_FREEING clear)
Here, we change to set inline_node flag only for linked inode for fixing.
--- fs/f2fs/data.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/f2fs/data.c +2 -1
@@ -1480,7 +1480,8 @@ restart:if (pos + len <=MAX_INLINE_DATA ) {read_inline_data (page, ipage);set_inode_flag (F2FS_I (inode),FI_DATA_EXIST ); -set_inline_node (ipage); +if (inode->i_nlink) +set_inline_node (ipage); }else { err =f2fs_convert_inline_page (&dn, page);if (err)
Greg Kroah-Hartman
maintainerPATCH 2/121 MIPS64: R6: R2 emulation bugfix
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leonid Yegoshin <[email protected]>
commit 41fa29e4d8cf4150568a0fe9bb4d62229f9caed5 upstream.
Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64.
Replaced by STR(PTR)
[[email protected]: Apply changes as requested in the review process.]
Patchwork: https://patchwork.linux-mips.org/patch/9911/
--- arch/mips/kernel/mips-r2-to-r6-emul.c | 105 +++++++++++++++++----------------- 1 file changed, 53 insertions(+), 52 deletions(-)
arch/mips/kernel/mips-r2-to-r6-emul.c +53 -52
@@ -28,6 +28,7 @@#include <asm/inst.h> #include <asm/mips-r2-to-r6-emul.h> #include <asm/local.h> +#include <asm/mipsregs.h> #include <asm/ptrace.h> #include <asm/uaccess.h>
@@ -1251,10 +1252,10 @@ fpu_emul:" j 10b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1326,10 +1327,10 @@ fpu_emul:" j 10b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1397,10 +1398,10 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1467,10 +1468,10 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1582,14 +1583,14 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" -" .word 5b,8b\n" -" .word 6b,8b\n" -" .word 7b,8b\n" -" .word 0b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n" + STR(PTR) " 5b,8b\n" + STR(PTR) " 6b,8b\n" + STR(PTR) " 7b,8b\n" + STR(PTR) " 0b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1701,14 +1702,14 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" -" .word 5b,8b\n" -" .word 6b,8b\n" -" .word 7b,8b\n" -" .word 0b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n" + STR(PTR) " 5b,8b\n" + STR(PTR) " 6b,8b\n" + STR(PTR) " 7b,8b\n" + STR(PTR) " 0b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1820,14 +1821,14 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" -" .word 5b,8b\n" -" .word 6b,8b\n" -" .word 7b,8b\n" -" .word 0b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n" + STR(PTR) " 5b,8b\n" + STR(PTR) " 6b,8b\n" + STR(PTR) " 7b,8b\n" + STR(PTR) " 0b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -1938,14 +1939,14 @@ fpu_emul:" j 9b\n" " .previous\n" " .section __ex_table,\"a\"\n" -" .word 1b,8b\n" -" .word 2b,8b\n" -" .word 3b,8b\n" -" .word 4b,8b\n" -" .word 5b,8b\n" -" .word 6b,8b\n" -" .word 7b,8b\n" -" .word 0b,8b\n" + STR(PTR) " 1b,8b\n" + STR(PTR) " 2b,8b\n" + STR(PTR) " 3b,8b\n" + STR(PTR) " 4b,8b\n" + STR(PTR) " 5b,8b\n" + STR(PTR) " 6b,8b\n" + STR(PTR) " 7b,8b\n" + STR(PTR) " 0b,8b\n"" .previous\n" " .set pop\n" : "+&r"(rt), "=&r"(rs),
@@ -2000,7 +2001,7 @@ fpu_emul:"j 2b\n" ".previous\n" ".section __ex_table,\"a\"\n" -".word 1b, 3b\n" + STR(PTR) " 1b,3b\n"".previous\n" : "=&r"(res), "+&r"(err) : "r"(vaddr), "i"(SIGSEGV)
@@ -2058,7 +2059,7 @@ fpu_emul:"j 2b\n" ".previous\n" ".section __ex_table,\"a\"\n" -".word 1b, 3b\n" + STR(PTR) " 1b,3b\n"".previous\n" : "+&r"(res), "+&r"(err) : "r"(vaddr), "i"(SIGSEGV));
@@ -2119,7 +2120,7 @@ fpu_emul:"j 2b\n" ".previous\n" ".section __ex_table,\"a\"\n" -".word 1b, 3b\n" + STR(PTR) " 1b,3b\n"".previous\n" : "=&r"(res), "+&r"(err) : "r"(vaddr), "i"(SIGSEGV)
@@ -2182,7 +2183,7 @@ fpu_emul:"j 2b\n" ".previous\n" ".section __ex_table,\"a\"\n" -".word 1b, 3b\n" + STR(PTR) " 1b,3b\n"".previous\n" : "+&r"(res), "+&r"(err) : "r"(vaddr), "i"(SIGSEGV));
Greg Kroah-Hartman
maintainerPATCH 3/121 MIPS: math-emu: Fix jalr emulation when rd == $0
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit ab4a92e66741b35ca12f8497896bafbe579c28a1 upstream.
When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing to GPR $0 which should actually always remain zeroed. This would lead to any further instructions emulated which use $0 operating on a bogus value until the task is next context switched, at which point the value of $0 in the task context would be restored to the correct zero by a store in SAVE_SOME. Fix this by not writing to rd if it is $0.
Patchwork: https://patchwork.linux-mips.org/patch/13160/
--- arch/mips/math-emu/cp1emu.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/mips/math-emu/cp1emu.c +5 -3
@@ -445,9 +445,11 @@ static int isBranchInstr(struct pt_regscase spec_op:switch (insn.r_format.func) {case jalr_op: - regs->regs[insn.r_format.rd] = - regs->cp0_epc + dec_insn.pc_inc + - dec_insn.next_pc_inc; +if (insn.r_format.rd !=0 ) { + regs->regs[insn.r_format.rd] = + regs->cp0_epc + dec_insn.pc_inc + + dec_insn.next_pc_inc; + }/* Fall through */ case jr_op:/* For R6, JR already emulated in jalr_op */
Greg Kroah-Hartman
maintainerPATCH 4/121 MIPS: MSA: Fix a link error on `_init_msa_upper with older GCC
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit e49d38488515057dba8f0c2ba4cfde5be4a7281f upstream.
Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b of vector registers when MSA is first used"):
arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbb90): undefined reference to _init_msa_upper' traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against _init_msa_upper' traps.c:(.text+0xbef0): undefined reference to _init_msa_upper' traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against _init_msa_upper'
to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are unable to figure out that calls to _init_msa_upper' are indeed dead. Of the many ways to tackle this failure choose the approach we have already taken in thread_msa_context_live'.
[[email protected]: Drop patch segment to junk file.]
Patchwork: https://patchwork.linux-mips.org/patch/13271/
--- arch/mips/include/asm/msa.h | 13 +++++++++++++ arch/mips/kernel/traps.c | 6 +++--- 2 files changed, 16 insertions(+), 3 deletions(-)
arch/mips/include/asm/msa.h +13 -0
@@ -147,6 +147,19 @@ static inline void restore_msa(struct ta_restore_msa (t); } +static inline void init_msa_upper (void ) +{ +/* +* Check cpu_has_msa only if it's a constant. This will allow the +* compiler to optimise out code for CPUs without MSA without adding +* an extra redundant check for CPUs with MSA. +*/ +if (__builtin_constant_p (cpu_has_msa) && !cpu_has_msa) +return ; + +_init_msa_upper (); +} +#ifdef TOOLCHAIN_SUPPORTS_MSA #define __BUILD_MSA_CTL_REG (name, cs) \
arch/mips/kernel/traps.c +3 -3
@@ -1249,7 +1249,7 @@ static int enable_restore_fp_context(int err =init_fpu ();if (msa && !err) {enable_msa (); -_init_msa_upper (); +init_msa_upper ();set_thread_flag (TIF_USEDMSA );set_thread_flag (TIF_MSA_CTX_LIVE ); }
@@ -1312,7 +1312,7 @@ static int enable_restore_fp_context(int*/ prior_msa =test_and_set_thread_flag (TIF_MSA_CTX_LIVE );if (!prior_msa && was_fpu_owner) { -_init_msa_upper (); +init_msa_upper (); goto out; }
@@ -1329,7 +1329,7 @@ static int enable_restore_fp_context(int* of each vector register such that it cannot see data left * behind by another task. */ -_init_msa_upper (); +init_msa_upper (); }else {/* We need to restore the vector context. */ restore_msa (current);
Greg Kroah-Hartman
maintainerPATCH 5/121 MIPS: Dont unwind to user mode with EVA
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit a816b306c62195b7c43c92cb13330821a96bdc27 upstream.
When unwinding through IRQs and exceptions, the unwinding only continues if the PC is a kernel text address, however since EVA it is possible for user and kernel address ranges to overlap, potentially allowing unwinding to continue to user mode if the user PC happens to be in the kernel text address range.
Adjust the check to also ensure that the register state from before the exception is actually running in kernel mode, i.e. !user_mode(regs).
I don't believe any harm can come of this problem, since the PC is only output, the stack pointer is checked to ensure it resides within the task's stack page before it is dereferenced in search of the return address, and the return address register is similarly only output (if the PC is in a leaf function or the beginning of a non-leaf function).
However unwind_stack() is only meant for unwinding kernel code, so to be correct the unwind should stop there.
Patchwork: https://patchwork.linux-mips.org/patch/11700/
--- arch/mips/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/kernel/process.c +1 -1
@@ -455,7 +455,7 @@ unsigned long notrace unwind_stack_by_ad *sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) { regs = (struct pt_regs *)*sp; pc = regs->cp0_epc; -if (__kernel_text_address (pc)) { +if (!user_mode (regs) &&__kernel_text_address (pc)) { *sp = regs->regs[29 ]; *ra = regs->regs[31 ];return pc;
Greg Kroah-Hartman
maintainerPATCH 6/121 MIPS: Avoid using unwind_stack() with usermode
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 81a76d7119f63c359750e4adeff922a31ad1135f upstream.
When showing backtraces in response to traps, for example crashes and address errors (usually unaligned accesses) when they are set in debugfs to be reported, unwind_stack will be used if the PC was in the kernel text address range. However since EVA it is possible for user and kernel address ranges to overlap, and even without EVA userland can still trigger an address error by jumping to a KSeg0 address.
Adjust the check to also ensure that it was running in kernel mode. I don't believe any harm can come of this problem, since unwind_stack() is sufficiently defensive, however it is only meant for unwinding kernel code, so to be correct it should use the raw backtracing instead.
Patchwork: https://patchwork.linux-mips.org/patch/11701/
--- arch/mips/kernel/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/kernel/traps.c +1 -1
@@ -145,7 +145,7 @@ static void show_backtrace(struct task_sif (!task) task = current; -if (raw_show_trace || !__kernel_text_address (pc)) { +if (raw_show_trace ||user_mode (regs) || !__kernel_text_address (pc)) {show_raw_backtrace (sp);return ; }
Greg Kroah-Hartman
maintainerPATCH 7/121 MIPS: Fix siginfo.h to use strict posix types
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 5daebc477da4dfeb31ae193d83084def58fd2697 upstream.
Commit 85efde6f4e0d ("make exported headers use strict posix types") changed the asm-generic siginfo.h to use the __kernel_* types, and commit 3a471cbc081b ("remove __KERNEL_STRICT_NAMES") make the internal types accessible only to the kernel, but the MIPS implementation hasn't been updated to match.
Switch to proper types now so that the exported asm/siginfo.h won't produce quite so many compiler errors when included alone by a user program.
Patchwork: https://patchwork.linux-mips.org/patch/12477/
--- arch/mips/include/uapi/asm/siginfo.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/mips/include/uapi/asm/siginfo.h +9 -9
@@ -42,13 +42,13 @@ typedef struct siginfo {/* kill() */ struct { -pid_t _pid;/* sender's pid */ +__kernel_pid_t _pid;/* sender's pid */ __ARCH_SI_UID_T _uid;/* sender's uid */ } _kill;/* POSIX.1b timers */ struct { -timer_t _tid;/* timer id */ +__kernel_timer_t _tid;/* timer id */ int _overrun;/* overrun count */ char _pad[sizeof ( __ARCH_SI_UID_T) -sizeof (int )];sigval_t _sigval;/* same as below */
@@ -57,26 +57,26 @@ typedef struct siginfo {/* POSIX.1b signals */ struct { -pid_t _pid;/* sender's pid */ +__kernel_pid_t _pid;/* sender's pid */ __ARCH_SI_UID_T _uid;/* sender's uid */ sigval_t _sigval; } _rt;/* SIGCHLD */ struct { -pid_t _pid;/* which child */ +__kernel_pid_t _pid;/* which child */ __ARCH_SI_UID_T _uid;/* sender's uid */ int _status;/* exit code */ -clock_t _utime; -clock_t _stime; +__kernel_clock_t _utime; +__kernel_clock_t _stime; } _sigchld;/* IRIX SIGCHLD */ struct { -pid_t _pid;/* which child */ -clock_t _utime; +__kernel_pid_t _pid;/* which child */ +__kernel_clock_t _utime;int _status;/* exit code */ -clock_t _stime; +__kernel_clock_t _stime; } _irix_sigchld;/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
Greg Kroah-Hartman
maintainerPATCH 8/121 MIPS: Fix uapi include in exported asm/siginfo.h
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 987e5b834467c9251ca584febda65ef8f66351a9 upstream.
Since commit 8cb48fe169dd ("MIPS: Provide correct siginfo_t.si_stime"), MIPS' uapi/asm/siginfo.h has included uapi/asm-generic/siginfo.h directly before defining MIPS' struct siginfo, in order to get the necessary definitions needed for the siginfo struct without the generic copy_siginfo() hitting compiler errors due to struct siginfo not yet being defined.
Now that the generic copy_siginfo() is moved out to linux/signal.h we can safely include asm-generic/siginfo.h before defining the MIPS specific struct siginfo, which avoids the uapi/ include as well as breakage due to generic copy_siginfo() being defined before struct siginfo.
--- arch/mips/include/uapi/asm/siginfo.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/mips/include/uapi/asm/siginfo.h +1 -3
@@ -28,7 +28,7 @@#define __ARCH_SIGSYS -#include <uapi/asm-generic/siginfo.h> +#include <asm-generic/siginfo.h> /* We can't use generic siginfo_t, because our si_code and si_errno are swapped */ typedef struct siginfo {
@@ -123,6 +123,4 @@ typedef struct siginfo {#define SI_TIMER __SI_CODE(__SI_TIMER, -3)/* sent by timer expiration */ #define SI_MESGQ __SI_CODE(__SI_MESGQ, -4)/* sent by real time mesq state change */ -#include <asm-generic/siginfo.h> -#endif /* _UAPI_ASM_SIGINFO_H */
Greg Kroah-Hartman
maintainerPATCH 9/121 MIPS: Fix watchpoint restoration
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit a7e89326b415b5d81c4b1016fd4a40db861eb58d upstream.
Commit f51246efee2b ("MIPS: Get rid of finish_arch_switch().") moved the __restore_watch() call from finish_arch_switch() (i.e. after resume() returns) to before the resume() call in switch_to(). This results in watchpoints only being restored when a task is descheduled, preventing the watchpoints from being effective most of the time, except due to chance before the watchpoints are lazily removed.
Fix the call sequence from switch_to() through to mips_install_watch_registers() to pass the task_struct pointer of the next task, instead of using current. This allows the watchpoints for the next (non-current) task to be restored without reintroducing finish_arch_switch().
Patchwork: https://patchwork.linux-mips.org/patch/12726/
--- arch/mips/include/asm/switch_to.h | 2 +- arch/mips/include/asm/watch.h | 10 +++++----- arch/mips/kernel/pm.c | 2 +- arch/mips/kernel/watch.c | 5 ++--- 4 files changed, 9 insertions(+), 10 deletions(-)
arch/mips/include/asm/switch_to.h +1 -1
@@ -105,7 +105,7 @@ do { \__clear_software_ll_bit (); \if (cpu_has_userlocal) \write_c0_userlocal (task_thread_info (next)->tp_value); \ -__restore_watch (); \ +__restore_watch (next); \ (last) =resume (prev, next,task_thread_info (next)); \ }while (0 )
arch/mips/include/asm/watch.h +5 -5
@@ -12,21 +12,21 @@#include <asm/mipsregs.h> -void mips_install_watch_registers (void ); +void mips_install_watch_registers (struct task_struct *t);void mips_read_watch_registers (void );void mips_clear_watch_registers (void );void mips_probe_watch_registers (struct cpuinfo_mips *c);#ifdef CONFIG_HARDWARE_WATCHPOINTS -#define __restore_watch () do { \ +#define __restore_watch (task) do { \ if (unlikely(test_bit(TIF_LOAD_WATCH, \ - ¤t_thread_info()->flags))) { \ - mips_install_watch_registers(); \ + &task_thread_info(task)->flags))) { \ + mips_install_watch_registers(task); \ } \ } while (0)#else -#define __restore_watch () do {} while (0) +#define __restore_watch (task) do {} while (0)#endif #endif /* _ASM_WATCH_H */
arch/mips/kernel/pm.c +1 -1
@@ -56,7 +56,7 @@ static void mips_cpu_restore(void)write_c0_userlocal (current_thread_info ()->tp_value);/* Restore watch registers */ -__restore_watch (); +__restore_watch (current); }/**
arch/mips/kernel/watch.c +2 -3
@@ -15,10 +15,9 @@* Install the watch registers for the current thread. A maximum of * four registers are installed although the machine may have more. */ -void mips_install_watch_registers (void ) +void mips_install_watch_registers (struct task_struct *t) { -struct mips3264_watch_reg_state *watches = - ¤t->thread.watch.mips3264; +struct mips3264_watch_reg_state *watches = &t->thread.watch.mips3264;switch (current_cpu_data.watch_reg_use_cnt) {default :BUG ();
Greg Kroah-Hartman
maintainerPATCH 10/121 MIPS: Handle highmem pages in __update_cache
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit f4281bba818105c7c91799abe40bc05c0dbdaa25 upstream.
The following patch will expose __update_cache to highmem pages. Handle them by mapping them in for the duration of the cache maintenance, just like in __flush_dcache_page. The code for that isn't shared because we need the page address in __update_cache so sharing became messy. Given that the entirity is an extra 5 lines, just duplicate it.
Patchwork: https://patchwork.linux-mips.org/patch/12721/
--- arch/mips/mm/cache.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
arch/mips/mm/cache.c +9 -1
@@ -143,9 +143,17 @@ void __update_cache(struct vm_area_strucreturn ; page =pfn_to_page (pfn);if (page_mapping (page) &&Page_dcache_dirty (page)) { - addr = (unsigned long )page_address (page); +if (PageHighMem (page)) + addr = (unsigned long )kmap_atomic (page); +else + addr = (unsigned long )page_address (page); +if (exec ||pages_do_alias (addr, address &PAGE_MASK ))flush_data_cache_page (addr); + +if (PageHighMem (page)) +__kunmap_atomic ((void *)addr); +ClearPageDcacheDirty (page); } }
Greg Kroah-Hartman
maintainerPATCH 11/121 MIPS: Sync icache & dcache in set_pte_at
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 37d22a0d798b5c938b277d32cfd86dc231381342 upstream.
It's possible for pages to become visible prior to update_mmu_cache running if a thread within the same address space preempts the current thread or runs simultaneously on another CPU. That is, the following scenario is possible:
CPU0 CPU1
write to page
flush_dcache_page
flush_icache_page
set_pte_at
map page
update_mmu_cache
If CPU1 maps the page in between CPU0's set_pte_at, which marks it valid & visible, and update_mmu_cache where the dcache flush occurs then CPU1s icache will fill from stale data (unless it fills from the dcache, in which case all is good, but most MIPS CPUs don't have this property). Commit 4d46a67a3eb8 ("MIPS: Fix race condition in lazy cache flushing.") attempted to fix that by performing the dcache flush in flush_icache_page such that it occurs before the set_pte_at call makes the page visible. However it has the problem that not all code that writes to pages exposed to userland call flush_icache_page. There are many callers of set_pte_at under mm/ and only 2 of them do call flush_icache_page. Thus the race window between a page becoming visible & being coherent between the icache & dcache remains open in some cases.
To illustrate some of the cases, a WARN was added to __update_cache with this patch applied that triggered in cases where a page about to be flushed from the dcache was not the last page provided to flush_icache_page. That is, backtraces were obtained for cases in which the race window is left open without this patch. The 2 standout examples follow.
When forking a process:
[ 15.271842] [<80417630>] __update_cache+0xcc/0x188 [ 15.277274] [<80530394>] copy_page_range+0x56c/0x6ac [ 15.282861] [<8042936c>] copy_process.part.54+0xd40/0x17ac [ 15.289028] [<80429f80>] do_fork+0xe4/0x420 [ 15.293747] [<80413808>] handle_sys+0x128/0x14c
When exec'ing an ELF binary:
[ 14.445964] [<80417630>] __update_cache+0xcc/0x188 [ 14.451369] [<80538d88>] move_page_tables+0x414/0x498 [ 14.457075] [<8055d848>] setup_arg_pages+0x220/0x318 [ 14.462685] [<805b0f38>] load_elf_binary+0x530/0x12a0 [ 14.468374] [<8055ec3c>] search_binary_handler+0xbc/0x214 [ 14.474444] [<8055f6c0>] do_execveat_common+0x43c/0x67c [ 14.480324] [<8055f938>] do_execve+0x38/0x44 [ 14.485137] [<80413808>] handle_sys+0x128/0x14c
These code paths write into a page, call flush_dcache_page then call set_pte_at without flush_icache_page inbetween. The end result is that the icache can become corrupted & userland processes may execute unexpected or invalid code, typically resulting in a reserved instruction exception, a trap or a segfault.
Fix this race condition fully by performing any cache maintenance required to keep the icache & dcache in sync in set_pte_at, before the page is made valid. This has the added bonus of ensuring the cache maintenance always happens in one location, rather than being duplicated in flush_icache_page & update_mmu_cache. It also matches the way other architectures solve the same problem (see arm, ia64 & powerpc).
Patchwork: https://patchwork.linux-mips.org/patch/12722/
--- arch/mips/include/asm/cacheflush.h | 6 ------ arch/mips/include/asm/pgtable.h | 26 +++++++++++++++++++++----- arch/mips/mm/cache.c | 19 +++---------------- 3 files changed, 24 insertions(+), 27 deletions(-)
arch/mips/include/asm/cacheflush.h +0 -6
@@ -51,7 +51,6 @@ extern void (*flush_cache_range)(struct unsigned long start, unsigned long end);extern void (*flush_cache_page)(struct vm_area_struct *vma,unsigned long page,unsigned long pfn);extern void __flush_dcache_page (struct page *page); -extern void __flush_icache_page (struct vm_area_struct *vma,struct page *page);#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1static inline void flush_dcache_page (struct page *page)
@@ -77,11 +76,6 @@ static inline void flush_anon_page(strucstatic inline void flush_icache_page (struct vm_area_struct *vma,struct page *page) { -if (!cpu_has_ic_fills_f_dc && (vma->vm_flags &VM_EXEC ) && -Page_dcache_dirty (page)) { -__flush_icache_page (vma, page); -ClearPageDcacheDirty (page); - } }extern void (*flush_icache_range)(unsigned long start,unsigned long end);
arch/mips/include/asm/pgtable.h +21 -5
@@ -127,10 +127,14 @@ do { \ } \ }while (0 ) +static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, +pte_t *ptep,pte_t pteval); +#if defined(CONFIG_PHYS_ADDR_T_64BIT ) && defined(CONFIG_CPU_MIPS32 )#define pte_none (pte) (!(((pte).pte_high) & ~_PAGE_GLOBAL))#define pte_present (pte) ((pte).pte_low & _PAGE_PRESENT) +#define pte_no_exec (pte) ((pte).pte_low & _PAGE_NO_EXEC)static inline void set_pte (pte_t *ptep,pte_t pte) {
@@ -148,7 +152,6 @@ static inline void set_pte(pte_t *ptep, buddy->pte_high |= _PAGE_GLOBAL; } } -#define set_pte_at (mm, addr, ptep, pteval) set_pte(ptep, pteval)static inline void pte_clear (struct mm_struct *mm,unsigned long addr,pte_t *ptep) {
@@ -166,6 +169,7 @@ static inline void pte_clear(struct mm_s#define pte_none (pte) (!(pte_val(pte) & ~_PAGE_GLOBAL))#define pte_present (pte) (pte_val(pte) & _PAGE_PRESENT) +#define pte_no_exec (pte) (pte_val(pte) & _PAGE_NO_EXEC)/* * Certain architectures need to do special things when pte's
@@ -218,7 +222,6 @@ static inline void set_pte(pte_t *ptep, }#endif } -#define set_pte_at (mm, addr, ptep, pteval) set_pte(ptep, pteval)static inline void pte_clear (struct mm_struct *mm,unsigned long addr,pte_t *ptep) {
@@ -234,6 +237,22 @@ static inline void pte_clear(struct mm_s }#endif +static inline void set_pte_at (struct mm_struct *mm,unsigned long addr, +pte_t *ptep,pte_t pteval) +{ +extern void __update_cache (unsigned long address,pte_t pte); + +if (!pte_present (pteval)) + goto cache_sync_done; + +if (pte_present (*ptep) && (pte_pfn (*ptep) ==pte_pfn (pteval))) + goto cache_sync_done; + +__update_cache (addr, pteval); +cache_sync_done: +set_pte (ptep, pteval); +} +/* * (pmds are folded into puds so this doesn't get actually called, * but the define is needed for a generic inline function.)
@@ -430,15 +449,12 @@ static inline pte_t pte_modify(pte_t pteextern void __update_tlb (struct vm_area_struct *vma,unsigned long address,pte_t pte); -extern void __update_cache (struct vm_area_struct *vma,unsigned long address, -pte_t pte);static inline void update_mmu_cache (struct vm_area_struct *vma,unsigned long address,pte_t *ptep) {pte_t pte = *ptep;__update_tlb (vma, address, pte); -__update_cache (vma, address, pte); } static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
arch/mips/mm/cache.c +3 -16
@@ -119,30 +119,17 @@ void __flush_anon_page(struct page *pageEXPORT_SYMBOL (__flush_anon_page); -void __flush_icache_page (struct vm_area_struct *vma,struct page *page) -{ -unsigned long addr; - -if (PageHighMem (page)) -return ; - - addr = (unsigned long )page_address (page); -flush_data_cache_page (addr); -} -EXPORT_SYMBOL_GPL (__flush_icache_page); - -void __update_cache (struct vm_area_struct *vma,unsigned long address, -pte_t pte) +void __update_cache (unsigned long address,pte_t pte) {struct page *page;unsigned long pfn, addr; -int exec = (vma->vm_flags &VM_EXEC ) && !cpu_has_ic_fills_f_dc; +int exec = !pte_no_exec (pte) && !cpu_has_ic_fills_f_dc; pfn =pte_pfn (pte);if (unlikely (!pfn_valid (pfn)))return ; page =pfn_to_page (pfn); -if (page_mapping (page) &&Page_dcache_dirty (page)) { +if (Page_dcache_dirty (page)) {if (PageHighMem (page)) addr = (unsigned long )kmap_atomic (page);else
Greg Kroah-Hartman
maintainerPATCH 12/121 MIPS: Loongson-3: Fix build error after ld-version.sh modification
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 820880cdba0137baff6cc0e828c3c418c363ae44 upstream.
Commit d5ece1cb074b2c ("Fix ld-version.sh to handle large 3rd version part") modifies the ld version description. This causes a build error on Loongson-3, so fix it.
Patchwork: https://patchwork.linux-mips.org/patch/12890/
--- arch/mips/loongson64/Platform | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/loongson64/Platform +1 -1
@@ -31,7 +31,7 @@ cflags-$(CONFIG_CPU_LOONGSON3) += -Wa,-- # can't easily be used safely within the kbuild framework. # ifeq ($(call cc-ifversion, -ge, 0409, y), y) - ifeq ($(call ld-ifversion, -ge, 22500000, y), y) + ifeq ($(call ld-ifversion, -ge, 225000000, y), y) cflags-$(CONFIG_CPU_LOONGSON3) += \ $(call cc-option,-march=loongson3a -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64) else
Greg Kroah-Hartman
maintainerPATCH 13/121 MIPS: ath79: make bootconsole wait for both THRE and TEMT
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthias Schiffer <[email protected]>
commit f5b556c94c8490d42fea79d7b4ae0ecbc291e69d upstream.
This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole.
Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial controller (which would sometimes result in garbage being transmitted.) This change does not cause a visible performance loss.
In addition, this seems to fix a hang observed in certain configurations on many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
A more complete follow-up patch will disable 8250 autoconfig for ath79 altogether (the serial controller is detected as a 16550A, which is not fully compatible with the ath79 serial, and the autoconfig may lead to undefined behavior on ath79.)
--- arch/mips/ath79/early_printk.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/mips/ath79/early_printk.c +4 -2
@@ -31,13 +31,15 @@ static inline void prom_putchar_wait(voi }while (1 ); } +#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE) +static void prom_putchar_ar71xx (unsigned char ch) {void __iomem *base = (void __iomem *)(KSEG1ADDR (AR71XX_UART_BASE )); -prom_putchar_wait (base +UART_LSR *4 ,UART_LSR_THRE ,UART_LSR_THRE ); +prom_putchar_wait (base +UART_LSR *4 ,BOTH_EMPTY ,BOTH_EMPTY );__raw_writel (ch, base +UART_TX *4 ); -prom_putchar_wait (base +UART_LSR *4 ,UART_LSR_THRE ,UART_LSR_THRE ); +prom_putchar_wait (base +UART_LSR *4 ,BOTH_EMPTY ,BOTH_EMPTY ); }static void prom_putchar_ar933x (unsigned char ch)
Greg Kroah-Hartman
maintainerPATCH 14/121 MIPS: Reserve nosave data for hibernation
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit a95d069204e178f18476f5499abab0d0d9cbc32c upstream.
After commit 92923ca3aacef63c92d ("mm: meminit: only set page reserved in the memblock region"), the MIPS hibernation is broken. Because pages in nosave data section should be "reserved", but currently they aren't set to "reserved" at initialization. This patch makes hibernation work again.
Patchwork: https://patchwork.linux-mips.org/patch/12888/
--- arch/mips/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+)
arch/mips/kernel/setup.c +3 -0
@@ -706,6 +706,9 @@ static void __init arch_mem_init(char **for_each_memblock (reserved, reg)if (reg->size !=0 )reserve_bootmem (reg->base, reg->size,BOOTMEM_DEFAULT ); + +reserve_bootmem_region (__pa_symbol (&__nosave_begin), +__pa_symbol (&__nosave_end));/* Reserve for hibernation */ }static void __init resource_init (void )
Greg Kroah-Hartman
maintainerPATCH 15/121 MIPS: Loongson-3: Reserve 32MB for RS780E integrated GPU
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 3484de7bcbed20ecbf2b8d80671619e7059e2dd7 upstream.
Due to datasheet, reserving 0xff800000~0xffffffff (8MB below 4GB) is not enough for RS780E integrated GPU's TOM (top of memory) registers and MSI/MSI-x memory region, so we reserve 0xfe000000~0xffffffff (32MB below 4GB).
Patchwork: https://patchwork.linux-mips.org/patch/12889/
--- arch/mips/loongson64/loongson-3/numa.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/mips/loongson64/loongson-3/numa.c +3 -3
@@ -213,10 +213,10 @@ static void __init node_mem_init(unsigne BOOTMEM_DEFAULT);if (node ==0 &&node_end_pfn (0 ) >= (0xffffffff >>PAGE_SHIFT )) { -/* Reserve 0xff800000~0xffffffff for RS780E integrated GPU */ +/* Reserve 0xfe000000~0xffffffff for RS780E integrated GPU */ reserve_bootmem_node (NODE_DATA (node), - (node_addrspace_offset |0xff800000 ), -8 <<20 ,BOOTMEM_DEFAULT ); + (node_addrspace_offset |0xfe000000 ), +32 <<20 ,BOOTMEM_DEFAULT ); }sparse_memory_present_with_active_regions (node);
Greg Kroah-Hartman
maintainerPATCH 16/121 MIPS: Use copy_s.fmt rather than copy_u.fmt
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 8a3c8b48aca8771bff3536e40aa26ffb311699d1 upstream.
In revision 1.12 of the MSA specification, the copy_u.w instruction has been removed for MIPS32 & the copy_u.d instruction has been removed for MIPS64. Newer toolchains (eg. Codescape SDK essentials 2015.10) will complain about this like so:
arch/mips/kernel/r4k_fpu.S:290: Error: opcode not supported on this
processor: mips32r2 (mips32r2) `copy_u.w $1,$w26[3]'
Since we always copy to the width of a GPR, simply use copy_s instead of copy_u to fix this.
Patchwork: https://patchwork.linux-mips.org/patch/13061/
--- arch/mips/include/asm/asmmacro.h | 24 ++++++++++++------------ arch/mips/kernel/r4k_fpu.S | 10 +++++----- 2 files changed, 17 insertions(+), 17 deletions(-)
arch/mips/include/asm/asmmacro.h +12 -12
@@ -298,21 +298,21 @@ .set pop .endm - .macro copy_u_w ws, n + .macro copy_s_w ws, n .set push .set mips32r2 .set fp=64 .set msa - copy_u.w $1, $w\ws[\n] + copy_s.w $1, $w\ws[\n] .set pop .endm - .macro copy_u_d ws, n + .macro copy_s_d ws, n .set push .set mips64r2 .set fp=64 .set msa - copy_u.d $1, $w\ws[\n] + copy_s.d $1, $w\ws[\n] .set pop .endm
@@ -346,8 +346,8 @@#define STH_MSA_INSN 0x5800081f#define STW_MSA_INSN 0x5800082f#define STD_MSA_INSN 0x5800083f -#define COPY_UW_MSA_INSN 0x58f00056 -#define COPY_UD_MSA_INSN 0x58f80056 +#define COPY_SW_MSA_INSN 0x58b00056 +#define COPY_SD_MSA_INSN 0x58b80056#define INSERT_W_MSA_INSN 0x59300816#define INSERT_D_MSA_INSN 0x59380816#else
@@ -361,8 +361,8 @@#define STH_MSA_INSN 0x78000825#define STW_MSA_INSN 0x78000826#define STD_MSA_INSN 0x78000827 -#define COPY_UW_MSA_INSN 0x78f00059 -#define COPY_UD_MSA_INSN 0x78f80059 +#define COPY_SW_MSA_INSN 0x78b00059 +#define COPY_SD_MSA_INSN 0x78b80059#define INSERT_W_MSA_INSN 0x79300819#define INSERT_D_MSA_INSN 0x79380819#endif
@@ -461,21 +461,21 @@ .set pop .endm - .macro copy_u_w ws, n + .macro copy_s_w ws, n .set push .set noat SET_HARDFLOAT .insn - .word COPY_UW_MSA_INSN | (\n << 16) | (\ws << 11) + .word COPY_SW_MSA_INSN | (\n << 16) | (\ws << 11) .set pop .endm - .macro copy_u_d ws, n + .macro copy_s_d ws, n .set push .set noat SET_HARDFLOAT .insn - .word COPY_UD_MSA_INSN | (\n << 16) | (\ws << 11) + .word COPY_SD_MSA_INSN | (\n << 16) | (\ws << 11) .set pop .endm
arch/mips/kernel/r4k_fpu.S +5 -5
@@ -244,17 +244,17 @@ LEAF(\name) .set push .set noat #ifdef CONFIG_64BIT - copy_u_d \wr, 1 + copy_s_d \wr, 1 EX sd $1, \off(\base) #elif defined(CONFIG_CPU_LITTLE_ENDIAN) - copy_u_w \wr, 2 + copy_s_w \wr, 2 EX sw $1, \off(\base) - copy_u_w \wr, 3 + copy_s_w \wr, 3 EX sw $1, (\off+4)(\base) #else /* CONFIG_CPU_BIG_ENDIAN */ - copy_u_w \wr, 2 + copy_s_w \wr, 2 EX sw $1, (\off+4)(\base) - copy_u_w \wr, 3 + copy_s_w \wr, 3 EX sw $1, \off(\base) #endif .set pop
Greg Kroah-Hartman
maintainerPATCH 17/121 MIPS: Fix MSA ld_*/st_* asm macros to use PTR_ADDU
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit ea1688573426adc2587ed52d086b51c7c62eaca3 upstream.
The MSA ld_*/st_* assembler macros for when the toolchain doesn't support MSA use addu to offset the base address. However it is a virtual memory pointer so fix it to use PTR_ADDU which expands to daddu for 64-bit kernels.
Patchwork: https://patchwork.linux-mips.org/patch/13062/
--- arch/mips/include/asm/asmmacro.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
arch/mips/include/asm/asmmacro.h +8 -8
@@ -393,7 +393,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word LDB_MSA_INSN | (\wd << 6) .set pop .endm
@@ -402,7 +402,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word LDH_MSA_INSN | (\wd << 6) .set pop .endm
@@ -411,7 +411,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word LDW_MSA_INSN | (\wd << 6) .set pop .endm
@@ -420,7 +420,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word LDD_MSA_INSN | (\wd << 6) .set pop .endm
@@ -429,7 +429,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word STB_MSA_INSN | (\wd << 6) .set pop .endm
@@ -438,7 +438,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word STH_MSA_INSN | (\wd << 6) .set pop .endm
@@ -447,7 +447,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word STW_MSA_INSN | (\wd << 6) .set pop .endm
@@ -456,7 +456,7 @@ .set push .set noat SET_HARDFLOAT - addu $1, \base, \off + PTR_ADDU $1, \base, \off .word STD_MSA_INSN | (\wd << 6) .set pop .endm
Greg Kroah-Hartman
maintainerPATCH 18/121 MIPS: Force CPUs to lose FP context during mode switches
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 6b8322576e9d325b65c54fbef64e4e8690ad70ce upstream.
Commit 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") added support for the PR_SET_FP_MODE prctl, which allows a userland program to modify its FP mode at runtime. This is most notably required if dynamic linking leads to the FP mode requirement changing at runtime from that indicated in the initial executable's ELF header. In order to avoid overhead in the general FP context restore code, it aimed to have threads in the process become unable to enable the FPU during a mode switch & have the thread calling the prctl syscall wait for all other threads in the process to be context switched at least once. Once that happens we can know that no thread in the process whose mode will be switched has live FP context, and it's safe to perform the mode switch. However in the (rare) case of modeswitches occurring in multithreaded programs this can lead to indeterminate delays for the thread invoking the prctl syscall, and the code monitoring for those context switches was woefully inadequate for all but the simplest cases.
Fix this by broadcasting an IPI if other CPUs may have live FP context for an affected thread, with a handler causing those CPUs to relinquish their FPU ownership. Threads will then be allowed to continue running but will stall on the wait_on_atomic_t in enable_restore_fp_context if they attempt to use FP again whilst the mode switch is still in progress. The end result is less fragile poking at scheduler context switch counts & a more expedient completion of the mode switch.
Patchwork: https://patchwork.linux-mips.org/patch/13145/
--- arch/mips/kernel/process.c | 40 +++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 23 deletions(-)
arch/mips/kernel/process.c +17 -23
@@ -580,11 +580,19 @@ int mips_get_process_fp_mode(struct taskreturn value; } +static void prepare_for_fp_mode_switch (void *info) +{ +struct mm_struct *mm = info; + +if (current->mm == mm) +lose_fpu (1 ); +} +int mips_set_process_fp_mode (struct task_struct *task,unsigned int value) {const unsigned int known_bits =PR_FP_MODE_FR |PR_FP_MODE_FRE ; -unsigned long switch_count;struct task_struct *t; +int max_users;/* Check the value is valid */ if (value & ~known_bits)
@@ -610,31 +618,17 @@ int mips_set_process_fp_mode(struct tasksmp_mb__after_atomic ();/* -* If there are multiple online CPUs then wait until all threads whose -* FP mode is about to change have been context switched. This approach -* allows us to only worry about whether an FP mode switch is in -* progress when FP is first used in a tasks time slice. Pretty much all -* of the mode switch overhead can thus be confined to cases where mode -* switches are actually occurring. That is, to here. However for the -* thread performing the mode switch it may take a while... +* If there are multiple online CPUs then force any which are running +* threads in this process to lose their FPU context, which they can't +* regain until fp_mode_switching is cleared later. */ if (num_online_cpus () >1 ) { -spin_lock_irq (&task->sighand->siglock); - -for_each_thread (task, t) { -if (t == current) -continue ; - - switch_count = t->nvcsw + t->nivcsw; - -do { -spin_unlock_irq (&task->sighand->siglock); -cond_resched (); -spin_lock_irq (&task->sighand->siglock); - }while ((t->nvcsw + t->nivcsw) == switch_count); - } +/* No need to send an IPI for the local CPU */ + max_users = (task->mm == current->mm) ?1 :0 ; -spin_unlock_irq (&task->sighand->siglock); +if (atomic_read (¤t->mm->mm_users) > max_users) +smp_call_function (prepare_for_fp_mode_switch, + (void *)current->mm,1 ); }/*
Greg Kroah-Hartman
maintainerPATCH 19/121 MIPS: Prevent "restoration" of MSA context in non-MSA kernels
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 6533af4d4831c421cd9aa4dce7cfc19a3514cc09 upstream.
If a kernel doesn't support MSA context (ie. CONFIG_CPU_HAS_MSA=n) then it will only keep 64 bits per FP register in thread context, and the calls to set_fpr64 in restore_msa_extcontext will overrun the end of the FP register context into the FCSR & MSACSR values. GCC 6.x has become smart enough to detect this & complain like so:
arch/mips/kernel/signal.c: In function 'protected_restore_fp_context':
./arch/mips/include/asm/processor.h:114:17: error: array subscript is above array bounds [-Werror=array-bounds]
fpr->val##width[FPR_IDX(width, idx)] = val; \
~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
./arch/mips/include/asm/processor.h:118:1: note: in expansion of macro 'BUILD_FPR_ACCESS'
BUILD_FPR_ACCESS(64)
The only way to trigger this code to run would be for a program to set up an artificial extended MSA context structure following a sigframe & execute sigreturn. Whilst this doesn't allow a program to write to any state that it couldn't already, it makes little sense to allow this "restoration" of MSA context in a system that doesn't support MSA.
Fix this by killing a program with SIGSYS if it tries something as crazy as "restoring" fake MSA context in this way, also fixing the build error & allowing for most of restore_msa_extcontext to be optimised out of kernels without support for MSA.
Patchwork: https://patchwork.linux-mips.org/patch/13164/
--- arch/mips/kernel/signal.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
arch/mips/kernel/signal.c +5 -2
@@ -195,6 +195,9 @@ static int restore_msa_extcontext(void _unsigned int csr;int i, err; +if (!config_enabled (CONFIG_CPU_HAS_MSA )) +return SIGSYS ; +if (size !=sizeof (*msa))return -EINVAL ;
@@ -398,8 +401,8 @@ int protected_restore_fp_context(void __ } fp_done: -if (used &USED_EXTCONTEXT ) - err |=restore_extcontext (sc_to_extcontext (sc)); +if (!err && (used &USED_EXTCONTEXT )) + err =restore_extcontext (sc_to_extcontext (sc));return err ?: sig; }
Greg Kroah-Hartman
maintainerPATCH 20/121 MIPS: Disable preemption during prctl(PR_SET_FP_MODE, ...)
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit bd239f1e1429e7781096bf3884bdb1b2b1bb4f28 upstream.
Whilst a PR_SET_FP_MODE prctl is performed there are decisions made based upon whether the task is executing on the current CPU. This may change if we're preempted, so disable preemption to avoid such changes for the lifetime of the mode switch.
Patchwork: https://patchwork.linux-mips.org/patch/13144/
--- arch/mips/kernel/process.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/mips/kernel/process.c +4 -0
@@ -609,6 +609,9 @@ int mips_set_process_fp_mode(struct taskif (!(value &PR_FP_MODE_FR ) && cpu_has_fpu && cpu_has_mips_r6)return -EOPNOTSUPP ; +/* Proceed with the mode switch */ +preempt_disable (); +/* Save FP & vector context, then disable FPU & MSA */ if (task->signal == current->signal)lose_fpu (1 );
@@ -653,6 +656,7 @@ int mips_set_process_fp_mode(struct task/* Allow threads to use FP again */ atomic_set (&task->mm->context.fp_mode_switching,0 ); +preempt_enable ();return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 21/121 MIPS: ptrace: Fix FP context restoration FCSR regression
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit 4249548454f7ba4581aeee26bd83f42b48a14d15 upstream.
Fix a floating-point context restoration regression introduced with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") that causes a Floating Point exception and consequently a kernel oops with hard float configurations when one or more FCSR Enable and their corresponding Cause bits are set both at a time via a ptrace(2) call.
To do so reinstate Cause bit masking originally introduced with commit b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause bits") to address this exact problem and then inadvertently removed from the PTRACE_SETFPREGS request with the commit referred above.
Patchwork: https://patchwork.linux-mips.org/patch/13238/
--- arch/mips/kernel/ptrace.c | 1 + 1 file changed, 1 insertion(+)
arch/mips/kernel/ptrace.c +1 -0
@@ -176,6 +176,7 @@ int ptrace_setfpregs(struct task_struct }__get_user (value, data +64 ); + value &= ~FPU_CSR_ALL_X ; fcr31 = child->thread.fpu.fcr31; mask = boot_cpu_data.fpu_msk31; child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask);
Greg Kroah-Hartman
maintainerPATCH 22/121 MIPS: ptrace: Prevent writes to read-only FCSR bits
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit abf378be49f38c4d3e23581d3df3fa9f1b1b11d2 upstream.
Correct the cases missed with commit 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling") and prevent writes to read-only FCSR bits there.
This in particular applies to FP context initialisation where any IEEE 754-2008 bits preset by `mips_set_personality_nan' are cleared before the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request addressing FPC_CSR where no masking of read-only FCSR bits is done.
Remove the FCSR clearing from FP context initialisation then and unify PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out code from `ptrace_setfpregs' and calling it from both places.
This mostly matters to soft float configurations where the emulator can be switched this way to a mode which should not be accessible and cannot be set with the CTC1 instruction. With hard float configurations any effect is transient anyway as read-only bits will retain their values at the time the FP context is restored.
Patchwork: https://patchwork.linux-mips.org/patch/13239/
--- arch/mips/kernel/ptrace.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-)
arch/mips/kernel/ptrace.c +19 -9
@@ -57,8 +57,7 @@ static void init_fp_ctx(struct task_stru/* Begin with data registers set to all 1s... */ memset (&target->thread.fpu.fpr, ~0 ,sizeof (target->thread.fpu.fpr)); -/* ...and FCSR zeroed */ - target->thread.fpu.fcr31 =0 ; +/* FCSR has been preset by `mips_set_personality_nan'. */ /* * Record that the target has "used" math, such that the context
@@ -80,6 +79,22 @@ void ptrace_disable(struct task_struct * }/* +* Poke at FCSR according to its mask. Don't set the cause bits as +* this is currently not handled correctly in FP context restoration +* and will cause an oops if a corresponding enable bit is set. +*/ +static void ptrace_setfcr31 (struct task_struct *child,u32 value) +{ +u32 fcr31; +u32 mask; + + value &= ~FPU_CSR_ALL_X ; + fcr31 = child->thread.fpu.fcr31; + mask = boot_cpu_data.fpu_msk31; + child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask); +} + +/* * Read a general register set. We always use the 64-bit format, even * for 32-bit kernels and for 32-bit processes on a 64-bit kernel. * Registers are sign extended to fill the available space.
@@ -159,9 +174,7 @@ int ptrace_setfpregs(struct task_struct {union fpureg *fregs;u64 fpr_val; -u32 fcr31;u32 value; -u32 mask;int i;if (!access_ok (VERIFY_READ , data,33 *8 ))
@@ -176,10 +189,7 @@ int ptrace_setfpregs(struct task_struct }__get_user (value, data +64 ); - value &= ~FPU_CSR_ALL_X ; - fcr31 = child->thread.fpu.fcr31; - mask = boot_cpu_data.fpu_msk31; - child->thread.fpu.fcr31 = (value & ~mask) | (fcr31 & mask); +ptrace_setfcr31 (child, value);/* FIR may not be written. */
@@ -806,7 +816,7 @@ long arch_ptrace(struct task_struct *chibreak ;#endif case FPC_CSR : - child->thread.fpu.fcr31 = data & ~FPU_CSR_ALL_X ; +ptrace_setfcr31 (child, data);break ; case DSP_BASE ... DSP_BASE + 5: {dspreg_t *dregs;
Greg Kroah-Hartman
maintainerPATCH 23/121 MIPS: Fix sigreturn via VDSO on microMIPS kernel
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 13eb192d10bcc9ac518d57356179071d603bcb4e upstream.
In microMIPS kernels, handle_signal() sets the isa16 mode bit in the vdso address so that the sigreturn trampolines (which are offset from the VDSO) get executed as microMIPS.
However commit ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") changed the offsets to come from the VDSO image, which already have the isa16 mode bit set correctly since they're extracted from the VDSO shared library symbol table.
Drop the isa16 mode bit handling from handle_signal() to fix sigreturn for cores which support both microMIPS and normal MIPS. This doesn't fix microMIPS only cores, since the VDSO is still built for normal MIPS, but thats a separate problem.
Patchwork: https://patchwork.linux-mips.org/patch/13348/
--- arch/mips/kernel/signal.c | 8 -------- 1 file changed, 8 deletions(-)
arch/mips/kernel/signal.c +0 -8
@@ -770,15 +770,7 @@ static void handle_signal(struct ksignalsigset_t *oldset =sigmask_to_save ();int ret;struct mips_abi *abi = current->thread.abi; -#ifdef CONFIG_CPU_MICROMIPS -void *vdso; -unsigned long tmp = (unsigned long )current->mm->context.vdso; - -set_isa16_mode (tmp); - vdso = (void *)tmp; -#else void *vdso = current->mm->context.vdso; -#endif if (regs->regs[0 ]) {switch (regs->regs[2 ]) {
Greg Kroah-Hartman
maintainerPATCH 24/121 MIPS: Build microMIPS VDSO for microMIPS kernels
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit bb93078e655be1e24d68f28f2756676e62c037ce upstream.
MicroMIPS kernels may be expected to run on microMIPS only cores which don't support the normal MIPS instruction set, so be sure to pass the -mmicromips flag through to the VDSO cflags.
Patchwork: https://patchwork.linux-mips.org/patch/13349/
--- arch/mips/vdso/Makefile | 1 + 1 file changed, 1 insertion(+)
arch/mips/vdso/Makefile +1 -0
@@ -5,6 +5,7 @@ obj-vdso-y := elf.o gettimeofday.o sigre ccflags-vdso := \ $(filter -I%,$(KBUILD_CFLAGS)) \ $(filter -E%,$(KBUILD_CFLAGS)) \ + $(filter -mmicromips,$(KBUILD_CFLAGS)) \ $(filter -march=%,$(KBUILD_CFLAGS)) cflags-vdso := $(ccflags-vdso) \ $(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \
Greg Kroah-Hartman
maintainerPATCH 25/121 MIPS: lib: Mark intrinsics notrace
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harvey Hunt <[email protected]>
commit aedcfbe06558a9f53002e82d5be64c6c94687726 upstream.
On certain MIPS32 devices, the ftrace tracer "function_graph" uses __lshrdi3() during the capturing of trace data. ftrace then attempts to trace __lshrdi3() which leads to infinite recursion and a stack overflow. Fix this by marking __lshrdi3() as notrace. Mark the other compiler intrinsics as notrace in case the compiler decides to use them in the ftrace path.
Patchwork: https://patchwork.linux-mips.org/patch/13354/
--- arch/mips/lib/ashldi3.c | 2 +- arch/mips/lib/ashrdi3.c | 2 +- arch/mips/lib/bswapdi.c | 2 +- arch/mips/lib/bswapsi.c | 2 +- arch/mips/lib/cmpdi2.c | 2 +- arch/mips/lib/lshrdi3.c | 2 +- arch/mips/lib/ucmpdi2.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-)
arch/mips/lib/ashldi3.c +1 -1
@@ -2,7 +2,7 @@#include "libgcc.h" -long long __ashldi3 (long long u,word_type b) +long long notrace __ashldi3 (long long u,word_type b) {DWunion uu, w;word_type bm;
arch/mips/lib/ashrdi3.c +1 -1
@@ -2,7 +2,7 @@#include "libgcc.h" -long long __ashrdi3 (long long u,word_type b) +long long notrace __ashrdi3 (long long u,word_type b) {DWunion uu, w;word_type bm;
arch/mips/lib/bswapdi.c +1 -1
@@ -1,6 +1,6 @@#include <linux/module.h> -unsigned long long __bswapdi2 (unsigned long long u) +unsigned long long notrace __bswapdi2 (unsigned long long u) {return (((u) &0xff00000000000000ull ) >>56 ) | (((u) & 0x00ff000000000000ull) >> 40) |
arch/mips/lib/bswapsi.c +1 -1
@@ -1,6 +1,6 @@#include <linux/module.h> -unsigned int __bswapsi2 (unsigned int u) +unsigned int notrace __bswapsi2(unsigned int u) {return (((u) &0xff000000 ) >>24 ) | (((u) & 0x00ff0000) >> 8) |
arch/mips/lib/cmpdi2.c +1 -1
@@ -2,7 +2,7 @@#include "libgcc.h" -word_type __cmpdi2 (long long a,long long b) +word_type notrace __cmpdi2(long long a, long long b) {const DWunion au = { .ll = a
arch/mips/lib/lshrdi3.c +1 -1
@@ -2,7 +2,7 @@#include "libgcc.h" -long long __lshrdi3 (long long u,word_type b) +long long notrace __lshrdi3 (long long u,word_type b) {DWunion uu, w;word_type bm;
arch/mips/lib/ucmpdi2.c +1 -1
@@ -2,7 +2,7 @@#include "libgcc.h" -word_type __ucmpdi2 (unsigned long long a,unsigned long long b) +word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b) {const DWunion au = {.ll = a};const DWunion bu = {.ll = b};
Greg Kroah-Hartman
maintainerPATCH 26/121 MIPS: VDSO: Build with `-fno-strict-aliasing
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit 94cc36b84acc29f543b48bc5ed786011b112a666 upstream.
Avoid an aliasing issue causing a build error in VDSO:
In file included from include/linux/srcu.h:34:0,
from include/linux/notifier.h:15,
from ./arch/mips/include/asm/uprobes.h:9,
from include/linux/uprobes.h:61,
from include/linux/mm_types.h:13,
from ./arch/mips/include/asm/vdso.h:14,
from arch/mips/vdso/vdso.h:27,
from arch/mips/vdso/gettimeofday.c:11:include/linux/workqueue.h: In function 'work_static':include/linux/workqueue.h:186:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
return *work_data_bits(work) & WORK_STRUCT_STATIC;
^
cc1: all warnings being treated as errors
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
with a CONFIG_DEBUG_OBJECTS_WORK configuration and GCC 5.2.0. Include `-fno-strict-aliasing' along with compiler options used, as required for kernel code, fixing a problem present since the introduction of VDSO with commit ebb5e78cc634 ("MIPS: Initial implementation of a VDSO").
Thanks to Tejun for diagnosing this properly!
Patchwork: https://patchwork.linux-mips.org/patch/13357/
--- arch/mips/vdso/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/mips/vdso/Makefile +2 -1
@@ -9,7 +9,8 @@ ccflags-vdso := \ $(filter -march=%,$(KBUILD_CFLAGS)) cflags-vdso := $(ccflags-vdso) \ $(filter -W%,$(filter-out -Wa$(comma)%,$(KBUILD_CFLAGS))) \ - -O2 -g -fPIC -fno-common -fno-builtin -G 0 -DDISABLE_BRANCH_PROFILING \ + -O2 -g -fPIC -fno-strict-aliasing -fno-common -fno-builtin -G 0 \ + -DDISABLE_BRANCH_PROFILING \ $(call cc-option, -fno-stack-protector) aflags-vdso := $(ccflags-vdso) \ $(filter -I%,$(KBUILD_CFLAGS)) \
Greg Kroah-Hartman
maintainerPATCH 27/121 affs: fix remount failure when there are no options changed
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit 01d6e08711bf90bc4d7ead14a93a0cbd73b1896a upstream.
Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition.
However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM.
This patch fixes the bug. We fail with ENOMEM only if data is non-NULL.
The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options).
--- fs/affs/super.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/affs/super.c +3 -2
@@ -528,7 +528,7 @@ affs_remount(struct super_block *sb, intchar *prefix =NULL ; new_opts =kstrdup (data,GFP_KERNEL ); -if (!new_opts) +if (data && !new_opts)return -ENOMEM ;pr_debug ("%s(flags=0x%x,opts=\"%s\")\n" , __func__, *flags, data);
@@ -546,7 +546,8 @@ affs_remount(struct super_block *sb, int }flush_delayed_work (&sbi->sb_work); -replace_mount_options (sb, new_opts); +if (new_opts) +replace_mount_options (sb, new_opts); sbi->s_flags = mount_flags; sbi->s_mode = mode;
Greg Kroah-Hartman
maintainerPATCH 28/121 ASoC: ak4642: Enable cache usage to fix crashes on resume
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit d3030d11961a8c103cf07aed59905276ddfc06c2 upstream.
The ak4642 driver is using a regmap cache sync to restore the configuration of the chip on resume but (as Peter observed) does not actually define a register cache which means that the resume is never going to work and we trigger asserts in regmap. Fix this by enabling caching.
--- sound/soc/codecs/ak4642.c | 3 +++ 1 file changed, 3 insertions(+)
sound/soc/codecs/ak4642.c +3 -0
@@ -560,6 +560,7 @@ static const struct regmap_config ak4642 .max_register = FIL1_3, .reg_defaults = ak4642_reg, .num_reg_defaults = NUM_AK4642_REG_DEFAULTS, + .cache_type = REGCACHE_RBTREE, };static const struct regmap_config ak4643_regmap = {
@@ -568,6 +569,7 @@ static const struct regmap_config ak4643 .max_register = SPK_MS, .reg_defaults = ak4643_reg, .num_reg_defaults = ARRAY_SIZE(ak4643_reg), + .cache_type = REGCACHE_RBTREE, };static const struct regmap_config ak4648_regmap = {
@@ -576,6 +578,7 @@ static const struct regmap_config ak4648 .max_register = EQ_FBEQE, .reg_defaults = ak4648_reg, .num_reg_defaults = ARRAY_SIZE(ak4648_reg), + .cache_type = REGCACHE_RBTREE, };static const struct ak4642_drvdata ak4642_drvdata = {
Greg Kroah-Hartman
maintainerPATCH 29/121 Input: uinput - handle compat ioctl for UI_SET_PHYS
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricky Liang <[email protected]>
commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.
When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS ioctl needs to be treated with special care, as it has the pointer size encoded in the command.
--- drivers/input/misc/uinput.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/input/misc/uinput.c +6 -0
@@ -981,9 +981,15 @@ static long uinput_ioctl(struct file *fi }#ifdef CONFIG_COMPAT + +#define UI_SET_PHYS_COMPAT _IOW(UINPUT_IOCTL_BASE, 108, compat_uptr_t) +static long uinput_compat_ioctl (struct file *file,unsigned int cmd,unsigned long arg) { +if (cmd ==UI_SET_PHYS_COMPAT ) + cmd =UI_SET_PHYS ; +return uinput_ioctl_handler (file, cmd, arg,compat_ptr (arg)); }#endif
Greg Kroah-Hartman
maintainerPATCH 30/121 Input: xpad - move pending clear to the correct location
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Rojtberg <[email protected]>
commit 4efc6939a83c54fb3417541be48991afd0290ba3 upstream.
otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27
--- drivers/input/joystick/xpad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/joystick/xpad.c +1 -1
@@ -756,6 +756,7 @@ static bool xpad_prepare_next_out_packetif (packet) {memcpy (xpad->odata, packet->data, packet->len); xpad->irq_out->transfer_buffer_length = packet->len; + packet->pending = false;return true; }
@@ -797,7 +798,6 @@ static void xpad_irq_out(struct urb *urbswitch (status) {case 0 :/* success */ - xpad->out_packets[xpad->last_out_packet].pending = false; xpad->irq_out_active =xpad_prepare_next_out_packet (xpad);break ;
Greg Kroah-Hartman
maintainerPATCH 31/121 Input: xpad - prevent spurious input from wired Xbox 360 controllers
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cameron Gutman <[email protected]>
commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 upstream.
After initially connecting a wired Xbox 360 controller or sending it a command to change LEDs, a status/response packet is interpreted as controller input. This causes the state of buttons represented in byte 2 of the controller data packet to be incorrect until the next valid input packet. Wireless Xbox 360 controllers are not affected.
Writing a new value to the LED device while holding the Start button and running jstest is sufficient to reproduce this bug. An event will come through with the Start button released.
Xboxdrv also won't attempt to read controller input from a packet where byte 0 is non-zero. It also checks that byte 1 is 0x14, but that value differs between wired and wireless controllers and this code is shared by both. I think just checking byte 0 is enough to eliminate unwanted packets.
The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00
--- drivers/input/joystick/xpad.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/input/joystick/xpad.c +4 -0
@@ -457,6 +457,10 @@ static void xpad_process_packet(struct ustatic void xpad360_process_packet (struct usb_xpad *xpad,struct input_dev *dev,u16 cmd,unsigned char *data) { +/* valid pad data */ +if (data[0 ] !=0x00 ) +return ; +/* digital pad */ if (xpad->mapping &MAP_DPAD_TO_BUTTONS ) {/* dpad as buttons (left, right, up, down) */
Greg Kroah-Hartman
maintainerPATCH 32/121 ARM: sun4i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Priit Laes <[email protected]>
commit bec38aaafd9ec1463dd3857f02bc029707e4213d upstream.
Seems like dram_gate 5 was forgotten when DRAM gate driver was added.
Enable it.
--- arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun4i-a10.dtsi +1 -1
@@ -96,7 +96,7 @@ allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0"; clocks = <&pll5 1>, <&ahb_gates 34>, <&ahb_gates 36>, <&ahb_gates 44>, <&ahb_gates 46>, - <&dram_gates 25>, <&dram_gates 26>; + <&dram_gates 5>, <&dram_gates 25>, <&dram_gates 26>; status = "disabled"; }; };
Greg Kroah-Hartman
maintainerPATCH 33/121 ARM: sun7i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Priit Laes <[email protected]>
commit 4b8ccef22fb547007ac38c4e5a28a773adee1e6e upstream.
Seems like dram_gate 5 was forgotten when DRAM gating driver was added.
Add it.
--- arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm/boot/dts/sun7i-a20.dtsi +3 -2
@@ -85,8 +85,9 @@ compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; allwinner,pipeline = "de_be0-lcd0-tve0"; - clocks = <&pll5 1>, <&ahb_gates 34>, <&ahb_gates 36>, - <&ahb_gates 44>, <&dram_gates 26>; + clocks = <&pll5 1>, + <&ahb_gates 34>, <&ahb_gates 36>, <&ahb_gates 44>, + <&dram_gates 5>, <&dram_gates 26>; status = "disabled"; }; };
Greg Kroah-Hartman
maintainerPATCH 34/121 ARM: mvebu: fix GPIO config on the Linksys boards
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Imre Kaloz <[email protected]>
commit 9800917cf92f5b5fe5cae706cb70db8d014f663c upstream.
Some of the GPIO configs were wrong in the submitted DTS files, this patch fixes all affected boards.
--- arch/arm/boot/dts/armada-385-linksys.dtsi | 6 +++--- arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/boot/dts/armada-385-linksys.dtsi +3 -3
@@ -245,7 +245,7 @@ button@2 { label = "Factory Reset Button"; linux,code = <KEY_RESTART>; - gpios = <&gpio1 15 GPIO_ACTIVE_LOW>; + gpios = <&gpio0 29 GPIO_ACTIVE_LOW>; }; };
@@ -260,7 +260,7 @@ }; sata { - gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>; + gpios = <&gpio1 22 GPIO_ACTIVE_LOW>; default-state = "off"; }; };
@@ -313,7 +313,7 @@ &pinctrl { keys_pin: keys-pin { - marvell,pins = "mpp24", "mpp47"; + marvell,pins = "mpp24", "mpp29"; marvell,function = "gpio"; };
arch/arm/boot/dts/armada-xp-linksys-mamba.dts +2 -2
@@ -304,13 +304,13 @@ button@1 { label = "WPS"; linux,code = <KEY_WPS_BUTTON>; - gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; + gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; }; button@2 { label = "Factory Reset Button"; linux,code = <KEY_RESTART>; - gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; + gpios = <&gpio1 1 GPIO_ACTIVE_LOW>; }; };
Greg Kroah-Hartman
maintainerPATCH 35/121 ARM: dts: at91: fix typo in sama5d2 PIN_PD24 description
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Vallee <[email protected]>
commit b1f3a3b03eb5f61b4051e2da9aa15653e705e111 upstream.
Fix a typo on PIN_PD24 for UTXD2 and FLEXCOM4_IO3 which were wrongly linked to PIN_PD23).
--- arch/arm/boot/dts/sama5d2-pinfunc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/sama5d2-pinfunc.h +2 -2
@@ -837,8 +837,8 @@#define PIN_PD23__ISC_FIELD PINMUX_PIN(PIN_PD23, 6, 4)#define PIN_PD24 120#define PIN_PD24__GPIO PINMUX_PIN(PIN_PD24, 0, 0) -#define PIN_PD24__UTXD2 PINMUX_PIN(PIN_PD23, 1, 2) -#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD23, 3, 3) +#define PIN_PD24__UTXD2 PINMUX_PIN(PIN_PD24, 1, 2) +#define PIN_PD24__FLEXCOM4_IO3 PINMUX_PIN(PIN_PD24, 3, 3)#define PIN_PD25 121#define PIN_PD25__GPIO PINMUX_PIN(PIN_PD25, 0, 0)#define PIN_PD25__SPI1_SPCK PINMUX_PIN(PIN_PD25, 1, 3)
Greg Kroah-Hartman
maintainerPATCH 36/121 ARM: dts: exynos: Add interrupt line to MAX8997 PMIC on exynos4210-trats
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit 330d12764e15f6e3e94ff34cda29db96d2589c24 upstream.
MAX8997 PMIC requires interrupt and fails probing without it.
--- arch/arm/boot/dts/exynos4210-trats.dts | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/boot/dts/exynos4210-trats.dts +2 -0
@@ -298,6 +298,8 @@ compatible = "maxim,max8997-pmic"; reg = <0x66>; + interrupt-parent = <&gpx0>; + interrupts = <7 0>; max8997,pmic-buck1-uses-gpio-dvs; max8997,pmic-buck2-uses-gpio-dvs;
Greg Kroah-Hartman
maintainerPATCH 37/121 ARM: dts: imx35: restore existing used clock enumeration
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Kurz <[email protected]>
commit 3397c2c45b1b6f54834dfeae30a73046f33ca943 upstream.
A new element got inserted into enum mx35_clks with commit 3713e3f5e927 ("clk: imx35: define two clocks for rtc"). This insertion shifted most nummerical clock assignments to a new nummerical value which in turn rendered most hardcoded nummeric values in imx35.dtsi incorrect.
Restore the existing order by moving the newly introduced clock to the end of the enum. Update the dts documentation accordingly.
--- Documentation/devicetree/bindings/clock/imx35-clock.txt | 1 + drivers/clk/imx/clk-imx35.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/clock/imx35-clock.txt +1 -0
@@ -94,6 +94,7 @@ clocks and IDs. csi_sel 79 iim_gate 80 gpu2d_gate 81 + ckli_gate 82 Examples:
drivers/clk/imx/clk-imx35.c +2 -2
@@ -66,7 +66,7 @@ static const char *std_sel[] = {"ppll",static const char *ipg_per_sel[] = {"ahb_per_div" ,"arm_per_div" };enum mx35_clks { - ckih, ckil, mpll, ppll, mpll_075, arm, hsp, hsp_div, hsp_sel, ahb, ipg, + ckih, mpll, ppll, mpll_075, arm, hsp, hsp_div, hsp_sel, ahb, ipg, arm_per_div, ahb_per_div, ipg_per, uart_sel, uart_div, esdhc_sel, esdhc1_div, esdhc2_div, esdhc3_div, spdif_sel, spdif_div_pre, spdif_div_post, ssi_sel, ssi1_div_pre, ssi1_div_post, ssi2_div_pre,
@@ -79,7 +79,7 @@ enum mx35_clks { rtc_gate, rtic_gate, scc_gate, sdma_gate, spba_gate, spdif_gate, ssi1_gate, ssi2_gate, uart1_gate, uart2_gate, uart3_gate, usbotg_gate, wdog_gate, max_gate, admux_gate, csi_gate, csi_div, csi_sel, iim_gate, - gpu2d_gate, clk_max + gpu2d_gate, ckil, clk_max };static struct clk *clk[clk_max];
Greg Kroah-Hartman
maintainerPATCH 38/121 ath9k: Add a module parameter to invert LED polarity.
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vittorio Gambaletta (VittGam) <[email protected]>
commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.
The LED can be active high instead of active low on some hardware.
Add the led_active_high module parameter. It defaults to -1 to obey platform data as before.
Setting the parameter to 1 or 0 will force the LED respectively active high or active low.
--- drivers/net/wireless/ath/ath9k/init.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/wireless/ath/ath9k/init.c +7 -0
@@ -49,6 +49,10 @@ int ath9k_led_blink;module_param_named (blink, ath9k_led_blink, int,0444 );MODULE_PARM_DESC (blink,"Enable LED blink on activity" ); +static int ath9k_led_active_high =-1 ; +module_param_named (led_active_high, ath9k_led_active_high, int,0444 ); +MODULE_PARM_DESC (led_active_high,"Invert LED polarity" ); +static int ath9k_btcoex_enable;module_param_named (btcoex_enable, ath9k_btcoex_enable, int,0444 );MODULE_PARM_DESC (btcoex_enable,"Enable wifi-BT coexistence" );
@@ -600,6 +604,9 @@ static int ath9k_init_softc(u16 devid, sif (ret)return ret; +if (ath9k_led_active_high !=-1 ) + ah->config.led_active_high = ath9k_led_active_high ==1 ; +/* * Enable WLAN/BT RX Antenna diversity only when: *
Greg Kroah-Hartman
maintainerPATCH 39/121 ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vittorio Gambaletta (VittGam) <[email protected]>
commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.
The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity (active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on the same Atheros MB92 design.
--- drivers/net/wireless/ath/ath9k/pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/wireless/ath/ath9k/pci.c +10 -0
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pc { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */ { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ + +#ifdef CONFIG_ATH9K_PCOEM + /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */ + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS, +0x0029 , +PCI_VENDOR_ID_ATHEROS , +0x2096 ), + .driver_data = ATH9K_PCI_LED_ACT_HI }, +#endif + { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ #ifdef CONFIG_ATH9K_PCOEM
Greg Kroah-Hartman
maintainerPATCH 40/121 ath10k: fix debugfs pktlog_filter write
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anilkumar Kolli <[email protected]>
commit 9ddc486aa09a3413a6c492fcf160ce61bfccb7b1 upstream.
It is observed that, we are disabling the packet log if we write same value to the pktlog_filter for the second time. Always enable pktlogs on non zero filter.
--- drivers/net/wireless/ath/ath10k/debug.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/debug.c +6 -1
@@ -2019,7 +2019,12 @@ static ssize_t ath10k_write_pktlog_filte goto out; } -if (filter && (filter != ar->debug.pktlog_filter)) { +if (filter == ar->debug.pktlog_filter) { + ret = count; + goto out; + } + +if (filter) { ret =ath10k_wmi_pdev_pktlog_enable (ar, filter);if (ret) { ath10k_warn(ar, "failed to enable pktlog filter %x: %d\n",
Greg Kroah-Hartman
maintainerPATCH 41/121 ath10k: fix firmware assert in monitor mode
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
commit 8a75fc54745fd3ce9062ab1cc6429a9da9ac2a68 upstream.
commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed an issue on monitor mode. Configuring NSS upon monitor interface creation is causing target assert in all qca9888x and qca6174 firmware. Firmware assert issue can be reproduced by below sequence even after reverting commit 166de3f1895d ("ath10k: remove supported chain mask").
ip link set wlan0 down
iw wlan0 set type monitor
iw phy0 set antenna 7
ip link set wlan0 up
This issue is originally reported on qca9888 with 10.1 firmware.
--- drivers/net/wireless/ath/ath10k/mac.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/mac.c +4 -1
@@ -4489,7 +4489,10 @@ static int ath10k_add_interface(struct i goto err_vdev_delete; } -if (ar->cfg_tx_chainmask) { +/* Configuring number of spatial stream for monitor interface is causing +* target assert in qca9888 and qca6174. +*/ +if (ar->cfg_tx_chainmask && (vif->type !=NL80211_IFTYPE_MONITOR )) {u16 nss =get_nss_from_chainmask (ar->cfg_tx_chainmask); vdev_param = ar->wmi.vdev_param->nss;
Greg Kroah-Hartman
maintainerPATCH 42/121 ath10k: fix rx_channel during hw reconfigure
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
commit 1ce8c1484e80010a6e4b9611c65668ff77556f45 upstream.
Upon firmware assert, restart work will be triggered so that mac80211 will reconfigure the driver. An issue is reported that after restart work, survey dump data do not contain in-use (SURVEY_INFO_IN_USE) info for operating channel. During reconfigure, since mac80211 already has valid channel context for given radio, channel context iteration return num_chanctx > 0. Hence rx_channel is always NULL. Fix this by assigning channel context to rx_channel when driver restart is in progress.
--- drivers/net/wireless/ath/ath10k/mac.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/mac.c +7 -1
@@ -6453,7 +6453,13 @@ ath10k_mac_update_rx_channel(struct ath1 def = &vifs[0 ].new_ctx->def; ar->rx_channel = def->chan; - }else if (ctx &&ath10k_mac_num_chanctxs (ar) ==0 ) { + }else if ((ctx &&ath10k_mac_num_chanctxs (ar) ==0 ) || + (ctx && (ar->state ==ATH10K_STATE_RESTARTED ))) { +/* During driver restart due to firmware assert, since mac80211 +* already has valid channel context for given radio, channel +* context iteration return num_chanctx > 0. So fix rx_channel +* when restart is in progress. +*/ ar->rx_channel = ctx->def.chan; }else { ar->rx_channel =NULL ;
Greg Kroah-Hartman
maintainerPATCH 43/121 ath10k: fix kernel panic, move arvifs list head init before htt init
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anilkumar Kolli <[email protected]>
commit 4ad24a9d83bd4bf0a85e95bf144e18d3fda4fbf1 upstream.
It is observed that while loading and unloading ath10k modules in an infinite loop, before ath10k_core_start() completion HTT rx frames are received, while processing these frames, dereferencing the arvifs list code is getting hit before initilizing the arvifs list, causing a kernel panic.
This patch initilizes the arvifs list before initilizing htt.
Fixes the below issue:
[<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 [ath10k_core]) [<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core]) [<bf88c0dc>] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core]) [<bf88c0dc>] (ath10k_htt_txrx_compl_task [ath10k_core]) [<c0234100>] (tasklet_action+0x8c/0xec)
[<c0234100>] (tasklet_action)
[<c02337c0>] (__do_softirq+0xf8/0x228)
[<c02337c0>] (__do_softirq) [<c0233920>] (run_ksoftirqd+0x30/0x90)
Code: e5954ad8 e2899008 e1540009 0a00000d (e5943008) ---[ end trace 71de5c2e011dbf56 ]--- Kernel panic - not syncing: Fatal exception in interrupt
--- drivers/net/wireless/ath/ath10k/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/net/wireless/ath/ath10k/core.c +4 -4
@@ -1723,6 +1723,10 @@ int ath10k_core_start(struct ath10k *ar, goto err_hif_stop; } + ar->free_vdev_map = (1LL << ar->max_num_vdevs) -1 ; + +INIT_LIST_HEAD (&ar->arvifs); +/* we don't care about HTT in UTF mode */ if (mode ==ATH10K_FIRMWARE_MODE_NORMAL ) { status =ath10k_htt_setup (&ar->htt);
@@ -1736,10 +1740,6 @@ int ath10k_core_start(struct ath10k *ar,if (status) goto err_hif_stop; - ar->free_vdev_map = (1LL << ar->max_num_vdevs) -1 ; - -INIT_LIST_HEAD (&ar->arvifs); -return 0 ; err_hif_stop:
Greg Kroah-Hartman
maintainerPATCH 44/121 ath5k: Change led pin configuration for compaq c700 laptop
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Salisbury <[email protected]>
commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.
Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop") added a pin configuration for the Compaq c700 laptop. However, the polarity of the led pin is reversed. It should be red for wifi off and blue for wifi on, but it is the opposite. This bug was reported in the following bug report:
http://pad.lv/972604
--- drivers/net/wireless/ath/ath5k/led.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath5k/led.c +1 -1
@@ -77,7 +77,7 @@ static const struct pci_device_id ath5k_/* HP Compaq CQ60-206US ([email protected]) */ { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137a), ATH_LED(3, 1) },/* HP Compaq C700 ([email protected]) */ - { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 1) }, + { ATH_SDEVICE(PCI_VENDOR_ID_HP, 0x0137b), ATH_LED(3, 0) },/* LiteOn AR5BXB63 ([email protected]) */ { ATH_SDEVICE(PCI_VENDOR_ID_ATHEROS, 0x3067), ATH_LED(3, 0) },/* IBM-specific AR5212 (all others) */
Greg Kroah-Hartman
maintainerPATCH 45/121 hwrng: exynos - Fix unbalanced PM runtime put on timeout error path
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit f1925d78d7b710a1179828d53e918295f5f5d222 upstream.
In case of timeout during read operation, the exit path lacked PM runtime put. This could lead to unbalanced runtime PM usage counter thus leaving the device in an active state.
--- drivers/char/hw_random/exynos-rng.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/char/hw_random/exynos-rng.c +7 -3
@@ -89,6 +89,7 @@ static int exynos_read(struct hwrng *rng struct exynos_rng, rng);u32 *data = buf;int retry =100 ; +int ret =4 ;pm_runtime_get_sync (exynos_rng->dev);
@@ -97,17 +98,20 @@ static int exynos_read(struct hwrng *rngwhile (!(exynos_rng_readl (exynos_rng,EXYNOS_PRNG_STATUS_OFFSET ) &PRNG_DONE ) && --retry)cpu_relax (); -if (!retry) -return -ETIMEDOUT ; +if (!retry) { + ret = -ETIMEDOUT ; + goto out; + }exynos_rng_writel (exynos_rng,PRNG_DONE ,EXYNOS_PRNG_STATUS_OFFSET ); *data =exynos_rng_readl (exynos_rng,EXYNOS_PRNG_OUT1_OFFSET ); +out:pm_runtime_mark_last_busy (exynos_rng->dev);pm_runtime_put_sync_autosuspend (exynos_rng->dev); -return 4 ; +return ret; }static int exynos_rng_probe (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 46/121 rtlwifi: rtl8723be: Add antenna select module parameter
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit c18d8f5095715c56bb3cd9cba64242542632054b upstream.
A number of new laptops have been delivered with only a single antenna. In principle, this is OK; however, a problem arises when the on-board EEPROM is programmed to use the other antenna connection. The option of opening the computer and moving the connector is not always possible as it will void the warranty in some cases. In addition, this solution breaks the Windows driver when the box dual boots Linux and Windows.
A fix involving a new module parameter has been developed. This commit adds the new parameter and implements the changes needed for the driver.
--- drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 5 +++++ drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 3 +++ drivers/net/wireless/realtek/rtlwifi/wifi.h | 3 +++ 3 files changed, 11 insertions(+)
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c +5 -0
@@ -2684,6 +2684,7 @@ void rtl8723be_read_bt_coexist_info_from bool auto_load_fail, u8 *hwinfo) { struct rtl_priv *rtlpriv = rtl_priv(hw); +struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;u8 value;u32 tmpu_32;
@@ -2702,6 +2703,10 @@ void rtl8723be_read_bt_coexist_info_from rtlpriv->btcoexist.btc_info.ant_num =ANT_X2 ; } +/* override ant_num / ant_path */ +if (mod_params->ant_sel) + rtlpriv->btcoexist.btc_info.ant_num = + (mod_params->ant_sel ==1 ?ANT_X2 :ANT_X1 ); }void rtl8723be_bt_reg_init (struct ieee80211_hw *hw)
drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c +3 -0
@@ -273,6 +273,7 @@ static struct rtl_mod_params rtl8723be_m .msi_support = false, .disable_watchdog = false, .debug = DBG_EMERG, + .ant_sel = 0, };static struct rtl_hal_cfg rtl8723be_hal_cfg = {
@@ -394,6 +395,7 @@ module_param_named(fwlps, rtl8723be_mod_module_param_named (msi, rtl8723be_mod_params.msi_support, bool,0444 );module_param_named (disable_watchdog, rtl8723be_mod_params.disable_watchdog, bool,0444 ); +module_param_named (ant_sel, rtl8723be_mod_params.ant_sel, int,0444 );MODULE_PARM_DESC (swenc,"Set to 1 for software crypto (default 0)\n" );MODULE_PARM_DESC (ips,"Set to 0 to not use link power save (default 1)\n" );MODULE_PARM_DESC (swlps,"Set to 1 to use SW control power save (default 0)\n" );
@@ -402,6 +404,7 @@ MODULE_PARM_DESC(msi, "Set to 1 to use MMODULE_PARM_DESC (debug,"Set debug level (0-5) (default 0)" );MODULE_PARM_DESC (disable_watchdog,"Set to 1 to disable the watchdog (default 0)\n" ); +MODULE_PARM_DESC (ant_sel,"Set to 1 or 2 to force antenna number (default 0)\n" ); static SIMPLE_DEV_PM_OPS(rtlwifi_pm_ops, rtl_pci_suspend, rtl_pci_resume);
drivers/net/wireless/realtek/rtlwifi/wifi.h +3 -0
@@ -2246,6 +2246,9 @@ struct rtl_mod_params {/* default 0: 1 means do not disable interrupts */ bool int_clear; + +/* select antenna */ +int ant_sel; };struct rtl_hal_usbint_cfg {
Greg Kroah-Hartman
maintainerPATCH 47/121 rtlwifi: btcoexist: Implement antenna selection
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit baa1702290953295e421f0f433e2b1ff4815827c upstream.
The previous patch added an option to rtl8723be to manually select the antenna for those cases when only a single antenna is present, and the on-board EEPROM is incorrectly programmed. This patch implements the necessary changes in the Bluetooth coexistence driver.
--- drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 9 ++- drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 27 +++++++++- drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 2 drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 5 + 4 files changed, 38 insertions(+), 5 deletions(-)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c +7 -2
@@ -1203,7 +1203,6 @@ static void btc8723b2ant_set_ant_path(st/* Force GNT_BT to low */ btcoexist->btc_write_1byte_bitmask (btcoexist,0x765 ,0x18 ,0x0 ); - btcoexist->btc_write_2byte (btcoexist,0x948 ,0x0 );if (board_info->btdm_ant_pos ==BTC_ANTENNA_AT_MAIN_PORT ) {/* tell firmware "no antenna inverse" */
@@ -1211,19 +1210,25 @@ static void btc8723b2ant_set_ant_path(st h2c_parameter[1 ] =1 ;/* ext switch type */ btcoexist->btc_fill_h2c (btcoexist,0x65 ,2 , h2c_parameter); + btcoexist->btc_write_2byte (btcoexist,0x948 ,0x0 ); }else {/* tell firmware "antenna inverse" */ h2c_parameter[0 ] =1 ; h2c_parameter[1 ] =1 ;/* ext switch type */ btcoexist->btc_fill_h2c (btcoexist,0x65 ,2 , h2c_parameter); + btcoexist->btc_write_2byte (btcoexist,0x948 ,0x280 ); } }/* ext switch setting */ if (use_ext_switch) {/* fixed internal switch S1->WiFi, S0->BT */ - btcoexist->btc_write_2byte (btcoexist,0x948 ,0x0 ); +if (board_info->btdm_ant_pos ==BTC_ANTENNA_AT_MAIN_PORT ) + btcoexist->btc_write_2byte (btcoexist,0x948 ,0x0 ); +else + btcoexist->btc_write_2byte (btcoexist,0x948 ,0x280 ); +switch (antpos_type) {case BTC_ANT_WIFI_AT_MAIN :/* ext switch main at wifi */
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c +26 -1
@@ -965,13 +965,38 @@ void exhalbtc_set_chip_type(u8 chip_type } } -void exhalbtc_set_ant_num (u8 type,u8 ant_num) +void exhalbtc_set_ant_num (struct rtl_priv *rtlpriv,u8 type,u8 ant_num) {if (BT_COEX_ANT_TYPE_PG == type) { gl_bt_coexist.board_info.pg_ant_num = ant_num; gl_bt_coexist.board_info.btdm_ant_num = ant_num; +/* The antenna position: +* Main (default) or Aux for pgAntNum=2 && btdmAntNum =1. +* The antenna position should be determined by +* auto-detect mechanism. +* The following is assumed to main, +* and those must be modified +* if y auto-detect mechanism is ready +*/ +if ((gl_bt_coexist.board_info.pg_ant_num ==2 ) && + (gl_bt_coexist.board_info.btdm_ant_num ==1 )) + gl_bt_coexist.board_info.btdm_ant_pos = +BTC_ANTENNA_AT_MAIN_PORT ; +else + gl_bt_coexist.board_info.btdm_ant_pos = +BTC_ANTENNA_AT_MAIN_PORT ; }else if (BT_COEX_ANT_TYPE_ANTDIV == type) { gl_bt_coexist.board_info.btdm_ant_num = ant_num; + gl_bt_coexist.board_info.btdm_ant_pos = +BTC_ANTENNA_AT_MAIN_PORT ; + }else if (type ==BT_COEX_ANT_TYPE_DETECTED ) { + gl_bt_coexist.board_info.btdm_ant_num = ant_num; +if (rtlpriv->cfg->mod_params->ant_sel ==1 ) + gl_bt_coexist.board_info.btdm_ant_pos = +BTC_ANTENNA_AT_AUX_PORT ; +else + gl_bt_coexist.board_info.btdm_ant_pos = +BTC_ANTENNA_AT_MAIN_PORT ; } }
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h +1 -1
@@ -535,7 +535,7 @@ void exhalbtc_set_bt_patch_version(u16 bvoid exhalbtc_update_min_bt_rssi (char bt_rssi);void exhalbtc_set_bt_exist (bool bt_exist);void exhalbtc_set_chip_type (u8 chip_type); -void exhalbtc_set_ant_num (u8 type,u8 ant_num); +void exhalbtc_set_ant_num (struct rtl_priv *rtlpriv,u8 type,u8 ant_num);void exhalbtc_display_bt_coex_info (struct btc_coexist *btcoexist);void exhalbtc_signal_compensation (struct btc_coexist *btcoexist,u8 *rssi_wifi,u8 *rssi_bt);
drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c +4 -1
@@ -72,7 +72,10 @@ void rtl_btc_init_hal_vars(struct rtl_pr __func__, bt_type);exhalbtc_set_chip_type (bt_type); -exhalbtc_set_ant_num (BT_COEX_ANT_TYPE_PG , ant_num); +if (rtlpriv->cfg->mod_params->ant_sel ==1 ) +exhalbtc_set_ant_num (rtlpriv,BT_COEX_ANT_TYPE_DETECTED ,1 ); +else +exhalbtc_set_ant_num (rtlpriv,BT_COEX_ANT_TYPE_PG , ant_num); }void rtl_btc_init_hw_config (struct rtl_priv *rtlpriv)
Greg Kroah-Hartman
maintainerPATCH 48/121 rtlwifi: Fix logic error in enter/exit power-save mode
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: wang yanqing <[email protected]>
commit 873ffe154ae074c46ed2d72dbd9a2a99f06f55b4 upstream.
In commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue"), the tests for enter/exit power-save mode were inverted. With this change applied, the wifi connection becomes much more stable.
--- drivers/net/wireless/realtek/rtlwifi/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/realtek/rtlwifi/base.c +2 -2
@@ -1660,9 +1660,9 @@ void rtl_watchdog_wq_callback(void *dataif (((rtlpriv->link_info.num_rx_inperiod + rtlpriv->link_info.num_tx_inperiod) >8 ) || (rtlpriv->link_info.num_rx_inperiod >2 )) -rtl_lps_enter (hw); -else rtl_lps_leave (hw); +else +rtl_lps_enter (hw); } rtlpriv->link_info.num_rx_inperiod =0 ;
Greg Kroah-Hartman
maintainerPATCH 49/121 rtlwifi: pci: use dev_kfree_skb_irq instead of kfree_skb in rtl_pci_reset_trx_ring
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: wang yanqing <[email protected]>
commit cf968937d27751296920e6b82ffa89735e3a0023 upstream.
We can't use kfree_skb in irq disable context, because spin_lock_irqsave make sure we are always in irq disable context, use dev_kfree_skb_irq instead of kfree_skb is better than dev_kfree_skb_any.
This patch fix below kernel warning:
[ 7612.095528] ------------[ cut here ]------------ [ 7612.095546] WARNING: CPU: 3 PID: 4460 at kernel/softirq.c:150 __local_bh_enable_ip+0x58/0x80() [ 7612.095550] Modules linked in: rtl8723be x86_pkg_temp_thermal btcoexist rtl_pci rtlwifi rtl8723_common [ 7612.095567] CPU: 3 PID: 4460 Comm: ifconfig Tainted: G W 4.4.0+ #4 [ 7612.095570] Hardware name: LENOVO 20DFA04FCD/20DFA04FCD, BIOS J5ET48WW (1.19 ) 08/27/2015 [ 7612.095574] 00000000 00000000 da37fc70 c12ce7c5 00000000 da37fca0 c104cc59 c19d4454 [ 7612.095584] 00000003 0000116c c19d4784 00000096 c10508a8 c10508a8 00000200 c1b42400 [ 7612.095594] f29be780 da37fcb0 c104ccad 00000009 00000000 da37fcbc c10508a8 f21f08b8 [ 7612.095604] Call Trace: [ 7612.095614] [<c12ce7c5>] dump_stack+0x41/0x5c [ 7612.095620] [<c104cc59>] warn_slowpath_common+0x89/0xc0 [ 7612.095628] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095634] [<c10508a8>] ? __local_bh_enable_ip+0x58/0x80 [ 7612.095640] [<c104ccad>] warn_slowpath_null+0x1d/0x20 [ 7612.095646] [<c10508a8>] __local_bh_enable_ip+0x58/0x80 [ 7612.095653] [<c16b7d34>] destroy_conntrack+0x64/0xa0 [ 7612.095660] [<c16b300f>] nf_conntrack_destroy+0xf/0x20 [ 7612.095665] [<c1677565>] skb_release_head_state+0x55/0xa0 [ 7612.095670] [<c16775bb>] skb_release_all+0xb/0x20 [ 7612.095674] [<c167760b>] __kfree_skb+0xb/0x60 [ 7612.095679] [<c16776f0>] kfree_skb+0x30/0x70 [ 7612.095686] [<f81b869d>] ? rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095692] [<f81b869d>] rtl_pci_reset_trx_ring+0x22d/0x370 [rtl_pci] [ 7612.095698] [<f81b87f9>] rtl_pci_start+0x19/0x190 [rtl_pci] [ 7612.095705] [<f81970e6>] rtl_op_start+0x56/0x90 [rtlwifi] [ 7612.095712] [<c17e3f16>] drv_start+0x36/0xc0 [ 7612.095717] [<c17f5ab3>] ieee80211_do_open+0x2d3/0x890 [ 7612.095725] [<c16820fe>] ? call_netdevice_notifiers_info+0x2e/0x60 [ 7612.095730] [<c17f60bd>] ieee80211_open+0x4d/0x50 [ 7612.095736] [<c16891b3>] __dev_open+0xa3/0x130 [ 7612.095742] [<c183fa53>] ? _raw_spin_unlock_bh+0x13/0x20 [ 7612.095748] [<c1689499>] __dev_change_flags+0x89/0x140 [ 7612.095753] [<c127c70d>] ? selinux_capable+0xd/0x10 [ 7612.095759] [<c1689589>] dev_change_flags+0x29/0x60 [ 7612.095765] [<c1700b93>] devinet_ioctl+0x553/0x670 [ 7612.095772] [<c12db758>] ? _copy_to_user+0x28/0x40 [ 7612.095777] [<c17018b5>] inet_ioctl+0x85/0xb0 [ 7612.095783] [<c166e647>] sock_ioctl+0x67/0x260 [ 7612.095788] [<c166e5e0>] ? sock_fasync+0x80/0x80 [ 7612.095795] [<c115c99b>] do_vfs_ioctl+0x6b/0x550 [ 7612.095800] [<c127c812>] ? selinux_file_ioctl+0x102/0x1e0 [ 7612.095807] [<c10a8914>] ? timekeeping_suspend+0x294/0x320 [ 7612.095813] [<c10a256a>] ? __hrtimer_run_queues+0x14a/0x210 [ 7612.095820] [<c1276e24>] ? security_file_ioctl+0x34/0x50 [ 7612.095827] [<c115cef0>] SyS_ioctl+0x70/0x80 [ 7612.095832] [<c1001804>] do_fast_syscall_32+0x84/0x120 [ 7612.095839] [<c183ff91>] sysenter_past_esp+0x36/0x55 [ 7612.095844] ---[ end trace 97e9c637a20e8348 ]---
--- drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/realtek/rtlwifi/pci.c +1 -1
@@ -1573,7 +1573,7 @@ int rtl_pci_reset_trx_ring(struct ieee80 true, HW_DESC_TXBUFF_ADDR), skb->len, PCI_DMA_TODEVICE); -kfree_skb (skb); +dev_kfree_skb_irq (skb); ring->idx = (ring->idx +1 ) % ring->entries; } ring->idx =0 ;
Greg Kroah-Hartman
maintainerPATCH 50/121 Revert "lpfc: Delete unnecessary checks before the function call mempool_destroy"
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin K. Petersen <[email protected]>
commit d65c8fff867a6450c58ce31572e883148a445ddf upstream.
This reverts commit 9be321819c43417432a8376428b90fe3fe3a3510 which caused a regression on hardware using the SLI3 interface.
--- drivers/scsi/lpfc/lpfc_mem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/scsi/lpfc/lpfc_mem.c +4 -2
@@ -231,13 +231,15 @@ lpfc_mem_free(struct lpfc_hba *phba)if (phba->lpfc_hbq_pool)pci_pool_destroy (phba->lpfc_hbq_pool); phba->lpfc_hbq_pool =NULL ; -mempool_destroy (phba->rrq_pool); + +if (phba->rrq_pool) +mempool_destroy (phba->rrq_pool); phba->rrq_pool =NULL ;/* Free NLP memory pool */ mempool_destroy (phba->nlp_mem_pool); phba->nlp_mem_pool =NULL ; -if (phba->sli_rev ==LPFC_SLI_REV4 ) { +if (phba->sli_rev ==LPFC_SLI_REV4 && phba->active_rrq_pool) {mempool_destroy (phba->active_rrq_pool); phba->active_rrq_pool =NULL ; }
Greg Kroah-Hartman
maintainerPATCH 51/121 aacraid: Start adapter after updating number of MSIX vectors
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <[email protected]>
commit 116d77fea02e2a5aded7d29ba4c692774cb339f1 upstream.
The adapter has to be started after updating the number of MSIX Vectors
--- drivers/scsi/aacraid/linit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/aacraid/linit.c +1 -1
@@ -1431,8 +1431,8 @@ static int aac_acquire_resources(struct/* After EEH recovery or suspend resume, max_msix count * may change, therfore updating in init as well. */ -aac_adapter_start (dev); dev->init->Sa_MSIXVectors =cpu_to_le32 (dev->max_msix); +aac_adapter_start (dev); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 52/121 aacraid: Relinquish CPU during timeout wait
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <[email protected]>
commit 07beca2be24cc710461c0b131832524c9ee08910 upstream.
aac_fib_send has a special function case for initial commands during driver initialization using wait < 0(pseudo sync mode). In this case, the command does not sleep but rather spins checking for timeout.This loop is calls cpu_relax() in an attempt to allow other processes/threads to use the CPU, but this function does not relinquish the CPU and so the command will hog the processor. This was observed in a KDUMP "crashkernel" and that prevented the "command thread" (which is responsible for completing the command from being timed out) from starting because it could not get the CPU.
Fixed by replacing "cpu_relax()" call with "schedule()"
--- drivers/scsi/aacraid/commsup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/scsi/aacraid/commsup.c +4 -4
@@ -637,10 +637,10 @@ int aac_fib_send(u16 command, struct fib }return -EFAULT ; } -/* We used to udelay() here but that absorbed -* a CPU when a timeout occured. Not very -* useful. */ -cpu_relax (); +/* +* Allow other processes / CPUS to use core +*/ +schedule (); } }else if (down_interruptible (&fibptr->event_wait)) {/* Do nothing ... satisfy
Greg Kroah-Hartman
maintainerPATCH 53/121 aacraid: Fix for aac_command_thread hang
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <[email protected]>
commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 upstream.
Typically under error conditions, it is possible for aac_command_thread() to miss the wakeup from kthread_stop() and go back to sleep, causing it to hang aac_shutdown.
In the observed scenario, the adapter is not functioning correctly and so aac_fib_send() never completes (or time-outs depending on how it was called). Shortly after aac_command_thread() starts it performs aac_fib_send(SendHostTime) which hangs. When aac_probe_one /aac_get_adapter_info send time outs, kthread_stop is called which breaks the command thread out of it's hang.
The code will still go back to sleep in schedule_timeout() without checking kthread_should_stop() so it causes aac_probe_one to hang until the schedule_timeout() which is 30 minutes.
Fixed by: Adding another kthread_should_stop() before schedule_timeout()
--- drivers/scsi/aacraid/commsup.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/scsi/aacraid/commsup.c +4 -0
@@ -1996,6 +1996,10 @@ int aac_command_thread(void *data)if (difference <=0 ) difference =1 ;set_current_state (TASK_INTERRUPTIBLE ); + +if (kthread_should_stop ()) +break ; +schedule_timeout (difference);if (kthread_should_stop ())
Greg Kroah-Hartman
maintainerPATCH 54/121 aacraid: Fix for KDUMP driver hang
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <[email protected]>
commit 78cbccd3bd683c295a44af8050797dc4a41376ff upstream.
When KDUMP is triggered the driver first talks to the firmware in INTX mode, but the adapter firmware is still in MSIX mode. Therefore the first driver command hangs since the driver is waiting for an INTX response and firmware gives a MSIX response. If when the OS is installed on a RAID drive created by the adapter KDUMP will hang since the driver does not receive a response in sync mode.
Fixed by: Change the firmware to INTX mode if it is in MSIX mode before sending the first sync command.
--- drivers/scsi/aacraid/aacraid.h | 1 + drivers/scsi/aacraid/comminit.c | 24 ++++++++++++++++++++++++ 2 files changed, 25 insertions(+)
drivers/scsi/aacraid/aacraid.h +1 -0
@@ -29,6 +29,7 @@ enum {#define AAC_INT_MODE_MSI (1<<1)#define AAC_INT_MODE_AIF (1<<2)#define AAC_INT_MODE_SYNC (1<<3) +#define AAC_INT_MODE_MSIX (1<<16)#define AAC_INT_ENABLE_TYPE1_INTX 0xfffffffb#define AAC_INT_ENABLE_TYPE1_MSIX 0xfffffffa
drivers/scsi/aacraid/comminit.c +24 -0
@@ -37,6 +37,7 @@#include <linux/spinlock.h> #include <linux/slab.h> #include <linux/blkdev.h> +#include <linux/delay.h> #include <linux/completion.h> #include <linux/mm.h> #include <scsi/scsi_host.h>
@@ -47,6 +48,20 @@ struct aac_common aac_config = { .irq_mod = 1 }; +static inline int aac_is_msix_mode (struct aac_dev *dev) +{ +u32 status; + + status =src_readl (dev, MUnit.OMR); +return (status &AAC_INT_MODE_MSIX ); +} + +static inline void aac_change_to_intx (struct aac_dev *dev) +{ +aac_src_access_devreg (dev,AAC_DISABLE_MSIX ); +aac_src_access_devreg (dev,AAC_ENABLE_INTX ); +} +static int aac_alloc_comm (struct aac_dev *dev,void **commaddr,unsigned long commsize,unsigned long commalign) {unsigned char *base;
@@ -427,6 +442,15 @@ struct aac_dev *aac_init_adapter(struct dev->comm_interface =AAC_COMM_PRODUCER ; dev->raw_io_interface = dev->raw_io_64 =0 ; + +/* +* Enable INTX mode, if not done already Enabled +*/ +if (aac_is_msix_mode (dev)) { +aac_change_to_intx (dev); +dev_info (&dev->pdev->dev,"Changed firmware to INTX mode" ); + } + if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES, 0, 0, 0, 0, 0, 0, status+0, status+1, status+2, status+3, NULL)) &&
Greg Kroah-Hartman
maintainerPATCH 55/121 regulator: Try to resolve regulators supplies on registration
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Martinez Canillas <[email protected]>
commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85 upstream.
Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") moved the regulator supplies lookup logic from the regulators registration to the regulators get time.
Unfortunately, that changed the behavior of the regulator core since now a parent supply with a child regulator marked as always-on, won't be enabled unless a client driver attempts to get the child regulator during boot.
This patch tries to resolve the parent supply for the already registered regulators each time that a new regulator is registered. So the regulators that have child regulators marked as always on will be enabled regardless if a driver gets the child regulator or not.
That was the behavior before the mentioned commit, since parent supplies were looked up at regulator registration time instead of during child get.
Since regulator_resolve_supply() checks for rdev->supply, most of the times it will be a no-op. Errors aren't checked to keep the possible out of order dependencies which was the motivation for the mentioned commit.
Also, the supply being available will be enforced on regulator get anyways in case the resolve fails on regulators registration.
--- drivers/regulator/core.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/regulator/core.c +9 -0
@@ -3840,6 +3840,11 @@ static void rdev_init_debugfs(struct reg &rdev->bypass_count); } +static int regulator_register_resolve_supply (struct device *dev,void *data) +{ +return regulator_resolve_supply (dev_to_rdev (dev)); +} +/** * regulator_register - register regulator * @regulator_desc: regulator to register
@@ -3986,6 +3991,10 @@ regulator_register(const struct regulato }rdev_init_debugfs (rdev); + +/* try to resolve regulators supply since a new one was registered */ +class_for_each_device (®ulator_class,NULL ,NULL , + regulator_register_resolve_supply); out:mutex_unlock (®ulator_list_mutex);kfree (config);
Greg Kroah-Hartman
maintainerPATCH 56/121 hwmon: (ads7828) Enable internal reference
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akshay Bhat <[email protected]>
commit 7a18afe8097731b8ffb6cb5b2b3b418ded77c105 upstream.
On ads7828 the internal reference defaults to off upon power up. When using internal reference, it needs to be turned on and the voltage needs to settle before normal conversion cycle can be started. Hence perform a dummy read in the probe to enable the internal reference allowing the voltage to settle before performing a normal read.
Without this fix, the first read from the ADC when using internal reference always returns incorrect data.
--- drivers/hwmon/ads7828.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/hwmon/ads7828.c +10 -0
@@ -120,6 +120,7 @@ static int ads7828_probe(struct i2c_clieunsigned int vref_mv =ADS7828_INT_VREF_MV ;bool diff_input = false;bool ext_vref = false; +unsigned int regval; data =devm_kzalloc (dev,sizeof (struct ads7828_data ),GFP_KERNEL );if (!data)
@@ -154,6 +155,15 @@ static int ads7828_probe(struct i2c_clieif (!diff_input) data->cmd_byte |=ADS7828_CMD_SD_SE ; +/* +* Datasheet specifies internal reference voltage is disabled by +* default. The internal reference voltage needs to be enabled and +* voltage needs to settle before getting valid ADC data. So perform a +* dummy read to enable the internal reference voltage. +*/ +if (!ext_vref) +regmap_read (data->regmap, data->cmd_byte, ®val); + hwmon_dev =devm_hwmon_device_register_with_groups (dev, client->name, data, ads7828_groups);
Greg Kroah-Hartman
maintainerPATCH 57/121 mfd: intel_quark_i2c_gpio: Remove clock tree on error path
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit 7f0c5ae18d649ed2f4978cbf07c02a0ff732f23e upstream.
There is a potential resource leak in case when ->probe() fails. We have to unregister and remove clock tree which is done here.
This is a follow up to previously pushed commit c4726abce63b ("mfd:intel_quark_i2c_gpio: Use clkdev_create()") that prevents double free() when clkdev_drop() followed by kfree() in devm_kcalloc() release stage.
I leave Fixes tag here, but the backporting will require to backport the commit c4726abce63b ("mfd: intel_quark_i2c_gpio: Use clkdev_create()") first.
--- drivers/mfd/intel_quark_i2c_gpio.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)
drivers/mfd/intel_quark_i2c_gpio.c +17 -8
@@ -139,6 +139,7 @@ static int intel_quark_register_i2c_clk( INTEL_QUARK_I2C_CONTROLLER_CLK);if (!quark_mfd->i2c_clk_lookup) { +clk_unregister (quark_mfd->i2c_clk);dev_err (&pdev->dev,"Fixed clk register failed\n" );return -ENOMEM ; }
@@ -150,7 +151,7 @@ static void intel_quark_unregister_i2c_c {struct intel_quark_mfd *quark_mfd =dev_get_drvdata (&pdev->dev); -if (!quark_mfd->i2c_clk || !quark_mfd->i2c_clk_lookup) +if (!quark_mfd->i2c_clk_lookup)return ;clkdev_drop (quark_mfd->i2c_clk_lookup);
@@ -246,25 +247,33 @@ static int intel_quark_mfd_probe(struct quark_mfd =devm_kzalloc (&pdev->dev,sizeof (*quark_mfd),GFP_KERNEL );if (!quark_mfd)return -ENOMEM ; + quark_mfd->pdev = pdev; +dev_set_drvdata (&pdev->dev, quark_mfd); ret =intel_quark_register_i2c_clk (quark_mfd);if (ret)return ret; -dev_set_drvdata (&pdev->dev, quark_mfd); - ret =intel_quark_i2c_setup (pdev, &intel_quark_mfd_cells[1 ]);if (ret) -return ret; + goto err_unregister_i2c_clk; ret =intel_quark_gpio_setup (pdev, &intel_quark_mfd_cells[0 ]);if (ret) -return ret; + goto err_unregister_i2c_clk; + + ret =mfd_add_devices (&pdev->dev,0 , intel_quark_mfd_cells, +ARRAY_SIZE (intel_quark_mfd_cells),NULL ,0 , +NULL ); +if (ret) + goto err_unregister_i2c_clk; + +return 0 ; -return mfd_add_devices (&pdev->dev,0 , intel_quark_mfd_cells, -ARRAY_SIZE (intel_quark_mfd_cells),NULL ,0 , -NULL ); +err_unregister_i2c_clk: +intel_quark_unregister_i2c_clk (pdev); +return ret; }static void intel_quark_mfd_remove (struct pci_dev *pdev)
Greg Kroah-Hartman
maintainerPATCH 58/121 mfd: intel-lpss: Save register context on suspend
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heikki Krogerus <[email protected]>
commit 41a3da2b8e1639d983192e3650670df4ecc94cf7 upstream.
All configurations are lost and the registers will have default values when the hardware is suspended and resumed, so saving the private register space context on suspend, and restoring it on resume.
--- drivers/mfd/intel-lpss.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
drivers/mfd/intel-lpss.c +18 -1
@@ -34,6 +34,7 @@#define LPSS_DEV_SIZE 0x200#define LPSS_PRIV_OFFSET 0x200#define LPSS_PRIV_SIZE 0x100 +#define LPSS_PRIV_REG_COUNT (LPSS_PRIV_SIZE / 4)#define LPSS_IDMA64_OFFSET 0x800#define LPSS_IDMA64_SIZE 0x800
@@ -76,6 +77,7 @@ struct intel_lpss {struct mfd_cell *cell;struct device *dev;void __iomem *priv; +u32 priv_ctx[LPSS_PRIV_REG_COUNT ];int devid;u32 caps;u32 active_ltr;
@@ -493,6 +495,16 @@ EXPORT_SYMBOL_GPL(intel_lpss_prepare);int intel_lpss_suspend (struct device *dev) { +struct intel_lpss *lpss =dev_get_drvdata (dev); +unsigned int i; + +/* Save device context */ +for (i =0 ; i <LPSS_PRIV_REG_COUNT ; i++) + lpss->priv_ctx[i] =readl (lpss->priv + i *4 ); + +/* Put the device into reset state */ +writel (0 , lpss->priv +LPSS_PRIV_RESETS ); +return 0 ; }EXPORT_SYMBOL_GPL (intel_lpss_suspend);
@@ -500,8 +512,13 @@ EXPORT_SYMBOL_GPL(intel_lpss_suspend);int intel_lpss_resume (struct device *dev) {struct intel_lpss *lpss =dev_get_drvdata (dev); +unsigned int i; -intel_lpss_init_dev (lpss); +intel_lpss_deassert_reset (lpss); + +/* Restore device context */ +for (i =0 ; i <LPSS_PRIV_REG_COUNT ; i++) +writel (lpss->priv_ctx[i], lpss->priv + i *4 );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 60/121 PM / Runtime: Fix error path in pm_runtime_force_resume()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <[email protected]>
commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream.
As pm_runtime_set_active() may fail because the device's parent isn't active, we can end up executing the ->runtime_resume() callback for the device when it isn't allowed.
Fix this by invoking pm_runtime_set_active() before running the callback and let's also deal with the error code.
--- drivers/base/power/runtime.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/base/power/runtime.c +7 -2
@@ -1506,11 +1506,16 @@ int pm_runtime_force_resume(struct devic goto out; } - ret =callback (dev); + ret =pm_runtime_set_active (dev);if (ret) goto out; -pm_runtime_set_active (dev); + ret =callback (dev); +if (ret) { +pm_runtime_set_suspended (dev); + goto out; + } +pm_runtime_mark_last_busy (dev); out:pm_runtime_enable (dev);
Greg Kroah-Hartman
maintainerPATCH 61/121 cpuidle: Indicate when a device has been unregistered
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Gerlach <[email protected]>
commit c998c07836f985b24361629dc98506ec7893e7a0 upstream.
Currently the 'registered' member of the cpuidle_device struct is set to 1 during cpuidle_register_device. In this same function there are checks to see if the device is already registered to prevent duplicate calls to register the device, but this value is never set to 0 even on unregister of the device. Because of this, any attempt to call cpuidle_register_device after a call to cpuidle_unregister_device will fail which shouldn't be the case.
To prevent this, set registered to 0 when the device is unregistered.
--- drivers/cpuidle/cpuidle.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/cpuidle/cpuidle.c +2 -0
@@ -433,6 +433,8 @@ static void __cpuidle_unregister_device(list_del (&dev->device_list);per_cpu (cpuidle_devices, dev->cpu) =NULL ;module_put (drv->owner); + + dev->registered =0 ; }static void __cpuidle_device_init (struct cpuidle_device *dev)
Greg Kroah-Hartman
maintainerPATCH 62/121 cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Lezcano <[email protected]>
commit e7387da52028b072489c45efeb7a916c0205ebd2 upstream.
Commit 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) rightfully fixed a regression by letting the coupled idle state framework to handle local interrupt enabling when the CPU is exiting an idle state.
The current code checks if the idle state is coupled and, if so, it will let the coupled code to enable interrupts. This way, it can decrement the ready-count before handling the interrupt. This mechanism prevents the other CPUs from waiting for a CPU which is handling interrupts.
But the check is done against the state index returned by the back end driver's ->enter functions which could be different from the initial index passed as parameter to the cpuidle_enter_state() function.
entered_state = target_state->enter(dev, drv, index);
[ ... ]
if (!cpuidle_state_is_coupled(drv, entered_state))
local_irq_enable();
[ ... ]
If the 'index' is referring to a coupled idle state but the 'entered_state' is *not* coupled, then the interrupts are enabled again. All CPUs blocked on the sync barrier may busy loop longer if the CPU has interrupts to handle before decrementing the ready-count. That's consuming more energy than saving.
--- drivers/cpuidle/cpuidle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/cpuidle/cpuidle.c +1 -1
@@ -214,7 +214,7 @@ int cpuidle_enter_state(struct cpuidle_dtick_broadcast_exit (); } -if (!cpuidle_state_is_coupled (drv, entered_state)) +if (!cpuidle_state_is_coupled (drv, index))local_irq_enable (); diff =ktime_to_us (ktime_sub (time_end, time_start));
Greg Kroah-Hartman
maintainerPATCH 63/121 clk: bcm2835: Fix PLL poweron
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Anholt <[email protected]>
commit e708b383f4b94feca2e0d5d06e1cfc13cdfea100 upstream.
In poweroff, we set the reset bit and the power down bit, but only managed to unset the reset bit for poweron. This meant that if HDMI did -EPROBE_DEFER after it had grabbed its clocks, we'd power down the PLLH (that had been on at boot time) and never recover.
--- drivers/clk/bcm/clk-bcm2835.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/clk/bcm/clk-bcm2835.c +4 -0
@@ -921,6 +921,10 @@ static int bcm2835_pll_on(struct clk_hwconst struct bcm2835_pll_data *data = pll->data;ktime_t timeout; +cprman_write (cprman, data->a2w_ctrl_reg, +cprman_read (cprman, data->a2w_ctrl_reg) & + ~A2W_PLL_CTRL_PWRDN ); +/* Take the PLL out of reset. */ cprman_write (cprman, data->cm_ctrl_reg,cprman_read (cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST );
Greg Kroah-Hartman
maintainerPATCH 64/121 clk: at91: fix check of clk_register() returned value
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Zapolskiy <[email protected]>
commit cb0ceaf77d93964a0d00477c79f4499123f6159c upstream.
The clk_register() function returns a valid pointer to struct clk or ERR_PTR() error code, this makes a check for returned NULL value useless and may lead to oops on error path.
--- drivers/clk/at91/clk-h32mx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/at91/clk-h32mx.c +1 -1
@@ -114,7 +114,7 @@ static void __init of_sama5d4_clk_h32mx_ h32mxclk->regmap = regmap; clk =clk_register (NULL , &h32mxclk->hw); -if (!clk) { +if (IS_ERR (clk)) {kfree (h32mxclk);return ; }
Greg Kroah-Hartman
maintainerPATCH 65/121 clk: bcm2835: pll_off should only update CM_PLL_ANARST
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Sperl <[email protected]>
commit 6727f086cfe4ddcc651eb2bf4301abfcf619be06 upstream.
bcm2835_pll_off is currently assigning CM_PLL_ANARST to the control register, which may lose the other bits that are currently set by the clock dividers.
It also now locks during the read/modify/write cycle of both registers.
audio domain clocks")
--- drivers/clk/bcm/clk-bcm2835.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +8 -2
@@ -910,8 +910,14 @@ static void bcm2835_pll_off(struct clk_hstruct bcm2835_cprman *cprman = pll->cprman;const struct bcm2835_pll_data *data = pll->data; -cprman_write (cprman, data->cm_ctrl_reg,CM_PLL_ANARST ); -cprman_write (cprman, data->a2w_ctrl_reg,A2W_PLL_CTRL_PWRDN ); +spin_lock (&cprman->regs_lock); +cprman_write (cprman, data->cm_ctrl_reg, +cprman_read (cprman, data->cm_ctrl_reg) | +CM_PLL_ANARST ); +cprman_write (cprman, data->a2w_ctrl_reg, +cprman_read (cprman, data->a2w_ctrl_reg) | +A2W_PLL_CTRL_PWRDN ); +spin_unlock (&cprman->regs_lock); }static int bcm2835_pll_on (struct clk_hw *hw)
Greg Kroah-Hartman
maintainerPATCH 66/121 clk: bcm2835: divider value has to be 1 or more
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Sperl <[email protected]>
commit 997f16bd5d2e9b3456027f96fcadfe1e2bf12f4e upstream.
Current clamping of a normal divider allows a value < 1 to be valid.
A divider of < 1 would actually only be possible if we had a PLL...
So this patch clamps the divider to 1.
audio domain clocks")
--- drivers/clk/bcm/clk-bcm2835.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +3 -2
@@ -1194,8 +1194,9 @@ static u32 bcm2835_clock_choose_div(stru div += unused_frac_mask +1 ; div &= ~unused_frac_mask; -/* Clamp to the limits. */ - div =max (div, unused_frac_mask +1 ); +/* clamp to min divider of 1 */ + div =max_t (u32, div,1 <<CM_DIV_FRAC_BITS ); +/* clamp to the highest possible fractional divider */ div =min_t (u32, div,GENMASK (data->int_bits +CM_DIV_FRAC_BITS -1 ,CM_DIV_FRAC_BITS - data->frac_bits));
Greg Kroah-Hartman
maintainerPATCH 67/121 clk: bcm2835: correctly enable fractional clock support
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Sperl <[email protected]>
commit 959ca92a3235fc4b17c1e18483fc390b3d612254 upstream.
The current driver calculates the clock divider with fractional support enabled.
But it does not enable fractional support in the control register itself resulting in an integer only divider, but in clk_set_rate responds back the fractionally divided clock frequency.
This patch enables fractional support in the control register whenever there is a fractional bit set in the requested clock divider.
Mash clock limits are are also handled for the PWM clock applying the correct divider limits (2 and max_int) applicable to basic fractional divider support (mash order of 1).
It also adds locking to protect the read/modify/write cycle of the register modification.
audio domain clocks")
--- drivers/clk/bcm/clk-bcm2835.c | 45 ++++++++++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 6 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +39 -6
@@ -51,6 +51,7 @@#define CM_GNRICCTL 0x000#define CM_GNRICDIV 0x004# define CM_DIV_FRAC_BITS 12 +# define CM_DIV_FRAC_MASK GENMASK(CM_DIV_FRAC_BITS - 1, 0)#define CM_VPUCTL 0x008#define CM_VPUDIV 0x00c
@@ -128,6 +129,7 @@# define CM_GATE BIT(CM_GATE_BIT)# define CM_BUSY BIT(7)# define CM_BUSYD BIT(8) +# define CM_FRAC BIT(9)# define CM_SRC_SHIFT 0# define CM_SRC_BITS 4# define CM_SRC_MASK 0xf
@@ -644,6 +646,7 @@ struct bcm2835_clock_data {u32 frac_bits;bool is_vpu_clock; +bool is_mash_clock; };static const char *const bcm2835_clock_per_parents[] = {
@@ -825,6 +828,7 @@ static const struct bcm2835_clock_data b .div_reg = CM_PWMDIV, .int_bits = 12, .frac_bits = 12, + .is_mash_clock = true, };struct bcm2835_pll {
@@ -1184,7 +1188,7 @@ static u32 bcm2835_clock_choose_div(struGENMASK (CM_DIV_FRAC_BITS - data->frac_bits,0 ) >>1 ;u64 temp = (u64 )parent_rate <<CM_DIV_FRAC_BITS ;u64 rem; -u32 div; +u32 div, mindiv, maxdiv; rem =do_div (temp, rate); div = temp;
@@ -1194,11 +1198,23 @@ static u32 bcm2835_clock_choose_div(stru div += unused_frac_mask +1 ; div &= ~unused_frac_mask; -/* clamp to min divider of 1 */ - div =max_t (u32, div,1 <<CM_DIV_FRAC_BITS ); -/* clamp to the highest possible fractional divider */ - div =min_t (u32, div,GENMASK (data->int_bits +CM_DIV_FRAC_BITS -1 , -CM_DIV_FRAC_BITS - data->frac_bits)); +/* different clamping limits apply for a mash clock */ +if (data->is_mash_clock) { +/* clamp to min divider of 2 */ + mindiv =2 <<CM_DIV_FRAC_BITS ; +/* clamp to the highest possible integer divider */ + maxdiv = (BIT (data->int_bits) -1 ) <<CM_DIV_FRAC_BITS ; + }else { +/* clamp to min divider of 1 */ + mindiv =1 <<CM_DIV_FRAC_BITS ; +/* clamp to the highest possible fractional divider */ + maxdiv =GENMASK (data->int_bits +CM_DIV_FRAC_BITS -1 , +CM_DIV_FRAC_BITS - data->frac_bits); + } + +/* apply the clamping limits */ + div =max_t (u32, div, mindiv); + div =min_t (u32, div, maxdiv);return div; }
@@ -1292,9 +1308,26 @@ static int bcm2835_clock_set_rate(structstruct bcm2835_cprman *cprman = clock->cprman;const struct bcm2835_clock_data *data = clock->data;u32 div =bcm2835_clock_choose_div (hw, rate, parent_rate, false); +u32 ctl; + +spin_lock (&cprman->regs_lock); + +/* +* Setting up frac support +* +* In principle it is recommended to stop/start the clock first, +* but as we set CLK_SET_RATE_GATE during registration of the +* clock this requirement should be take care of by the +* clk-framework. +*/ + ctl =cprman_read (cprman, data->ctl_reg) & ~CM_FRAC ; + ctl |= (div &CM_DIV_FRAC_MASK ) ?CM_FRAC :0 ; +cprman_write (cprman, data->ctl_reg, ctl);cprman_write (cprman, data->div_reg, div); +spin_unlock (&cprman->regs_lock); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 68/121 pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Jeffery <[email protected]>
commit 71324fdc72ef0163e57631aa814a9a81e9e4770b upstream.
The range is registered into a linked list which can be referenced throughout the lifetime of the driver. Ensure the range's memory is useful for the same lifetime by adding it to the driver's private data structure.
The bug was introduced in the driver's initial commit, which was present in v3.10.
--- drivers/pinctrl/samsung/pinctrl-exynos5440.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
drivers/pinctrl/samsung/pinctrl-exynos5440.c +8 -7
@@ -107,6 +107,7 @@ struct exynos5440_pmx_func {* @nr_groups: number of pin groups available. * @pmx_functions: list of pin functions parsed from device tree. * @nr_functions: number of pin functions available. +* @range: gpio range to register with pinctrl */ struct exynos5440_pinctrl_priv_data {void __iomem *reg_base;
@@ -117,6 +118,7 @@ struct exynos5440_pinctrl_priv_data {unsigned int nr_groups;const struct exynos5440_pmx_func *pmx_functions;unsigned int nr_functions; +struct pinctrl_gpio_range range; };/**
@@ -742,7 +744,6 @@ static int exynos5440_pinctrl_register(sstruct pinctrl_desc *ctrldesc;struct pinctrl_dev *pctl_dev;struct pinctrl_pin_desc *pindesc, *pdesc; -struct pinctrl_gpio_range grange;char *pin_names;int pin, ret;
@@ -794,12 +795,12 @@ static int exynos5440_pinctrl_register(sreturn PTR_ERR (pctl_dev); } - grange.name ="exynos5440-pctrl-gpio-range" ; - grange.id =0 ; - grange.base =0 ; - grange.npins =EXYNOS5440_MAX_PINS ; - grange.gc = priv->gc; -pinctrl_add_gpio_range (pctl_dev, &grange); + priv->range.name ="exynos5440-pctrl-gpio-range" ; + priv->range.id =0 ; + priv->range.base =0 ; + priv->range.npins =EXYNOS5440_MAX_PINS ; + priv->range.gc = priv->gc; +pinctrl_add_gpio_range (pctl_dev, &priv->range);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 69/121 PCI: Disable all BAR sizing for devices with non-compliant BARs
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prarit Bhargava <[email protected]>
commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream.
b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with the PCI spec. But it didn't do anything for expansion ROM BARs, so we still try to size them, resulting in warnings like this on Broadwell-EP:
pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]
Move the non-compliant BAR check from __pci_read_base() up to pci_read_bases() so it applies to the expansion ROM BAR as well as to BARs 0-5.
Note that direct callers of __pci_read_base(), like sriov_init(), will now bypass this check. We haven't had reports of devices with broken SR-IOV BARs yet.
--- drivers/pci/probe.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/pci/probe.c +3 -3
@@ -179,9 +179,6 @@ int __pci_read_base(struct pci_dev *dev,u16 orig_cmd;struct pci_bus_region region, inverted_region; -if (dev->non_compliant_bars) -return 0 ; - mask = type ?PCI_ROM_ADDRESS_MASK : ~0 ;/* No printks while decoding is disabled! */
@@ -322,6 +319,9 @@ static void pci_read_bases(struct pci_de {unsigned int pos, reg; +if (dev->non_compliant_bars) +return ; +for (pos =0 ; pos < howmany; pos++) {struct resource *res = &dev->resource[pos]; reg =PCI_BASE_ADDRESS_0 + (pos <<2 );
Greg Kroah-Hartman
maintainerPATCH 70/121 media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiffany Lin <[email protected]>
commit baf43c6eace43868e490f18560287fa3481b2159 upstream.
In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved filed of v4l2_create_buffers filled with zero
Reserved field is filled with zero in v4l_create_bufs.
This patch copy reserved field of v4l2_create_buffer from kernel space to user space
--- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/v4l2-core/v4l2-compat-ioctl32.c +2 -1
@@ -280,7 +280,8 @@ static int put_v4l2_format32(struct v4l2static int put_v4l2_create32 (struct v4l2_create_buffers *kp,struct v4l2_create_buffers32 __user *up) {if (!access_ok (VERIFY_WRITE , up,sizeof (struct v4l2_create_buffers32 )) || -copy_to_user (up, kp, offsetof(struct v4l2_create_buffers32 , format))) +copy_to_user (up, kp, offsetof(struct v4l2_create_buffers32 , format)) || +copy_to_user (up->reserved, kp->reserved,sizeof (kp->reserved)))return -EFAULT ;return __put_v4l2_format32 (&kp->format, &up->format); }
Greg Kroah-Hartman
maintainerPATCH 71/121 PKCS#7: fix missing break on OID_sha224 case
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
commit 06af9b0f4949b85b20107e6d75f5eba15111d220 upstream.
The OID_sha224 case is missing a break and it falls through to the -ENOPKG error default. Since HASH_ALGO_SHA224 seems to be supported, this looks like an unintentional missing break.
--- crypto/asymmetric_keys/pkcs7_parser.c | 1 + 1 file changed, 1 insertion(+)
crypto/asymmetric_keys/pkcs7_parser.c +1 -0
@@ -237,6 +237,7 @@ int pkcs7_sig_note_digest_algo(void *conbreak ;case OID_sha224: ctx->sinfo->sig.hash_algo ="sha224" ; +break ;default :printk ("Unsupported digest algo: %u\n" , ctx->last_oid);return -ENOPKG ;
Greg Kroah-Hartman
maintainerPATCH 72/121 mm: use phys_addr_t for reserve_bootmem_region() arguments
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Bader <[email protected]>
commit 4b50bcc7eda4d3cc9e3f2a0aa60e590fedf728c5 upstream.
Since commit 92923ca3aace ("mm: meminit: only set page reserved in the memblock region") the reserved bit is set on reserved memblock regions. However start and end address are passed as unsigned long. This is only 32bit on i386, so it can end up marking the wrong pages reserved for ranges at 4GB and above.
This was observed on a 32bit Xen dom0 which was booted with initial memory set to a value below 4G but allowing to balloon in memory (dom0_mem=1024M for example). This would define a reserved bootmem region for the additional memory (for example on a 8GB system there was a reverved region covering the 4GB-8GB range). But since the addresses were passed on as unsigned long, this was actually marking all pages from 0 to 4GB as reserved.
--- include/linux/mm.h | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
include/linux/mm.h +1 -1
@@ -1782,7 +1782,7 @@ extern void free_highmem_page(struct pagextern void adjust_managed_page_count (struct page *page,long count);extern void mem_init_print_info (const char *str); -extern void reserve_bootmem_region (unsigned long start,unsigned long end); +extern void reserve_bootmem_region (phys_addr_t start,phys_addr_t end);/* Free the reserved page into the buddy system, so it gets managed. */ static inline void __free_reserved_page (struct page *page)
mm/page_alloc.c +1 -1
@@ -1003,7 +1003,7 @@ static inline void init_reserved_page(un* marks the pages PageReserved. The remaining valid pages are later * sent to the buddy page allocator. */ -void __meminit reserve_bootmem_region (unsigned long start,unsigned long end) +void __meminit reserve_bootmem_region (phys_addr_t start,phys_addr_t end) {unsigned long start_pfn =PFN_DOWN (start);unsigned long end_pfn =PFN_UP (end);
Greg Kroah-Hartman
maintainerPATCH 73/121 mm/compaction.c: fix zoneindex in kcompactd()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Feng <[email protected]>
commit 6cd9dc3e75078ef646076fa63adfb9b85ced0b66 upstream.
While testing the kcompactd in my platform 3G MEM only DMA ZONE. I found the kcompactd never wakeup. It seems the zoneindex has already minus 1 before. So the traverse here should be <=.
It fixes a regression where kswapd could previously compact, but kcompactd not. Not a crash fix though.
--- mm/compaction.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
mm/compaction.c +2 -2
@@ -1742,7 +1742,7 @@ static bool kcompactd_node_suitable(pg_dstruct zone *zone;enum zone_type classzone_idx = pgdat->kcompactd_classzone_idx; -for (zoneid =0 ; zoneid < classzone_idx; zoneid++) { +for (zoneid =0 ; zoneid <= classzone_idx; zoneid++) { zone = &pgdat->node_zones[zoneid];if (!populated_zone (zone))
@@ -1777,7 +1777,7 @@ static void kcompactd_do_work(pg_data_t cc.classzone_idx);count_vm_event (KCOMPACTD_WAKE ); -for (zoneid =0 ; zoneid < cc.classzone_idx; zoneid++) { +for (zoneid =0 ; zoneid <= cc.classzone_idx; zoneid++) {int status; zone = &pgdat->node_zones[zoneid];
Greg Kroah-Hartman
maintainerPATCH 74/121 wait/ptrace: assume __WALL if the child is traced
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
commit bf959931ddb88c4e4366e96dd22e68fa0db9527c upstream.
The following program (simplified version of generated by syzkaller)
#include <pthread.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <stdio.h>
#include <signal.h>
void *thread_func(void *arg)
{
ptrace(PTRACE_TRACEME, 0,0,0);
return 0;
}
int main(void)
{
pthread_t thread;
if (fork())
return 0;
while (getppid() != 1)
;
pthread_create(&thread, NULL, thread_func, NULL);
pthread_join(thread, NULL);
return 0;
}creates an unreapable zombie if /sbin/init doesn't use __WALL.
This is not a kernel bug, at least in a sense that everything works as
expected: debugger should reap a traced sub-thread before it can reap the leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.
Unfortunately, it seems that /sbin/init in most (all?) distributions doesn't use it and we have to change the kernel to avoid the problem. Note also that most init's use sys_waitid() which doesn't allow __WALL, so the necessary user-space fix is not that trivial.
This patch just adds the "ptrace" check into eligible_child(). To some degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is mostly ignored when the tracee reports to debugger. Or WSTOPPED, the tracer doesn't need to set this flag to wait for the stopped tracee.
This obviously means the user-visible change: __WCLONE and __WALL no longer have any meaning for debugger. And I can only hope that this won't break something, but at least strace/gdb won't suffer.
We could make a more conservative change. Say, we can take __WCLONE into account, or !thread_group_leader(). But it would be nice to not complicate these historical/confusing checks.
--- kernel/exit.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
kernel/exit.c +20 -9
@@ -918,17 +918,28 @@ static int eligible_pid(struct wait_optstask_pid_type (p, wo->wo_type) == wo->wo_pid; } -static int eligible_child (struct wait_opts *wo,struct task_struct *p) +static int +eligible_child (struct wait_opts *wo,bool ptrace,struct task_struct *p) {if (!eligible_pid (wo, p))return 0 ; -/* Wait for all children (clone and not) if __WALL is set; -* otherwise, wait for clone children *only* if __WCLONE is -* set; otherwise, wait for non-clone children *only*. (Note: -* A "clone" child here is one that reports to its parent -* using a signal other than SIGCHLD.) */ -if (((p->exit_signal !=SIGCHLD ) ^ !!(wo->wo_flags & __WCLONE)) - && !(wo->wo_flags & __WALL)) + +/* +* Wait for all children (clone and not) if __WALL is set or +* if it is traced by us. +*/ +if (ptrace || (wo->wo_flags & __WALL)) +return 1 ; + +/* +* Otherwise, wait for clone children *only* if __WCLONE is set; +* otherwise, wait for non-clone children *only*. +* +* Note: a "clone" child here is one that reports to its parent +* using a signal other than SIGCHLD, or a non-leader thread which +* we can only see if it is traced by us. +*/ +if ((p->exit_signal !=SIGCHLD ) ^ !!(wo->wo_flags & __WCLONE))return 0 ;return 1 ;
@@ -1300,7 +1311,7 @@ static int wait_consider_task(struct waiif (unlikely (exit_state ==EXIT_DEAD ))return 0 ; - ret =eligible_child (wo, p); + ret =eligible_child (wo, ptrace, p);if (!ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 75/121 QE-UART: add "fsl,t1040-ucc-uart" to of_device_id
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhao Qiang <[email protected]>
commit 11ca2b7ab432eb90906168c327733575e68d388f upstream.
New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart. So add it.
--- drivers/tty/serial/ucc_uart.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/tty/serial/ucc_uart.c +3 -0
@@ -1478,6 +1478,9 @@ static const struct of_device_id ucc_uar .type = "serial", .compatible = "ucc_uart", }, + { + .compatible = "fsl,t1040-ucc-uart", + }, {}, };MODULE_DEVICE_TABLE (of, ucc_uart_match);
Greg Kroah-Hartman
maintainerPATCH 76/121 batman-adv: Fix double neigh_node_put in batadv_v_ogm_route_update
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Eckelmann <[email protected]>
The router is put down twice when it was non-NULL and either orig_ifinfo is NULL afterwards or batman-adv receives a packet with the same sequence number. This will end up in a use-after-free when the batadv_neigh_node is removed because the reference counter ended up too early at 0.
This patch is skipping netdev and is being sent directly to stable in accordance with David S. Miller[1].
The reason is that this patch applies only on linux-4.6 and not on linux-4.7/net because it was "accidentally" fixed by a refactoring commit (more details in [2]).
It addresses a reference imbalance which systematically leads to a use-after-free and then a kernel crash.
[1] https://www.mail-archive.com/[email protected]/msg15258.html
[2] https://www.mail-archive.com/[email protected]/msg15252.html
---
Cheers,
net/batman-adv/bat_v_ogm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/batman-adv/bat_v_ogm.c +3 -1
@@ -529,8 +529,10 @@ static void batadv_v_ogm_route_update(st goto out; } -if (router) +if (router) {batadv_neigh_node_put (router); + router =NULL ; + }/* Update routes, and check if the OGM is from the best next hop */ batadv_v_ogm_orig_update(bat_priv, orig_node, neigh_node, ogm2,
Greg Kroah-Hartman
maintainerPATCH 77/121 powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hari Bathini <[email protected]>
commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream.
Some of the interrupt vectors on 64-bit POWER server processors are only 32 bytes long (8 instructions), which is not enough for the full first-level interrupt handler. For these we need to branch to an out-of-line (OOL) handler. But when we are running a relocatable kernel, interrupt vectors till __end_interrupts marker are copied down to real address 0x100. So, branching to labels (ie. OOL handlers) outside this section must be handled differently (see LOAD_HANDLER()), considering relocatable kernel, which would need at least 4 instructions.
However, branching from interrupt vector means that we corrupt the CFAR (come-from address register) on POWER7 and later processors as mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions) that contains the part up to the point where the CFAR is saved in the PACA should be part of the short interrupt vectors before we branch out to OOL handlers.
But as mentioned already, there are interrupt vectors on 64-bit POWER server processors that are only 32 bytes long (like vectors 0x4f00, 0x4f20, etc.), which cannot accomodate the above two cases at the same time owing to space constraint. Currently, in these interrupt vectors, we simply branch out to OOL handlers, without using LOAD_HANDLER(), which leaves us vulnerable when running a relocatable kernel (eg. kdump case). While this has been the case for sometime now and kdump is used widely, we were fortunate not to see any problems so far, for three reasons:
1. In almost all cases, production kernel (relocatable) is used for kdump as well, which would mean that crashed kernel's OOL handler would be at the same place where we end up branching to, from short interrupt vector of kdump kernel.
2. Also, OOL handler was unlikely the reason for crash in almost all the kdump scenarios, which meant we had a sane OOL handler from crashed kernel that we branched to.
3. On most 64-bit POWER server processors, page size is large enough that marking interrupt vector code as executable (see commit 429d2e83) leads to marking OOL handler code from crashed kernel, that sits right below interrupt vector code from kdump kernel, as executable as well.
Let us fix this by moving the __end_interrupts marker down past OOL handlers to make sure that we also copy OOL handlers to real address 0x100 when running a relocatable kernel.
This fix has been tested successfully in kdump scenario, on an LPAR with 4K page size by using different default/production kernel and kdump kernel.
Also tested by manually corrupting the OOL handlers in the first kernel and then kdump'ing, and then causing the OOL handlers to fire - mpe.
--- arch/powerpc/kernel/exceptions-64s.S | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
arch/powerpc/kernel/exceptions-64s.S +11 -5
@@ -953,11 +953,6 @@ hv_facility_unavailable_relon_trampoline #endif STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist) - /* Other future vectors */ - .align 7 - .globl __end_interrupts -__end_interrupts: - .align 7 system_call_entry: b system_call_common
@@ -1244,6 +1239,17 @@ __end_handlers: STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable) STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable) + /* + * The __end_interrupts marker must be past the out-of-line (OOL) + * handlers, so that they are copied to real address 0x100 when running + * a relocatable kernel. This ensures they can be reached from the short + * trampoline handlers (like 0x4f00, 0x4f20, etc.) which branch + * directly, without using LOAD_HANDLER(). + */ + .align 7 + .globl __end_interrupts +__end_interrupts: + #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) /* * Data area reserved for FWNMI option.
Greg Kroah-Hartman
maintainerPATCH 78/121 powerpc/eeh: Dont report error in eeh_pe_reset_and_recover()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gavin Shan <[email protected]>
commit affeb0f2d3a9af419ad7ef4ac782e1540b2f7b28 upstream.
The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrough device are transferred to guest and backwards, meaning the device's driver is vfio-pci or none. When the driver is vfio-pci that provides error_detected() error handler only, the handler simply stops the guest and it's not expected behaviour. On the other hand, no error handlers will be called if we don't have a bound driver.
This ignores the error handler in eeh_pe_reset_and_recover() that reports the error to device driver to avoid the exceptional behaviour.
--- arch/powerpc/kernel/eeh_driver.c | 3 --- 1 file changed, 3 deletions(-)
arch/powerpc/kernel/eeh_driver.c +0 -3
@@ -564,9 +564,6 @@ int eeh_pe_reset_and_recover(struct eeh_/* Save states */ eeh_pe_dev_traverse (pe, eeh_dev_save_state,NULL ); -/* Report error */ -eeh_pe_dev_traverse (pe, eeh_report_error, &result); -/* Issue reset */ ret =eeh_reset_pe (pe);if (ret) {
Greg Kroah-Hartman
maintainerPATCH 79/121 Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guilherme G. Piccoli <[email protected]>
commit c2078d9ef600bdbe568c89e5ddc2c6f15b7982c8 upstream.
This reverts commit 89a51df5ab1d38b257300b8ac940bbac3bb0eb9b.
The function eeh_add_device_early() is used to perform EEH initialization in devices added later on the system, like in hotplug/DLPAR scenarios. Since the commit 89a51df5ab1d ("powerpc/eeh:
Fix crash in eeh_add_device_early() on Cell") a new check was introduced in this function - Cell has no EEH capabilities which led to kernel oops if hotplug was performed, so checking for eeh_enabled() was introduced to avoid the issue.
However, in architectures that EEH is present like pSeries or PowerNV, we might reach a case in which no PCI devices are present on boot time and so EEH is not initialized. Then, if a device is added via DLPAR for example, eeh_add_device_early() fails because eeh_enabled() is false, and EEH end up not being enabled at all.
This reverts the aforementioned patch since a new verification was introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore.
--- arch/powerpc/kernel/eeh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/eeh.c +1 -1
@@ -1068,7 +1068,7 @@ void eeh_add_device_early(struct pci_dnstruct pci_controller *phb;struct eeh_dev *edev =pdn_to_eeh_dev (pdn); -if (!edev || !eeh_enabled ()) +if (!edev)return ;if (!eeh_has_flag (EEH_PROBE_MODE_DEVTREE ))
Greg Kroah-Hartman
maintainerPATCH 80/121 powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gavin Shan <[email protected]>
commit 5a0cdbfd17b90a89c64a71d8aec9773ecdb20d0d upstream.
The function eeh_pe_reset_and_recover() is used to recover EEH error when the passthrou device are transferred to guest and backwards. The content in the device's config space will be lost on PE reset issued in the middle of the recovery. The function saves/restores it before/after the reset. However, config access to some adapters like Broadcom BCM5719 at this point will causes fenced PHB. The config space is always blocked and we save 0xFF's that are restored at late point. The memory BARs are totally corrupted, causing another EEH error upon access to one of the memory BARs.
This restores the config space on those adapters like BCM5719 from the content saved to the EEH device when it's populated, to resolve above issue.
--- arch/powerpc/kernel/eeh_driver.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
arch/powerpc/kernel/eeh_driver.c +23 -0
@@ -171,6 +171,16 @@ static void *eeh_dev_save_state(void *daif (!edev)return NULL ; +/* +* We cannot access the config space on some adapters. +* Otherwise, it will cause fenced PHB. We don't save +* the content in their config space and will restore +* from the initial config space saved when the EEH +* device is created. +*/ +if (edev->pe && (edev->pe->state &EEH_PE_CFG_RESTRICTED )) +return NULL ; + pdev =eeh_dev_to_pci_dev (edev);if (!pdev)return NULL ;
@@ -312,6 +322,19 @@ static void *eeh_dev_restore_state(voidif (!edev)return NULL ; +/* +* The content in the config space isn't saved because +* the blocked config space on some adapters. We have +* to restore the initial saved config space when the +* EEH device is created. +*/ +if (edev->pe && (edev->pe->state &EEH_PE_CFG_RESTRICTED )) { +if (list_is_last (&edev->list, &edev->pe->edevs)) +eeh_pe_restore_bars (edev->pe); + +return NULL ; + } + pdev =eeh_dev_to_pci_dev (edev);if (!pdev)return NULL ;
Greg Kroah-Hartman
maintainerPATCH 81/121 xen/events: Dont move disabled irqs
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Lagerwall <[email protected]>
commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.
Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded irq_move_irq() but left out checking if the IRQ is disabled. This broke resuming from suspend since it tries to move a (disabled) irq without holding the IRQ's desc->lock. Fix it by adding in a check for disabled IRQs.
The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31! invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ... CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016 task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000 RIP: 0010:[<ffffffff810e26e2>] [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0 RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8 RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000 R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0 R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66 Call Trace: [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0 [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150 [<ffffffff814ca659>] xen_irq_resume+0x319/0x360 [<ffffffff814c7e75>] xen_suspend+0xb5/0x180 [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0 [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80 [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140 [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220 [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160 [<ffffffff810a3830>] ? sort_range+0x30/0x30 [<ffffffff810a0588>] kthread+0xd8/0xf0 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0 [<ffffffff8182568f>] ret_from_fork+0x3f/0x70 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
--- drivers/xen/events/events_base.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/xen/events/events_base.c +4 -2
@@ -487,7 +487,8 @@ static void eoi_pirq(struct irq_data *daif (!VALID_EVTCHN (evtchn))return ; -if (unlikely (irqd_is_setaffinity_pending (data))) { +if (unlikely (irqd_is_setaffinity_pending (data)) && +likely (!irqd_irq_disabled (data))) {int masked =test_and_set_mask (evtchn);clear_evtchn (evtchn);
@@ -1370,7 +1371,8 @@ static void ack_dynirq(struct irq_data *if (!VALID_EVTCHN (evtchn))return ; -if (unlikely (irqd_is_setaffinity_pending (data))) { +if (unlikely (irqd_is_setaffinity_pending (data)) && +likely (!irqd_irq_disabled (data))) {int masked =test_and_set_mask (evtchn);clear_evtchn (evtchn);
Greg Kroah-Hartman
maintainerPATCH 82/121 xen: use same main loop for counting and remapping pages
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit dd14be92fbf5bc1ef7343f34968440e44e21b46a upstream.
Instead of having two functions for cycling through the E820 map in order to count to be remapped pages and remap them later, just use one function with a caller supplied sub-function called for each region to be processed. This eliminates the possibility of a mismatch between both loops which showed up in certain configurations.
--- arch/x86/xen/setup.c | 65 ++++++++++++++++++++------------------------------- 1 file changed, 26 insertions(+), 39 deletions(-)
arch/x86/xen/setup.c +26 -39
@@ -393,6 +393,9 @@ static unsigned long __init xen_set_idenunsigned long i =0 ;unsigned long n = end_pfn - start_pfn; +if (remap_pfn ==0 ) + remap_pfn = nr_pages; +while (i < n) {unsigned long cur_pfn = start_pfn + i;unsigned long left = n - i;
@@ -438,17 +441,29 @@ static unsigned long __init xen_set_idenreturn remap_pfn; } -static void __init xen_set_identity_and_remap (unsigned long nr_pages) +static unsigned long __init xen_count_remap_pages ( +unsigned long start_pfn,unsigned long end_pfn,unsigned long nr_pages, +unsigned long remap_pages) +{ +if (start_pfn >= nr_pages) +return remap_pages; + +return remap_pages +min (end_pfn, nr_pages) - start_pfn; +} + +static unsigned long __init xen_foreach_remap_area (unsigned long nr_pages, +unsigned long (*func)(unsigned long start_pfn,unsigned long end_pfn, +unsigned long nr_pages,unsigned long last_val)) {phys_addr_t start =0 ; -unsigned long last_pfn = nr_pages; +unsigned long ret_val =0 ;const struct e820entry *entry = xen_e820_map;int i;/* * Combine non-RAM regions and gaps until a RAM region (or the -* end of the map) is reached, then set the 1:1 map and -* remap the memory in those non-RAM regions. +* end of the map) is reached, then call the provided function +* to perform its duty on the non-RAM region. * * The combined non-RAM regions are rounded to a whole number * of pages so any partial pages are accessible via the 1:1
@@ -466,14 +481,13 @@ static void __init xen_set_identity_and_ end_pfn =PFN_UP (entry->addr);if (start_pfn < end_pfn) - last_pfn =xen_set_identity_and_remap_chunk ( - start_pfn, end_pfn, nr_pages, - last_pfn); + ret_val =func (start_pfn, end_pfn, nr_pages, + ret_val); start = end; } } -pr_info ("Released %ld page(s)\n" , xen_released_pages); +return ret_val; }/*
@@ -596,35 +610,6 @@ static void __init xen_ignore_unusable(v } } -static unsigned long __init xen_count_remap_pages (unsigned long max_pfn) -{ -unsigned long extra =0 ; -unsigned long start_pfn, end_pfn; -const struct e820entry *entry = xen_e820_map; -int i; - - end_pfn =0 ; -for (i =0 ; i < xen_e820_map_entries; i++, entry++) { - start_pfn =PFN_DOWN (entry->addr); -/* Adjacent regions on non-page boundaries handling! */ - end_pfn =min (end_pfn, start_pfn); - -if (start_pfn >= max_pfn) -return extra + max_pfn - end_pfn; - -/* Add any holes in map to result. */ - extra += start_pfn - end_pfn; - - end_pfn =PFN_UP (entry->addr + entry->size); - end_pfn =min (end_pfn, max_pfn); - -if (entry->type !=E820_RAM ) - extra += end_pfn - start_pfn; - } - -return extra; -} -bool __init xen_is_e820_reserved (phys_addr_t start,phys_addr_t size) {struct e820entry *entry;
@@ -804,7 +789,7 @@ char * __init xen_memory_setup(void) max_pages =xen_get_max_pages ();/* How many extra pages do we need due to remapping? */ - max_pages +=xen_count_remap_pages (max_pfn); + max_pages +=xen_foreach_remap_area (max_pfn, xen_count_remap_pages);if (max_pages > max_pfn) extra_pages += max_pages - max_pfn;
@@ -922,7 +907,9 @@ char * __init xen_memory_setup(void)* Set identity map on non-RAM pages and prepare remapping the * underlying RAM. */ -xen_set_identity_and_remap (max_pfn); +xen_foreach_remap_area (max_pfn, xen_set_identity_and_remap_chunk); + +pr_info ("Released %ld page(s)\n" , xen_released_pages);return "Xen" ; }
Greg Kroah-Hartman
maintainerPATCH 84/121 drm/gma500: Fix possible out of bounds read
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Itai Handler <[email protected]>
commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.
Fix possible out of bounds read, by adding missing comma. The code may read pass the end of the dsi_errors array when the most significant bit (bit #31) in the intr_stat register is set.
This bug has been detected using CppCheck (static analysis tool).
--- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c +1 -1
@@ -72,7 +72,7 @@ static const char *const dsi_errors[] ="RX Prot Violation" ,"HS Generic Write FIFO Full" ,"LP Generic Write FIFO Full" , -"Generic Read Data Avail" +"Generic Read Data Avail" ,"Special Packet Sent" , "Tearing Effect", };
Greg Kroah-Hartman
maintainerPATCH 85/121 drm/vmwgfx: Kill some lockdep warnings
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellstrom <[email protected]>
commit 93cd16817ae5ddcfc548784b51c76bf6d7923442 upstream.
Some global KMS state that is elsewhere protected by the mode_config mutex here needs to be protected with a local mutex. Remove corresponding lockdep checks and introduce a new driver-private global_kms_state_mutex, and make sure its locking order is *after* the crtc locks in order to avoid having to release those when the new mutex is taken.
--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 27 +++++++++++++-------------- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 3 +++ drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 3 +++ 5 files changed, 21 insertions(+), 14 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +1 -0
@@ -628,6 +628,7 @@ static int vmw_driver_load(struct drm_demutex_init (&dev_priv->cmdbuf_mutex);mutex_init (&dev_priv->release_mutex);mutex_init (&dev_priv->binding_mutex); +mutex_init (&dev_priv->global_kms_state_mutex);rwlock_init (&dev_priv->resource_lock);ttm_lock_init (&dev_priv->reservation_sem);spin_lock_init (&dev_priv->hw_lock);
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +1 -0
@@ -412,6 +412,7 @@ struct vmw_private {struct drm_property *implicit_placement_property;unsigned num_implicit;struct vmw_framebuffer *implicit_fb; +struct mutex global_kms_state_mutex;/* * Context and surface management.
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +13 -14
@@ -2143,13 +2143,13 @@ int vmw_kms_fbdev_init_data(struct vmw_pvoid vmw_kms_del_active (struct vmw_private *dev_priv,struct vmw_display_unit *du) { -lockdep_assert_held_once (&dev_priv->dev->mode_config.mutex); - +mutex_lock (&dev_priv->global_kms_state_mutex);if (du->active_implicit) {if (--(dev_priv->num_implicit) ==0 ) dev_priv->implicit_fb =NULL ; du->active_implicit = false; } +mutex_unlock (&dev_priv->global_kms_state_mutex); }/**
@@ -2165,8 +2165,7 @@ void vmw_kms_add_active(struct vmw_privastruct vmw_display_unit *du, struct vmw_framebuffer *vfb) { - lockdep_assert_held_once(&dev_priv->dev->mode_config.mutex); - + mutex_lock(&dev_priv->global_kms_state_mutex);WARN_ON_ONCE (!dev_priv->num_implicit && dev_priv->implicit_fb);if (!du->active_implicit && du->is_implicit) {
@@ -2174,6 +2173,7 @@ void vmw_kms_add_active(struct vmw_priva du->active_implicit = true; dev_priv->num_implicit++; } +mutex_unlock (&dev_priv->global_kms_state_mutex); }/**
@@ -2190,16 +2190,13 @@ bool vmw_kms_crtc_flippable(struct vmw_p struct drm_crtc *crtc) {struct vmw_display_unit *du =vmw_crtc_to_du (crtc); +bool ret; -lockdep_assert_held_once (&dev_priv->dev->mode_config.mutex); - -if (!du->is_implicit) -return true; - -if (dev_priv->num_implicit !=1 ) -return false; +mutex_lock (&dev_priv->global_kms_state_mutex); + ret = !du->is_implicit || dev_priv->num_implicit ==1 ; +mutex_unlock (&dev_priv->global_kms_state_mutex); -return true; +return ret; }/**
@@ -2214,16 +2211,18 @@ void vmw_kms_update_implicit_fb(struct vstruct vmw_display_unit *du =vmw_crtc_to_du (crtc);struct vmw_framebuffer *vfb; -lockdep_assert_held_once (&dev_priv->dev->mode_config.mutex); +mutex_lock (&dev_priv->global_kms_state_mutex);if (!du->is_implicit) -return ; + goto out_unlock; vfb =vmw_framebuffer_to_vfb (crtc->primary->fb);WARN_ON_ONCE (dev_priv->num_implicit !=1 && dev_priv->implicit_fb != vfb); dev_priv->implicit_fb = vfb; +out_unlock: +mutex_unlock (&dev_priv->global_kms_state_mutex); }/**
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +3 -0
@@ -285,14 +285,17 @@ static int vmw_sou_crtc_set_config(struc }/* Only one active implicit frame-buffer at a time. */ +mutex_lock (&dev_priv->global_kms_state_mutex);if (sou->base.is_implicit && dev_priv->implicit_fb && vfb && !(dev_priv->num_implicit ==1 && sou->base.active_implicit) && dev_priv->implicit_fb != vfb) { +mutex_unlock (&dev_priv->global_kms_state_mutex);DRM_ERROR ("Multiple implicit framebuffers not supported.\n" );return -EINVAL ; } +mutex_unlock (&dev_priv->global_kms_state_mutex);/* since they always map one to one these are safe */ connector = &sou->base.connector;
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +3 -0
@@ -553,12 +553,15 @@ static int vmw_stdu_crtc_set_config(stru }/* Only one active implicit frame-buffer at a time. */ +mutex_lock (&dev_priv->global_kms_state_mutex);if (!turning_off && stdu->base.is_implicit && dev_priv->implicit_fb && !(dev_priv->num_implicit ==1 && stdu->base.active_implicit) && dev_priv->implicit_fb != vfb) { +mutex_unlock (&dev_priv->global_kms_state_mutex);DRM_ERROR ("Multiple implicit framebuffers not supported.\n" );return -EINVAL ; } +mutex_unlock (&dev_priv->global_kms_state_mutex);/* Since they always map one to one these are safe */ connector = &stdu->base.connector;
Greg Kroah-Hartman
maintainerPATCH 86/121 drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 6b8812eb004ee2b24aac8b1a711a0e8e797df3ce upstream.
This is a port of radeon commit:3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284
drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh to amdgpu.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c +1 -1
@@ -150,7 +150,7 @@ u32 amdgpu_dpm_get_vrefresh(struct amdgplist_for_each_entry (crtc, &dev->mode_config.crtc_list, head) { amdgpu_crtc =to_amdgpu_crtc (crtc);if (crtc->enabled && amdgpu_crtc->enabled && amdgpu_crtc->hw_mode.clock) { - vrefresh = amdgpu_crtc->hw_mode.vrefresh; + vrefresh =drm_mode_vrefresh (&amdgpu_crtc->hw_mode);break ; } }
Greg Kroah-Hartman
maintainerPATCH 87/121 drm/amdgpu: Fix hdmi deep color support.
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Kleiner <[email protected]>
commit 9d746ab68163d642dae13756b2b3145b2e38cb65 upstream.
When porting the hdmi deep color detection code from radeon-kms to amdgpu-kms apparently some kind of copy and paste error happened, attaching an else branch to the wrong if statement.
The result is that hdmi deep color mode is always disabled, regardless of gpu and display capabilities and user wishes, as the code mistakenly thinks that the display doesn't provide the required max_tmds_clock limit and falls back to 8 bpc.
This patch fixes deep color support, as tested on a R9 380 Tonga Pro + suitable display, and should be backported to all kernels with amdgpu-kms support.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +5 -5
@@ -194,12 +194,12 @@ int amdgpu_connector_get_monitor_bpc(str bpc =8 ;DRM_DEBUG ("%s: HDMI deep color 10 bpc exceeds max tmds clock. Using %d bpc.\n" , connector->name, bpc); - }else if (bpc >8 ) { -/* max_tmds_clock missing, but hdmi spec mandates it for deep color. */ -DRM_DEBUG ("%s: Required max tmds clock for HDMI deep color missing. Using 8 bpc.\n" , - connector->name); - bpc =8 ; } + }else if (bpc >8 ) { +/* max_tmds_clock missing, but hdmi spec mandates it for deep color. */ +DRM_DEBUG ("%s: Required max tmds clock for HDMI deep color missing. Using 8 bpc.\n" , + connector->name); + bpc =8 ; } }
Greg Kroah-Hartman
maintainerPATCH 88/121 drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b upstream.
During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count since we only set it once in the code, however if we use num_connector from struct drm_mode_config we risk it's value changing under us. On top of that, there's even a chance that dev->mode_config.num_connector != fb_helper->connector_count. If the number of connectors happens to increase under us, we'll end up using the wrong array size for memcpy and start writing beyond the actual length of the array, occasionally resulting in kernel panics.
Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive.
--- drivers/gpu/drm/i915/intel_fbdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_fbdev.c +3 -3
@@ -366,12 +366,12 @@ static bool intel_fb_initial_config(struuint64_t conn_configured =0 , mask;int pass =0 ; - save_enabled =kcalloc (dev->mode_config.num_connector,sizeof (bool ), + save_enabled =kcalloc (fb_helper->connector_count,sizeof (bool ),GFP_KERNEL );if (!save_enabled)return false; -memcpy (save_enabled, enabled, dev->mode_config.num_connector); +memcpy (save_enabled, enabled, fb_helper->connector_count); mask = (1 << fb_helper->connector_count) -1 ; retry:for (i =0 ; i < fb_helper->connector_count; i++) {
@@ -510,7 +510,7 @@ retry:if (fallback) { bail:DRM_DEBUG_KMS ("Not using firmware configuration\n" ); -memcpy (enabled, save_enabled, dev->mode_config.num_connector); +memcpy (enabled, save_enabled, fb_helper->connector_count);kfree (save_enabled);return false; }
Greg Kroah-Hartman
maintainerPATCH 89/121 drm/fb_helper: Fix references to dev->mode_config.num_connector
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.
During boot, MST hotplugs are generally expected (even if no physical hotplugging occurs) and result in DRM's connector topology changing. This means that using num_connector from the current mode configuration can lead to the number of connectors changing under us. This can lead to some nasty scenarios in fbcon:
- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value of dev->mode_config.num_connectors, and end up going out of bounds since dev->mode_config.num_connectors is now larger then the array we allocated.
fb_helper->connector_count however, will always remain consistent while we do a modeset in fb_helper.
Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive.
[danvet: Clarify why we need this. Also remove the now unused "dev" local variable to appease gcc.]
--- drivers/gpu/drm/drm_fb_helper.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_fb_helper.c +2 -3
@@ -1895,7 +1895,6 @@ static int drm_pick_crtcs(struct drm_fb_ int n, int width, int height) { int c, o; -struct drm_device *dev = fb_helper->dev;struct drm_connector *connector;const struct drm_connector_helper_funcs *connector_funcs;struct drm_encoder *encoder;
@@ -1914,7 +1913,7 @@ static int drm_pick_crtcs(struct drm_fb_if (modes[n] ==NULL )return best_score; - crtcs =kzalloc (dev->mode_config.num_connector * + crtcs =kzalloc (fb_helper->connector_count *sizeof (struct drm_fb_helper_crtc *),GFP_KERNEL );if (!crtcs)return best_score;
@@ -1960,7 +1959,7 @@ static int drm_pick_crtcs(struct drm_fb_if (score > best_score) { best_score = score;memcpy (best_crtcs, crtcs, - dev->mode_config.num_connector * + fb_helper->connector_count *sizeof (struct drm_fb_helper_crtc *)); } }
Greg Kroah-Hartman
maintainerPATCH 90/121 drm/i915: Discard previous atomic state on resume if connectors change
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
If an MST device is disconnected while the machine is suspended, the number of connectors will change as well after we call intel_dp_mst_resume(). This means that any previous atomic state we had before suspending is no longer valid, since it'll still be pointing to missing connectors. We need to check for this before committing the state, otherwise we'll kernel panic on resume whenever if any MST display was disconnected before we started resuming:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffffa01588ef>] drm_atomic_helper_check_modeset+0x29f/0xb40 [drm_kms_helper] Call Trace: [<ffffffffa02354f4>] intel_atomic_check+0x34/0x1180 [i915] [<ffffffff810e6c3f>] ? mark_held_locks+0x6f/0xa0 [<ffffffff810e6d99>] ? trace_hardirqs_on_caller+0x129/0x1b0 [<ffffffffa00ff1d2>] drm_atomic_check_only+0x192/0x620 [drm] [<ffffffff813ee001>] ? pci_pm_thaw+0x21/0x90 [<ffffffffa00ff677>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa023e0ad>] intel_display_resume+0xbd/0x160 [i915] [<ffffffff813ee070>] ? pci_pm_thaw+0x90/0x90 [<ffffffffa01b60d8>] i915_drm_resume+0xd8/0x160 [i915] [<ffffffffa01b6185>] i915_pm_resume+0x25/0x30 [i915] [<ffffffff813ee0d4>] pci_pm_resume+0x64/0xa0 [<ffffffff814d9ea0>] dpm_run_callback+0x90/0x190 [<ffffffff814da455>] device_resume+0xd5/0x1f0 [<ffffffff814da58d>] async_resume+0x1d/0x50 [<ffffffff810b6718>] async_run_entry_fn+0x48/0x150 [<ffffffff810acc19>] process_one_work+0x1e9/0x5c0 [<ffffffff810acb96>] ? process_one_work+0x166/0x5c0 [<ffffffff810ad038>] worker_thread+0x48/0x4e0 [<ffffffff810acff0>] ? process_one_work+0x5c0/0x5c0 [<ffffffff810b3794>] kthread+0xe4/0x100 [<ffffffff81742672>] ret_from_fork+0x22/0x50 [<ffffffff810b36b0>] ? kthread_create_on_node+0x200/0x200
Changes since v1:
- Move drm_atomic_state_free() call down so we're holding the appropriate locks when destroying the atomic state
Changes since v2:
- Check that state != NULL before we start accessing it's members
This fix is only required for 4.6 and below. David Airlie's patchseries for 4.7 to add connector reference counting provides a more proper fix for this.
Upstream fix: 0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)")
--- drivers/gpu/drm/i915/intel_display.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/gpu/drm/i915/intel_display.c +12 -0
@@ -15958,6 +15958,18 @@ void intel_display_resume(struct drm_dev retry: ret =drm_modeset_lock_all_ctx (dev, &ctx); +/* +* With MST, the number of connectors can change between suspend and +* resume, which means that the state we want to restore might now be +* impossible to use since it'll be pointing to non-existant +* connectors. +*/ +if (ret ==0 && state && + state->num_connector != dev->mode_config.num_connector) { +drm_atomic_state_free (state); + state =NULL ; + } +if (ret ==0 && !setup) { setup = true;
Greg Kroah-Hartman
maintainerPATCH 91/121 drm/atomic: Verify connector->funcs != NULL when clearing states
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude <[email protected]>
Unfortunately since we don't have Dave's connector refcounting patch here yet, it's very possible that drm_atomic_state_default_clear() could get called by intel_display_resume() when intel_dp_mst_destroy_connector() isn't completely finished destroying an mst connector, but has already finished setting connector->funcs to NULL. As such, we need to treat the connector like it's already been destroyed and just skip it, otherwise we'll end up dereferencing a NULL pointer.
This fix is only required for 4.6 and below. David Airlie's patchseries for 4.7 to add connector reference counting provides a more proper fix for this.
Changes since v1:
- Fix leftover whitespace
Upstream fix: 0552f7651bc2 ("drm/i915/mst: use reference counted connectors. (v3)")
--- drivers/gpu/drm/drm_atomic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_atomic.c +1 -1
@@ -139,7 +139,7 @@ void drm_atomic_state_default_clear(strufor (i =0 ; i < state->num_connector; i++) {struct drm_connector *connector = state->connectors[i]; -if (!connector) +if (!connector || !connector->funcs)continue ;/*
Greg Kroah-Hartman
maintainerPATCH 92/121 Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Glenn Ruben Bakke <[email protected]>
commit 55441070ca1cbd47ce1ad2959bbf4b47aed9b83b upstream.
The memcpy of ipv6 header destination address to the skb control block (sbk->cb) in header_create() results in currupted memory when bt_xmit() is issued. The skb->cb is "released" in the return of header_create() making room for lower layer to minipulate the skb->cb.
The value retrieved in bt_xmit is not persistent across header creation and sending, and the lower layer will overwrite portions of skb->cb, making the copied destination address wrong.
The memory corruption will lead to non-working multicast as the first 4 bytes of the copied destination address is replaced by a value that resolves into a non-multicast prefix.
This fix removes the dependency on the skb control block between header creation and send, by moving the destination address memcpy to the send function path (setup_create, which is called from bt_xmit).
--- net/bluetooth/6lowpan.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
net/bluetooth/6lowpan.c +4 -7
@@ -431,15 +431,18 @@ static int setup_header(struct sk_buff * bdaddr_t *peer_addr, u8 *peer_addr_type) {struct in6_addr ipv6_daddr; +struct ipv6hdr *hdr;struct lowpan_dev *dev;struct lowpan_peer *peer;bdaddr_t addr, *any =BDADDR_ANY ;u8 *daddr = any->b;int err, status =0 ; + hdr =ipv6_hdr (skb); + dev =lowpan_dev (netdev); -memcpy (&ipv6_daddr, &lowpan_cb (skb)->addr,sizeof (ipv6_daddr)); +memcpy (&ipv6_daddr, &hdr->daddr,sizeof (ipv6_daddr));if (ipv6_addr_is_multicast (&ipv6_daddr)) {lowpan_cb (skb)->chan =NULL ;
@@ -489,15 +492,9 @@ static int header_create(struct sk_buff unsigned short type, const void *_daddr, const void *_saddr, unsigned int len) { - struct ipv6hdr *hdr; - if (type != ETH_P_IPV6) return -EINVAL; - hdr =ipv6_hdr (skb); - -memcpy (&lowpan_cb (skb)->addr, &hdr->daddr,sizeof (struct in6_addr )); -return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 101/121 ext4: fix data exposure after a crash
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 06bd3c36a733ac27962fea7d6f47168841376824 upstream.
Huang has reported that in his powerfail testing he is seeing stale block contents in some of recently allocated blocks although he mounts ext4 in data=ordered mode. After some investigation I have found out that indeed when delayed allocation is used, we don't add inode to transaction's list of inodes needing flushing before commit. Originally we were doing that but commit f3b59291a69d removed the logic with a flawed argument that it is not needed.
The problem is that although for delayed allocated blocks we write their contents immediately after allocating them, there is no guarantee that the IO scheduler or device doesn't reorder things and thus transaction allocating blocks and attaching them to inode can reach stable storage before actual block contents. Actually whenever we attach freshly allocated blocks to inode using a written extent, we should add inode to transaction's ordered inode list to make sure we properly wait for block contents to be written before committing the transaction. So that is what we do in this patch. This also handles other cases where stale data exposure was possible - like filling hole via mmap in data=ordered,nodelalloc mode.
The only exception to the above rule are extending direct IO writes where blkdev_direct_IO() waits for IO to complete before increasing i_size and thus stale data exposure is not possible. For now we don't complicate the code with optimizing this special case since the overhead is pretty low. In case this is observed to be a performance problem we can always handle it using a special flag to ext4_map_blocks().
--- fs/ext4/inode.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-)
fs/ext4/inode.c +15 -9
@@ -684,6 +684,21 @@ out_sem: ret =check_block_validity (inode, map);if (ret !=0 )return ret; + +/* +* Inodes with freshly allocated blocks where contents will be +* visible after transaction commit must be on transaction's +* ordered data list. +*/ +if (map->m_flags &EXT4_MAP_NEW && + !(map->m_flags &EXT4_MAP_UNWRITTEN ) && + !(flags &EXT4_GET_BLOCKS_ZERO ) && + !IS_NOQUOTA (inode) && +ext4_should_order_data (inode)) { + ret =ext4_jbd2_file_inode (handle, inode); +if (ret) +return ret; + } }return retval; }
@@ -1289,15 +1304,6 @@ static int ext4_write_end(struct file *fint i_size_changed =0 ;trace_ext4_write_end (inode, pos, len, copied); -if (ext4_test_inode_state (inode,EXT4_STATE_ORDERED_MODE )) { - ret =ext4_jbd2_file_inode (handle, inode); -if (ret) { -unlock_page (page); -put_page (page); - goto errout; - } - } -if (ext4_has_inline_data (inode)) { ret =ext4_write_inline_data_end (inode, pos, len, copied, page);
Greg Kroah-Hartman
maintainerPATCH 102/121 ext4: fix hang when processing corrupted orphaned inode list
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit c9eb13a9105e2e418f72e46a2b6da3f49e696902 upstream.
If the orphaned inode list contains inode #5, ext4_iget() returns a bad inode (since the bootloader inode should never be referenced directly). Because of the bad inode, we end up processing the inode repeatedly and this hangs the machine.
This can be reproduced via:
mke2fs -t ext4 /tmp/foo.img 100
debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
mount -o loop /tmp/foo.img /mnt
(But don't do this if you are using an unpatched kernel if you care about the system staying functional. :-)
This bug was found by the port of American Fuzzy Lop into the kernel to find file system problems[1]. (Since it *only* happens if inode #5 shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not surprising that AFL needed two hours before it found it.)
Reported by: Vegard Nossum <[email protected]>
--- fs/ext4/ialloc.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
fs/ext4/ialloc.c +6 -4
@@ -1183,11 +1183,13 @@ struct inode *ext4_orphan_get(struct sup goto iget_failed;/* -* If the orphans has i_nlinks > 0 then it should be able to be -* truncated, otherwise it won't be removed from the orphan list -* during processing and an infinite loop will result. +* If the orphans has i_nlinks > 0 then it should be able to +* be truncated, otherwise it won't be removed from the orphan +* list during processing and an infinite loop will result. +* Similarly, it must not be a bad inode. */ -if (inode->i_nlink && !ext4_can_truncate (inode)) +if ((inode->i_nlink && !ext4_can_truncate (inode)) || +is_bad_inode (inode)) goto bad_orphan;if (NEXT_ORPHAN (inode) > max_ino)
Greg Kroah-Hartman
maintainerPATCH 103/121 ext4: clean up error handling when orphan list is corrupted
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 7827a7f6ebfcb7f388dc47fddd48567a314701ba upstream.
Instead of just printing warning messages, if the orphan list is corrupted, declare the file system is corrupted. If there are any reserved inodes in the orphaned inode list, declare the file system corrupted and stop right away to avoid doing more potential damage to the file system.
--- fs/ext4/ialloc.c | 49 ++++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 27 deletions(-)
fs/ext4/ialloc.c +22 -27
@@ -1150,25 +1150,20 @@ struct inode *ext4_orphan_get(struct supunsigned long max_ino =le32_to_cpu (EXT4_SB (sb)->s_es->s_inodes_count);ext4_group_t block_group;int bit; -struct buffer_head *bitmap_bh; +struct buffer_head *bitmap_bh =NULL ;struct inode *inode =NULL ; -long err = -EIO ; +int err = -EFSCORRUPTED ; -/* Error cases - e2fsck has already cleaned up for us */ -if (ino > max_ino) { -ext4_warning (sb,"bad orphan ino %lu! e2fsck was run?" , ino); - err = -EFSCORRUPTED ; - goto error; - } +if (ino <EXT4_FIRST_INO (sb) || ino > max_ino) + goto bad_orphan; block_group = (ino -1 ) /EXT4_INODES_PER_GROUP (sb); bit = (ino -1 ) %EXT4_INODES_PER_GROUP (sb); bitmap_bh =ext4_read_inode_bitmap (sb, block_group);if (IS_ERR (bitmap_bh)) { - err =PTR_ERR (bitmap_bh); -ext4_warning (sb,"inode bitmap error %ld for orphan %lu" , - ino, err); - goto error; +ext4_error (sb,"inode bitmap error %ld for orphan %lu" , + ino,PTR_ERR (bitmap_bh)); +return (struct inode *) bitmap_bh; }/* Having the inode bit set should be a 100% indicator that this
@@ -1179,8 +1174,12 @@ struct inode *ext4_orphan_get(struct sup goto bad_orphan; inode =ext4_iget (sb, ino); -if (IS_ERR (inode)) - goto iget_failed; +if (IS_ERR (inode)) { + err =PTR_ERR (inode); +ext4_error (sb,"couldn't read orphan inode %lu (err %d)" , + ino, err); +return inode; + }/* * If the orphans has i_nlinks > 0 then it should be able to
@@ -1197,29 +1196,25 @@ struct inode *ext4_orphan_get(struct supbrelse (bitmap_bh);return inode; -iget_failed: - err =PTR_ERR (inode); - inode =NULL ; bad_orphan: -ext4_warning (sb,"bad orphan inode %lu! e2fsck was run?" , ino); -printk (KERN_WARNING "ext4_test_bit(bit=%d, block=%llu) = %d\n" , - bit, (unsigned long long )bitmap_bh->b_blocknr, -ext4_test_bit (bit, bitmap_bh->b_data)); -printk (KERN_WARNING "inode=%p\n" , inode); +ext4_error (sb,"bad orphan inode %lu" , ino); +if (bitmap_bh) +printk (KERN_ERR "ext4_test_bit(bit=%d, block=%llu) = %d\n" , + bit, (unsigned long long )bitmap_bh->b_blocknr, +ext4_test_bit (bit, bitmap_bh->b_data));if (inode) { -printk (KERN_WARNING "is_bad_inode(inode)=%d\n" , +printk (KERN_ERR "is_bad_inode(inode)=%d\n" ,is_bad_inode (inode)); -printk (KERN_WARNING "NEXT_ORPHAN(inode)=%u\n" , +printk (KERN_ERR "NEXT_ORPHAN(inode)=%u\n" ,NEXT_ORPHAN (inode)); -printk (KERN_WARNING "max_ino=%lu\n" , max_ino); -printk (KERN_WARNING "i_nlink=%u\n" , inode->i_nlink); +printk (KERN_ERR "max_ino=%lu\n" , max_ino); +printk (KERN_ERR "i_nlink=%u\n" , inode->i_nlink);/* Avoid freeing blocks if we got a bad deleted inode */ if (inode->i_nlink ==0 ) inode->i_blocks =0 ;iput (inode); }brelse (bitmap_bh); -error:return ERR_PTR (err); }
Greg Kroah-Hartman
maintainerPATCH 104/121 ext4: fix check of dqget() return value in ext4_ioctl_setproject()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Seth Forshee <[email protected]>
commit ff0bc08454917964291f72ee5b8eca66de4bc250 upstream.
A failed call to dqget() returns an ERR_PTR() and not null. Fix the check in ext4_ioctl_setproject() to handle this correctly.
--- fs/ext4/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/ioctl.c +1 -1
@@ -365,7 +365,7 @@ static int ext4_ioctl_setproject(structstruct dquot *transfer_to[MAXQUOTAS ] = { }; transfer_to[PRJQUOTA ] =dqget (sb,make_kqid_projid (kprojid)); -if (transfer_to[PRJQUOTA ]) { +if (!IS_ERR (transfer_to[PRJQUOTA ])) { err =__dquot_transfer (inode, transfer_to);dqput (transfer_to[PRJQUOTA ]);if (err)
Greg Kroah-Hartman
maintainerPATCH 105/121 ext4: fix oops on corrupted filesystem
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 74177f55b70e2f2be770dd28684dd6d17106a4ba upstream.
When filesystem is corrupted in the right way, it can happen ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we subsequently remove inode from the in-memory orphan list. However this deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we leave i_orphan list_head with a stale content. Later we can look at this content causing list corruption, oops, or other issues. The reported trace looked like:
WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100() list_del corruption, 0000000061c1d6e0->next is LIST_POISON1 0000000000100100) CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250 Stack: 60462947 62219960 602ede24 62219960 602ede24 603ca293 622198f0 602f02eb 62219950 6002c12c 62219900 601b4d6b Call Trace: [<6005769c>] ? vprintk_emit+0x2dc/0x5c0 [<602ede24>] ? printk+0x0/0x94 [<600190bc>] show_stack+0xdc/0x1a0 [<602ede24>] ? printk+0x0/0x94 [<602ede24>] ? printk+0x0/0x94 [<602f02eb>] dump_stack+0x2a/0x2c [<6002c12c>] warn_slowpath_common+0x9c/0xf0 [<601b4d6b>] ? __list_del_entry+0x6b/0x100 [<6002c254>] warn_slowpath_fmt+0x94/0xa0 [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0 [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0 [<60023ebf>] ? set_signals+0x3f/0x50 [<600a205a>] ? kmem_cache_free+0x10a/0x180 [<602f4e88>] ? mutex_lock+0x18/0x30 [<601b4d6b>] __list_del_entry+0x6b/0x100 [<601177ec>] ext4_orphan_del+0x22c/0x2f0 [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0 [<6010b973>] ? ext4_truncate+0x383/0x390 [<6010bc8b>] ext4_write_begin+0x30b/0x4b0 [<6001bb50>] ? copy_from_user+0x0/0xb0 [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0 [<60072c4f>] generic_perform_write+0xaf/0x1e0 [<600c4166>] ? file_update_time+0x46/0x110 [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0 [<6010030f>] ext4_file_write_iter+0x15f/0x470 [<60094e10>] ? unlink_file_vma+0x0/0x70 [<6009b180>] ? unlink_anon_vmas+0x0/0x260 [<6008f169>] ? free_pgtables+0xb9/0x100 [<600a6030>] __vfs_write+0xb0/0x130 [<600a61d5>] vfs_write+0xa5/0x170 [<600a63d6>] SyS_write+0x56/0xe0 [<6029fcb0>] ? __libc_waitpid+0x0/0xa0 [<6001b698>] handle_syscall+0x68/0x90 [<6002633d>] userspace+0x4fd/0x600 [<6002274f>] ? save_registers+0x1f/0x40 [<60028bd7>] ? arch_prctl+0x177/0x1b0 [<60017bd5>] fork_handler+0x85/0x90
Fix the problem by using list_del_init() as we always should with i_orphan list.
--- fs/ext4/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/namei.c +1 -1
@@ -2828,7 +2828,7 @@ int ext4_orphan_add(handle_t *handle, st* list entries can cause panics at unmount time. */ mutex_lock (&sbi->s_orphan_lock); -list_del (&EXT4_I (inode)->i_orphan); +list_del_init (&EXT4_I (inode)->i_orphan);mutex_unlock (&sbi->s_orphan_lock); } }
Greg Kroah-Hartman
maintainerPATCH 106/121 ext4: address UBSAN warning in mb_find_order_for_block()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolai Stange <[email protected]>
commit b5cb316cdf3a3f5f6125412b0f6065185240cfdc upstream.
Currently, in mb_find_order_for_block(), there's a loop like the following:
while (order <= e4b->bd_blkbits + 1) {
...
bb += 1 << (e4b->bd_blkbits - order);
}Note that the updated bb is used in the loop's next iteration only.
However, at the last iteration, that is at order == e4b->bd_blkbits + 1, the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11 shift exponent -1 is negative [...] Call Trace: [<ffffffff818c4d35>] dump_stack+0xbc/0x117 [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169 [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158 [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590 [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80 [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240 [...]
Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of bb is never used again.
Silence UBSAN by introducing another variable, bb_incr, holding the next increment to apply to bb and adjust that one by right shifting it by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
--- fs/ext4/mballoc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/ext4/mballoc.c +3 -1
@@ -1266,6 +1266,7 @@ static void ext4_mb_unload_buddy(structstatic int mb_find_order_for_block (struct ext4_buddy *e4b,int block) {int order =1 ; +int bb_incr =1 << (e4b->bd_blkbits -1 );void *bb;BUG_ON (e4b->bd_bitmap == e4b->bd_buddy);
@@ -1278,7 +1279,8 @@ static int mb_find_order_for_block(struc/* this block is part of buddy of order 'order' */ return order; } - bb +=1 << (e4b->bd_blkbits - order); + bb += bb_incr; + bb_incr >>=1 ; order++; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 107/121 ext4: silence UBSAN in ext4_mb_init()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolai Stange <[email protected]>
commit 935244cd54b86ca46e69bc6604d2adfb1aec2d42 upstream.
Currently, in ext4_mb_init(), there's a loop like the following:
do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
} while (i <= sb->s_blocksize_bits + 1);Note that the updated offset is used in the loop's next iteration only.
However, at the last iteration, that is at i == sb->s_blocksize_bits + 1, the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3)) and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15 shift exponent 4294967295 is too large for 32-bit type 'int' [...] Call Trace: [<ffffffff818c4d25>] dump_stack+0xbc/0x117 [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169 [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158 [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390 [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0 [<ffffffff814293c7>] ? create_cache+0x57/0x1f0 [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0 [<ffffffff821c2168>] ? mutex_lock+0x38/0x60 [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50 [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0 [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0 [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0 [...]
Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of offset is never used again.
Silence UBSAN by introducing another variable, offset_incr, holding the next increment to apply to offset and adjust that one by right shifting it by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
--- fs/ext4/mballoc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/ext4/mballoc.c +4 -2
@@ -2585,7 +2585,7 @@ int ext4_mb_init(struct super_block *sb) {struct ext4_sb_info *sbi =EXT4_SB (sb);unsigned i, j; -unsigned offset; +unsigned offset, offset_incr;unsigned max;int ret;
@@ -2614,11 +2614,13 @@ int ext4_mb_init(struct super_block *sb) i =1 ; offset =0 ; + offset_incr =1 << (sb->s_blocksize_bits -1 ); max = sb->s_blocksize <<2 ;do { sbi->s_mb_offsets[i] = offset; sbi->s_mb_maxs[i] = max; - offset +=1 << (sb->s_blocksize_bits - i); + offset += offset_incr; + offset_incr = offset_incr >>1 ; max = max >>1 ; i++; }while (i <= sb->s_blocksize_bits +1 );
Greg Kroah-Hartman
maintainerPATCH 108/121 nfs: avoid race that crashes nfs_init_commit
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Weston Andros Adamson <[email protected]>
commit ade8febde0271513360bac44883dbebad44276c3 upstream.
Since the patch "NFS: Allow multiple commit requests in flight per file" we can run multiple simultaneous commits on the same inode. This introduced a race over collecting pages to commit that made it possible to call nfs_init_commit() with an empty list - which causes crashes like the one below.
The fix is to catch this race and avoid calling nfs_init_commit and initiate_commit when there is no work to do.
Here is the crash:
[600522.076832] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [600522.078475] IP: [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.078745] PGD 4272b1067 PUD 4272cb067 PMD 0 [600522.078972] Oops: 0000 [#1] SMP [600522.079204] Modules linked in: nfsv3 nfs_layout_flexfiles rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache dcdbas ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vmw_vsock_vmci_transport vsock bonding ipmi_devintf ipmi_msghandler coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev vmw_balloon parport_pc parport acpi_cpufreq vmw_vmci i2c_piix4 shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmxnet3 [600522.081380] vmw_pvscsi ata_generic pata_acpi [600522.081809] CPU: 3 PID: 15667 Comm: /usr/bin/python Not tainted 4.1.9-100.pd.88.el7.x86_64 #1 [600522.082281] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [600522.082814] task: ffff8800bbbfa780 ti: ffff88042ae84000 task.ti: ffff88042ae84000 [600522.083378] RIP: 0010:[<ffffffffa0479e72>] [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.083973] RSP: 0018:ffff88042ae87438 EFLAGS: 00010246 [600522.084571] RAX: 0000000000000000 RBX: ffff880003485e40 RCX: ffff88042ae87588 [600522.085188] RDX: 0000000000000000 RSI: ffff88042ae874b0 RDI: ffff880003485e40 [600522.085756] RBP: ffff88042ae87448 R08: ffff880003486010 R09: ffff88042ae874b0 [600522.086332] R10: 0000000000000000 R11: 0000000000000005 R12: ffff88042ae872d0 [600522.086905] R13: ffff88042ae874b0 R14: ffff880003485e40 R15: ffff88042704c840 [600522.087484] FS: 00007f4728ff2740(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [600522.088070] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [600522.088663] CR2: 0000000000000040 CR3: 000000042b6aa000 CR4: 00000000001406e0 [600522.089327] Stack: [600522.089926] 0000000000000001 ffff88042ae87588 ffff88042ae874f8 ffffffffa04f09fa [600522.090549] 0000000000017840 0000000000017840 ffff88042ae87588 ffff8803258d9930 [600522.091169] ffff88042ae87578 ffffffffa0563d80 0000000000000000 ffff88042704c840 [600522.091789] Call Trace: [600522.092420] [<ffffffffa04f09fa>] pnfs_generic_commit_pagelist+0x1da/0x320 [nfsv4] [600522.093052] [<ffffffffa0563d80>] ? ff_layout_commit_prepare_v3+0x30/0x30 [nfs_layout_flexfiles] [600522.093696] [<ffffffffa0562645>] ff_layout_commit_pagelist+0x15/0x20 [nfs_layout_flexfiles] [600522.094359] [<ffffffffa047bc78>] nfs_generic_commit_list+0xe8/0x120 [nfs] [600522.095032] [<ffffffffa047bd6a>] nfs_commit_inode+0xba/0x110 [nfs] [600522.095719] [<ffffffffa046ac54>] nfs_release_page+0x44/0xd0 [nfs] [600522.096410] [<ffffffff811a8122>] try_to_release_page+0x32/0x50 [600522.097109] [<ffffffff811bd4f1>] shrink_page_list+0x961/0xb30 [600522.097812] [<ffffffff811bdced>] shrink_inactive_list+0x1cd/0x550 [600522.098530] [<ffffffff811bea65>] shrink_lruvec+0x635/0x840 [600522.099250] [<ffffffff811bed60>] shrink_zone+0xf0/0x2f0 [600522.099974] [<ffffffff811bf312>] do_try_to_free_pages+0x192/0x470 [600522.100709] [<ffffffff811bf6ca>] try_to_free_pages+0xda/0x170 [600522.101464] [<ffffffff811b2198>] __alloc_pages_nodemask+0x588/0x970 [600522.102235] [<ffffffff811fbbd5>] alloc_pages_vma+0xb5/0x230 [600522.103000] [<ffffffff813a1589>] ? cpumask_any_but+0x39/0x50 [600522.103774] [<ffffffff811d6115>] wp_page_copy.isra.55+0x95/0x490 [600522.104558] [<ffffffff810e3438>] ? __wake_up+0x48/0x60 [600522.105357] [<ffffffff811d7d3b>] do_wp_page+0xab/0x4f0 [600522.106137] [<ffffffff810a1bbb>] ? release_task+0x36b/0x470 [600522.106902] [<ffffffff8126dbd7>] ? eventfd_ctx_read+0x67/0x1c0 [600522.107659] [<ffffffff811da2a8>] handle_mm_fault+0xc78/0x1900 [600522.108431] [<ffffffff81067ef1>] __do_page_fault+0x181/0x420 [600522.109173] [<ffffffff811446a6>] ? __audit_syscall_exit+0x1e6/0x280 [600522.109893] [<ffffffff810681c0>] do_page_fault+0x30/0x80 [600522.110594] [<ffffffff81024f36>] ? syscall_trace_leave+0xc6/0x120 [600522.111288] [<ffffffff81790a58>] page_fault+0x28/0x30 [600522.111947] Code: 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 4c 8d 87 d0 01 00 00 48 89 e5 53 48 89 fb 48 83 ec 08 4c 8b 0e 49 8b 41 18 4c 39 ce <48> 8b 40 40 4c 8b 50 30 74 24 48 8b 87 d0 01 00 00 48 8b 7e 08 [600522.113343] RIP [<ffffffffa0479e72>] nfs_init_commit+0x22/0x130 [nfs] [600522.114003] RSP <ffff88042ae87438> [600522.114636] CR2: 0000000000000040
--- fs/nfs/pnfs_nfs.c | 28 ++++++++++++++++++++++++++++ fs/nfs/write.c | 4 ++++ 2 files changed, 32 insertions(+)
fs/nfs/pnfs_nfs.c +28 -0
@@ -246,6 +246,23 @@ void pnfs_fetch_commit_bucket_list(struc } +/* Helper function for pnfs_generic_commit_pagelist to catch an empty +* page list. This can happen when two commits race. */ +static bool +pnfs_generic_commit_cancel_empty_pagelist (struct list_head *pages, +struct nfs_commit_data *data, +struct nfs_commit_info *cinfo) +{ +if (list_empty (pages)) { +if (atomic_dec_and_test (&cinfo->mds->rpcs_out)) +wake_up_atomic_t (&cinfo->mds->rpcs_out); +nfs_commitdata_release (data); +return true; + } + +return false; +} +/* This follows nfs_commit_list pretty closely */ int pnfs_generic_commit_pagelist(struct inode *inode, struct list_head *mds_pages,
@@ -280,6 +297,11 @@ pnfs_generic_commit_pagelist(struct inodlist_for_each_entry_safe (data, tmp, &list, pages) {list_del_init (&data->pages);if (data->ds_commit_index <0 ) { +/* another commit raced with us */ +if (pnfs_generic_commit_cancel_empty_pagelist (mds_pages, + data, cinfo)) +continue ; +nfs_init_commit (data, mds_pages,NULL , cinfo); nfs_initiate_commit(NFS_CLIENT(inode), data, NFS_PROTO(data->inode),
@@ -288,6 +310,12 @@ pnfs_generic_commit_pagelist(struct inodLIST_HEAD (pages);pnfs_fetch_commit_bucket_list (&pages, data, cinfo); + +/* another commit raced with us */ +if (pnfs_generic_commit_cancel_empty_pagelist (&pages, + data, cinfo)) +continue ; +nfs_init_commit (data, &pages, data->lseg, cinfo);initiate_commit (data, how); }
fs/nfs/write.c +4 -0
@@ -1709,6 +1709,10 @@ nfs_commit_list(struct inode *inode, str {struct nfs_commit_data *data; +/* another commit raced with us */ +if (list_empty (head)) +return 0 ; + data =nfs_commitdata_alloc ();if (!data)
Greg Kroah-Hartman
maintainerPATCH 109/121 PM / sleep: Handle failures in device_suspend_late() consistently
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.
Grygorii Strashko reports:
The PM runtime will be left disabled for the device if its .suspend_late() callback fails and async suspend is not allowed for this device. In this case device will not be added in dpm_late_early_list and dpm_resume_early() will ignore this device, as result PM runtime will be disabled for it forever (side effect: after 8 subsequent failures for the same device the PM runtime will be reenabled due to disable_depth overflow).
To fix this problem, add devices to dpm_late_early_list regardless of whether or not device_suspend_late() returns errors for them.
That will ensure failures in there to be handled consistently for all devices regardless of their async suspend/resume status.
--- drivers/base/power/main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/base/power/main.c +3 -2
@@ -1267,14 +1267,15 @@ int dpm_suspend_late(pm_message_t state) error =device_suspend_late (dev);mutex_lock (&dpm_list_mtx); +if (!list_empty (&dev->power.entry)) +list_move (&dev->power.entry, &dpm_late_early_list); +if (error) {pm_dev_err (dev, state," late" , error);dpm_save_failed_dev (dev_name (dev));put_device (dev);break ; } -if (!list_empty (&dev->power.entry)) -list_move (&dev->power.entry, &dpm_late_early_list);put_device (dev);if (async_error)
Greg Kroah-Hartman
maintainerPATCH 111/121 scripts/package/Makefile: rpmbuild add support of RPMOPTS
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Pandruvada <[email protected]>
commit 65a9f31c5042e5bb50d30ed8ae374044be561054 upstream.
After commit 21a59991ce0c ("scripts/package/Makefile: rpmbuild is needed for rpm targets"), it is no longer possible to specify RPMOPTS. For example, we can no longer able to control _topdir using the following make command.
make RPMOPTS="--define '_topdir /home/xyz/workspace/'" binrpm-pkg
--- scripts/package/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
scripts/package/Makefile +2 -2
@@ -52,7 +52,7 @@ rpm-pkg rpm: FORCE $(call cmd,src_tar,$(KERNELPATH),kernel.spec) $(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version mv -f $(objtree)/.tmp_version $(objtree)/.version - rpmbuild --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz + rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz rm $(KERNELPATH).tar.gz kernel.spec # binrpm-pkg
@@ -63,7 +63,7 @@ binrpm-pkg: FORCE $(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version mv -f $(objtree)/.tmp_version $(objtree)/.version - rpmbuild --define "_builddir $(objtree)" --target \ + rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \ $(UTS_MACHINE) -bb $(objtree)/binkernel.spec rm binkernel.spec
Greg Kroah-Hartman
maintainerPATCH 112/121 mm: thp: avoid false positive VM_BUG_ON_PAGE in page_move_anon_rmap()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill A. Shutemov <[email protected]>
commit 0798d3c022dc63eb0ec02b511e1f76ca8411ef8e upstream.
If page_move_anon_rmap() is refiling a pmd-splitted THP mapped in a tail page from a pte, the "address" must be THP aligned in order for the page->index bugcheck to pass in the CONFIG_DEBUG_VM=y builds.
--- mm/rmap.c | 2 ++ 1 file changed, 2 insertions(+)
mm/rmap.c +2 -0
@@ -1098,6 +1098,8 @@ void page_move_anon_rmap(struct page *paVM_BUG_ON_PAGE (!PageLocked (page), page);VM_BUG_ON_VMA (!anon_vma, vma); +if (IS_ENABLED (CONFIG_DEBUG_VM ) &&PageTransHuge (page)) + address &=HPAGE_PMD_MASK ;VM_BUG_ON_PAGE (page->index !=linear_page_index (vma, address), page); anon_vma = (void *) anon_vma +PAGE_MAPPING_ANON ;
Greg Kroah-Hartman
maintainerPATCH 113/121 gcov: disable tree-loop-im to reduce stack usage
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit c87bf431448b404a6ef5fbabd74c0e3e42157a7f upstream.
Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
After some investigation, I found that this behavior started with gcc-4.9, and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
A suggested workaround for it is to use the -fno-tree-loop-im flag that turns off one of the optimization stages in gcc, so the code runs a little slower but does not use excessive amounts of stack.
We could make this conditional on the gcc version, but I could not find an easy way to do this in Kbuild and the benefit would be fairly small, given that most of the gcc version in production are affected now.
I'm marking this for 'stable' backports because it addresses a bug with code generation in gcc that exists in all kernel versions with the affected gcc releases.
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Makefile +1 -1
@@ -364,7 +364,7 @@ AFLAGS_MODULE = LDFLAGS_MODULE = CFLAGS_KERNEL = AFLAGS_KERNEL = -CFLAGS_GCOV = -fprofile-arcs -ftest-coverage +CFLAGS_GCOV = -fprofile-arcs -ftest-coverage -fno-tree-loop-im CFLAGS_KCOV = -fsanitize-coverage=trace-pc
Greg Kroah-Hartman
maintainerPATCH 114/121 xfs: disallow rw remount on fs with unknown ro-compat features
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Sandeen <[email protected]>
commit d0a58e833931234c44e515b5b8bede32bd4e6eed upstream.
Today, a kernel which refuses to mount a filesystem read-write due to unknown ro-compat features can still transition to read-write via the remount path. The old kernel is most likely none the wiser, because it's unaware of the new feature, and isn't using it. However, writing to the filesystem may well corrupt metadata related to that new feature, and moving to a newer kernel which understand the feature will have problems.
Right now the only ro-compat feature we have is the free inode btree, which showed up in v3.16. It would be good to push this back to all the active stable kernels, I think, so that if anyone is using newer mkfs (which enables the finobt feature) with older kernel releases, they'll be protected.
--- fs/xfs/xfs_super.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
fs/xfs/xfs_super.c +10 -0
@@ -1276,6 +1276,16 @@ xfs_fs_remount(return -EINVAL ; } +if (XFS_SB_VERSION_NUM (sbp) ==XFS_SB_VERSION_5 && +xfs_sb_has_ro_compat_feature (sbp, +XFS_SB_FEAT_RO_COMPAT_UNKNOWN )) { +xfs_warn (mp, +"ro->rw transition prohibited on unknown (0x%x) ro-compat filesystem" , + (sbp->sb_features_ro_compat & +XFS_SB_FEAT_RO_COMPAT_UNKNOWN )); +return -EINVAL ; + } + mp->m_flags &= ~XFS_MOUNT_RDONLY ;/*
Greg Kroah-Hartman
maintainerPATCH 115/121 xfs: Dont wrap growfs AGFL indexes
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit ad747e3b299671e1a53db74963cc6c5f6cdb9f6d upstream.
Commit 96f859d ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") allowed the freelist to use the empty slot at the end of the freelist on 64 bit systems that was not being used due to sizeof() rounding up the structure size.
This has caused versions of xfs_repair prior to 4.5.0 (which also has the fix) to report this as a corruption once the filesystem has been grown. Older kernels can also have problems (seen from a whacky container/vm management environment) mounting filesystems grown on a system with a newer kernel than the vm/container it is deployed on.
To avoid this problem, change the initial free list indexes not to wrap across the end of the AGFL, hence avoiding the initialisation of agf_fllast to the last index in the AGFL.
--- fs/xfs/xfs_fsops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/xfs/xfs_fsops.c +2 -2
@@ -243,8 +243,8 @@ xfs_growfs_data_private( agf->agf_roots[XFS_BTNUM_CNTi] =cpu_to_be32 (XFS_CNT_BLOCK (mp)); agf->agf_levels[XFS_BTNUM_BNOi] =cpu_to_be32 (1 ); agf->agf_levels[XFS_BTNUM_CNTi] =cpu_to_be32 (1 ); - agf->agf_flfirst =0 ; - agf->agf_fllast =cpu_to_be32 (XFS_AGFL_SIZE (mp) -1 ); + agf->agf_flfirst =cpu_to_be32 (1 ); + agf->agf_fllast =0 ; agf->agf_flcount =0 ; tmpsize = agsize -XFS_PREALLOC_BLOCKS (mp); agf->agf_freeblks =cpu_to_be32 (tmpsize);
Greg Kroah-Hartman
maintainerPATCH 116/121 xfs: remove xfs_fs_evict_inode()
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit 8179c03629de67f515d3ab825b5a9428687d4b85 upstream.
Joe Lawrence reported a list_add corruption with 4.6-rc1 when testing some custom md administration code that made it's own block device nodes for the md array. The simple test loop of:
for i in {0..100}; do
mknod --mode=0600 $tmp/tmp_node b $MAJOR $MINOR mdadm --detail --export $tmp/tmp_node > /dev/null rm -f $tmp/tmp_node
done
Would produce this warning in bd_acquire() when mdadm opened the device node:
list_add double add: new=ffff88043831c7b8, prev=ffff8804380287d8, next=ffff88043831c7b8.
And then produce this from bd_forget from kdevtmpfs evicting a block dev inode:
list_del corruption. prev->next should be ffff8800bb83eb10, but was ffff88043831c7b8
This is a regression caused by commit c19b3b05 ("xfs: mode di_mode to vfs inode"). The issue is that xfs_inactive() frees the unlinked inode, and the above commit meant that this freeing zeroed the mode in the struct inode. The problem is that after evict() has called ->evict_inode, it expects the i_mode to be intact so that it can call bd_forget() or cd_forget() to drop the reference to the block device inode attached to the XFS inode.
In reality, the only thing we do in xfs_fs_evict_inode() that is not generic is call xfs_inactive(). We can move the xfs_inactive() call to xfs_fs_destroy_inode() without any problems at all, and this will leave the VFS inode intact until it is completely done with it.
So, remove xfs_fs_evict_inode(), and do the work it used to do in ->destroy_inode instead.
--- fs/xfs/xfs_super.c | 28 +++++++--------------------- 1 file changed, 7 insertions(+), 21 deletions(-)
fs/xfs/xfs_super.c +7 -21
@@ -928,7 +928,7 @@ xfs_fs_alloc_inode(/* * Now that the generic code is guaranteed not to be accessing -* the linux inode, we can reclaim the inode. +* the linux inode, we can inactivate and reclaim the inode. */ STATIC void xfs_fs_destroy_inode(
@@ -938,9 +938,14 @@ xfs_fs_destroy_inode(trace_xfs_destroy_inode (ip); -XFS_STATS_INC (ip->i_mount, vn_reclaim); +ASSERT (!rwsem_is_locked (&ip->i_iolock.mr_lock)); +XFS_STATS_INC (ip->i_mount, vn_rele); +XFS_STATS_INC (ip->i_mount, vn_remove); + +xfs_inactive (ip);ASSERT (XFS_FORCED_SHUTDOWN (ip->i_mount) || ip->i_delayed_blks ==0 ); +XFS_STATS_INC (ip->i_mount, vn_reclaim);/* * We should never get here with one of the reclaim flags already set.
@@ -987,24 +992,6 @@ xfs_fs_inode_init_once( "xfsino", ip->i_ino); } -STATIC void -xfs_fs_evict_inode ( -struct inode *inode) -{ -xfs_inode_t *ip =XFS_I (inode); - -ASSERT (!rwsem_is_locked (&ip->i_iolock.mr_lock)); - -trace_xfs_evict_inode (ip); - -truncate_inode_pages_final (&inode->i_data); -clear_inode (inode); -XFS_STATS_INC (ip->i_mount, vn_rele); -XFS_STATS_INC (ip->i_mount, vn_remove); - -xfs_inactive (ip); -} -/* * We do an unlocked check for XFS_IDONTCACHE here because we are already * serialised against cache hits here via the inode->i_lock and igrab() in
@@ -1673,7 +1660,6 @@ xfs_fs_free_cached_objects(static const struct super_operations xfs_super_operations = { .alloc_inode = xfs_fs_alloc_inode, .destroy_inode = xfs_fs_destroy_inode, - .evict_inode = xfs_fs_evict_inode, .drop_inode = xfs_fs_drop_inode, .put_super = xfs_fs_put_super, .sync_fs = xfs_fs_sync_fs,
Greg Kroah-Hartman
maintainerPATCH 117/121 xfs: xfs_iflush_cluster fails to abort on error
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.
When a failure due to an inode buffer occurs, the error handling fails to abort the inode writeback correctly. This can result in the inode being reclaimed whilst still in the AIL, leading to use-after-free situations as well as filesystems that cannot be unmounted as the inode log items left in the AIL never get removed.
Fix this by ensuring fatal errors from xfs_imap_to_bp() result in the inode flush being aborted correctly.
--- fs/xfs/xfs_inode.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
fs/xfs/xfs_inode.c +13 -4
@@ -3327,7 +3327,7 @@ xfs_iflush( struct xfs_buf **bpp) {struct xfs_mount *mp = ip->i_mount; -struct xfs_buf *bp; +struct xfs_buf *bp =NULL ;struct xfs_dinode *dip;int error;
@@ -3369,14 +3369,22 @@ xfs_iflush( }/* -* Get the buffer containing the on-disk inode. +* Get the buffer containing the on-disk inode. We are doing a try-lock +* operation here, so we may get an EAGAIN error. In that case, we +* simply want to return with the inode still dirty. +* +* If we get any other error, we effectively have a corruption situation +* and we cannot flush the inode, so we treat it the same as failing +* xfs_iflush_int(). */ error =xfs_imap_to_bp (mp,NULL , &ip->i_imap, &dip, &bp,XBF_TRYLOCK ,0 ); -if (error || !bp) { +if (error == -EAGAIN ) {xfs_ifunlock (ip);return error; } +if (error) + goto corrupt_out;/* * First flush out the inode that xfs_iflush was called with.
@@ -3404,7 +3412,8 @@ xfs_iflush(return 0 ; corrupt_out: -xfs_buf_relse (bp); +if (bp) +xfs_buf_relse (bp);xfs_force_shutdown (mp,SHUTDOWN_CORRUPT_INCORE ); cluster_corrupt_out: error = -EFSCORRUPTED ;
Greg Kroah-Hartman
maintainerPATCH 118/121 xfs: fix inode validity check in xfs_iflush_cluster
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit 51b07f30a71c27405259a0248206ed4e22adbee2 upstream.
Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs:
convert inode cache lookups to use RCU locking") back in late 2010, and so xfs_iflush_cluster checks the wrong inode for whether it is still valid under RCU protection. Fix it to lock and check the correct inode.
(*) Careless-idiot: Dave Chinner <[email protected]>
--- fs/xfs/xfs_inode.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
fs/xfs/xfs_inode.c +4 -4
@@ -3205,13 +3205,13 @@ xfs_iflush_cluster(* We need to check under the i_flags_lock for a valid inode * here. Skip it if it is not valid or the wrong inode. */ -spin_lock (&ip->i_flags_lock); -if (!ip->i_ino || +spin_lock (&iq->i_flags_lock); +if (!iq->i_ino || (XFS_INO_TO_AGINO (mp, iq->i_ino) & mask) != first_index) { -spin_unlock (&ip->i_flags_lock); +spin_unlock (&iq->i_flags_lock);continue ; } -spin_unlock (&ip->i_flags_lock); +spin_unlock (&iq->i_flags_lock);/* * Do an un-protected check to see if the inode is dirty and
Greg Kroah-Hartman
maintainerPATCH 119/121 xfs: skip stale inodes in xfs_iflush_cluster
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.
We don't write back stale inodes so we should skip them in xfs_iflush_cluster, too.
--- fs/xfs/xfs_inode.c | 1 + 1 file changed, 1 insertion(+)
fs/xfs/xfs_inode.c +1 -0
@@ -3207,6 +3207,7 @@ xfs_iflush_cluster(*/ spin_lock (&iq->i_flags_lock);if (!iq->i_ino || +__xfs_iflags_test (iq,XFS_ISTALE ) || (XFS_INO_TO_AGINO (mp, iq->i_ino) & mask) != first_index) {spin_unlock (&iq->i_flags_lock);continue ;
Greg Kroah-Hartman
maintainerPATCH 120/121 drm: msm: remove unused variable
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 6979cd54c0667189bb0805c0fcebfef8afc5a191 upstream.
A recent cleanup removed the only user of the 'kms' variable in msm_preclose(), causing a harmless compiler warning:
drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms' [-Werror=unused-variable]
This removes the variable as well.
--- drivers/gpu/drm/msm/msm_drv.c | 1 - 1 file changed, 1 deletion(-)
drivers/gpu/drm/msm/msm_drv.c +0 -1
@@ -465,7 +465,6 @@ static void msm_preclose(struct drm_devi {struct msm_drm_private *priv = dev->dev_private;struct msm_file_private *ctx = file->driver_priv; -struct msm_kms *kms = priv->kms;mutex_lock (&dev->struct_mutex);if (ctx == priv->lastctx)
Greg Kroah-Hartman
maintainerPATCH 121/121 IB/hfi1: Fix hard lockup due to not using save/restore spin lock
In reply to Greg Kroah-Hartman4.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Marciniszyn <[email protected]>
commit 7049de65c9e520886f06d6f9deceaaed5d93fb7c upstream.
Commit b9b06cb6feda
("IB/hfi1: Fix missing lock/unlock in verbs drain callback") added a spin lock.
Unfortunately, the new lock code can be called from a base level interrupt state, and an interrupt that can get stacked will attempt to get the same lock.
Fix by using the flag save/restore spin lock variation.
--- drivers/staging/rdma/hfi1/qp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/staging/rdma/hfi1/qp.c +3 -2
@@ -512,6 +512,7 @@ static void iowait_wakeup(struct iowaitstatic void iowait_sdma_drained (struct iowait *wait) {struct rvt_qp *qp =iowait_to_qp (wait); +unsigned long flags;/* * This happens when the send engine notes
@@ -519,12 +520,12 @@ static void iowait_sdma_drained(struct i* do the flush work until that QP's * sdma work has finished. */ -spin_lock (&qp->s_lock); +spin_lock_irqsave (&qp->s_lock, flags);if (qp->s_flags &RVT_S_WAIT_DMA ) { qp->s_flags &= ~RVT_S_WAIT_DMA ;hfi1_schedule_send (qp); } -spin_unlock (&qp->s_lock); +spin_unlock_irqrestore (&qp->s_lock, flags); }/**
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 18 lines · Kevin Hilman
Quoted 16 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
Quoted 8 lines
Quoted 5 lines
defconfig: apq8016-sbc: 1 failed lab defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labTheses two are real boot regressions, bisections forthcoming.
This, plus several arm builds, plus all MIPS builds are failing. I am out of town, bisecting tonight.
Guenter
Greg Kroah-Hartman
maintainerQuoted 22 lines · Guenter Roeck
Quoted 21 lines · Kevin Hilman
Quoted 19 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
defconfig: apq8016-sbc: 1 failed lab
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labTheses two are real boot regressions, bisections forthcoming.
This, plus several arm builds, plus all MIPS builds are failing. I am out of town, bisecting tonight.
There were a TON of MIPS changes in this release, it's as if those maintainers went on a bug-fixing spree. I wouldn't be surprised if any of them broke things given my lack of ability to test them :(
thanks,
greg k-h
Quoted 22 lines · Guenter Roeck
Quoted 21 lines · Kevin Hilman
Quoted 19 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
defconfig: apq8016-sbc: 1 failed lab
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labTheses two are real boot regressions, bisections forthcoming.
This, plus several arm builds, plus all MIPS builds are failing. I am out of town, bisecting tonight.
Followup: Reverting both 'MIPS: Sync icache & dcache in set_pte_at' and 'MIPS:
Handle highmem pages in __update_cache' fixes the mips build problem for me. Tested in 4.4 and 4.6. I also ran a qemu test with 4.6 after reverting those patches, which passed.
Guenter
Quoted 18 lines · Kevin Hilman
Quoted 16 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
Quoted 7 lines
Quoted 5 lines
defconfig: apq8016-sbc: 1 failed lab defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labTheses two are real boot regressions, bisections forthcoming.
I have bisected[1] these two failures down to 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on registration") and confirmed that reverting this patch on top of this stable queue fixes the boot issue.
Adding Mark B. and Javier C. to this thread for discussion.
Cheers,
Tyler
Hello,
Quoted 25 lines · Tyler Baker
Quoted 24 lines · Kevin Hilman
Quoted 21 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
defconfig: apq8016-sbc: 1 failed lab defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed lab
Quoted 9 lines
Quoted 1 line
Theses two are real boot regressions, bisections forthcoming.
I have bisected[1] these two failures down to
5e3ca2b349b1("regulator: Try to resolve regulators supplies on registration") and confirmed that reverting this patch on top of this stable queue fixes the boot issue.Adding Mark B. and Javier C. to this thread for discussion.
I'm not familiar with the apq8016-sbc board or Qualcomm platforms in general but this patch is known to cause deadlocks when looking up regulators that were not registered via OF. This was an issue on at least some Nvidia boards.
So since this patch made it to stable, commit a21513742308 ("regulator: Fix deadlock during regulator registration") [0] should also be included.
Quoted 6 lines
Cheers,
Tyler
[0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a21513742308
Best regards,
Signature · 3 lines
Javier Martinez Canillas Open Source Group Samsung Research America
Quoted 10 lines · Javier Martinez Canillas
Quoted 4 lines · Tyler Baker
I have bisected[1] these two failures down to
5e3ca2b349b1("regulator: Try to resolve regulators supplies on registration") and confirmed that reverting this patch on top of this stable queue fixes the boot issue.I'm not familiar with the apq8016-sbc board or Qualcomm platforms in general but this patch is known to cause deadlocks when looking up regulators that were not registered via OF. This was an issue on at least some Nvidia boards.
The Qualcomm platforms are running into trouble because the qcom_smd driver is broken and apparently nobody checks -next works for their boards since they only noticed after -rc1 in spite of the change having been in -next for a good few weeks. You need at least "regulator:qcom_smd: add list_voltage callback" and "regulator: qcom_smd: add regulator ops for pm8941 lnldo" from my tree which I didn't send to Linus yet since we only got them in at the end of last week. I think that's probably OK for v4.6 TBH, the platform is fairly incomplete upstream and the original patch fixes issues for other systems.
Quoted 2 lines
So since this patch made it to stable, commit
a21513742308("regulator: Fix deadlock during regulator registration") [0] should also be included.
Please.
Greg Kroah-Hartman
maintainerQuoted 38 lines · Javier Martinez Canillas
Hello,
Quoted 25 lines · Tyler Baker
Quoted 24 lines · Kevin Hilman
Quoted 21 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
defconfig: apq8016-sbc: 1 failed lab defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labQuoted 9 lines
Quoted 1 line
Theses two are real boot regressions, bisections forthcoming.
I have bisected[1] these two failures down to
5e3ca2b349b1("regulator: Try to resolve regulators supplies on registration") and confirmed that reverting this patch on top of this stable queue fixes the boot issue.Adding Mark B. and Javier C. to this thread for discussion.
Quoted 6 lines
I'm not familiar with the apq8016-sbc board or Qualcomm platforms in general but this patch is known to cause deadlocks when looking up regulators that were not registered via OF. This was an issue on at least some Nvidia boards.
So since this patch made it to stable, commit
a21513742308("regulator: Fix deadlock during regulator registration") [0] should also be included.
Ugh. Why wasn't that patch also marked for stable inclusion? This was a problem waiting to happen that could have been totally avoided :(
I'll queue it up this evening, thanks.
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
Quoted 6 lines · Javier Martinez Canillas
I'm not familiar with the apq8016-sbc board or Qualcomm platforms in general but this patch is known to cause deadlocks when looking up regulators that were not registered via OF. This was an issue on at least some Nvidia boards.
So since this patch made it to stable, commit
a21513742308("regulator: Fix deadlock during regulator registration") [0] should also be included.Ugh. Why wasn't that patch also marked for stable inclusion? This was a problem waiting to happen that could have been totally avoided :(
Mostly because I forgot that the original one was at the time I applied it.
Greg Kroah-Hartman
maintainerQuoted 43 lines · Greg Kroah-Hartman
Quoted 42 lines · Javier Martinez Canillas
Hello,
Quoted 25 lines · Tyler Baker
Quoted 24 lines · Kevin Hilman
Quoted 21 lines · kernelci.org bot
stable-queue boot: 73 boots: 3 failed, 68 passed with 2 offline (v4.6.1-121-g2276ff7d4bf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/
Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.6.1-121-g2276ff7d4bf9/Tree: stable-queue
Branch: local/linux-4.6.y.queue
Git Describe: v4.6.1-121-g2276ff7d4bf9
Git Commit:2276ff7d4bf9c438832f761ffd525cacf55362cdGit URL:git://server.roeck-us.net/git/linux-stable.git
Tested: 28 unique boards, 9 SoC families, 16 builds out of 100Boot Failures Detected: https://kernelci.org/boot/?v4.6.1-121-g2276ff7d4bf9&fail
arm64:
defconfig: apq8016-sbc: 1 failed lab defconfig+CONFIG_RANDOMIZE_BASE=y: apq8016-sbc: 1 failed labQuoted 9 lines
Quoted 1 line
Theses two are real boot regressions, bisections forthcoming.
I have bisected[1] these two failures down to
5e3ca2b349b1("regulator: Try to resolve regulators supplies on registration") and confirmed that reverting this patch on top of this stable queue fixes the boot issue.Adding Mark B. and Javier C. to this thread for discussion.
I'm not familiar with the apq8016-sbc board or Qualcomm platforms in general but this patch is known to cause deadlocks when looking up regulators that were not registered via OF. This was an issue on at least some Nvidia boards.
Quoted 7 lines
Quoted 2 lines
So since this patch made it to stable, commit
a21513742308("regulator: Fix deadlock during regulator registration") [0] should also be included.Ugh. Why wasn't that patch also marked for stable inclusion? This was a problem waiting to happen that could have been totally avoided :(
I'll queue it up this evening, thanks.
Ok, that patch does not apply to 4.5-stable, or 4.4-stable, so I'm going to only apply it to 4.6-stable, and drop the original patch, 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on registration") from the 4.4 and 4.5 queues.
thanks,
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.2 release. There are 121 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Jun 7 21:43:16 UTC 2016. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.2-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.2 release. There are 121 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Jun 7 21:43:16 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 132 fail: 16
Failed builds:
mips:defconfig (binutils 2.22)
mips:allnoconfig
mips:defconfig (binutils 2.24)
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig (binutils 2.25)
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:defconfig
unicore32:defconfig
unicore32:allnoconfig
Qemu test results:
total: 107 pass: 98 fail: 9
Failed tests:
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:malta_defconfig:nosmp
mipsel:malta_defconfig:smp
mips64el:malta_defconfig:nosmp
mips64el:malta_defconfig:smp
mips64el:fuloong2e_defconfig:fulong2e
Details are available at http://kerneltests.org/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 43 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.2 release. There are 121 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Jun 7 21:43:16 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 132 fail: 16Failed builds:
mips:defconfig (binutils 2.22)
mips:allnoconfig
mips:defconfig (binutils 2.24)
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig (binutils 2.25)
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:defconfig
unicore32:defconfig
unicore32:allnoconfigQemu test results:
total: 107 pass: 98 fail: 9Failed tests:
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:malta_defconfig:nosmp
mipsel:malta_defconfig:smp
mips64el:malta_defconfig:nosmp
mips64el:malta_defconfig:smp
mips64el:fuloong2e_defconfig:fulong2e
Quoted 1 line
Details are available at http://kerneltests.org/builders.
Thanks for these, I think I've fixed them all now.
greg k-h
Quoted 44 lines · Greg Kroah-Hartman
Quoted 43 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.6.2 release. There are 121 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue Jun 7 21:43:16 UTC 2016. Anything received after that time might be too late.
Build results:
total: 148 pass: 132 fail: 16Failed builds:
mips:defconfig (binutils 2.22)
mips:allnoconfig
mips:defconfig (binutils 2.24)
mips:allmodconfig
mips:allnoconfig
mips:bcm47xx_defconfig (binutils 2.25)
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
mips:defconfig
unicore32:defconfig
unicore32:allnoconfigQemu test results:
total: 107 pass: 98 fail: 9Failed tests:
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:malta_defconfig:nosmp
mipsel:malta_defconfig:smp
mips64el:malta_defconfig:nosmp
mips64el:malta_defconfig:smp
mips64el:fuloong2e_defconfig:fulong2e
Quoted 4 lines
Quoted 1 line
Details are available at http://kerneltests.org/builders.
Thanks for these, I think I've fixed them all now.
I did a quick test; looks like your fix for mips is working for 4.4, 4.5, and 4.6. I'll let you know if the complete build shows a problem.
Guenter