4.19.73-stable review
Subsystems (8)
Greg Kroah-Hartman
maintainercover 4.19.73-stable review
This is the start of the stable review cycle for the 4.19.73 release. There are 190 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 Sun 15 Sep 2019 01:03:32 PM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.73-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.19.73-rc1
yongduan <[email protected]>
vhost: make sure log_num < in_num
Michael S. Tsirkin <[email protected]>
vhost: block speculation of translated descriptors
Gustavo Romero <[email protected]>
powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts
Breno Leitao <[email protected]>
powerpc/tm: Remove msr_tm_active()
Lyude Paul <[email protected]>
PCI: Reset both NVIDIA GPU and HDA in ThinkPad P50 workaround
Colin Ian King <[email protected]>
ext4: unsigned int compared against zero
Theodore Ts'o <[email protected]>
ext4: fix block validity checks for journal inodes using indirect blocks
Theodore Ts'o <[email protected]>
ext4: don't perform block validity checks on the journal inode
Lyude Paul <[email protected]>
drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors
Halil Pasic <[email protected]>
virtio/s390: fix race on airq_areas[]
Ville Syrjälä <[email protected]>
drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
Coly Li <[email protected]>
bcache: fix race in btree_flush_write()
Coly Li <[email protected]>
bcache: add comments for mutex_lock(&b->write_lock)
Coly Li <[email protected]>
bcache: only clear BTREE_NODE_dirty bit when it is set
Trond Myklebust <[email protected]>
NFSv4: Fix delegation state recovery
Arnd Bergmann <[email protected]>
iio: adc: gyroadc: fix uninitialized return code
Ralph Campbell <[email protected]>
mm/migrate.c: initialize pud_entry in migrate_vma()
Michał Mirosław <[email protected]>
i2c: at91: fix clk_offset for sama5d2
Michał Mirosław <[email protected]>
i2c: at91: disable TXRDY interrupt after sending data
Bartosz Golaszewski <[email protected]>
gpio: don't WARN() on NULL descs if gpiolib is disabled
Chris Wilson <[email protected]>
iommu/iova: Remove stale cached32_node
Suraj Jitindar Singh <[email protected]>
powerpc/mm: Limit rma_size to 1TB when running without HV mode
Takashi Iwai <[email protected]>
ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips
Sébastien Szymanski <[email protected]>
drm/panel: Add support for Armadeus ST0700 Adapt
Mike Snitzer <[email protected]>
dm thin metadata: check if in fail_io mode when setting needs_check
Norbert Manthey <[email protected]>
pstore: Fix double-free in pstore_mkfile() failure path
Nadav Amit <[email protected]>
resource: fix locking in find_next_iomem_res()
Bjorn Helgaas <[email protected]>
resource: Fix find_next_iomem_res() iteration issue
Bjorn Helgaas <[email protected]>
resource: Include resource end in walk_*() interfaces
Johannes Thumshirn <[email protected]>
btrfs: correctly validate compression type
Bart Van Assche <[email protected]>
RDMA/srp: Accept again source addresses that do not have a port number
Bart Van Assche <[email protected]>
RDMA/srp: Document srp_parse_in() arguments
Linus Walleij <[email protected]>
ARM: dts: gemini: Set DIR-685 SPI CS as active low
Michael Neuling <[email protected]>
KVM: PPC: Book3S HV: Fix CR0 setting in TM emulation
Paul Mackerras <[email protected]>
KVM: PPC: Use ccr field in pt_regs struct embedded in vcpu struct
Wanpeng Li <[email protected]>
KVM: VMX: check CPUID before allowing read/write of IA32_XSS
Sean Christopherson <[email protected]>
KVM: VMX: Fix handling of #MC that occurs during VM-Entry
Sean Christopherson <[email protected]>
KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value
Paolo Bonzini <[email protected]>
KVM: x86: optimize check for valid PAT value
Yan, Zheng <[email protected]>
ceph: use ceph_evict_inode to cleanup inode's resource
Takashi Iwai <[email protected]>
ALSA: hda - Don't resume forcibly i915 HDMI/DP codec
Paulo Alcantara (SUSE) <[email protected]>
cifs: Properly handle auto disabling of serverino option
Benjamin Block <[email protected]>
scsi: zfcp: fix request object use-after-free in send path causing wrong traces
Ajay Singh <[email protected]>
staging: wilc1000: fix error path cleanup in wilc_wlan_initialize()
Roman Bolshakov <[email protected]>
scsi: target/iblock: Fix overrun in WRITE SAME emulation
Bart Van Assche <[email protected]>
scsi: target/core: Use the SECTOR_SHIFT constant
Mike Salvatore <[email protected]>
apparmor: reset pos on failure to unpack for various functions
Mike Marciniszyn <[email protected]>
IB/hfi1: Avoid hardlockup with flushlist_lock
Jon Hunter <[email protected]>
clk: tegra210: Fix default rates for HDA clocks
Jon Hunter <[email protected]>
clk: tegra: Fix maximum audio sync clock for Tegra124/210
Ronnie Sahlberg <[email protected]>
cifs: add spinlock for the openFileList to cifsInodeInfo
Filipe Manana <[email protected]>
Btrfs: fix race between block group removal and block group allocation
Shirish S <[email protected]>
drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc
Louis Li <[email protected]>
drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)
Peter Xu <[email protected]>
kvm: Check irqchip mode before assign irqfd
Kent Russell <[email protected]>
drm/amdkfd: Add missing Polaris10 ID
Eugeniy Paltsev <[email protected]>
ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
Eugeniy Paltsev <[email protected]>
ARC: mm: fix uninitialised signal code in do_page_fault
Eric W. Biederman <[email protected]>
signal/arc: Use force_sig_fault where appropriate
Milan Broz <[email protected]>
dm crypt: move detailed message into debug level
Long Li <[email protected]>
cifs: smbd: take an array of reqeusts when sending upper layer data
Jisheng Zhang <[email protected]>
PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify code
Adrian Hunter <[email protected]>
mmc: sdhci-pci: Add support for Intel CML
Ming Lei <[email protected]>
blk-mq: free hw queue's resource in hctx's release handler
Yufen Yu <[email protected]>
dm mpath: fix missing call of path selector type->end_io
Lyude Paul <[email protected]>
PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
Logan Gunthorpe <[email protected]>
PCI: Add macro for Switchtec quirk declarations
Christoph Muellner <[email protected]>
dt-bindings: mmc: Add disable-cqe-dcmd property.
Sowjanya Komatineni <[email protected]>
dt-bindings: mmc: Add supports-cqe property
Christian Lamparter <[email protected]>
ARM: dts: qcom: ipq4019: enlarge PCIe BAR range
Niklas Cassel <[email protected]>
ARM: dts: qcom: ipq4019: Fix MSI IRQ type
Mathias Kresin <[email protected]>
ARM: dts: qcom: ipq4019: fix PCI range
Theodore Ts'o <[email protected]>
ext4: protect journal inode's blocks using block_validity
Koen Vandeputte <[email protected]>
media: i2c: tda1997x: select V4L2_FWNODE
ZhangXiaoxu <[email protected]>
cifs: Fix lease buffer length error
Sean Christopherson <[email protected]>
KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels
WANG Chao <[email protected]>
x86/kvm: move kvm_load/put_guest_xcr0 into atomic context
Ben Gardon <[email protected]>
kvm: mmu: Fix overflow on kvm mmu page limit calculation
Moni Shoua <[email protected]>
IB/mlx5: Reset access mask when looping inside page fault handler
Dinh Nguyen <[email protected]>
arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's
Hans de Goede <[email protected]>
usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps
Chris Wilson <[email protected]>
drm/i915: Sanity check mmap length against object size
Joonas Lahtinen <[email protected]>
drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set
Pavel Shilovsky <[email protected]>
CIFS: Fix leaking locked VFS cache pages in writeback retry
Pavel Shilovsky <[email protected]>
CIFS: Fix error paths in writeback code
Ben Dooks <[email protected]>
drm: add __user attribute to ptr_to_compat()
Bjorn Andersson <[email protected]>
PCI: qcom: Don't deassert reset GPIO during probe
Bjorn Andersson <[email protected]>
PCI: qcom: Fix error handling in runtime PM support
Dan Robertson <[email protected]>
btrfs: init csum_list before possible free
Anand Jain <[email protected]>
btrfs: scrub: fix circular locking dependency warning
David Sterba <[email protected]>
btrfs: scrub: move scrub_setup_ctx allocation out of device_list_mutex
David Sterba <[email protected]>
btrfs: scrub: pass fs_info to scrub_setup_ctx
Takeshi Saito <[email protected]>
mmc: renesas_sdhi: Fix card initialization failure in high speed mode
Michael Ellerman <[email protected]>
powerpc/kvm: Save and restore host AMR/IAMR/UAMOR
Russell King <[email protected]>
spi: spi-gpio: fix SPI_CS_HIGH capability
Pavel Tatashin <[email protected]>
x86/kvmclock: set offset for kvm unstable clock
Ihab Zhaika <[email protected]>
iwlwifi: add new card for 9260 series
Luca Coelho <[email protected]>
iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules
Lyude Paul <[email protected]>
drm/nouveau: Don't WARN_ON VCPI allocation failures
Felix Fietkau <[email protected]>
mt76: fix corrupted software generated tx CCMP PN
Krzysztof Kozlowski <[email protected]>
iio: adc: exynos-adc: Use proper number of channels for Exynos4x12
Jonathan Bakker <[email protected]>
dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant
Jonathan Bakker <[email protected]>
iio: adc: exynos-adc: Add S5PV210 variant
Sean Christopherson <[email protected]>
KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run
Tang Junhui <[email protected]>
bcache: treat stale && dirty keys as bad keys
Coly Li <[email protected]>
bcache: replace hard coded number with BUCKET_GC_GEN_MAX
Jarkko Sakkinen <[email protected]>
tpm: Fix some name collisions with drivers/char/tpm.h
Jarkko Nikula <[email protected]>
mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies
José Roberto de Souza <[email protected]>
drm/i915/ilk: Fix warning when reading emon_status with no output
Ville Syrjälä <[email protected]>
drm/vblank: Allow dynamic per-crtc max_vblank_count
Gilad Ben-Yossef <[email protected]>
crypto: ccree - add missing inline qualifier
Gilad Ben-Yossef <[email protected]>
crypto: ccree - fix resume race condition on init
Yishai Hadas <[email protected]>
IB/uverbs: Fix OOPs upon device disassociation
Vineet Gupta <[email protected]>
ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault
Vineet Gupta <[email protected]>
ARC: show_regs: lockdep: re-enable preemption
Hans Verkuil <[email protected]>
media: vim2m: only cancel work if it is for right context
Qu Wenruo <[email protected]>
btrfs: Use real device structure to verify dev extent
Qu Wenruo <[email protected]>
btrfs: volumes: Make sure no dev extent is beyond device boundary
Ram Pai <[email protected]>
powerpc/pkeys: Fix handling of pkey state across fork()
Shivasharan S <[email protected]>
scsi: megaraid_sas: Use 63-bit DMA addressing
Shivasharan S <[email protected]>
scsi: megaraid_sas: Add check for reset adapter bit
Shivasharan S <[email protected]>
scsi: megaraid_sas: Fix combined reply queue mode detection
Nikolay Borisov <[email protected]>
btrfs: Fix error handling in btrfs_cleanup_ordered_extents
Nikolay Borisov <[email protected]>
btrfs: Remove extent_io_ops::fill_delalloc
Filipe Manana <[email protected]>
Btrfs: fix deadlock with memory reclaim during scrub
Omar Sandoval <[email protected]>
Btrfs: clean up scrub is_dev_replace parameter
Paul Mackerras <[email protected]>
KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode switch
Chris Wilson <[email protected]>
drm/i915: Cleanup gt powerstate from gem
Chris Wilson <[email protected]>
drm/i915: Restore sane defaults for KMS on GEM error load
Hans Verkuil <[email protected]>
media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work
Hans Verkuil <[email protected]>
media: vim2m: use workqueue
Harald Freudenberger <[email protected]>
s390/zcrypt: reinit ap queue state machine during device probe
Bartosz Golaszewski <[email protected]>
ARM: davinci: dm644x: define gpio interrupts as separate resources
Bartosz Golaszewski <[email protected]>
ARM: davinci: dm355: define gpio interrupts as separate resources
Bartosz Golaszewski <[email protected]>
ARM: davinci: dm646x: define gpio interrupts as separate resources
Bartosz Golaszewski <[email protected]>
ARM: davinci: dm365: define gpio interrupts as separate resources
Bartosz Golaszewski <[email protected]>
ARM: davinci: da8xx: define gpio interrupts as separate resources
Lyude Paul <[email protected]>
drm/amd/dm: Understand why attaching path/tile properties are needed
Rex Zhu <[email protected]>
drm/amd/pp: Fix truncated clock value when set watermark
David Francis <[email protected]>
powerplay: Respect units on max dcfclk watermark
Dexuan Cui <[email protected]>
Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
Dexuan Cui <[email protected]>
Drivers: hv: kvp: Fix the indentation of some "break" statements
Lyude Paul <[email protected]>
drm/atomic_helper: Disallow new modesets on unregistered connectors
Imre Deak <[email protected]>
drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
Dhinakaran Pandiyan <[email protected]>
drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
Lyude Paul <[email protected]>
drm/i915: Fix intel_dp_mst_best_encoder()
Vitaly Kuznetsov <[email protected]>
x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
Ladi Prosek <[email protected]>
KVM: hyperv: define VP assist page helpers
Vitaly Kuznetsov <[email protected]>
KVM: x86: hyperv: keep track of mismatched VP indexes
Vitaly Kuznetsov <[email protected]>
KVM: x86: hyperv: consistently use 'hv_vcpu' for 'struct kvm_vcpu_hv' variables
Vitaly Kuznetsov <[email protected]>
KVM: x86: hyperv: enforce vp_index < KVM_MAX_VCPUS
Feifei Xu <[email protected]>
drm/amdgpu: Update gc_9_0 golden settings.
Feifei Xu <[email protected]>
drm/amdgpu/gfx9: Update gfx9 golden settings.
Brian Norris <[email protected]>
remoteproc: qcom: q6v5-mss: add SCM probe dependency
Zhimin Gu <[email protected]>
x86, hibernate: Fix nosave_regions setup for hibernation
Dexuan Cui <[email protected]>
Drivers: hv: kvp: Fix two "this statement may fall through" warnings
David Howells <[email protected]>
keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h
Giridhar Malavali <[email protected]>
scsi: qla2xxx: Move log messages before issuing command to firmware
Hans Verkuil <[email protected]>
media: cec: remove cec-edid.c
Hans Verkuil <[email protected]>
media: cec/v4l2: move V4L2 specific CEC functions to V4L2
Jan-Marek Glogowski <[email protected]>
drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
YueHaibing <[email protected]>
kernel/module: Fix mem leak in module_add_modinfo_attrs
Jessica Yu <[email protected]>
modules: always page-align module section allocations
Brian Norris <[email protected]>
remoteproc: qcom: q6v5: shore up resource probe handling
Nathan Chancellor <[email protected]>
clk: s2mps11: Add used attribute to s2mps11_dt_match
Hannes Reinecke <[email protected]>
nvme-fc: use separate work queue to avoid warning
David Abdurachmanov <[email protected]>
riscv: remove unused variable in ftrace
Nicolas Boichat <[email protected]>
scripts/decode_stacktrace: match basepath using shell prefix operator, not regex
Dmitry Voytik <[email protected]>
arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64
Fabien Dessenne <[email protected]>
media: stm32-dcmi: fix irq = 0 case
Christophe Leroy <[email protected]>
powerpc/64: mark start_here_multiplatform as __ref
Steven Rostedt (VMware) <[email protected]>
x86/ftrace: Fix warning and considate ftrace_jmp_replace() and ftrace_call_replace()
Hangbin Liu <[email protected]>
selftests: fib_rule_tests: use pre-defined DEV_ADDR
Jason A. Donenfeld <[email protected]>
timekeeping: Use proper ktime_add when adding nsecs in coarse offset
Manikanta Pubbisetty <[email protected]>
{nl,mac}80211: fix interface combinations on crypto controlled devices
Dennis Zhou <[email protected]>
blk-iolatency: fix STS_AGAIN handling
Liu Bo <[email protected]>
Blk-iolatency: warn on negative inflight IO counter
Dexuan Cui <[email protected]>
hv_sock: Fix hang when a connection is closed
Sven Eckelmann <[email protected]>
batman-adv: Only read OGM tvlv_len after buffer len check
Eric Dumazet <[email protected]>
batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
Gustavo Romero <[email protected]>
powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
Tiwei Bie <[email protected]>
vhost/test: fix build for vhost test - again
Tiwei Bie <[email protected]>
vhost/test: fix build for vhost test
Dan Carpenter <[email protected]>
drm/vmwgfx: Fix double free in vmw_recv_msg()
Liangyan <[email protected]>
sched/fair: Don't assign runtime for throttled cfs_rq
Hui Wang <[email protected]>
ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre
Jian-Hong Pan <[email protected]>
ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
Sam Bazley <[email protected]>
ALSA: hda/realtek - Add quirk for HP Pavilion 15
Takashi Iwai <[email protected]>
ALSA: hda/realtek - Fix overridden device-specific initialization
Takashi Iwai <[email protected]>
ALSA: hda - Fix potential endless loop at applying quirks
-------------
Diffstat:
.../display/panel/armadeus,st0700-adapt.txt | 9 ++ .../bindings/iio/adc/samsung,exynos-adc.txt | 6 +- Documentation/devicetree/bindings/mmc/mmc.txt | 4 + Makefile | 4 +- arch/arc/kernel/troubleshoot.c | 8 ++ arch/arc/mm/fault.c | 38 ++---- arch/arm/boot/dts/gemini-dlink-dir-685.dts | 2 +- arch/arm/boot/dts/qcom-ipq4019.dtsi | 6 +- arch/arm/mach-davinci/devices-da8xx.c | 40 ++++++ arch/arm/mach-davinci/dm355.c | 30 ++++ arch/arm/mach-davinci/dm365.c | 35 +++++ arch/arm/mach-davinci/dm644x.c | 20 +++ arch/arm/mach-davinci/dm646x.c | 10 ++ arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 3 + arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 + arch/powerpc/include/asm/kvm_book3s.h | 4 +- arch/powerpc/include/asm/kvm_book3s_64.h | 4 +- arch/powerpc/include/asm/kvm_booke.h | 4 +- arch/powerpc/include/asm/kvm_host.h | 2 - arch/powerpc/include/asm/mmu_context.h | 15 +- arch/powerpc/include/asm/reg.h | 7 +- arch/powerpc/kernel/asm-offsets.c | 4 +- arch/powerpc/kernel/head_64.S | 2 + arch/powerpc/kernel/process.c | 38 ++---- arch/powerpc/kvm/book3s_64_mmu_hv.c | 3 + arch/powerpc/kvm/book3s_emulate.c | 12 +- arch/powerpc/kvm/book3s_hv.c | 19 ++- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 30 ++-- arch/powerpc/kvm/book3s_hv_tm.c | 12 +- arch/powerpc/kvm/book3s_hv_tm_builtin.c | 5 +- arch/powerpc/kvm/book3s_pr.c | 4 +- arch/powerpc/kvm/bookehv_interrupts.S | 8 +- arch/powerpc/kvm/emulate_loadstore.c | 1 - arch/powerpc/mm/hash_utils_64.c | 9 ++ arch/powerpc/mm/pkeys.c | 10 ++ arch/riscv/kernel/ftrace.c | 1 - arch/x86/include/asm/kvm_host.h | 15 +- arch/x86/kernel/ftrace.c | 42 +++--- arch/x86/kernel/kvmclock.c | 6 +- arch/x86/kernel/setup.c | 2 +- arch/x86/kvm/emulate.c | 10 ++ arch/x86/kvm/hyperv.c | 71 ++++++++-- arch/x86/kvm/hyperv.h | 4 + arch/x86/kvm/irq.c | 7 + arch/x86/kvm/irq.h | 1 + arch/x86/kvm/lapic.c | 14 +- arch/x86/kvm/lapic.h | 2 +- arch/x86/kvm/mmu.c | 13 +- arch/x86/kvm/mmu.h | 2 +- arch/x86/kvm/mtrr.c | 10 +- arch/x86/kvm/svm.c | 2 + arch/x86/kvm/vmx.c | 41 +++--- arch/x86/kvm/x86.c | 26 ++-- arch/x86/kvm/x86.h | 12 ++ block/blk-core.c | 3 +- block/blk-iolatency.c | 55 +++----- block/blk-mq-sysfs.c | 6 + block/blk-mq.c | 8 +- block/blk-mq.h | 2 +- drivers/char/tpm/st33zp24/i2c.c | 2 +- drivers/char/tpm/st33zp24/spi.c | 2 +- drivers/char/tpm/st33zp24/st33zp24.h | 4 +- drivers/char/tpm/tpm_i2c_infineon.c | 15 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 16 +-- drivers/clk/clk-s2mps11.c | 2 +- drivers/clk/tegra/clk-audio-sync.c | 3 +- drivers/clk/tegra/clk-tegra-audio.c | 7 +- drivers/clk/tegra/clk-tegra114.c | 9 +- drivers/clk/tegra/clk-tegra124.c | 9 +- drivers/clk/tegra/clk-tegra210.c | 11 +- drivers/clk/tegra/clk-tegra30.c | 9 +- drivers/clk/tegra/clk.h | 4 +- drivers/crypto/ccree/cc_driver.c | 7 +- drivers/crypto/ccree/cc_pm.c | 13 +- drivers/crypto/ccree/cc_pm.h | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 5 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 5 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 - drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 32 ++--- drivers/gpu/drm/drm_atomic.c | 21 +++ drivers/gpu/drm/drm_ioc32.c | 6 +- drivers/gpu/drm/drm_vblank.c | 45 +++++- drivers/gpu/drm/i915/i915_debugfs.c | 4 + drivers/gpu/drm/i915/i915_gem.c | 39 ++++-- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_cdclk.c | 11 ++ drivers/gpu/drm/i915/intel_display.c | 37 +++-- drivers/gpu/drm/i915/intel_dp.c | 16 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 2 - drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +- drivers/gpu/drm/panel/panel-simple.c | 29 ++++ drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +- drivers/hv/hv_kvp.c | 32 ++++- drivers/i2c/busses/i2c-at91.c | 11 +- drivers/iio/adc/exynos_adc.c | 31 +++++ drivers/iio/adc/rcar-gyroadc.c | 4 +- drivers/infiniband/core/uverbs_main.c | 7 +- drivers/infiniband/hw/hfi1/sdma.c | 9 +- drivers/infiniband/hw/mlx5/odp.c | 3 +- drivers/infiniband/ulp/srp/ib_srp.c | 24 +++- drivers/iommu/iova.c | 5 +- drivers/md/bcache/btree.c | 49 ++++++- drivers/md/bcache/btree.h | 2 + drivers/md/bcache/extents.c | 15 +- drivers/md/bcache/journal.c | 7 + drivers/md/dm-crypt.c | 5 +- drivers/md/dm-mpath.c | 17 ++- drivers/md/dm-rq.c | 8 +- drivers/md/dm-target.c | 3 +- drivers/md/dm-thin-metadata.c | 7 +- drivers/media/cec/Makefile | 2 +- drivers/media/cec/cec-adap.c | 13 ++ drivers/media/cec/cec-edid.c | 95 ------------- drivers/media/i2c/Kconfig | 3 +- drivers/media/i2c/adv7604.c | 4 +- drivers/media/i2c/adv7842.c | 4 +- drivers/media/i2c/tc358743.c | 2 +- drivers/media/platform/stm32/stm32-dcmi.c | 2 +- drivers/media/platform/vim2m.c | 28 ++-- drivers/media/platform/vivid/vivid-vid-cap.c | 4 +- drivers/media/platform/vivid/vivid-vid-common.c | 2 +- drivers/media/v4l2-core/v4l2-dv-timings.c | 151 +++++++++++++++++++++ drivers/mfd/Kconfig | 6 +- drivers/mmc/host/renesas_sdhi_core.c | 11 +- drivers/mmc/host/sdhci-pci-core.c | 2 + drivers/mmc/host/sdhci-pci.h | 2 + drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 65 ++++++++- drivers/net/wireless/intel/iwlwifi/iwl-config.h | 9 +- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 56 ++++---- .../net/wireless/mediatek/mt76/mt76x2_mac_common.c | 2 +- drivers/nvme/host/fc.c | 15 +- drivers/pci/controller/dwc/pcie-designware-host.c | 21 ++- drivers/pci/controller/dwc/pcie-qcom.c | 58 +++++--- drivers/pci/quirks.c | 148 ++++++++++++-------- drivers/remoteproc/qcom_q6v5.c | 44 ++++-- drivers/remoteproc/qcom_q6v5_pil.c | 3 + drivers/s390/crypto/ap_bus.c | 8 +- drivers/s390/crypto/ap_bus.h | 1 + drivers/s390/crypto/ap_queue.c | 15 ++ drivers/s390/crypto/zcrypt_cex2a.c | 1 - drivers/s390/crypto/zcrypt_cex4.c | 1 - drivers/s390/crypto/zcrypt_pcixcc.c | 1 - drivers/s390/scsi/zfcp_fsf.c | 10 +- drivers/s390/virtio/virtio_ccw.c | 3 + drivers/scsi/megaraid/megaraid_sas_base.c | 76 +++++++---- drivers/scsi/qla2xxx/qla_gs.c | 15 +- drivers/scsi/qla2xxx/qla_init.c | 48 +++---- drivers/spi/spi-gpio.c | 3 +- drivers/staging/wilc1000/linux_wlan.c | 12 +- drivers/target/target_core_iblock.c | 6 +- drivers/target/target_core_iblock.h | 1 - drivers/usb/typec/tcpm.c | 27 +++- drivers/vhost/test.c | 13 +- drivers/vhost/vhost.c | 10 +- fs/btrfs/compression.c | 16 +++ fs/btrfs/compression.h | 1 + fs/btrfs/ctree.h | 3 + fs/btrfs/extent-tree.c | 34 ++--- fs/btrfs/extent_io.c | 20 ++- fs/btrfs/extent_io.h | 5 - fs/btrfs/inode.c | 40 ++++-- fs/btrfs/props.c | 6 +- fs/btrfs/scrub.c | 119 ++++++++++------ fs/btrfs/volumes.c | 29 ++++ fs/ceph/inode.c | 7 +- fs/ceph/super.c | 2 +- fs/ceph/super.h | 2 +- fs/cifs/cifs_fs_sb.h | 5 + fs/cifs/cifsfs.c | 1 + fs/cifs/cifsglob.h | 24 ++++ fs/cifs/cifssmb.c | 24 +++- fs/cifs/connect.c | 8 +- fs/cifs/file.c | 37 +++-- fs/cifs/inode.c | 10 ++ fs/cifs/misc.c | 1 + fs/cifs/smb2pdu.c | 1 + fs/cifs/smbdirect.c | 55 ++++---- fs/cifs/smbdirect.h | 5 +- fs/cifs/transport.c | 2 +- fs/ext4/block_validity.c | 54 ++++++++ fs/ext4/extents.c | 12 +- fs/ext4/inode.c | 4 + fs/nfs/delegation.c | 2 +- fs/nfs/delegation.h | 2 +- fs/nfs/nfs4proc.c | 25 ++-- fs/pstore/inode.c | 12 +- include/drm/drm_device.h | 8 +- include/drm/drm_vblank.h | 22 +++ include/linux/device-mapper.h | 3 +- include/linux/gpio/consumer.h | 62 ++++----- include/media/cec.h | 80 ----------- include/media/v4l2-dv-timings.h | 6 + include/net/cfg80211.h | 15 ++ include/uapi/linux/keyctl.h | 7 +- kernel/module.c | 29 ++-- kernel/resource.c | 110 +++++++-------- kernel/sched/fair.c | 5 + kernel/time/timekeeping.c | 2 +- mm/migrate.c | 17 +-- net/batman-adv/bat_iv_ogm.c | 20 ++- net/batman-adv/netlink.c | 2 +- net/mac80211/util.c | 7 +- net/vmw_vsock/hyperv_transport.c | 8 ++ net/wireless/core.c | 6 +- net/wireless/nl80211.c | 4 +- net/wireless/util.c | 27 +++- scripts/decode_stacktrace.sh | 2 +- security/apparmor/policy_unpack.c | 40 +++++- sound/pci/hda/hda_auto_parser.c | 4 +- sound/pci/hda/hda_codec.c | 8 +- sound/pci/hda/hda_codec.h | 2 + sound/pci/hda/hda_generic.c | 3 +- sound/pci/hda/hda_generic.h | 1 + sound/pci/hda/hda_intel.c | 6 +- sound/pci/hda/patch_hdmi.c | 6 +- sound/pci/hda/patch_realtek.c | 17 +++ tools/testing/selftests/net/fib_rule_tests.sh | 5 +- virt/kvm/eventfd.c | 9 ++ 222 files changed, 2346 insertions(+), 1170 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/190 ALSA: hda - Fix potential endless loop at applying quirks
From: Takashi Iwai <[email protected]>
commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream.
Since the chained quirks via chained_before flag is applied before the depth check, it may lead to the endless recursive calls, when the chain were set up incorrectly. Fix it by moving the depth check at the beginning of the loop.
--- sound/pci/hda/hda_auto_parser.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/pci/hda/hda_auto_parser.c +2 -2
@@ -828,6 +828,8 @@ static void apply_fixup(struct hda_codecwhile (id >=0 ) {const struct hda_fixup *fix = codec->fixup_list + id; +if (++depth >10 ) +break ;if (fix->chained_before)apply_fixup (codec, fix->chain_id, action, depth +1 );
@@ -867,8 +869,6 @@ static void apply_fixup(struct hda_codec }if (!fix->chained || fix->chained_before)break ; -if (++depth >10 ) -break ; id = fix->chain_id; } }
Greg Kroah-Hartman
maintainerPATCH 2/190 ALSA: hda/realtek - Fix overridden device-specific initialization
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream.
The recent change to shuffle the codec initialization procedure for Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") caused the silent output on some machines. This change was supposed to be safe, but it isn't actually; some devices have quirk setups to override the EAPD via COEF or BTL in the additional verb table, which is applied at the beginning of snd_hda_gen_init(). And this EAPD setup is again overridden in alc_auto_init_amp().
For recovering from the regression, tell snd_hda_gen_init() not to apply the verbs there by a new flag, then apply the verbs in alc_init().
--- sound/pci/hda/hda_generic.c | 3 ++- sound/pci/hda/hda_generic.h | 1 + sound/pci/hda/patch_realtek.c | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-)
sound/pci/hda/hda_generic.c +2 -1
@@ -5991,7 +5991,8 @@ int snd_hda_gen_init(struct hda_codec *cif (spec->init_hook) spec->init_hook (codec); -snd_hda_apply_verbs (codec); +if (!spec->skip_verbs) +snd_hda_apply_verbs (codec);init_multi_out (codec);init_extra_out (codec);
sound/pci/hda/hda_generic.h +1 -0
@@ -247,6 +247,7 @@ struct hda_gen_spec { unsigned int indep_hp_enabled:1; /* independent HP enabled */ unsigned int have_aamix_ctl:1; unsigned int hp_mic_jack_modes:1; + unsigned int skip_verbs:1; /* don't apply verbs at snd_hda_gen_init() *//* additional mute flags (only effective with auto_mute_via_amp=1) */ u64 mute_bits;
sound/pci/hda/patch_realtek.c +2 -0
@@ -836,9 +836,11 @@ static int alc_init(struct hda_codec *coif (spec->init_hook) spec->init_hook (codec); + spec->gen.skip_verbs =1 ;/* applied in below */ snd_hda_gen_init (codec);alc_fix_pll (codec);alc_auto_init_amp (codec, spec->init_amp); +snd_hda_apply_verbs (codec);/* apply verbs here after own init */ snd_hda_apply_fixup (codec,HDA_FIXUP_ACT_INIT );
Greg Kroah-Hartman
maintainerPATCH 3/190 ALSA: hda/realtek - Add quirk for HP Pavilion 15
In reply to Greg Kroah-HartmanFrom: Sam Bazley <[email protected]>
commit d33cd42d86671bed870827aa399aeb9f1da74119 upstream.
HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin.
[ rearranged in the SSID number order by tiwai ]
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -6845,6 +6845,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x103c ,0x82c0 ,"HP G3 mini premium" ,ALC221_FIXUP_HP_MIC_NO_PRESENCE ),SND_PCI_QUIRK (0x103c ,0x83b9 ,"HP Spectre x360" ,ALC269_FIXUP_HP_MUTE_LED_MIC3 ),SND_PCI_QUIRK (0x103c ,0x8497 ,"HP Envy x360" ,ALC269_FIXUP_HP_MUTE_LED_MIC3 ), +SND_PCI_QUIRK (0x103c ,0x84e7 ,"HP Pavilion 15" ,ALC269_FIXUP_HP_MUTE_LED_MIC3 ),SND_PCI_QUIRK (0x1043 ,0x103e ,"ASUS X540SA" ,ALC256_FIXUP_ASUS_MIC ),SND_PCI_QUIRK (0x1043 ,0x103f ,"ASUS TX300" ,ALC282_FIXUP_ASUS_TX300 ), SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
Greg Kroah-Hartman
maintainerPATCH 4/190 ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
In reply to Greg Kroah-HartmanFrom: Jian-Hong Pan <[email protected]>
commit 60083f9e94b2f28047d71ed778adf89357c1a8fb upstream.
Original pin node values of ASUS UX431FL with ALC294:
0x12 0xb7a601400x13 0x400000000x14 0x901701100x15 0x411111f00x16 0x411111f00x17 0x901701110x18 0x411111f00x19 0x411111f00x1a 0x411111f00x1b 0x411111f00x1d 0x4066852d0x1e 0x411111f00x1f 0x411111f00x21 0x04211020
1. Has duplicated internal speakers (0x14 & 0x17) which makes the output route become confused. So, the output volume cannot be changed by setting.
2. Misses the headset mic pin node.
This patch disables the confusing speaker (NID 0x14) and enables the headset mic (NID 0x19).
--- sound/pci/hda/patch_realtek.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
sound/pci/hda/patch_realtek.c +12 -0
@@ -5675,6 +5675,7 @@ enum {ALC286_FIXUP_ACER_AIO_HEADSET_MIC ,ALC256_FIXUP_ASUS_MIC_NO_PRESENCE ,ALC299_FIXUP_PREDATOR_SPK , + ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC, }; static const struct hda_fixup alc269_fixups[] = {
@@ -6703,6 +6704,16 @@ static const struct hda_fixup alc269_fix { } } }, + [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC ] = { + .type =HDA_FIXUP_PINS , + .v.pins = (const struct hda_pintbl []) { + {0x14 ,0x411111f0 },/* disable confusing internal speaker */ + {0x19 ,0x04a11150 },/* use as headset mic, without its own jack detect */ + { } + }, + .chained = true, + .chain_id =ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC + }, };static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6862,6 +6873,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x1043 ,0x1427 ,"Asus Zenbook UX31E" ,ALC269VB_FIXUP_ASUS_ZENBOOK ),SND_PCI_QUIRK (0x1043 ,0x1517 ,"Asus Zenbook UX31A" ,ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A ),SND_PCI_QUIRK (0x1043 ,0x16e3 ,"ASUS UX50" ,ALC269_FIXUP_STEREO_DMIC ), +SND_PCI_QUIRK (0x1043 ,0x17d1 ,"ASUS UX431FL" ,ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC ),SND_PCI_QUIRK (0x1043 ,0x1a13 ,"Asus G73Jw" ,ALC269_FIXUP_ASUS_G73JW ),SND_PCI_QUIRK (0x1043 ,0x1a30 ,"ASUS X705UD" ,ALC256_FIXUP_ASUS_MIC ), SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
Greg Kroah-Hartman
maintainerPATCH 5/190 ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre
In reply to Greg Kroah-HartmanFrom: Hui Wang <[email protected]>
commit 2a36c16efab254dd6017efeb35ad88ecc96f2328 upstream.
This ThinkCentre machine has a new realtek codec alc222, it is not in the support list, we add it in the realtek.c then this machine can apply FIXUPs for the realtek codec.
And this machine has two front mics which can't be handled by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't work on this machine. Fortunately another FIXUP ALC283_FIXUP_HEADSET_MIC also can change the location for one of the two mics on this machine.
--- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/patch_realtek.c +2 -0
@@ -6951,6 +6951,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x17aa ,0x312a ,"ThinkCentre Station" ,ALC294_FIXUP_LENOVO_MIC_LOCATION ),SND_PCI_QUIRK (0x17aa ,0x312f ,"ThinkCentre Station" ,ALC294_FIXUP_LENOVO_MIC_LOCATION ),SND_PCI_QUIRK (0x17aa ,0x313c ,"ThinkCentre Station" ,ALC294_FIXUP_LENOVO_MIC_LOCATION ), +SND_PCI_QUIRK (0x17aa ,0x3151 ,"ThinkCentre Station" ,ALC283_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x17aa ,0x3902 ,"Lenovo E50-80" ,ALC269_FIXUP_DMIC_THINKPAD_ACPI ),SND_PCI_QUIRK (0x17aa ,0x3977 ,"IdeaPad S210" ,ALC283_FIXUP_INT_MIC ), SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
@@ -8813,6 +8814,7 @@ static int patch_alc680(struct hda_codecstatic const struct hda_device_id snd_hda_id_realtek[] = {HDA_CODEC_ENTRY (0x10ec0215 ,"ALC215" , patch_alc269),HDA_CODEC_ENTRY (0x10ec0221 ,"ALC221" , patch_alc269), +HDA_CODEC_ENTRY (0x10ec0222 ,"ALC222" , patch_alc269),HDA_CODEC_ENTRY (0x10ec0225 ,"ALC225" , patch_alc269),HDA_CODEC_ENTRY (0x10ec0231 ,"ALC231" , patch_alc269),HDA_CODEC_ENTRY (0x10ec0233 ,"ALC233" , patch_alc269),
Greg Kroah-Hartman
maintainerPATCH 6/190 sched/fair: Dont assign runtime for throttled cfs_rq
In reply to Greg Kroah-HartmanFrom: Liangyan <[email protected]>
commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream.
do_sched_cfs_period_timer() will refill cfs_b runtime and call distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs attached to this cfs_b can't get runtime and will be throttled.
We find that one throttled cfs_rq has non-negative cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64 in snippet:
distribute_cfs_runtime() {
runtime = -cfs_rq->runtime_remaining + 1;
}The runtime here will change to a large number and consume all cfs_b->runtime in this cfs_b period.
According to Ben Segall, the throttled cfs_rq can have account_cfs_rq_runtime called on it because it is throttled before idle_balance, and the idle_balance calls update_rq_clock to add time that is accounted to the task.
This commit prevents cfs_rq to be assgined new runtime if it has been throttled until that distribute_cfs_runtime is called.
--- kernel/sched/fair.c | 5 +++++ 1 file changed, 5 insertions(+)
kernel/sched/fair.c +5 -0
@@ -4420,6 +4420,8 @@ static void __account_cfs_rq_runtime(strif (likely (cfs_rq->runtime_remaining >0 ))return ; +if (cfs_rq->throttled) +return ;/* * if we're unable to extend our runtime we resched so that the active * hierarchy can be throttled
@@ -4615,6 +4617,9 @@ static u64 distribute_cfs_runtime(structif (!cfs_rq_throttled (cfs_rq)) goto next; +/* By the above check, this should never be true */ +SCHED_WARN_ON (cfs_rq->runtime_remaining >0 ); + runtime = -cfs_rq->runtime_remaining +1 ;if (runtime > remaining) runtime = remaining;
Greg Kroah-Hartman
maintainerPATCH 7/190 drm/vmwgfx: Fix double free in vmw_recv_msg()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream.
We recently added a kfree() after the end of the loop:
if (retries == RETRIES) {
kfree(reply);
return -EINVAL;
}There are two problems. First the test is wrong and because retries equals RETRIES if we succeed on the last iteration through the loop. Second if we fail on the last iteration through the loop then the kfree is a double free.
When you're reading this code, please note the break statement at the end of the while loop. This patch changes the loop so that if it's not successful then "reply" is NULL and we can test for that afterward.
--- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +3 -5
@@ -353,7 +353,7 @@ static int vmw_recv_msg(struct rpc_chann !!(HIGH_WORD(ecx) & MESSAGE_STATUS_HB));if ((HIGH_WORD (ebx) &MESSAGE_STATUS_SUCCESS ) ==0 ) {kfree (reply); - + reply =NULL ;if ((HIGH_WORD (ebx) &MESSAGE_STATUS_CPT ) !=0 ) {/* A checkpoint occurred. Retry. */ continue ;
@@ -377,7 +377,7 @@ static int vmw_recv_msg(struct rpc_channif ((HIGH_WORD (ecx) &MESSAGE_STATUS_SUCCESS ) ==0 ) {kfree (reply); - + reply =NULL ;if ((HIGH_WORD (ecx) &MESSAGE_STATUS_CPT ) !=0 ) {/* A checkpoint occurred. Retry. */ continue ;
@@ -389,10 +389,8 @@ static int vmw_recv_msg(struct rpc_channbreak ; } -if (retries ==RETRIES ) { -kfree (reply); +if (!reply)return -EINVAL ; - } *msg_len = reply_len; *msg = reply;
Greg Kroah-Hartman
maintainerPATCH 8/190 vhost/test: fix build for vhost test
In reply to Greg Kroah-HartmanFrom: Tiwei Bie <[email protected]>
commit 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 upstream.
Since below commit, callers need to specify the iov_limit in vhost_dev_init() explicitly.
--- drivers/vhost/test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vhost/test.c +1 -1
@@ -116,7 +116,7 @@ static int vhost_test_open(struct inode dev = &n->dev; vqs[VHOST_TEST_VQ ] = &n->vqs[VHOST_TEST_VQ ]; n->vqs[VHOST_TEST_VQ ].handle_kick = handle_vq_kick; -vhost_dev_init (dev, vqs,VHOST_TEST_VQ_MAX ); +vhost_dev_init (dev, vqs,VHOST_TEST_VQ_MAX ,UIO_MAXIOV ); f->private_data = n;
Greg Kroah-Hartman
maintainerPATCH 9/190 vhost/test: fix build for vhost test - again
In reply to Greg Kroah-HartmanFrom: Tiwei Bie <[email protected]>
commit 264b563b8675771834419057cbe076c1a41fb666 upstream.
Since vhost_exceeds_weight() was introduced, callers need to specify the packet weight and byte weight in vhost_dev_init(). Note that, the packet weight isn't counted in this patch to keep the original behavior unchanged.
--- drivers/vhost/test.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/vhost/test.c +9 -4
@@ -23,6 +23,12 @@* Using this limit prevents one virtqueue from starving others. */ #define VHOST_TEST_WEIGHT 0x80000 +/* Max number of packets transferred before requeueing the job. +* Using this limit prevents one virtqueue from starving others with +* pkts. +*/ +#define VHOST_TEST_PKT_WEIGHT 256 +enum {VHOST_TEST_VQ =0 ,VHOST_TEST_VQ_MAX =1 ,
@@ -81,10 +87,8 @@ static void handle_vq(struct vhost_test }vhost_add_used_and_signal (&n->dev, vq, head,0 ); total_len += len; -if (unlikely (total_len >=VHOST_TEST_WEIGHT )) { -vhost_poll_queue (&vq->poll); +if (unlikely (vhost_exceeds_weight (vq,0 , total_len)))break ; - } }mutex_unlock (&vq->mutex);
@@ -116,7 +120,8 @@ static int vhost_test_open(struct inode dev = &n->dev; vqs[VHOST_TEST_VQ ] = &n->vqs[VHOST_TEST_VQ ]; n->vqs[VHOST_TEST_VQ ].handle_kick = handle_vq_kick; -vhost_dev_init (dev, vqs,VHOST_TEST_VQ_MAX ,UIO_MAXIOV ); +vhost_dev_init (dev, vqs,VHOST_TEST_VQ_MAX ,UIO_MAXIOV , +VHOST_TEST_PKT_WEIGHT ,VHOST_TEST_WEIGHT ); f->private_data = n;
Greg Kroah-Hartman
maintainerPATCH 10/190 powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
In reply to Greg Kroah-HartmanFrom: Gustavo Romero <[email protected]>
commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream.
When we take an FP unavailable exception in a transaction we have to account for the hardware FP TM checkpointed registers being incorrect. In this case for this process we know the current and checkpointed FP registers must be the same (since FP wasn't used inside the transaction) hence in the thread_struct we copy the current FP registers to the checkpointed ones.
This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr to determine if FP was on when in userspace. thread->ckpt_regs.msr represents the state of the MSR when exiting userspace. This is setup by check_if_tm_restore_required().
Unfortunatley there is an optimisation in giveup_all() which returns early if tsk->thread.regs->msr (via local variable usermsr) has FP=VEC=VSX=SPE=0. This optimisation means that check_if_tm_restore_required() is not called and hence thread->ckpt_regs.msr is not updated and will contain an old value.
This can happen if due to load_fp=255 we start a userspace process with MSR FP=1 and then we are context switched out. In this case thread->ckpt_regs.msr will contain FP=1. If that same process is then context switched in and load_fp overflows, MSR will have FP=0. If that process now enters a transaction and does an FP instruction, the FP unavailable will not update thread->ckpt_regs.msr (the bug) and MSR FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() will then not perform the required memcpy and the checkpointed FP regs in the thread struct will contain the wrong values.
The code path for this happening is:
Userspace: Kernel
Start userspace
with MSR FP/VEC/VSX/SPE=0 TM=1
< -----
...
tbegin
bne
fp instruction
FP unavailable
---- >
fp_unavailable_tm()
tm_reclaim_current()
tm_reclaim_thread()
giveup_all()
return early since FP/VMX/VSX=0
/* ckpt MSR not updated (Incorrect) */
tm_reclaim()
/* thread_struct ckpt FP regs contain junk (OK) */
/* Sees ckpt MSR FP=1 (Incorrect) */
no memcpy() performed
/* thread_struct ckpt FP regs not fixed (Incorrect) */
tm_recheckpoint()
/* Put junk in hardware checkpoint FP regs */
....
< -----
Return to userspace
with MSR TM=1 FP=1
with junk in the FP TM checkpoint
TM rollback
reads FP junkThis is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another.
This patch moves up check_if_tm_restore_required() in giveup_all() to ensure thread->ckpt_regs.msr is updated correctly.
A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c
Similarly for VMX.
This fixes CVE-2019-15030.
--- arch/powerpc/kernel/process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/powerpc/kernel/process.c +2 -1
@@ -499,13 +499,14 @@ void giveup_all(struct task_struct *tsk)if (!tsk->thread.regs)return ; +check_if_tm_restore_required (tsk); + usermsr = tsk->thread.regs->msr;if ((usermsr & msr_all_available) ==0 )return ;msr_check_and_set (msr_all_available); -check_if_tm_restore_required (tsk);WARN_ON ((usermsr &MSR_VSX ) && !((usermsr &MSR_FP ) && (usermsr &MSR_VEC )));
Greg Kroah-Hartman
maintainerPATCH 11/190 batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 3ee1bb7aae97324ec9078da1f00cb2176919563f upstream.
batadv_netlink_get_ifindex() needs to make sure user passed a correct u32 attribute.
syzbot reported :
BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968 genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482 netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253 __netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361 genl_family_rcv_msg net/netlink/genetlink.c:550 [inline] genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627 netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486 genl_rcv+0x63/0x80 net/netlink/genetlink.c:638 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337 netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg net/socket.c:661 [inline] ___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260 __sys_sendmsg net/socket.c:2298 [inline] __do_sys_sendmsg net/socket.c:2307 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2305 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x440209
--- net/batman-adv/netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/batman-adv/netlink.c +1 -1
@@ -118,7 +118,7 @@ batadv_netlink_get_ifindex(const struct {struct nlattr *attr =nlmsg_find_attr (nlh,GENL_HDRLEN , attrtype); -return attr ?nla_get_u32 (attr) :0 ; +return (attr &&nla_len (attr) ==sizeof (u32)) ?nla_get_u32 (attr) :0 ; }/**
Greg Kroah-Hartman
maintainerPATCH 12/190 batman-adv: Only read OGM tvlv_len after buffer len check
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit a15d56a60760aa9dbe26343b9a0ac5228f35d445 upstream.
Multiple batadv_ogm_packet can be stored in an skbuff. The functions batadv_iv_ogm_send_to_if()/batadv_iv_ogm_receive() use batadv_iv_ogm_aggr_packet() to check if there is another additional batadv_ogm_packet in the skb or not before they continue processing the packet.
The length for such an OGM is BATADV_OGM_HLEN + batadv_ogm_packet->tvlv_len. The check must first check that at least BATADV_OGM_HLEN bytes are available before it accesses tvlv_len (which is part of the header. Otherwise it might try read outside of the currently available skbuff to get the content of tvlv_len.
--- net/batman-adv/bat_iv_ogm.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-)
net/batman-adv/bat_iv_ogm.c +13 -7
@@ -463,17 +463,23 @@ static u8 batadv_hop_penalty(u8 tq, cons* batadv_iv_ogm_aggr_packet() - checks if there is another OGM attached * @buff_pos: current position in the skb * @packet_len: total length of the skb -* @tvlv_len: tvlv length of the previously considered OGM +* @ogm_packet: potential OGM in buffer * * Return: true if there is enough space for another OGM, false otherwise. */ -static bool batadv_iv_ogm_aggr_packet (int buff_pos,int packet_len, -__be16 tvlv_len) +static bool +batadv_iv_ogm_aggr_packet (int buff_pos,int packet_len, +const struct batadv_ogm_packet *ogm_packet) {int next_buff_pos =0 ; - next_buff_pos += buff_pos +BATADV_OGM_HLEN ; - next_buff_pos +=ntohs (tvlv_len); +/* check if there is enough space for the header */ + next_buff_pos += buff_pos +sizeof (*ogm_packet); +if (next_buff_pos > packet_len) +return false; + +/* check if there is enough space for the optional TVLV */ + next_buff_pos +=ntohs (ogm_packet->tvlv_len);return (next_buff_pos <= packet_len) && (next_buff_pos <=BATADV_MAX_AGGREGATION_BYTES );
@@ -501,7 +507,7 @@ static void batadv_iv_ogm_send_to_if(str/* adjust all flags and log packets */ while (batadv_iv_ogm_aggr_packet (buff_pos, forw_packet->packet_len, - batadv_ogm_packet->tvlv_len)) { + batadv_ogm_packet)) {/* we might have aggregated direct link packets with an * ordinary base packet */
@@ -1852,7 +1858,7 @@ static int batadv_iv_ogm_receive(struct/* unpack the aggregated packets and process them one by one */ while (batadv_iv_ogm_aggr_packet (ogm_offset,skb_headlen (skb), - ogm_packet->tvlv_len)) { + ogm_packet)) {batadv_iv_ogm_process (skb, ogm_offset, if_incoming); ogm_offset +=BATADV_OGM_HLEN ;
Greg Kroah-Hartman
maintainerPATCH 13/190 hv_sock: Fix hang when a connection is closed
In reply to Greg Kroah-Hartman[ Upstream commit 685703b497bacea8765bb409d6b73455b73c540e ]
There is a race condition for an established connection that is being closed by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the 'remove_sock' is false):
1 for the initial value;
1 for the sk being in the bound list;
1 for the sk being in the connected list;
1 for the delayed close_work.
After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may* decrease the refcnt to 3.
Concurrently, hvs_close_connection() runs in another thread:
calls vsock_remove_sock() to decrease the refcnt by 2; call sock_put() to decrease the refcnt to 0, and free the sk; next, the "release_sock(sk)" may hang due to use-after-free.
In the above, after hvs_release() finishes, if hvs_close_connection() runs faster than "__vsock_release() -> sock_put(sk)", then there is not any issue, because at the beginning of hvs_close_connection(), the refcnt is still 4.
The issue can be resolved if an extra reference is taken when the connection is established.
--- net/vmw_vsock/hyperv_transport.c | 8 ++++++++ 1 file changed, 8 insertions(+)
net/vmw_vsock/hyperv_transport.c +8 -0
@@ -320,6 +320,11 @@ static void hvs_close_connection(struct vmbus_channel *chan)lock_sock (sk);hvs_do_close_lock_held (vsock_sk (sk), true);release_sock (sk); + +/* Release the refcnt for the channel that's opened in +* hvs_open_connection(). +*/ +sock_put (sk); }static void hvs_open_connection (struct vmbus_channel *chan)
@@ -388,6 +393,9 @@ static void hvs_open_connection(struct vmbus_channel *chan) }set_per_channel_state (chan, conn_from_host ? new : sk); + +/* This reference will be dropped by hvs_close_connection(). */ +sock_hold (conn_from_host ? new : sk);vmbus_set_chn_rescind_callback (chan, hvs_close_connection);/* Set the pending send size to max packet size to always get
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 14/190 Blk-iolatency: warn on negative inflight IO counter
In reply to Greg Kroah-Hartman[ Upstream commit 391f552af213985d3d324c60004475759a7030c5 ]
This is to catch any unexpected negative value of inflight IO counter.
--- block/blk-iolatency.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
block/blk-iolatency.c +3 -1
@@ -560,6 +560,7 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)u64 now =ktime_to_ns (ktime_get ());bool issue_as_root =bio_issue_as_root_blkg (bio);bool enabled = false; +int inflight =0 ; blkg = bio->bi_blkg;if (!blkg)
@@ -585,7 +586,8 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio) } rqw = &iolat->rq_wait; -atomic_dec (&rqw->inflight); + inflight =atomic_dec_return (&rqw->inflight); +WARN_ON_ONCE (inflight <0 );if (iolat->min_lat_nsec ==0 ) goto next; iolatency_record_time(iolat, &bio->bi_issue, now,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 15/190 blk-iolatency: fix STS_AGAIN handling
In reply to Greg Kroah-Hartman[ Upstream commit c9b3007feca018d3f7061f5d5a14cb00766ffe9b ]
The iolatency controller is based on rq_qos. It increments on rq_qos_throttle() and decrements on either rq_qos_cleanup() or rq_qos_done_bio(). a3fb01ba5af0 fixes the double accounting issue where blk_mq_make_request() may call both rq_qos_cleanup() and rq_qos_done_bio() on REQ_NO_WAIT. So checking STS_AGAIN prevents the double decrement.
The above works upstream as the only way we can get STS_AGAIN is from blk_mq_get_request() failing. The STS_AGAIN handling isn't a real problem as bio_endio() skipping only happens on reserved tag allocation failures which can only be caused by driver bugs and already triggers WARN.
However, the fix creates a not so great dependency on how STS_AGAIN can be propagated. Internally, we (Facebook) carry a patch that kills read ahead if a cgroup is io congested or a fatal signal is pending. This combined with chained bios progagate their bi_status to the parent is not already set can can cause the parent bio to not clean up properly even though it was successful. This consequently leaks the inflight counter and can hang all IOs under that blkg.
To nip the adverse interaction early, this removes the rq_qos_cleanup() callback in iolatency in favor of cleaning up always on the rq_qos_done_bio() path.
--- block/blk-iolatency.c | 51 ++++++++++++------------------------------- 1 file changed, 14 insertions(+), 37 deletions(-)
block/blk-iolatency.c +14 -37
@@ -566,10 +566,6 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)if (!blkg)return ; -/* We didn't actually submit this bio, don't account it. */ -if (bio->bi_status ==BLK_STS_AGAIN ) -return ; - iolat =blkg_to_lat (bio->bi_blkg);if (!iolat)return ;
@@ -588,40 +584,22 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio) inflight =atomic_dec_return (&rqw->inflight);WARN_ON_ONCE (inflight <0 ); -if (iolat->min_lat_nsec ==0 ) - goto next; -iolatency_record_time (iolat, &bio->bi_issue, now, - issue_as_root); - window_start =atomic64_read (&iolat->window_start); -if (now > window_start && - (now - window_start) >= iolat->cur_win_nsec) { -if (atomic64_cmpxchg (&iolat->window_start, - window_start, now) == window_start) -iolatency_check_latencies (iolat, now); +/* +* If bi_status is BLK_STS_AGAIN, the bio wasn't actually +* submitted, so do not account for it. +*/ +if (iolat->min_lat_nsec && bio->bi_status !=BLK_STS_AGAIN ) { +iolatency_record_time (iolat, &bio->bi_issue, now, + issue_as_root); + window_start =atomic64_read (&iolat->window_start); +if (now > window_start && + (now - window_start) >= iolat->cur_win_nsec) { +if (atomic64_cmpxchg (&iolat->window_start, + window_start, now) == window_start) +iolatency_check_latencies (iolat, now); + } } -next: -wake_up (&rqw->wait); - blkg = blkg->parent; - } -} - -static void blkcg_iolatency_cleanup (struct rq_qos *rqos,struct bio *bio) -{ -struct blkcg_gq *blkg; - - blkg = bio->bi_blkg; -while (blkg && blkg->parent) { -struct rq_wait *rqw; -struct iolatency_grp *iolat; - - iolat =blkg_to_lat (blkg); -if (!iolat) - goto next; - - rqw = &iolat->rq_wait; -atomic_dec (&rqw->inflight);wake_up (&rqw->wait); -next: blkg = blkg->parent; } }
@@ -637,7 +615,6 @@ static void blkcg_iolatency_exit(struct rq_qos *rqos)static struct rq_qos_ops blkcg_iolatency_ops = { .throttle = blkcg_iolatency_throttle, - .cleanup = blkcg_iolatency_cleanup, .done_bio = blkcg_iolatency_done_bio, .exit = blkcg_iolatency_exit, };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 16/190 {nl,mac}80211: fix interface combinations on crypto controlled devices
In reply to Greg Kroah-Hartman[ Upstream commit e6f4051123fd33901e9655a675b22aefcdc5d277 ]
Commit 33d915d9e8ce ("{nl,mac}80211: allow 4addr AP operation on crypto controlled devices") has introduced a change which allows 4addr operation on crypto controlled devices (ex: ath10k). This change has inadvertently impacted the interface combinations logic on such devices.
General rule is that software interfaces like AP/VLAN should not be listed under supported interface combinations and should not be considered during validation of these combinations; because of the aforementioned change, AP/VLAN interfaces(if present) will be checked against interfaces supported by the device and blocks valid interface combinations.
Consider a case where an AP and AP/VLAN are up and running; when a second AP device is brought up on the same physical device, this AP will be checked against the AP/VLAN interface (which will not be part of supported interface combinations of the device) and blocks second AP to come up.
Add a new API cfg80211_iftype_allowed() to fix the problem, this API works for all devices with/without SW crypto control.
--- include/net/cfg80211.h | 15 +++++++++++++++ net/mac80211/util.c | 7 +++---- net/wireless/core.c | 6 ++---- net/wireless/nl80211.c | 4 +--- net/wireless/util.c | 27 +++++++++++++++++++++++++-- 5 files changed, 46 insertions(+), 13 deletions(-)
include/net/cfg80211.h +15 -0
@@ -6562,6 +6562,21 @@ int cfg80211_external_auth_request(struct net_device *netdev,struct cfg80211_external_auth_params *params, gfp_t gfp); +/** +* cfg80211_iftype_allowed - check whether the interface can be allowed +* @wiphy: the wiphy +* @iftype: interface type +* @is_4addr: use_4addr flag, must be '0' when check_swif is '1' +* @check_swif: check iftype against software interfaces +* +* Check whether the interface is allowed to operate; additionally, this API +* can be used to check iftype against the software interfaces when +* check_swif is '1'. +*/ +bool cfg80211_iftype_allowed (struct wiphy *wiphy,enum nl80211_iftype iftype, +bool is_4addr,u8 check_swif); + +/* Logging, debugging and troubleshooting/diagnostic helpers. */ /* wiphy_printk helpers, similar to dev_printk */
net/mac80211/util.c +3 -4
@@ -3527,9 +3527,7 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata, }/* Always allow software iftypes */ -if (local->hw.wiphy->software_iftypes &BIT (iftype) || - (iftype ==NL80211_IFTYPE_AP_VLAN && - local->hw.wiphy->flags &WIPHY_FLAG_4ADDR_AP )) { +if (cfg80211_iftype_allowed (local->hw.wiphy, iftype,0 ,1 )) {if (radar_detect)return -EINVAL ;return 0 ;
@@ -3564,7 +3562,8 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,if (sdata_iter == sdata || !ieee80211_sdata_running (sdata_iter) || - local->hw.wiphy->software_iftypes &BIT (wdev_iter->iftype)) +cfg80211_iftype_allowed (local->hw.wiphy, + wdev_iter->iftype,0 ,1 ))continue ; params.iftype_num[wdev_iter->iftype]++;
net/wireless/core.c +2 -4
@@ -1335,10 +1335,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb, }break ;case NETDEV_PRE_UP : -if (!(wdev->wiphy->interface_modes &BIT (wdev->iftype)) && - !(wdev->iftype ==NL80211_IFTYPE_AP_VLAN && - rdev->wiphy.flags &WIPHY_FLAG_4ADDR_AP && - wdev->use_4addr)) +if (!cfg80211_iftype_allowed (wdev->wiphy, wdev->iftype, + wdev->use_4addr,0 ))return notifier_from_errno (-EOPNOTSUPP );if (rfkill_blocked (rdev->rfkill))
net/wireless/nl80211.c +1 -3
@@ -3210,9 +3210,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)return err; } -if (!(rdev->wiphy.interface_modes & (1 << type)) && - !(type ==NL80211_IFTYPE_AP_VLAN && params.use_4addr && - rdev->wiphy.flags &WIPHY_FLAG_4ADDR_AP )) +if (!cfg80211_iftype_allowed (&rdev->wiphy, type, params.use_4addr,0 ))return -EOPNOTSUPP ; err =nl80211_parse_mon_options (rdev, type, info, ¶ms);
net/wireless/util.c +25 -2
@@ -1670,7 +1670,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,for (iftype =0 ; iftype <NUM_NL80211_IFTYPES ; iftype++) { num_interfaces += params->iftype_num[iftype];if (params->iftype_num[iftype] >0 && - !(wiphy->software_iftypes &BIT (iftype))) + !cfg80211_iftype_allowed (wiphy, iftype,0 ,1 )) used_iftypes |=BIT (iftype); }
@@ -1692,7 +1692,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,return -ENOMEM ;for (iftype =0 ; iftype <NUM_NL80211_IFTYPES ; iftype++) { -if (wiphy->software_iftypes &BIT (iftype)) +if (cfg80211_iftype_allowed (wiphy, iftype,0 ,1 ))continue ;for (j =0 ; j < c->n_limits; j++) { all_iftypes |= limits[j].types;
@@ -1895,3 +1895,26 @@ EXPORT_SYMBOL(rfc1042_header);const unsigned char bridge_tunnel_header[]__aligned(2) = {0xaa ,0xaa ,0x03 ,0x00 ,0x00 ,0xf8 };EXPORT_SYMBOL (bridge_tunnel_header); + +bool cfg80211_iftype_allowed (struct wiphy *wiphy,enum nl80211_iftype iftype, +bool is_4addr,u8 check_swif) + +{ +bool is_vlan = iftype ==NL80211_IFTYPE_AP_VLAN ; + +switch (check_swif) { +case 0 : +if (is_vlan && is_4addr) +return wiphy->flags &WIPHY_FLAG_4ADDR_AP ; +return wiphy->interface_modes &BIT (iftype); +case 1 : +if (!(wiphy->software_iftypes &BIT (iftype)) && is_vlan) +return wiphy->flags &WIPHY_FLAG_4ADDR_AP ; +return wiphy->software_iftypes &BIT (iftype); +default : +break ; + } + +return false; +} +EXPORT_SYMBOL (cfg80211_iftype_allowed);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 17/190 timekeeping: Use proper ktime_add when adding nsecs in coarse offset
In reply to Greg Kroah-Hartman[ Upstream commit 0354c1a3cdf31f44b035cfad14d32282e815a572 ]
While this doesn't actually amount to a real difference, since the macro evaluates to the same thing, every place else operates on ktime_t using these functions, so let's not break the pattern.
--- kernel/time/timekeeping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/time/timekeeping.c +1 -1
@@ -823,7 +823,7 @@ ktime_t ktime_get_coarse_with_offset(enum tk_offsets offs) }while (read_seqcount_retry (&tk_core.seq, seq)); -return base + nsecs; +return ktime_add_ns (base, nsecs); }EXPORT_SYMBOL_GPL (ktime_get_coarse_with_offset);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 18/190 selftests: fib_rule_tests: use pre-defined DEV_ADDR
In reply to Greg Kroah-Hartman[ Upstream commit 34632975cafdd07ce80e85c2eda4e9c16b5f2faa ]
DEV_ADDR is defined but not used. Use it in address setting. Do the same with IPv6 for consistency.
--- tools/testing/selftests/net/fib_rule_tests.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
tools/testing/selftests/net/fib_rule_tests.sh +3 -2
@@ -15,6 +15,7 @@ GW_IP6=2001:db8:1::2 SRC_IP6=2001:db8:1::3 DEV_ADDR=192.51.100.1 +DEV_ADDR6=2001:db8:1::1 DEV=dummy0 log_test()
@@ -55,8 +56,8 @@ setup() $IP link add dummy0 type dummy $IP link set dev dummy0 up - $IP address add 192.51.100.1/24 dev dummy0 - $IP -6 address add 2001:db8:1::1/64 dev dummy0 + $IP address add $DEV_ADDR/24 dev dummy0 + $IP -6 address add $DEV_ADDR6/64 dev dummy0 set +e }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 19/190 x86/ftrace: Fix warning and considate ftrace_jmp_replace() and ftrace_call_replace()
In reply to Greg Kroah-Hartman[ Upstream commit 745cfeaac09ce359130a5451d90cb0bd4094c290 ]
Arnd reported the following compiler warning:
arch/x86/kernel/ftrace.c:669:23: error: 'ftrace_jmp_replace' defined but not used [-Werror=unused-function]
The ftrace_jmp_replace() function now only has a single user and should be simply moved by that user. But looking at the code, it shows that ftrace_jmp_replace() is similar to ftrace_call_replace() except that instead of using the opcode of 0xe8 it uses 0xe9. It makes more sense to consolidate that function into one implementation that both ftrace_jmp_replace() and ftrace_call_replace() use by passing in the op code separate.
The structure in ftrace_code_union is also modified to replace the "e8" field with the more appropriate name "op".
--- arch/x86/kernel/ftrace.c | 42 ++++++++++++++++------------------------ 1 file changed, 17 insertions(+), 25 deletions(-)
arch/x86/kernel/ftrace.c +17 -25
@@ -53,7 +53,7 @@ int ftrace_arch_code_modify_post_process(void)union ftrace_code_union {char code[MCOUNT_INSN_SIZE ];struct { -unsigned char e8; +unsigned char op;int offset; } __attribute__((packed)); };
@@ -63,20 +63,23 @@ static int ftrace_calc_offset(long ip, long addr)return (int )(addr - ip); } -static unsigned char *ftrace_call_replace (unsigned long ip,unsigned long addr) +static unsigned char * +ftrace_text_replace (unsigned char op,unsigned long ip,unsigned long addr) {static union ftrace_code_union calc; - calc.e8 =0xe8 ; + calc.op = op; calc.offset =ftrace_calc_offset (ip +MCOUNT_INSN_SIZE , addr); -/* -* No locking needed, this must be called via kstop_machine -* which in essence is like running on a uniprocessor machine. -*/ return calc.code; } +static unsigned char * +ftrace_call_replace (unsigned long ip,unsigned long addr) +{ +return ftrace_text_replace (0xe8 , ip, addr); +} +static inline int within (unsigned long addr,unsigned long start,unsigned long end) {
@@ -686,22 +689,6 @@ int __init ftrace_dyn_arch_init(void)return 0 ; } -#if defined(CONFIG_X86_64 ) || defined(CONFIG_FUNCTION_GRAPH_TRACER ) -static unsigned char *ftrace_jmp_replace (unsigned long ip,unsigned long addr) -{ -static union ftrace_code_union calc; - -/* Jmp not a call (ignore the .e8) */ - calc.e8 =0xe9 ; - calc.offset =ftrace_calc_offset (ip +MCOUNT_INSN_SIZE , addr); - -/* -* ftrace external locks synchronize the access to the static variable. -*/ -return calc.code; -} -#endif -/* Currently only x86_64 supports dynamic trampolines */ #ifdef CONFIG_X86_64
@@ -923,8 +910,8 @@ static void *addr_from_call(void *ptr)return NULL ;/* Make sure this is a call */ -if (WARN_ON_ONCE (calc.e8 !=0xe8 )) { -pr_warn ("Expected e8, got %x\n" , calc.e8); +if (WARN_ON_ONCE (calc.op !=0xe8 )) { +pr_warn ("Expected e8, got %x\n" , calc.op);return NULL ; }
@@ -995,6 +982,11 @@ void arch_ftrace_trampoline_free(struct ftrace_ops *ops)#ifdef CONFIG_DYNAMIC_FTRACE extern void ftrace_graph_call (void ); +static unsigned char *ftrace_jmp_replace (unsigned long ip,unsigned long addr) +{ +return ftrace_text_replace (0xe9 , ip, addr); +} +static int ftrace_mod_jmp (unsigned long ip,void *func) {unsigned char *new;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 20/190 powerpc/64: mark start_here_multiplatform as __ref
In reply to Greg Kroah-Hartman[ Upstream commit 9c4e4c90ec24652921e31e9551fcaedc26eec86d ]
Otherwise, the following warning is encountered:
WARNING: vmlinux.o(.text+0x3dc6): Section mismatch in reference from the variable start_here_multiplatform to the function .init.text:.early_setup() The function start_here_multiplatform() references
the function __init .early_setup().
This is often because start_here_multiplatform lacks a __init
annotation or the annotation of .early_setup is wrong.
--- arch/powerpc/kernel/head_64.S | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/kernel/head_64.S +2 -0
@@ -906,6 +906,7 @@ p_toc: .8byte __toc_start + 0x8000 - 0b /* * This is where the main kernel code starts. */ +__REF start_here_multiplatform: /* set up the TOC */ bl relative_toc
@@ -981,6 +982,7 @@ start_here_multiplatform: RFI b . /* prevent speculative execution */ + .previous /* This is where all platforms converge execution */ start_here_common:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 21/190 media: stm32-dcmi: fix irq = 0 case
In reply to Greg Kroah-Hartman[ Upstream commit dbb9fcc8c2d8d4ea1104f51d4947a8a8199a2cb5 ]
Manage the irq = 0 case, where we shall return an error.
--- drivers/media/platform/stm32/stm32-dcmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/platform/stm32/stm32-dcmi.c +1 -1
@@ -1681,7 +1681,7 @@ static int dcmi_probe(struct platform_device *pdev)if (irq <=0 ) {if (irq != -EPROBE_DEFER )dev_err (&pdev->dev,"Could not get irq\n" ); -return irq; +return irq ? irq : -ENXIO ; } dcmi->res =platform_get_resource (pdev,IORESOURCE_MEM ,0 );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 22/190 arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64
In reply to Greg Kroah-Hartman[ Upstream commit 26e2d7b03ea7ff254bf78305aa44dda62e70b78e ]
After commit ef05bcb60c1a, boot from USB drives is broken. Fix this problem by enabling usb-host regulators during boot time.
--- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts +2 -0
@@ -40,6 +40,7 @@ pinctrl-0 = <&usb30_host_drv>; regulator-name = "vcc_host_5v"; regulator-always-on; + regulator-boot-on; vin-supply = <&vcc_sys>; };
@@ -50,6 +51,7 @@ pinctrl-0 = <&usb20_host_drv>; regulator-name = "vcc_host1_5v"; regulator-always-on; + regulator-boot-on; vin-supply = <&vcc_sys>; };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 23/190 scripts/decode_stacktrace: match basepath using shell prefix operator, not regex
In reply to Greg Kroah-Hartman[ Upstream commit 31013836a71e07751a6827f9d2ad41ef502ddaff ]
The basepath may contain special characters, which would confuse the regex matcher. ${var#prefix} does the right thing.
--- scripts/decode_stacktrace.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
scripts/decode_stacktrace.sh +1 -1
@@ -78,7 +78,7 @@ parse_symbol() { fi # Strip out the base of the path - code=${code//^$basepath/""} + code=${code#$basepath/} # In the case of inlines, move everything to same line code=${code//$'\n'/' '}
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 24/190 riscv: remove unused variable in ftrace
In reply to Greg Kroah-Hartman[ Upstream commit 397182e0db56b8894a43631ce72de14d90a29834 ]
Noticed while building kernel-4.20.0-0.rc5.git2.1.fc30 for Fedora 30/RISCV.
[..]
BUILDSTDERR: arch/riscv/kernel/ftrace.c: In function 'prepare_ftrace_return': BUILDSTDERR: arch/riscv/kernel/ftrace.c:135:6: warning: unused variable 'err' [-Wunused-variable] BUILDSTDERR: int err; BUILDSTDERR: ^~~
[..]
--- arch/riscv/kernel/ftrace.c | 1 - 1 file changed, 1 deletion(-)
arch/riscv/kernel/ftrace.c +0 -1
@@ -132,7 +132,6 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr, {unsigned long return_hooker = (unsigned long )&return_to_handler;unsigned long old; -int err;if (unlikely (atomic_read (¤t->tracing_graph_pause)))return ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 25/190 nvme-fc: use separate work queue to avoid warning
In reply to Greg Kroah-Hartman[ Upstream commit 8730c1ddb69bdeeb10c1f613a4e15e95862b1981 ]
When tearing down a controller the following warning is issued:
WARNING: CPU: 0 PID: 30681 at ../kernel/workqueue.c:2418 check_flush_dependency
This happens as the err_work workqueue item is scheduled on the system workqueue (which has WQ_MEM_RECLAIM not set), but is flushed from a workqueue which has WQ_MEM_RECLAIM set.
Fix this by providing an FC-NVMe specific workqueue.
--- drivers/nvme/host/fc.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/nvme/host/fc.c +12 -3
@@ -206,7 +206,7 @@ static LIST_HEAD(nvme_fc_lport_list);static DEFINE_IDA (nvme_fc_local_port_cnt);static DEFINE_IDA (nvme_fc_ctrl_cnt); - +static struct workqueue_struct *nvme_fc_wq;/* * These items are short-term. They will eventually be moved into
@@ -2053,7 +2053,7 @@ nvme_fc_error_recovery(struct nvme_fc_ctrl *ctrl, char *errmsg)*/ if (ctrl->ctrl.state ==NVME_CTRL_CONNECTING ) { active =atomic_xchg (&ctrl->err_work_active,1 ); -if (!active && !schedule_work (&ctrl->err_work)) { +if (!active && !queue_work (nvme_fc_wq, &ctrl->err_work)) {atomic_set (&ctrl->err_work_active,0 );WARN_ON (1 ); }
@@ -3321,6 +3321,10 @@ static int __init nvme_fc_init_module(void) {int ret; + nvme_fc_wq =alloc_workqueue ("nvme_fc_wq" ,WQ_MEM_RECLAIM ,0 ); +if (!nvme_fc_wq) +return -ENOMEM ; +/* * NOTE: * It is expected that in the future the kernel will combine
@@ -3338,7 +3342,8 @@ static int __init nvme_fc_init_module(void) fc_class =class_create (THIS_MODULE ,"fc" );if (IS_ERR (fc_class)) {pr_err ("couldn't register class fc\n" ); -return PTR_ERR (fc_class); + ret =PTR_ERR (fc_class); + goto out_destroy_wq; }/*
@@ -3362,6 +3367,9 @@ out_destroy_device:device_destroy (fc_class,MKDEV (0 ,0 )); out_destroy_class:class_destroy (fc_class); +out_destroy_wq: +destroy_workqueue (nvme_fc_wq); +return ret; }
@@ -3378,6 +3386,7 @@ static void __exit nvme_fc_exit_module(void)device_destroy (fc_class,MKDEV (0 ,0 ));class_destroy (fc_class); +destroy_workqueue (nvme_fc_wq); }module_init (nvme_fc_init_module);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 26/190 clk: s2mps11: Add used attribute to s2mps11_dt_match
In reply to Greg Kroah-Hartman[ Upstream commit 9c940bbe2bb47e03ca5e937d30b6a50bf9c0e671 ]
Clang warns after commit 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible"):
drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match' is not needed and will not be emitted [-Wunneeded-internal-declaration]
static const struct of_device_id s2mps11_dt_match[] = {
^1 warning generated.
This warning happens when a variable is used in some construct that doesn't require a reference to that variable to be emitted in the symbol table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold the data of the variable, not the variable itself.
$ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match 00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table
Normally, with device ID table variables, it means that the variable just needs to be tied to the device declaration at the bottom of the file, like s2mps11_clk_id:
$ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id 00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table 00000000 00000078 r s2mps11_clk_id
However, because the comment above this deliberately doesn't want this variable added to .of_match_table, we need to mark s2mps11_dt_match as __used to silence this warning. This makes it clear to Clang that the variable is used for something, even if a reference to it isn't being emitted.
--- drivers/clk/clk-s2mps11.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/clk-s2mps11.c +1 -1
@@ -255,7 +255,7 @@ MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);* This requires of_device_id table. In the same time this will not change the * actual *device* matching so do not add .of_match_table. */ -static const struct of_device_id s2mps11_dt_match[] = { +static const struct of_device_id s2mps11_dt_match[]__used = { { .compatible ="samsung,s2mps11-clk" , .data = (void *)S2MPS11X ,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 27/190 remoteproc: qcom: q6v5: shore up resource probe handling
In reply to Greg Kroah-Hartman[ Upstream commit 1e2517d126171a41f801738ffd19687836cd178a ]
Commit d5269c4553a6 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") fixed up our probe code to handle -EPROBE_DEFER, but it ignored one of our interrupts, and it also didn't really handle all the other error codes you might get (e.g., with a bad DT definition). Handle those all explicitly.
--- drivers/remoteproc/qcom_q6v5.c | 44 +++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 8 deletions(-)
drivers/remoteproc/qcom_q6v5.c +36 -8
@@ -188,6 +188,14 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,init_completion (&q6v5->stop_done); q6v5->wdog_irq =platform_get_irq_byname (pdev,"wdog" ); +if (q6v5->wdog_irq <0 ) { +if (q6v5->wdog_irq != -EPROBE_DEFER ) +dev_err (&pdev->dev, +"failed to retrieve wdog IRQ: %d\n" , + q6v5->wdog_irq); +return q6v5->wdog_irq; + } + ret = devm_request_threaded_irq(&pdev->dev, q6v5->wdog_irq, NULL, q6v5_wdog_interrupt, IRQF_TRIGGER_RISING | IRQF_ONESHOT,
@@ -198,8 +206,13 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev, } q6v5->fatal_irq =platform_get_irq_byname (pdev,"fatal" ); -if (q6v5->fatal_irq == -EPROBE_DEFER ) -return -EPROBE_DEFER ; +if (q6v5->fatal_irq <0 ) { +if (q6v5->fatal_irq != -EPROBE_DEFER ) +dev_err (&pdev->dev, +"failed to retrieve fatal IRQ: %d\n" , + q6v5->fatal_irq); +return q6v5->fatal_irq; + } ret = devm_request_threaded_irq(&pdev->dev, q6v5->fatal_irq, NULL, q6v5_fatal_interrupt,
@@ -211,8 +224,13 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev, } q6v5->ready_irq =platform_get_irq_byname (pdev,"ready" ); -if (q6v5->ready_irq == -EPROBE_DEFER ) -return -EPROBE_DEFER ; +if (q6v5->ready_irq <0 ) { +if (q6v5->ready_irq != -EPROBE_DEFER ) +dev_err (&pdev->dev, +"failed to retrieve ready IRQ: %d\n" , + q6v5->ready_irq); +return q6v5->ready_irq; + } ret = devm_request_threaded_irq(&pdev->dev, q6v5->ready_irq, NULL, q6v5_ready_interrupt,
@@ -224,8 +242,13 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev, } q6v5->handover_irq =platform_get_irq_byname (pdev,"handover" ); -if (q6v5->handover_irq == -EPROBE_DEFER ) -return -EPROBE_DEFER ; +if (q6v5->handover_irq <0 ) { +if (q6v5->handover_irq != -EPROBE_DEFER ) +dev_err (&pdev->dev, +"failed to retrieve handover IRQ: %d\n" , + q6v5->handover_irq); +return q6v5->handover_irq; + } ret = devm_request_threaded_irq(&pdev->dev, q6v5->handover_irq, NULL, q6v5_handover_interrupt,
@@ -238,8 +261,13 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,disable_irq (q6v5->handover_irq); q6v5->stop_irq =platform_get_irq_byname (pdev,"stop-ack" ); -if (q6v5->stop_irq == -EPROBE_DEFER ) -return -EPROBE_DEFER ; +if (q6v5->stop_irq <0 ) { +if (q6v5->stop_irq != -EPROBE_DEFER ) +dev_err (&pdev->dev, +"failed to retrieve stop-ack IRQ: %d\n" , + q6v5->stop_irq); +return q6v5->stop_irq; + } ret = devm_request_threaded_irq(&pdev->dev, q6v5->stop_irq, NULL, q6v5_stop_interrupt,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 28/190 modules: always page-align module section allocations
In reply to Greg Kroah-Hartman[ Upstream commit 38f054d549a869f22a02224cd276a27bf14b6171 ]
Some arches (e.g., arm64, x86) have moved towards non-executable module_alloc() allocations for security hardening reasons. That means that the module loader will need to set the text section of a module to executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always page-aligned to handle memory rwx permissions. On some arches with CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to executable, the BUG_ON() in frob_text() gets triggered since module section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n. Since the set_memory_* API works with pages, and since we need to call set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we might as well page-align all module section allocations for ease of managing rwx permissions of module sections (text, rodata, etc).
--- kernel/module.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
kernel/module.c +1 -6
@@ -76,14 +76,9 @@/* * Modules' sections will be aligned on page boundaries -* to ensure complete separation of code and data, but -* only when CONFIG_STRICT_MODULE_RWX=y +* to ensure complete separation of code and data */ -#ifdef CONFIG_STRICT_MODULE_RWX # define debug_align (X ) ALIGN(X, PAGE_SIZE) -#else -# define debug_align (X ) (X) -#endif /* If this is set, the section belongs in the init part of the module */ #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 29/190 kernel/module: Fix mem leak in module_add_modinfo_attrs
In reply to Greg Kroah-Hartman[ Upstream commit bc6f2a757d525e001268c3658bd88822e768f8db ]
In module_add_modinfo_attrs if sysfs_create_file
fails, we forget to free allocated modinfo_attrs
and roll back the sysfs files.
--- kernel/module.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
kernel/module.c +17 -5
@@ -1694,6 +1694,8 @@ static int add_usage_links(struct module *mod)return ret; } +static void module_remove_modinfo_attrs (struct module *mod,int end); +static int module_add_modinfo_attrs (struct module *mod) {struct module_attribute *attr;
@@ -1708,24 +1710,34 @@ static int module_add_modinfo_attrs(struct module *mod)return -ENOMEM ; temp_attr = mod->modinfo_attrs; -for (i =0 ; (attr = modinfo_attrs[i]) && !error; i++) { +for (i =0 ; (attr = modinfo_attrs[i]); i++) {if (!attr->test || attr->test (mod)) {memcpy (temp_attr, attr,sizeof (*temp_attr));sysfs_attr_init (&temp_attr->attr); error =sysfs_create_file (&mod->mkobj.kobj, &temp_attr->attr); +if (error) + goto error_out; ++temp_attr; } } + +return 0 ; + +error_out: +if (i >0 ) +module_remove_modinfo_attrs (mod, --i);return error; } -static void module_remove_modinfo_attrs (struct module *mod) +static void module_remove_modinfo_attrs (struct module *mod,int end) {struct module_attribute *attr;int i;for (i =0 ; (attr = &mod->modinfo_attrs[i]); i++) { +if (end >=0 && i > end) +break ;/* pick a field to test for end of list */ if (!attr->attr.name)break ;
@@ -1813,7 +1825,7 @@ static int mod_sysfs_setup(struct module *mod,return 0 ; out_unreg_modinfo_attrs: -module_remove_modinfo_attrs (mod); +module_remove_modinfo_attrs (mod,-1 ); out_unreg_param:module_param_sysfs_remove (mod); out_unreg_holders:
@@ -1849,7 +1861,7 @@ static void mod_sysfs_fini(struct module *mod) { } -static void module_remove_modinfo_attrs (struct module *mod) +static void module_remove_modinfo_attrs (struct module *mod,int end) { }
@@ -1865,7 +1877,7 @@ static void init_param_lock(struct module *mod)static void mod_sysfs_teardown (struct module *mod) {del_usage_links (mod); -module_remove_modinfo_attrs (mod); +module_remove_modinfo_attrs (mod,-1 );module_param_sysfs_remove (mod);kobject_put (mod->mkobj.drivers_dir);kobject_put (mod->holders_dir);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 30/190 drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
In reply to Greg Kroah-Hartman[ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ]
This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again.
This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook")
--- drivers/gpu/drm/i915/intel_dp.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/gpu/drm/i915/intel_dp.c +16 -0
@@ -4739,6 +4739,22 @@ intel_dp_long_pulse(struct intel_connector *connector,*/ status = connector_status_disconnected; goto out; + }else { +/* +* If display is now connected check links status, +* there has been known issues of link loss triggering +* long pulse. +* +* Some sinks (eg. ASUS PB287Q) seem to perform some +* weird HPD ping pong during modesets. So we can apparently +* end up with HPD going low during a modeset, and then +* going back up soon after. And once that happens we must +* retrain the link to get a picture. That's in case no +* userspace component reacted to intermittent HPD dip. +*/ +struct intel_encoder *encoder = &dp_to_dig_port (intel_dp)->base; + +intel_dp_retrain_link (encoder, ctx); }/*
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 31/190 media: cec/v4l2: move V4L2 specific CEC functions to V4L2
In reply to Greg Kroah-Hartman[ Upstream commit 9cfd2753f8f3923f89cbb15f940f3aa0e7202d3e ]
Several CEC functions are actually specific for use with receivers, i.e. they should be part of the V4L2 subsystem, not CEC.
These functions deal with validating and modifying EDIDs for (HDMI) receivers, and they do not actually have anything to do with the CEC subsystem and whether or not CEC is enabled. The problem was that if the CEC_CORE config option was not set, then these functions would become stubs, but that's not right: they should always be valid.
So replace the cec_ prefix by v4l2_ and move them to v4l2-dv-timings.c. Update all drivers that call these accordingly.
--- drivers/media/cec/cec-edid.c | 71 -------- drivers/media/i2c/adv7604.c | 4 +- drivers/media/i2c/adv7842.c | 4 +- drivers/media/i2c/tc358743.c | 2 +- drivers/media/platform/vivid/vivid-vid-cap.c | 4 +- .../media/platform/vivid/vivid-vid-common.c | 2 +- drivers/media/v4l2-core/v4l2-dv-timings.c | 151 ++++++++++++++++++ include/media/cec.h | 80 ---------- include/media/v4l2-dv-timings.h | 6 + 9 files changed, 165 insertions(+), 159 deletions(-)
drivers/media/cec/cec-edid.c +0 -71
@@ -22,74 +22,3 @@ u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size,return (edid[loc] <<8 ) | edid[loc +1 ]; }EXPORT_SYMBOL_GPL (cec_get_edid_phys_addr); - -void cec_set_edid_phys_addr (u8 *edid,unsigned int size,u16 phys_addr) -{ -unsigned int loc =cec_get_edid_spa_location (edid, size); -u8 sum =0 ; -unsigned int i; - -if (loc ==0 ) -return ; - edid[loc] = phys_addr >>8 ; - edid[loc +1 ] = phys_addr &0xff ; - loc &= ~0x7f ; - -/* update the checksum */ -for (i = loc; i < loc +127 ; i++) - sum += edid[i]; - edid[i] =256 - sum; -} -EXPORT_SYMBOL_GPL (cec_set_edid_phys_addr); - -u16 cec_phys_addr_for_input (u16 phys_addr,u8 input) -{ -/* Check if input is sane */ -if (WARN_ON (input ==0 || input >0xf )) -return CEC_PHYS_ADDR_INVALID ; - -if (phys_addr ==0 ) -return input <<12 ; - -if ((phys_addr &0x0fff ) ==0 ) -return phys_addr | (input <<8 ); - -if ((phys_addr &0x00ff ) ==0 ) -return phys_addr | (input <<4 ); - -if ((phys_addr &0x000f ) ==0 ) -return phys_addr | input; - -/* -* All nibbles are used so no valid physical addresses can be assigned -* to the input. -*/ -return CEC_PHYS_ADDR_INVALID ; -} -EXPORT_SYMBOL_GPL (cec_phys_addr_for_input); - -int cec_phys_addr_validate (u16 phys_addr,u16 *parent,u16 *port) -{ -int i; - -if (parent) - *parent = phys_addr; -if (port) - *port =0 ; -if (phys_addr ==CEC_PHYS_ADDR_INVALID ) -return 0 ; -for (i =0 ; i <16 ; i +=4 ) -if (phys_addr & (0xf << i)) -break ; -if (i ==16 ) -return 0 ; -if (parent) - *parent = phys_addr & (0xfff0 << i); -if (port) - *port = (phys_addr >> i) &0xf ; -for (i +=4 ; i <16 ; i +=4 ) -if ((phys_addr & (0xf << i)) ==0 ) -return -EINVAL ; -return 0 ; -} -EXPORT_SYMBOL_GPL (cec_phys_addr_validate);
drivers/media/i2c/adv7604.c +2 -2
@@ -2297,8 +2297,8 @@ static int adv76xx_set_edid(struct v4l2_subdev *sd, struct v4l2_edid *edid) edid->blocks =2 ;return -E2BIG ; } - pa =cec_get_edid_phys_addr (edid->edid, edid->blocks *128 , &spa_loc); - err =cec_phys_addr_validate (pa, &pa,NULL ); + pa =v4l2_get_edid_phys_addr (edid->edid, edid->blocks *128 , &spa_loc); + err =v4l2_phys_addr_validate (pa, &pa,NULL );if (err)return err;
drivers/media/i2c/adv7842.c +2 -2
@@ -791,8 +791,8 @@ static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port)return 0 ; } - pa =cec_get_edid_phys_addr (edid,256 , &spa_loc); - err =cec_phys_addr_validate (pa, &pa,NULL ); + pa =v4l2_get_edid_phys_addr (edid,256 , &spa_loc); + err =v4l2_phys_addr_validate (pa, &pa,NULL );if (err)return err;
drivers/media/i2c/tc358743.c +1 -1
@@ -1789,7 +1789,7 @@ static int tc358743_s_edid(struct v4l2_subdev *sd,return -E2BIG ; } pa =cec_get_edid_phys_addr (edid->edid, edid->blocks *128 ,NULL ); - err =cec_phys_addr_validate (pa, &pa,NULL ); + err =v4l2_phys_addr_validate (pa, &pa,NULL );if (err)return err;
drivers/media/platform/vivid/vivid-vid-cap.c +2 -2
@@ -1724,7 +1724,7 @@ int vidioc_s_edid(struct file *file, void *_fh,return -E2BIG ; } phys_addr =cec_get_edid_phys_addr (edid->edid, edid->blocks *128 ,NULL ); - ret =cec_phys_addr_validate (phys_addr, &phys_addr,NULL ); + ret =v4l2_phys_addr_validate (phys_addr, &phys_addr,NULL );if (ret)return ret;
@@ -1740,7 +1740,7 @@ set_phys_addr:for (i =0 ; i <MAX_OUTPUTS && dev->cec_tx_adap[i]; i++)cec_s_phys_addr (dev->cec_tx_adap[i], -cec_phys_addr_for_input (phys_addr, i +1 ), +v4l2_phys_addr_for_input (phys_addr, i +1 ), false);return 0 ; }
drivers/media/platform/vivid/vivid-vid-common.c +1 -1
@@ -863,7 +863,7 @@ int vidioc_g_edid(struct file *file, void *_fh,if (edid->blocks > dev->edid_blocks - edid->start_block) edid->blocks = dev->edid_blocks - edid->start_block;if (adap) -cec_set_edid_phys_addr (dev->edid, dev->edid_blocks *128 , adap->phys_addr); +v4l2_set_edid_phys_addr (dev->edid, dev->edid_blocks *128 , adap->phys_addr);memcpy (edid->edid, dev->edid + edid->start_block *128 , edid->blocks *128 );return 0 ; }
drivers/media/v4l2-core/v4l2-dv-timings.c +151 -0
160 lines not on this page · raw message
include/media/cec.h +0 -80
92 lines not on this page · raw message
include/media/v4l2-dv-timings.h +6 -0
@@ -234,4 +234,10 @@ v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,const struct hdmi_vendor_infoframe *hdmi, unsigned int height); +u16 v4l2_get_edid_phys_addr (const u8 *edid,unsigned int size, +unsigned int *offset); +void v4l2_set_edid_phys_addr (u8 *edid,unsigned int size,u16 phys_addr); +u16 v4l2_phys_addr_for_input (u16 phys_addr,u8 input); +int v4l2_phys_addr_validate (u16 phys_addr,u16 *parent,u16 *port); +#endif
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 32/190 media: cec: remove cec-edid.c
In reply to Greg Kroah-Hartman[ Upstream commit f94d463f1b7f83d465ed77521821583dbcdaa3c5 ]
Move cec_get_edid_phys_addr() to cec-adap.c. It's not worth keeping a separate source for this.
--- drivers/media/cec/Makefile | 2 +- drivers/media/cec/cec-adap.c | 13 +++++++++++++ drivers/media/cec/cec-edid.c | 24 ------------------------ 3 files changed, 14 insertions(+), 25 deletions(-) delete mode 100644 drivers/media/cec/cec-edid.c
drivers/media/cec/Makefile +1 -1
@@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -cec-objs := cec-core.o cec-adap.o cec-api.o cec-edid.o +cec-objs := cec-core.o cec-adap.o cec-api.o ifeq ($(CONFIG_CEC_NOTIFIER),y) cec-objs += cec-notifier.o
drivers/media/cec/cec-adap.c +13 -0
@@ -62,6 +62,19 @@ static unsigned int cec_log_addr2dev(const struct cec_adapter *adap, u8 log_addrreturn adap->log_addrs.primary_device_type[i <0 ?0 : i]; } +u16 cec_get_edid_phys_addr (const u8 *edid,unsigned int size, +unsigned int *offset) +{ +unsigned int loc =cec_get_edid_spa_location (edid, size); + +if (offset) + *offset = loc; +if (loc ==0 ) +return CEC_PHYS_ADDR_INVALID ; +return (edid[loc] <<8 ) | edid[loc +1 ]; +} +EXPORT_SYMBOL_GPL (cec_get_edid_phys_addr); +/* * Queue a new event for this filehandle. If ts == 0, then set it * to the current time.
drivers/media/cec/cec-edid.c deleted +0 -24
@@ -1,24 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* -* cec-edid - HDMI Consumer Electronics Control EDID & CEC helper functions -* -* Copyright 2016 Cisco Systems, Inc. and/or its affiliates. All rights reserved. -*/ - -#include <linux/module.h> -#include <linux/kernel.h> -#include <linux/types.h> -#include <media/cec.h> - -u16 cec_get_edid_phys_addr (const u8 *edid,unsigned int size, -unsigned int *offset) -{ -unsigned int loc =cec_get_edid_spa_location (edid, size); - -if (offset) - *offset = loc; -if (loc ==0 ) -return CEC_PHYS_ADDR_INVALID ; -return (edid[loc] <<8 ) | edid[loc +1 ]; -} -EXPORT_SYMBOL_GPL (cec_get_edid_phys_addr);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 33/190 scsi: qla2xxx: Move log messages before issuing command to firmware
In reply to Greg Kroah-Hartman[ Upstream commit 9fe278f44b4bc06cc61e33b2af65f87d507d13d0 ]
There is a probability that the SRB structure might have been released by the time the debug log message dereferences it. This patch moved the log messages before the command is issued to the firmware to prevent unknown behavior and kernel crash
--- drivers/scsi/qla2xxx/qla_gs.c | 15 ++++++----- drivers/scsi/qla2xxx/qla_init.c | 48 +++++++++++++++++---------------- 2 files changed, 33 insertions(+), 30 deletions(-)
drivers/scsi/qla2xxx/qla_gs.c +8 -7
@@ -3360,15 +3360,15 @@ int qla24xx_async_gpsc(scsi_qla_host_t *vha, fc_port_t *fcport) sp->u.iocb_cmd.timeout = qla2x00_async_iocb_timeout; sp->done = qla24xx_async_gpsc_sp_done; - rval =qla2x00_start_sp (sp); -if (rval !=QLA_SUCCESS ) - goto done_free_sp; -ql_dbg (ql_dbg_disc, vha,0x205e ,"Async-%s %8phC hdl=%x loopid=%x portid=%02x%02x%02x.\n" , sp->name, fcport->port_name, sp->handle, fcport->loop_id, fcport->d_id.b.domain, fcport->d_id.b.area, fcport->d_id.b.al_pa); + + rval =qla2x00_start_sp (sp); +if (rval !=QLA_SUCCESS ) + goto done_free_sp;return rval; done_free_sp:
@@ -3729,13 +3729,14 @@ int qla24xx_async_gpnid(scsi_qla_host_t *vha, port_id_t *id) sp->u.iocb_cmd.timeout = qla2x00_async_iocb_timeout; sp->done = qla2x00_async_gpnid_sp_done; +ql_dbg (ql_dbg_disc, vha,0x2067 , +"Async-%s hdl=%x ID %3phC.\n" , sp->name, + sp->handle, ct_req->req.port_id.port_id); + rval =qla2x00_start_sp (sp);if (rval !=QLA_SUCCESS ) goto done_free_sp; -ql_dbg (ql_dbg_disc, vha,0x2067 , -"Async-%s hdl=%x ID %3phC.\n" , sp->name, - sp->handle, ct_req->req.port_id.port_id);return rval; done_free_sp:
drivers/scsi/qla2xxx/qla_init.c +25 -23
113 lines not on this page · raw message
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 34/190 keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h
In reply to Greg Kroah-Hartman[ Upstream commit 2ecefa0a15fd0ef88b9cd5d15ceb813008136431 ]
The keyctl_dh_params struct in uapi/linux/keyctl.h contains the symbol "private" which means that the header file will cause compilation failure if #included in to a C++ program. Further, the patch that added the same struct to the keyutils package named the symbol "priv", not "private".
The previous attempt to fix this (commit 8a2336e549d3) did so by simply renaming the kernel's copy of the field to dh_private, but this then breaks existing userspace and as such has been reverted (commit 8c0f9f5b309d).
[And note, to those who think that wrapping the struct in extern "C" {}
will work: it won't; that only changes how symbol names are presented to the assembler and linker.].
Instead, insert an anonymous union around the "private" member and add a second member in there with the name "priv" to match the one in the keyutils package. The "private" member is then wrapped in !__cplusplus cpp-conditionals to hide it from C++.
--- include/uapi/linux/keyctl.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
include/uapi/linux/keyctl.h +6 -1
@@ -65,7 +65,12 @@/* keyctl structures */ struct keyctl_dh_params { -__s32 private; +union { +#ifndef __cplusplus +__s32 private; +#endif +__s32 priv; + };__s32 prime;__s32 base; };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 35/190 Drivers: hv: kvp: Fix two "this statement may fall through" warnings
In reply to Greg Kroah-Hartman[ Upstream commit fc62c3b1977d62e6374fd6e28d371bb42dfa5c9d ]
We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on the op code from the host to the userspace; when the userspace returns the info requested by the host, we pass the info on to the host in kvp_respond_to_host() -> process_ob_ipinfo(). BTW, the current buggy code actually doesn't cause any harm, because only message->kvp_hdr.operation is used by the userspace, in the case of KVP_OP_GET_IP_INFO.
The patch also adds a missing "break;" in kvp_send_key(). BTW, the current buggy code actually doesn't cause any harm, because in the case of KVP_OP_SET, the unexpected fall-through corrupts message->body.kvp_set.data.key_size, but that is not really used: see the definition of struct hv_kvp_exchg_msg_value.
--- drivers/hv/hv_kvp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/hv/hv_kvp.c +4 -2
@@ -353,7 +353,6 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg, int op) out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled; -default : utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id, MAX_ADAPTER_ID_SIZE, UTF16_LITTLE_ENDIAN,
@@ -406,7 +405,7 @@ kvp_send_key(struct work_struct *dummy)process_ib_ipinfo (in_msg, message,KVP_OP_SET_IP_INFO );break ;case KVP_OP_GET_IP_INFO : -process_ib_ipinfo (in_msg, message,KVP_OP_GET_IP_INFO ); +/* We only need to pass on message->kvp_hdr.operation. */ break ;case KVP_OP_SET :switch (in_msg->body.kvp_set.data.value_type) {
@@ -446,6 +445,9 @@ kvp_send_key(struct work_struct *dummy)break ; } + +break ; +case KVP_OP_GET : message->body.kvp_set.data.key_size = utf16s_to_utf8s(
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 36/190 x86, hibernate: Fix nosave_regions setup for hibernation
In reply to Greg Kroah-Hartman[ Upstream commit cc55f7537db6af371e9c1c6a71161ee40f918824 ]
On 32bit systems, nosave_regions(non RAM areas) located between max_low_pfn and max_pfn are not excluded from hibernation snapshot currently, which may result in a machine check exception when trying to access these unsafe regions during hibernation:
[ 612.800453] Disabling lock debugging due to kernel taint
[ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136
[ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560}
[ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086
[ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24
[ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt
[ 612.853380] Kernel panic - not syncing: Fatal machine check
[ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff)This is because on 32bit systems, pages above max_low_pfn are regarded as high memeory, and accessing unsafe pages might cause expected MCE. On the problematic 32bit system, there are reserved memory above low memory, which triggered the MCE:
e820 memory mapping:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data [ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable [ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable
Fix this problem by changing pfn limit from max_low_pfn to max_pfn. This fix does not impact 64bit system because on 64bit max_low_pfn is the same as max_pfn.
--- arch/x86/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/setup.c +1 -1
@@ -1251,7 +1251,7 @@ void __init setup_arch(char **cmdline_p) x86_init.hyper.guest_late_init ();e820__reserve_resources (); -e820__register_nosave_regions (max_low_pfn); +e820__register_nosave_regions (max_pfn); x86_init.resources.reserve_resources ();
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 37/190 remoteproc: qcom: q6v5-mss: add SCM probe dependency
In reply to Greg Kroah-Hartman[ Upstream commit bbcda30271752bb7490f2e2aef5411dbcae69116 ]
The memory ownership transfer request is performed using SCM, ensure that SCM is available before we probe the driver if memory protection is needed by the subsystem.
--- drivers/remoteproc/qcom_q6v5_pil.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/remoteproc/qcom_q6v5_pil.c +3 -0
@@ -1132,6 +1132,9 @@ static int q6v5_probe(struct platform_device *pdev)if (!desc)return -EINVAL ; +if (desc->need_mem_protection && !qcom_scm_is_available ()) +return -EPROBE_DEFER ; + rproc =rproc_alloc (&pdev->dev, pdev->name, &q6v5_ops, desc->hexagon_mba_image,sizeof (*qproc));if (!rproc) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 38/190 drm/amdgpu/gfx9: Update gfx9 golden settings.
In reply to Greg Kroah-Hartman[ Upstream commit 54d682d9a5b357eb711994fa94ef1bc44d7ce9d9 ]
Update the goldensettings for vega20.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +1 -1
@@ -82,7 +82,7 @@ MODULE_FIRMWARE("amdgpu/raven_rlc.bin");static const struct soc15_reg_golden golden_settings_gc_9_0[] = { -SOC15_REG_GOLDEN_VALUE (GC ,0 , mmDB_DEBUG2,0xf00fffff ,0x00000420 ), +SOC15_REG_GOLDEN_VALUE (GC ,0 , mmDB_DEBUG2,0xf00fffff ,0x00000400 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmGB_GPU_ID,0x0000000f ,0x00000000 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmPA_SC_BINNER_EVENT_CNTL_3,0x00000003 ,0x82400024 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmPA_SC_ENHANCE,0x3fffffff ,0x00000001 ),
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 39/190 drm/amdgpu: Update gc_9_0 golden settings.
In reply to Greg Kroah-Hartman[ Upstream commit c55045adf7210d246a016c961916f078ed31a951 ]
Add mmDB_DEBUG3 settings.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +1 -0
@@ -83,6 +83,7 @@ MODULE_FIRMWARE("amdgpu/raven_rlc.bin");static const struct soc15_reg_golden golden_settings_gc_9_0[] = {SOC15_REG_GOLDEN_VALUE (GC ,0 , mmDB_DEBUG2,0xf00fffff ,0x00000400 ), +SOC15_REG_GOLDEN_VALUE (GC ,0 , mmDB_DEBUG3,0x80000000 ,0x80000000 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmGB_GPU_ID,0x0000000f ,0x00000000 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmPA_SC_BINNER_EVENT_CNTL_3,0x00000003 ,0x82400024 ),SOC15_REG_GOLDEN_VALUE (GC ,0 , mmPA_SC_ENHANCE,0x3fffffff ,0x00000001 ),
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 40/190 KVM: x86: hyperv: enforce vp_index < KVM_MAX_VCPUS
In reply to Greg Kroah-Hartman[ Upstream commit 9170200ec0ebad70e5b9902bc93e2b1b11456a3b ]
Hyper-V TLFS (5.0b) states:
Quoted 5 lines
Virtual processors are identified by using an index (VP index). The maximum number of virtual processors per partition supported by the current implementation of the hypervisor can be obtained through CPUID leaf
0x40000005. A virtual processor index must be less than the maximum number of virtual processors per partition.
Forbid userspace to set VP_INDEX above KVM_MAX_VCPUS. get_vcpu_by_vpidx() can now be optimized to bail early when supplied vpidx is >= KVM_MAX_VCPUS.
--- arch/x86/kvm/hyperv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/kvm/hyperv.c +5 -3
@@ -132,8 +132,10 @@ static struct kvm_vcpu *get_vcpu_by_vpidx(struct kvm *kvm, u32 vpidx)struct kvm_vcpu *vcpu =NULL ;int i; -if (vpidx <KVM_MAX_VCPUS ) - vcpu =kvm_get_vcpu (kvm, vpidx); +if (vpidx >=KVM_MAX_VCPUS ) +return NULL ; + + vcpu =kvm_get_vcpu (kvm, vpidx);if (vcpu &&vcpu_to_hv_vcpu (vcpu)->vp_index == vpidx)return vcpu;kvm_for_each_vcpu (i, vcpu, kvm)
@@ -1044,7 +1046,7 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)switch (msr) {case HV_X64_MSR_VP_INDEX : -if (!host) +if (!host || (u32 )data >=KVM_MAX_VCPUS )return 1 ; hv->vp_index = (u32 )data;break ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 41/190 KVM: x86: hyperv: consistently use hv_vcpu for struct kvm_vcpu_hv variables
In reply to Greg Kroah-Hartman[ Upstream commit 1779a39f786397760ae7a7cc03cf37697d8ae58d ]
Rename 'hv' to 'hv_vcpu' in kvm_hv_set_msr/kvm_hv_get_msr(); 'hv' is 'reserved' for 'struct kvm_hv' variables across the file.
--- arch/x86/kvm/hyperv.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
arch/x86/kvm/hyperv.c +9 -9
@@ -1042,20 +1042,20 @@ static u64 current_task_runtime_100ns(void)static int kvm_hv_set_msr (struct kvm_vcpu *vcpu,u32 msr,u64 data,bool host) { -struct kvm_vcpu_hv *hv = &vcpu->arch.hyperv; +struct kvm_vcpu_hv *hv_vcpu = &vcpu->arch.hyperv;switch (msr) {case HV_X64_MSR_VP_INDEX :if (!host || (u32 )data >=KVM_MAX_VCPUS )return 1 ; - hv->vp_index = (u32 )data; + hv_vcpu->vp_index = (u32 )data;break ;case HV_X64_MSR_VP_ASSIST_PAGE : {u64 gfn;unsigned long addr;if (!(data &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE )) { - hv->hv_vapic = data; + hv_vcpu->hv_vapic = data;if (kvm_lapic_enable_pv_eoi (vcpu,0 ))return 1 ;break ;
@@ -1066,7 +1066,7 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)return 1 ;if (__clear_user ((void __user *)addr,PAGE_SIZE ))return 1 ; - hv->hv_vapic = data; + hv_vcpu->hv_vapic = data;kvm_vcpu_mark_page_dirty (vcpu, gfn);if (kvm_lapic_enable_pv_eoi (vcpu,gfn_to_gpa (gfn) |KVM_MSR_ENABLED ))
@@ -1082,7 +1082,7 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)case HV_X64_MSR_VP_RUNTIME :if (!host)return 1 ; - hv->runtime_offset = data -current_task_runtime_100ns (); + hv_vcpu->runtime_offset = data -current_task_runtime_100ns ();break ;case HV_X64_MSR_SCONTROL :case HV_X64_MSR_SVERSION :
@@ -1174,11 +1174,11 @@ static int kvm_hv_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata, bool host) {u64 data =0 ; -struct kvm_vcpu_hv *hv = &vcpu->arch.hyperv; +struct kvm_vcpu_hv *hv_vcpu = &vcpu->arch.hyperv;switch (msr) {case HV_X64_MSR_VP_INDEX : - data = hv->vp_index; + data = hv_vcpu->vp_index;break ;case HV_X64_MSR_EOI :return kvm_hv_vapic_msr_read (vcpu,APIC_EOI , pdata);
@@ -1187,10 +1187,10 @@ static int kvm_hv_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata,case HV_X64_MSR_TPR :return kvm_hv_vapic_msr_read (vcpu,APIC_TASKPRI , pdata);case HV_X64_MSR_VP_ASSIST_PAGE : - data = hv->hv_vapic; + data = hv_vcpu->hv_vapic;break ;case HV_X64_MSR_VP_RUNTIME : - data =current_task_runtime_100ns () + hv->runtime_offset; + data =current_task_runtime_100ns () + hv_vcpu->runtime_offset;break ;case HV_X64_MSR_SCONTROL :case HV_X64_MSR_SVERSION :
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 42/190 KVM: x86: hyperv: keep track of mismatched VP indexes
In reply to Greg Kroah-Hartman[ Upstream commit 87ee613d076351950b74383215437f841ebbeb75 ]
In most common cases VP index of a vcpu matches its vcpu index. Userspace is, however, free to set any mapping it wishes and we need to account for that when we need to find a vCPU with a particular VP index. To keep search algorithms optimal in both cases introduce 'num_mismatched_vp_indexes' counter showing how many vCPUs with mismatching VP index we have. In case the counter is zero we can assume vp_index == vcpu_idx.
--- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/hyperv.c | 26 +++++++++++++++++++++++--- 2 files changed, 26 insertions(+), 3 deletions(-)
arch/x86/include/asm/kvm_host.h +3 -0
@@ -784,6 +784,9 @@ struct kvm_hv {u64 hv_reenlightenment_control;u64 hv_tsc_emulation_control;u64 hv_tsc_emulation_status; + +/* How many vCPUs have VP index != vCPU index */ +atomic_t num_mismatched_vp_indexes; };enum kvm_irqchip_mode {
arch/x86/kvm/hyperv.c +23 -3
@@ -1045,11 +1045,31 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)struct kvm_vcpu_hv *hv_vcpu = &vcpu->arch.hyperv;switch (msr) { -case HV_X64_MSR_VP_INDEX : -if (!host || (u32 )data >=KVM_MAX_VCPUS ) +case HV_X64_MSR_VP_INDEX : { +struct kvm_hv *hv = &vcpu->kvm->arch.hyperv; +int vcpu_idx =kvm_vcpu_get_idx (vcpu); +u32 new_vp_index = (u32 )data; + +if (!host || new_vp_index >=KVM_MAX_VCPUS )return 1 ; - hv_vcpu->vp_index = (u32 )data; + +if (new_vp_index == hv_vcpu->vp_index) +return 0 ; + +/* +* The VP index is initialized to vcpu_index by +* kvm_hv_vcpu_postcreate so they initially match. Now the +* VP index is changing, adjust num_mismatched_vp_indexes if +* it now matches or no longer matches vcpu_idx. +*/ +if (hv_vcpu->vp_index == vcpu_idx) +atomic_inc (&hv->num_mismatched_vp_indexes); +else if (new_vp_index == vcpu_idx) +atomic_dec (&hv->num_mismatched_vp_indexes); + + hv_vcpu->vp_index = new_vp_index;break ; + }case HV_X64_MSR_VP_ASSIST_PAGE : {u64 gfn;unsigned long addr;
Signature · 1 line
2.20.1
Re: [PATCH 4.19 042/190] KVM: x86: hyperv: keep track of mismatched VP indexes
Quoted 7 lines · Greg Kroah-Hartman
[ Upstream commit
87ee613d076351950b74383215437f841ebbeb75]In most common cases VP index of a vcpu matches its vcpu index. Userspace is, however, free to set any mapping it wishes and we need to account for that when we need to find a vCPU with a particular VP index. To keep search algorithms optimal in both cases introduce '
num_mismatched_vp_indexes' counter showing how many vCPUs with mismatching VP index we have. In case the counter is zero we can assumevp_index==vcpu_idx.
I don't see why this is stable material.
arch/x86/include/asm/kvm_host.h struct kvm_hv { · line 790
Quoted 8 lines
arch/x86/include/asm/kvm_host.h +3
-0u64 hv_reenlightenment_control;u64 hv_tsc_emulation_control;u64 hv_tsc_emulation_status; + +/* How many vCPUs have VP index != vCPU index */ +atomic_t num_mismatched_vp_indexes; };
It adds a write-only variable ...
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Greg Kroah-Hartman
maintainerPATCH 43/190 KVM: hyperv: define VP assist page helpers
In reply to Greg Kroah-Hartman[ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ]
The state related to the VP assist page is still managed by the LAPIC code in the pv_eoi field.
--- arch/x86/kvm/hyperv.c | 23 +++++++++++++++++++++-- arch/x86/kvm/hyperv.h | 4 ++++ arch/x86/kvm/lapic.c | 4 ++-- arch/x86/kvm/lapic.h | 2 +- arch/x86/kvm/x86.c | 2 +- 5 files changed, 29 insertions(+), 6 deletions(-)
arch/x86/kvm/hyperv.c +21 -2
@@ -691,6 +691,24 @@ void kvm_hv_vcpu_uninit(struct kvm_vcpu *vcpu)stimer_cleanup (&hv_vcpu->stimer[i]); } +bool kvm_hv_assist_page_enabled (struct kvm_vcpu *vcpu) +{ +if (!(vcpu->arch.hyperv.hv_vapic &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE )) +return false; +return vcpu->arch.pv_eoi.msr_val &KVM_MSR_ENABLED ; +} +EXPORT_SYMBOL_GPL (kvm_hv_assist_page_enabled); + +bool kvm_hv_get_assist_page (struct kvm_vcpu *vcpu, +struct hv_vp_assist_page *assist_page) +{ +if (!kvm_hv_assist_page_enabled (vcpu)) +return false; +return !kvm_read_guest_cached (vcpu->kvm, &vcpu->arch.pv_eoi.data, + assist_page,sizeof (*assist_page)); +} +EXPORT_SYMBOL_GPL (kvm_hv_get_assist_page); +static void stimer_prepare_msg (struct kvm_vcpu_hv_stimer *stimer) {struct hv_message *msg = &stimer->msg;
@@ -1076,7 +1094,7 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host)if (!(data &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE )) { hv_vcpu->hv_vapic = data; -if (kvm_lapic_enable_pv_eoi (vcpu,0 )) +if (kvm_lapic_enable_pv_eoi (vcpu,0 ,0 ))return 1 ;break ; }
@@ -1089,7 +1107,8 @@ static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, u64 data, bool host) hv_vcpu->hv_vapic = data;kvm_vcpu_mark_page_dirty (vcpu, gfn);if (kvm_lapic_enable_pv_eoi (vcpu, -gfn_to_gpa (gfn) |KVM_MSR_ENABLED )) +gfn_to_gpa (gfn) |KVM_MSR_ENABLED , +sizeof (struct hv_vp_assist_page )))return 1 ;break ; }
arch/x86/kvm/hyperv.h +4 -0
@@ -62,6 +62,10 @@ void kvm_hv_vcpu_init(struct kvm_vcpu *vcpu);void kvm_hv_vcpu_postcreate (struct kvm_vcpu *vcpu);void kvm_hv_vcpu_uninit (struct kvm_vcpu *vcpu); +bool kvm_hv_assist_page_enabled (struct kvm_vcpu *vcpu); +bool kvm_hv_get_assist_page (struct kvm_vcpu *vcpu, +struct hv_vp_assist_page *assist_page); +static inline struct kvm_vcpu_hv_stimer *vcpu_to_stimer (struct kvm_vcpu *vcpu,int timer_index) {
arch/x86/kvm/lapic.c +2 -2
@@ -2633,7 +2633,7 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)return 0 ; } -int kvm_lapic_enable_pv_eoi (struct kvm_vcpu *vcpu,u64 data) +int kvm_lapic_enable_pv_eoi (struct kvm_vcpu *vcpu,u64 data,unsigned long len) {u64 addr = data & ~KVM_MSR_ENABLED ;if (!IS_ALIGNED (addr,4 ))
@@ -2643,7 +2643,7 @@ int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data)if (!pv_eoi_enabled (vcpu))return 0 ;return kvm_gfn_to_hva_cache_init (vcpu->kvm, &vcpu->arch.pv_eoi.data, - addr,sizeof (u8)); + addr, len); }void kvm_apic_accept_events (struct kvm_vcpu *vcpu)
arch/x86/kvm/lapic.h +1 -1
@@ -120,7 +120,7 @@ static inline bool kvm_hv_vapic_assist_page_enabled(struct kvm_vcpu *vcpu)return vcpu->arch.hyperv.hv_vapic &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE ; } -int kvm_lapic_enable_pv_eoi (struct kvm_vcpu *vcpu,u64 data); +int kvm_lapic_enable_pv_eoi (struct kvm_vcpu *vcpu,u64 data,unsigned long len);void kvm_lapic_init (void );void kvm_lapic_exit (void );
arch/x86/kvm/x86.c +1 -1
@@ -2494,7 +2494,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)break ;case MSR_KVM_PV_EOI_EN : -if (kvm_lapic_enable_pv_eoi (vcpu, data)) +if (kvm_lapic_enable_pv_eoi (vcpu, data,sizeof (u8)))return 1 ;break ;
Signature · 1 line
2.20.1
Re: [PATCH 4.19 043/190] KVM: hyperv: define VP assist page helpers
Quoted 4 lines · Greg Kroah-Hartman
[ Upstream commit
72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc]The state related to the VP assist page is still managed by the LAPIC code in the
pv_eoifield.
I don't get it.
Quoted 9 lines
arch/x86/kvm/hyperv.c +8
-0+bool kvm_hv_assist_page_enabled (struct kvm_vcpu *vcpu) +{ +if (!(vcpu->arch.hyperv.hv_vapic &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE )) +return false; +return vcpu->arch.pv_eoi.msr_val &KVM_MSR_ENABLED ; +} +EXPORT_SYMBOL_GPL (kvm_hv_assist_page_enabled); +
arch/x86/kvm/hyperv.c void kvm_hv_vcpu_uninit(struct kvm_vcpu *vcpu) · line 711
Quoted 10 lines
arch/x86/kvm/hyperv.c +10
-0+bool kvm_hv_get_assist_page (struct kvm_vcpu *vcpu, +struct hv_vp_assist_page *assist_page) +{ +if (!kvm_hv_assist_page_enabled (vcpu)) +return false; +return !kvm_read_guest_cached (vcpu->kvm, &vcpu->arch.pv_eoi.data, + assist_page,sizeof (*assist_page)); +} +EXPORT_SYMBOL_GPL (kvm_hv_get_assist_page); +
This adds two functions, but not their users. What bug is it fixing? I don't see any users in the next patch, either.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Sasha Levin
maintainerRe: [PATCH 4.19 043/190] KVM: hyperv: define VP assist page helpers
Quoted 22 lines · Pavel Machek
Quoted 4 lines · Greg Kroah-Hartman
[ Upstream commit
72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc]The state related to the VP assist page is still managed by the LAPIC code in the
pv_eoifield.I don't get it.
Quoted 14 lines
arch/x86/kvm/hyperv.c +13
-0+bool kvm_hv_assist_page_enabled (struct kvm_vcpu *vcpu) +{ +if (!(vcpu->arch.hyperv.hv_vapic &HV_X64_MSR_VP_ASSIST_PAGE_ENABLE )) +return false; +return vcpu->arch.pv_eoi.msr_val &KVM_MSR_ENABLED ; +} +EXPORT_SYMBOL_GPL (kvm_hv_assist_page_enabled); + +bool kvm_hv_get_assist_page (struct kvm_vcpu *vcpu, +struct hv_vp_assist_page *assist_page) +{ +if (!kvm_hv_assist_page_enabled (vcpu)) +return false;
Quoted 8 lines
arch/x86/kvm/hyperv.c void kvm_hv_vcpu_uninit(struct kvm_vcpu *vcpu) · line 711
Quoted 5 lines
arch/x86/kvm/hyperv.c +5
-0+return !kvm_read_guest_cached (vcpu->kvm, &vcpu->arch.pv_eoi.data, + assist_page,sizeof (*assist_page)); +} +EXPORT_SYMBOL_GPL (kvm_hv_get_assist_page); +This adds two functions, but not their users. What bug is it fixing? I don't see any users in the next patch, either.
Look closer at the following patch.
--
Thanks,
Sasha
Greg Kroah-Hartman
maintainerPATCH 44/190 x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
In reply to Greg Kroah-Hartman[ Upstream commit a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 ]
vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM native case it is 8. In case we restore KVM-native MSR last cache will be reinitialized with len=8 so trying to access VP assist page beyond 8 bytes with kvm_read_guest_cached() will fail.
Check if we re-initializing cache for the same address and preserve length in case it was greater.
--- arch/x86/kvm/lapic.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/x86/kvm/lapic.c +10 -2
@@ -2636,14 +2636,22 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)int kvm_lapic_enable_pv_eoi (struct kvm_vcpu *vcpu,u64 data,unsigned long len) {u64 addr = data & ~KVM_MSR_ENABLED ; +struct gfn_to_hva_cache *ghc = &vcpu->arch.pv_eoi.data; +unsigned long new_len; +if (!IS_ALIGNED (addr,4 ))return 1 ; vcpu->arch.pv_eoi.msr_val = data;if (!pv_eoi_enabled (vcpu))return 0 ; -return kvm_gfn_to_hva_cache_init (vcpu->kvm, &vcpu->arch.pv_eoi.data, - addr, len); + +if (addr == ghc->gpa && len <= ghc->len) + new_len = ghc->len; +else + new_len = len; + +return kvm_gfn_to_hva_cache_init (vcpu->kvm, ghc, addr, new_len); }void kvm_apic_accept_events (struct kvm_vcpu *vcpu)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 45/190 drm/i915: Fix intel_dp_mst_best_encoder()
In reply to Greg Kroah-Hartman[ Upstream commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c ]
Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder.
So, fix this by always returning a valid encoder regardless of the state of the MST port.
Changes since v1:
- Remove mst atomic helper, since this got replaced with a much simpler solution
--- drivers/gpu/drm/i915/intel_dp_mst.c | 2 -- 1 file changed, 2 deletions(-)
drivers/gpu/drm/i915/intel_dp_mst.c +0 -2
@@ -408,8 +408,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *cstruct intel_dp *intel_dp = intel_connector->mst_port;struct intel_crtc *crtc =to_intel_crtc (state->crtc); -if (!READ_ONCE (connector->registered)) -return NULL ;return &intel_dp->mst_encoders[crtc->pipe]->base.base; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 46/190 drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE
In reply to Greg Kroah-Hartman[ Upstream commit 53867b46fa8443713b3aee520d6ca558b222d829 ]
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE
--- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-)
drivers/gpu/drm/i915/i915_reg.h +1 -1
@@ -6531,7 +6531,7 @@ enum {#define PLANE_CTL_YUV422_UYVY (1 << 16)#define PLANE_CTL_YUV422_YVYU (2 << 16)#define PLANE_CTL_YUV422_VYUY (3 << 16) -#define PLANE_CTL_DECOMPRESSION_ENABLE (1 << 15) +#define PLANE_CTL_RENDER_DECOMPRESSION_ENABLE (1 << 15)#define PLANE_CTL_TRICKLE_FEED_DISABLE (1 << 14)#define PLANE_CTL_PLANE_GAMMA_DISABLE (1 << 13)/* Pre-GLK */ #define PLANE_CTL_TILED_MASK (0x7 << 10)
drivers/gpu/drm/i915/intel_display.c +4 -4
@@ -3561,11 +3561,11 @@ static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)case I915_FORMAT_MOD_Y_TILED :return PLANE_CTL_TILED_Y ;case I915_FORMAT_MOD_Y_TILED_CCS : -return PLANE_CTL_TILED_Y |PLANE_CTL_DECOMPRESSION_ENABLE ; +return PLANE_CTL_TILED_Y |PLANE_CTL_RENDER_DECOMPRESSION_ENABLE ;case I915_FORMAT_MOD_Yf_TILED:return PLANE_CTL_TILED_YF ;case I915_FORMAT_MOD_Yf_TILED_CCS: -return PLANE_CTL_TILED_YF |PLANE_CTL_DECOMPRESSION_ENABLE ; +return PLANE_CTL_TILED_YF |PLANE_CTL_RENDER_DECOMPRESSION_ENABLE ;default :MISSING_CASE (fb_modifier); }
@@ -8812,13 +8812,13 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc, fb->modifier =I915_FORMAT_MOD_X_TILED ;break ;case PLANE_CTL_TILED_Y : -if (val &PLANE_CTL_DECOMPRESSION_ENABLE ) +if (val &PLANE_CTL_RENDER_DECOMPRESSION_ENABLE ) fb->modifier =I915_FORMAT_MOD_Y_TILED_CCS ;else fb->modifier =I915_FORMAT_MOD_Y_TILED ;break ;case PLANE_CTL_TILED_YF : -if (val &PLANE_CTL_DECOMPRESSION_ENABLE ) +if (val &PLANE_CTL_RENDER_DECOMPRESSION_ENABLE ) fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS;else fb->modifier = I915_FORMAT_MOD_Yf_TILED;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 47/190 drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
In reply to Greg Kroah-Hartman[ Upstream commit 914a4fd8cd28016038ce749a818a836124a8d270 ]
If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption on the screen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
--- drivers/gpu/drm/i915/intel_display.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/intel_display.c +23 -2
@@ -2712,6 +2712,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,if (size_aligned *2 > dev_priv->stolen_usable_size)return false; +switch (fb->modifier) { +case DRM_FORMAT_MOD_LINEAR : +case I915_FORMAT_MOD_X_TILED : +case I915_FORMAT_MOD_Y_TILED : +break ; +default : +DRM_DEBUG_DRIVER ("Unsupported modifier for initial FB: 0x%llx\n" , + fb->modifier); +return false; + } +mutex_lock (&dev->struct_mutex); obj = i915_gem_object_create_stolen_for_preallocated(dev_priv, base_aligned,
@@ -2721,8 +2732,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,if (!obj)return false; -if (plane_config->tiling ==I915_TILING_X ) - obj->tiling_and_stride = fb->pitches[0 ] |I915_TILING_X ; +switch (plane_config->tiling) { +case I915_TILING_NONE : +break ; +case I915_TILING_X : +case I915_TILING_Y : + obj->tiling_and_stride = fb->pitches[0 ] | plane_config->tiling; +break ; +default : +MISSING_CASE (plane_config->tiling); +return false; + } mode_cmd.pixel_format = fb->format->format; mode_cmd.width = fb->width;
@@ -8812,6 +8832,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc, fb->modifier =I915_FORMAT_MOD_X_TILED ;break ;case PLANE_CTL_TILED_Y : + plane_config->tiling =I915_TILING_Y ;if (val &PLANE_CTL_RENDER_DECOMPRESSION_ENABLE ) fb->modifier =I915_FORMAT_MOD_Y_TILED_CCS ;else
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 48/190 drm/atomic_helper: Disallow new modesets on unregistered connectors
In reply to Greg Kroah-Hartman[ Upstream commit 4d80273976bf880c4bed9359b8f2d45663140c86 ]
With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors.
Changes since v5:
- Fix typo in comment, nothing else
--- drivers/gpu/drm/drm_atomic_helper.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_atomic_helper.c +20 -1
@@ -307,6 +307,26 @@ update_connector_routing(struct drm_atomic_state *state,return 0 ; } + crtc_state =drm_atomic_get_new_crtc_state (state, + new_connector_state->crtc); +/* +* For compatibility with legacy users, we want to make sure that +* we allow DPMS On->Off modesets on unregistered connectors. Modesets +* which would result in anything else must be considered invalid, to +* avoid turning on new displays on dead connectors. +* +* Since the connector can be unregistered at any point during an +* atomic check or commit, this is racy. But that's OK: all we care +* about is ensuring that userspace can't do anything but shut off the +* display on a connector that was destroyed after its been notified, +* not before. +*/ +if (!READ_ONCE (connector->registered) && crtc_state->active) { +DRM_DEBUG_ATOMIC ("[CONNECTOR:%d:%s] is not registered\n" , + connector->base.id, connector->name); +return -EINVAL ; + } + funcs = connector->helper_private;if (funcs->atomic_best_encoder)
@@ -351,7 +371,6 @@ update_connector_routing(struct drm_atomic_state *state,set_best_encoder (state, new_connector_state, new_encoder); - crtc_state =drm_atomic_get_new_crtc_state (state, new_connector_state->crtc); crtc_state->connectors_changed = true; DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 49/190 Drivers: hv: kvp: Fix the indentation of some "break" statements
In reply to Greg Kroah-Hartman[ Upstream commit d544c22d6951be3386ac59bb9a99c9bc566b3f09 ]
No functional change.
--- drivers/hv/hv_kvp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/hv/hv_kvp.c +4 -4
@@ -420,7 +420,7 @@ kvp_send_key(struct work_struct *dummy)UTF16_LITTLE_ENDIAN , message->body.kvp_set.data.value, HV_KVP_EXCHANGE_MAX_VALUE_SIZE - 1) + 1; -break ; +break ;case REG_U32 :/*
@@ -456,7 +456,7 @@ kvp_send_key(struct work_struct *dummy)UTF16_LITTLE_ENDIAN , message->body.kvp_set.data.key, HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1; -break ; +break ;case KVP_OP_DELETE : message->body.kvp_delete.key_size =
@@ -466,12 +466,12 @@ kvp_send_key(struct work_struct *dummy)UTF16_LITTLE_ENDIAN , message->body.kvp_delete.key, HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1; -break ; +break ;case KVP_OP_ENUMERATE : message->body.kvp_enum_data.index = in_msg->body.kvp_enum_data.index; -break ; +break ; } kvp_transaction.state =HVUTIL_USERSPACE_REQ ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 50/190 Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
In reply to Greg Kroah-Hartman[ Upstream commit e670de54c813b5bc3672dd1c67871dc60e9206f4 ]
In kvp_send_key(), we do need call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out the userland hv_kvp_daemon needs the info of operation, adapter_id and addr_family. With the incorrect fc62c3b1977d, the host can't get the VM's IP via KVP.
And, fc62c3b1977d added a "break;", but actually forgot to initialize the key_size/value in the case of KVP_OP_SET, so the default key_size of 0 is passed to the kvp daemon, and the pool files /var/lib/hyperv/.kvp_pool_* can't be updated.
This patch effectively rolls back the previous fc62c3b1977d, and correctly fixes the "this statement may fall through" warnings.
This patch is tested on WS 2012 R2 and 2016.
--- drivers/hv/hv_kvp.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-)
drivers/hv/hv_kvp.c +22 -4
@@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg, int op) out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled; +/* fallthrough */ + +case KVP_OP_GET_IP_INFO : utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id, MAX_ADAPTER_ID_SIZE, UTF16_LITTLE_ENDIAN,
@@ -405,7 +408,11 @@ kvp_send_key(struct work_struct *dummy)process_ib_ipinfo (in_msg, message,KVP_OP_SET_IP_INFO );break ;case KVP_OP_GET_IP_INFO : -/* We only need to pass on message->kvp_hdr.operation. */ +/* +* We only need to pass on the info of operation, adapter_id +* and addr_family to the userland kvp daemon. +*/ +process_ib_ipinfo (in_msg, message,KVP_OP_GET_IP_INFO );break ;case KVP_OP_SET :switch (in_msg->body.kvp_set.data.value_type) {
@@ -446,9 +453,9 @@ kvp_send_key(struct work_struct *dummy) } -break ; - -case KVP_OP_GET : +/* +* The key is always a string - utf16 encoding. +*/ message->body.kvp_set.data.key_size = utf16s_to_utf8s( (wchar_t *)in_msg->body.kvp_set.data.key,
@@ -456,6 +463,17 @@ kvp_send_key(struct work_struct *dummy)UTF16_LITTLE_ENDIAN , message->body.kvp_set.data.key, HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1; + +break ; + +case KVP_OP_GET : + message->body.kvp_get.data.key_size = +utf16s_to_utf8s ( + (wchar_t *)in_msg->body.kvp_get.data.key, + in_msg->body.kvp_get.data.key_size, +UTF16_LITTLE_ENDIAN , + message->body.kvp_get.data.key, +HV_KVP_EXCHANGE_MAX_KEY_SIZE -1 ) +1 ;break ;case KVP_OP_DELETE :
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 51/190 powerplay: Respect units on max dcfclk watermark
In reply to Greg Kroah-Hartman[ Upstream commit f191415b24a3ad3fa22088af7cd7fc328a2f469f ]
In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks.
One division by 100 was not converted into a division by 1000.
--- drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c +1 -1
@@ -674,7 +674,7 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table, table->WatermarkRow[1 ][i].MaxClock =cpu_to_le16 ((uint16_t ) (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz) / -100 ); +1000 ); table->WatermarkRow[1 ][i].MinUclk = cpu_to_le16((uint16_t) (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz) /
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 52/190 drm/amd/pp: Fix truncated clock value when set watermark
In reply to Greg Kroah-Hartman[ Upstream commit 4d454e9ffdb1ef5a51ebc147b5389c96048db683 ]
the clk value should be tranferred to MHz first and then transfer to uint16. otherwise, the clock value will be truncated.
--- .../gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c +16 -16
@@ -669,20 +669,20 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table,for (i =0 ; i < wm_with_clock_ranges->num_wm_dmif_sets; i++) { table->WatermarkRow[1 ][i].MinClock =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_dcfclk_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_dcfclk_clk_in_khz / +1000 )); table->WatermarkRow[1 ][i].MaxClock =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_dcfclk_clk_in_khz / +1000 )); table->WatermarkRow[1 ][i].MinUclk =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_min_mem_clk_in_khz / +1000 )); table->WatermarkRow[1 ][i].MaxUclk =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_mem_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_max_mem_clk_in_khz / +1000 )); table->WatermarkRow[1 ][i].WmSetting = (uint8_t ) wm_with_clock_ranges->wm_dmif_clocks_ranges[i].wm_set_id; }
@@ -690,20 +690,20 @@ int smu_set_watermarks_for_clocks_ranges(void *wt_table,for (i =0 ; i < wm_with_clock_ranges->num_wm_mcif_sets; i++) { table->WatermarkRow[0 ][i].MinClock =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_socclk_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_socclk_clk_in_khz / +1000 )); table->WatermarkRow[0 ][i].MaxClock =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_socclk_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_socclk_clk_in_khz / +1000 )); table->WatermarkRow[0 ][i].MinUclk =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_mem_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_min_mem_clk_in_khz / +1000 )); table->WatermarkRow[0 ][i].MaxUclk =cpu_to_le16 ((uint16_t ) - (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_mem_clk_in_khz) / -1000 ); + (wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_max_mem_clk_in_khz / +1000 )); table->WatermarkRow[0 ][i].WmSetting = (uint8_t ) wm_with_clock_ranges->wm_mcif_clocks_ranges[i].wm_set_id; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 53/190 drm/amd/dm: Understand why attaching path/tile properties are needed
In reply to Greg Kroah-Hartman[ Upstream commit 04ac4b0ed412f65230b456fcd9aa07e13befff89 ]
Path property is used for userspace to know what MST connector goes to what actual DRM DisplayPort connector, the tiling property is for tiling configurations. Not sure what else there is to figure out.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 --- 1 file changed, 3 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +0 -3
@@ -377,9 +377,6 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,drm_connector_attach_encoder (&aconnector->base, &aconnector->mst_encoder->base); -/* -* TODO: understand why this one is needed -*/ drm_object_attach_property( &connector->base, dev->mode_config.path_property,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 54/190 ARM: davinci: da8xx: define gpio interrupts as separate resources
In reply to Greg Kroah-Hartman[ Upstream commit 58a0afbf4c99ac355df16773af835b919b9432ee ]
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range.
--- arch/arm/mach-davinci/devices-da8xx.c | 40 +++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)
arch/arm/mach-davinci/devices-da8xx.c +40 -0
@@ -704,6 +704,46 @@ static struct resource da8xx_gpio_resources[] = { }, { /* interrupt */ .start = IRQ_DA8XX_GPIO0, + .end = IRQ_DA8XX_GPIO0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO1, + .end = IRQ_DA8XX_GPIO1, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO2, + .end = IRQ_DA8XX_GPIO2, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO3, + .end = IRQ_DA8XX_GPIO3, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO4, + .end = IRQ_DA8XX_GPIO4, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO5, + .end = IRQ_DA8XX_GPIO5, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO6, + .end = IRQ_DA8XX_GPIO6, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO7, + .end = IRQ_DA8XX_GPIO7, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DA8XX_GPIO8, .end = IRQ_DA8XX_GPIO8, .flags = IORESOURCE_IRQ, },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 55/190 ARM: davinci: dm365: define gpio interrupts as separate resources
In reply to Greg Kroah-Hartman[ Upstream commit 193c04374e281a56c7d4f96e66d329671945bebe ]
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range.
--- arch/arm/mach-davinci/dm365.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
arch/arm/mach-davinci/dm365.c +35 -0
@@ -267,6 +267,41 @@ static struct resource dm365_gpio_resources[] = { }, { /* interrupt */ .start = IRQ_DM365_GPIO0, + .end = IRQ_DM365_GPIO0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO1, + .end = IRQ_DM365_GPIO1, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO2, + .end = IRQ_DM365_GPIO2, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO3, + .end = IRQ_DM365_GPIO3, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO4, + .end = IRQ_DM365_GPIO4, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO5, + .end = IRQ_DM365_GPIO5, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO6, + .end = IRQ_DM365_GPIO6, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM365_GPIO7, .end = IRQ_DM365_GPIO7, .flags = IORESOURCE_IRQ, },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 56/190 ARM: davinci: dm646x: define gpio interrupts as separate resources
In reply to Greg Kroah-Hartman[ Upstream commit 2c9c83491f30afbce25796e185cd4d5e36080e31 ]
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range.
--- arch/arm/mach-davinci/dm646x.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
arch/arm/mach-davinci/dm646x.c +10 -0
@@ -442,6 +442,16 @@ static struct resource dm646x_gpio_resources[] = { }, { /* interrupt */ .start = IRQ_DM646X_GPIOBNK0, + .end = IRQ_DM646X_GPIOBNK0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM646X_GPIOBNK1, + .end = IRQ_DM646X_GPIOBNK1, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM646X_GPIOBNK2, .end = IRQ_DM646X_GPIOBNK2, .flags = IORESOURCE_IRQ, },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 57/190 ARM: davinci: dm355: define gpio interrupts as separate resources
In reply to Greg Kroah-Hartman[ Upstream commit 27db7baab640ea28d7994eda943fef170e347081 ]
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range.
--- arch/arm/mach-davinci/dm355.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
arch/arm/mach-davinci/dm355.c +30 -0
@@ -548,6 +548,36 @@ static struct resource dm355_gpio_resources[] = { }, { /* interrupt */ .start = IRQ_DM355_GPIOBNK0, + .end = IRQ_DM355_GPIOBNK0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK1, + .end = IRQ_DM355_GPIOBNK1, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK2, + .end = IRQ_DM355_GPIOBNK2, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK3, + .end = IRQ_DM355_GPIOBNK3, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK4, + .end = IRQ_DM355_GPIOBNK4, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK5, + .end = IRQ_DM355_GPIOBNK5, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_DM355_GPIOBNK6, .end = IRQ_DM355_GPIOBNK6, .flags = IORESOURCE_IRQ, },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 58/190 ARM: davinci: dm644x: define gpio interrupts as separate resources
In reply to Greg Kroah-Hartman[ Upstream commit adcf60ce14c8250761af9de907eb6c7d096c26d3 ]
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") the davinci GPIO driver fails to probe if we boot in legacy mode from any of the board files. Since the driver now expects every interrupt to be defined as a separate resource, split the definition of IRQ resources instead of having a single continuous interrupt range.
--- arch/arm/mach-davinci/dm644x.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
arch/arm/mach-davinci/dm644x.c +20 -0
@@ -492,6 +492,26 @@ static struct resource dm644_gpio_resources[] = { }, { /* interrupt */ .start = IRQ_GPIOBNK0, + .end = IRQ_GPIOBNK0, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_GPIOBNK1, + .end = IRQ_GPIOBNK1, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_GPIOBNK2, + .end = IRQ_GPIOBNK2, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_GPIOBNK3, + .end = IRQ_GPIOBNK3, + .flags = IORESOURCE_IRQ, + }, + { + .start = IRQ_GPIOBNK4, .end = IRQ_GPIOBNK4, .flags = IORESOURCE_IRQ, },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 59/190 s390/zcrypt: reinit ap queue state machine during device probe
In reply to Greg Kroah-Hartman[ Upstream commit 104f708fd1241b22f808bdf066ab67dc5a051de5 ]
Until the vfio-ap driver came into live there was a well known agreement about the way how ap devices are initialized and their states when the driver's probe function is called.
However, the vfio device driver when receiving an ap queue device does additional resets thereby removing the registration for interrupts for the ap device done by the ap bus core code. So when later the vfio driver releases the device and one of the default zcrypt drivers takes care of the device the interrupt registration needs to get renewed. The current code does no renew and result is that requests send into such a queue will never see a reply processed - the application hangs.
This patch adds a function which resets the aq queue state machine for the ap queue device and triggers the walk through the initial states (which are reset and registration for interrupts). This function is now called before the driver's probe function is invoked.
When the association between driver and device is released, the driver's remove function is called. The current implementation calls a ap queue function ap_queue_remove(). This invokation has been moved to the ap bus function to make the probe / remove pair for ap bus and drivers more symmetric.
--- drivers/s390/crypto/ap_bus.c | 8 ++++---- drivers/s390/crypto/ap_bus.h | 1 + drivers/s390/crypto/ap_queue.c | 15 +++++++++++++++ drivers/s390/crypto/zcrypt_cex2a.c | 1 - drivers/s390/crypto/zcrypt_cex4.c | 1 - drivers/s390/crypto/zcrypt_pcixcc.c | 1 - 6 files changed, 20 insertions(+), 7 deletions(-)
drivers/s390/crypto/ap_bus.c +4 -4
@@ -777,6 +777,8 @@ static int ap_device_probe(struct device *dev) drvres = ap_drv->flags &AP_DRIVER_FLAG_DEFAULT ;if (!!devres != !!drvres)return -ENODEV ; +/* (re-)init queue's state machine */ +ap_queue_reinit_state (to_ap_queue (dev)); }/* Add queue/card to list of active queues/cards */
@@ -809,6 +811,8 @@ static int ap_device_remove(struct device *dev)struct ap_device *ap_dev =to_ap_dev (dev);struct ap_driver *ap_drv = ap_dev->drv; +if (is_queue_dev (dev)) +ap_queue_remove (to_ap_queue (dev));if (ap_drv->remove) ap_drv->remove (ap_dev);
@@ -1446,10 +1450,6 @@ static void ap_scan_bus(struct work_struct *unused) aq->ap_dev.device.parent = &ac->ap_dev.device;dev_set_name (&aq->ap_dev.device,"%02x.%04x" , id, dom); -/* Start with a device reset */ -spin_lock_bh (&aq->lock); -ap_wait (ap_sm_event (aq,AP_EVENT_POLL )); -spin_unlock_bh (&aq->lock);/* Register device */ rc =device_register (&aq->ap_dev.device);if (rc) {
drivers/s390/crypto/ap_bus.h +1 -0
@@ -253,6 +253,7 @@ struct ap_queue *ap_queue_create(ap_qid_t qid, int device_type);void ap_queue_remove (struct ap_queue *aq);void ap_queue_suspend (struct ap_device *ap_dev);void ap_queue_resume (struct ap_device *ap_dev); +void ap_queue_reinit_state (struct ap_queue *aq);struct ap_card *ap_card_create (int id,int queue_depth,int raw_device_type,int comp_device_type,unsigned int functions);
drivers/s390/crypto/ap_queue.c +15 -0
@@ -718,5 +718,20 @@ void ap_queue_remove(struct ap_queue *aq) {ap_flush_queue (aq);del_timer_sync (&aq->timeout); + +/* reset with zero, also clears irq registration */ +spin_lock_bh (&aq->lock); +ap_zapq (aq->qid); + aq->state =AP_STATE_BORKED ; +spin_unlock_bh (&aq->lock); }EXPORT_SYMBOL (ap_queue_remove); + +void ap_queue_reinit_state (struct ap_queue *aq) +{ +spin_lock_bh (&aq->lock); + aq->state =AP_STATE_RESET_START ; +ap_wait (ap_sm_event (aq,AP_EVENT_POLL )); +spin_unlock_bh (&aq->lock); +} +EXPORT_SYMBOL (ap_queue_reinit_state);
drivers/s390/crypto/zcrypt_cex2a.c +0 -1
@@ -198,7 +198,6 @@ static void zcrypt_cex2a_queue_remove(struct ap_device *ap_dev)struct ap_queue *aq =to_ap_queue (&ap_dev->device);struct zcrypt_queue *zq = aq->private; -ap_queue_remove (aq);if (zq)zcrypt_queue_unregister (zq); }
drivers/s390/crypto/zcrypt_cex4.c +0 -1
@@ -273,7 +273,6 @@ static void zcrypt_cex4_queue_remove(struct ap_device *ap_dev)struct ap_queue *aq =to_ap_queue (&ap_dev->device);struct zcrypt_queue *zq = aq->private; -ap_queue_remove (aq);if (zq)zcrypt_queue_unregister (zq); }
drivers/s390/crypto/zcrypt_pcixcc.c +0 -1
@@ -276,7 +276,6 @@ static void zcrypt_pcixcc_queue_remove(struct ap_device *ap_dev)struct ap_queue *aq =to_ap_queue (&ap_dev->device);struct zcrypt_queue *zq = aq->private; -ap_queue_remove (aq);if (zq)zcrypt_queue_unregister (zq); }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 60/190 media: vim2m: use workqueue
In reply to Greg Kroah-Hartman[ Upstream commit 144bd0ee304c7d0690eec285aee93019d3f30fc8 ]
v4l2_ctrl uses mutexes, so we can't setup a ctrl_handler in interrupt context. Switch to a workqueue instead and drop the timer.
--- drivers/media/platform/vim2m.c | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-)
drivers/media/platform/vim2m.c +10 -15
@@ -3,7 +3,8 @@* * This is a virtual device driver for testing mem-to-mem videobuf framework. * It simulates a device that uses memory buffers for both source and -* destination, processes the data and issues an "irq" (simulated by a timer). +* destination, processes the data and issues an "irq" (simulated by a delayed +* workqueue). * The device is capable of multi-instance, multi-buffer-per-transaction * operation (via the mem2mem framework). *
@@ -19,7 +20,6 @@#include <linux/module.h> #include <linux/delay.h> #include <linux/fs.h> -#include <linux/timer.h> #include <linux/sched.h> #include <linux/slab.h>
@@ -148,7 +148,7 @@ struct vim2m_dev {struct mutex dev_mutex;spinlock_t irqlock; -struct timer_list timer; +struct delayed_work work_run;struct v4l2_m2m_dev *m2m_dev; };
@@ -336,12 +336,6 @@ static int device_process(struct vim2m_ctx *ctx,return 0 ; } -static void schedule_irq (struct vim2m_dev *dev,int msec_timeout) -{ -dprintk (dev,"Scheduling a simulated irq\n" ); -mod_timer (&dev->timer, jiffies +msecs_to_jiffies (msec_timeout)); -} -/* * mem2mem callbacks */
@@ -387,13 +381,14 @@ static void device_run(void *priv)device_process (ctx, src_buf, dst_buf); -/* Run a timer, which simulates a hardware irq */ -schedule_irq (dev, ctx->transtime); +/* Run delayed work, which simulates a hardware irq */ +schedule_delayed_work (&dev->work_run,msecs_to_jiffies (ctx->transtime)); } -static void device_isr (struct timer_list *t) +static void device_work (struct work_struct *w) { -struct vim2m_dev *vim2m_dev =from_timer (vim2m_dev, t, timer); +struct vim2m_dev *vim2m_dev = + container_of(w, struct vim2m_dev, work_run.work);struct vim2m_ctx *curr_ctx;struct vb2_v4l2_buffer *src_vb, *dst_vb;unsigned long flags;
@@ -805,6 +800,7 @@ static void vim2m_stop_streaming(struct vb2_queue *q)struct vb2_v4l2_buffer *vbuf;unsigned long flags; +flush_scheduled_work ();for (;;) {if (V4L2_TYPE_IS_OUTPUT (q->type)) vbuf =v4l2_m2m_src_buf_remove (ctx->fh.m2m_ctx);
@@ -1015,6 +1011,7 @@ static int vim2m_probe(struct platform_device *pdev) vfd = &dev->vfd; vfd->lock = &dev->dev_mutex; vfd->v4l2_dev = &dev->v4l2_dev; +INIT_DELAYED_WORK (&dev->work_run, device_work); ret =video_register_device (vfd,VFL_TYPE_GRABBER ,0 );if (ret) {
@@ -1026,7 +1023,6 @@ static int vim2m_probe(struct platform_device *pdev)v4l2_info (&dev->v4l2_dev,"Device registered as /dev/video%d\n" , vfd->num); -timer_setup (&dev->timer, device_isr,0 );platform_set_drvdata (pdev, dev); dev->m2m_dev =v4l2_m2m_init (&m2m_ops);
@@ -1083,7 +1079,6 @@ static int vim2m_remove(struct platform_device *pdev)media_device_cleanup (&dev->mdev);#endif v4l2_m2m_release (dev->m2m_dev); -del_timer_sync (&dev->timer);video_unregister_device (&dev->vfd);v4l2_device_unregister (&dev->v4l2_dev);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 61/190 media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work
In reply to Greg Kroah-Hartman[ Upstream commit 52117be68b82ee05c96da0a7beec319906ccf6cc ]
The use of flush_schedule_work() made no sense and caused a syzkaller error. Replace with the correct cancel_delayed_work_sync().
--- drivers/media/platform/vim2m.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/platform/vim2m.c +2 -1
@@ -797,10 +797,11 @@ static int vim2m_start_streaming(struct vb2_queue *q, unsigned count)static void vim2m_stop_streaming (struct vb2_queue *q) {struct vim2m_ctx *ctx =vb2_get_drv_priv (q); +struct vim2m_dev *dev = ctx->dev;struct vb2_v4l2_buffer *vbuf;unsigned long flags; -flush_scheduled_work (); +cancel_delayed_work_sync (&dev->work_run);for (;;) {if (V4L2_TYPE_IS_OUTPUT (q->type)) vbuf =v4l2_m2m_src_buf_remove (ctx->fh.m2m_ctx);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 62/190 drm/i915: Restore sane defaults for KMS on GEM error load
In reply to Greg Kroah-Hartman[ Upstream commit 7ed43df720c007d60bee6d81da07bcdc7e4a55ae ]
If we fail during GEM initialisation, we scrub the HW state by performing a device level GPU resuet. However, we want to leave the system in a usable state (with functioning KMS but no GEM) so after scrubbing the HW state, we need to restore some sane defaults and re-enable the low-level common parts of the GPU (such as the GMCH).
v2: Restore GTT entries.
--- drivers/gpu/drm/i915/i915_gem.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_gem.c +10 -1
@@ -5595,6 +5595,8 @@ err_uc_misc:i915_gem_cleanup_userptr (dev_priv);if (ret == -EIO ) { +mutex_lock (&dev_priv->drm.struct_mutex); +/* * Allow engine initialisation to fail by marking the GPU as * wedged. But we only want to do this where the GPU is angry,
@@ -5605,7 +5607,14 @@ err_uc_misc: "Failed to initialize GPU, declaring it wedged!\n");i915_gem_set_wedged (dev_priv); } - ret =0 ; + +/* Minimal basic recovery for KMS */ + ret =i915_ggtt_enable_hw (dev_priv); +i915_gem_restore_gtt_mappings (dev_priv); +i915_gem_restore_fences (dev_priv); +intel_init_clock_gating (dev_priv); + +mutex_unlock (&dev_priv->drm.struct_mutex); }i915_gem_drain_freed_objects (dev_priv);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 63/190 drm/i915: Cleanup gt powerstate from gem
In reply to Greg Kroah-Hartman[ Upstream commit 30b710840e4b9c9699d3d4b33fb19ad8880d4614 ]
Since the gt powerstate is allocated by i915_gem_init, clean it from i915_gem_fini for symmetry and to correct the imbalance on error.
--- drivers/gpu/drm/i915/i915_gem.c | 3 +++ drivers/gpu/drm/i915/intel_display.c | 4 ---- 2 files changed, 3 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/i915_gem.c +3 -0
@@ -5624,6 +5624,7 @@ err_uc_misc:void i915_gem_fini (struct drm_i915_private *dev_priv) {i915_gem_suspend_late (dev_priv); +intel_disable_gt_powersave (dev_priv);/* Flush any outstanding unpin_work. */ i915_gem_drain_workqueue (dev_priv);
@@ -5635,6 +5636,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)i915_gem_contexts_fini (dev_priv);mutex_unlock (&dev_priv->drm.struct_mutex); +intel_cleanup_gt_powersave (dev_priv); +intel_uc_fini_misc (dev_priv);i915_gem_cleanup_userptr (dev_priv);
drivers/gpu/drm/i915/intel_display.c +0 -4
@@ -15972,8 +15972,6 @@ void intel_modeset_cleanup(struct drm_device *dev)flush_work (&dev_priv->atomic_helper.free_work);WARN_ON (!llist_empty (&dev_priv->atomic_helper.free_list)); -intel_disable_gt_powersave (dev_priv); -/* * Interrupts and polling as the first thing to avoid creating havoc. * Too much stuff here (turning of connectors, ...) would
@@ -16001,8 +15999,6 @@ void intel_modeset_cleanup(struct drm_device *dev)intel_cleanup_overlay (dev_priv); -intel_cleanup_gt_powersave (dev_priv); -intel_teardown_gmbus (dev_priv);destroy_workqueue (dev_priv->modeset_wq);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 64/190 KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode switch
In reply to Greg Kroah-Hartman[ Upstream commit 234ff0b729ad882d20f7996591a964965647addf ]
Testing has revealed an occasional crash which appears to be caused by a race between kvmppc_switch_mmu_to_hpt and kvm_unmap_hva_range_hv. The symptom is a NULL pointer dereference in __find_linux_pte() called from kvm_unmap_radix() with kvm->arch.pgtable == NULL.
Looking at kvmppc_switch_mmu_to_hpt(), it does indeed clear kvm->arch.pgtable (via kvmppc_free_radix()) before setting kvm->arch.radix to NULL, and there is nothing to prevent kvm_unmap_hva_range_hv() or the other MMU callback functions from being called concurrently with kvmppc_switch_mmu_to_hpt() or kvmppc_switch_mmu_to_radix().
This patch therefore adds calls to spin_lock/unlock on the kvm->mmu_lock around the assignments to kvm->arch.radix, and makes sure that the partition-scoped radix tree or HPT is only freed after changing kvm->arch.radix.
This also takes the kvm->mmu_lock in kvmppc_rmap_reset() to make sure that the clearing of each rmap array (one per memslot) doesn't happen concurrently with use of the array in the kvm_unmap_hva_range_hv() or the other MMU callbacks.
--- arch/powerpc/kvm/book3s_64_mmu_hv.c | 3 +++ arch/powerpc/kvm/book3s_hv.c | 15 +++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-)
arch/powerpc/kvm/book3s_64_mmu_hv.c +3 -0
@@ -744,12 +744,15 @@ void kvmppc_rmap_reset(struct kvm *kvm) srcu_idx =srcu_read_lock (&kvm->srcu); slots =kvm_memslots (kvm);kvm_for_each_memslot (memslot, slots) { +/* Mutual exclusion with kvm_unmap_hva_range etc. */ +spin_lock (&kvm->mmu_lock);/* * This assumes it is acceptable to lose reference and * change bits across a reset. */ memset (memslot->arch.rmap,0 , memslot->npages *sizeof (*memslot->arch.rmap)); +spin_unlock (&kvm->mmu_lock); }srcu_read_unlock (&kvm->srcu, srcu_idx); }
arch/powerpc/kvm/book3s_hv.c +11 -4
@@ -3813,12 +3813,15 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu)/* Must be called with kvm->lock held and mmu_ready = 0 and no vcpus running */ int kvmppc_switch_mmu_to_hpt (struct kvm *kvm) { +kvmppc_rmap_reset (kvm); + kvm->arch.process_table =0 ; +/* Mutual exclusion with kvm_unmap_hva_range etc. */ +spin_lock (&kvm->mmu_lock); + kvm->arch.radix =0 ; +spin_unlock (&kvm->mmu_lock);kvmppc_free_radix (kvm);kvmppc_update_lpcr (kvm,LPCR_VPM1 ,LPCR_VPM1 |LPCR_UPRT |LPCR_GTSE |LPCR_HR ); -kvmppc_rmap_reset (kvm); - kvm->arch.radix =0 ; - kvm->arch.process_table =0 ;return 0 ; }
@@ -3831,10 +3834,14 @@ int kvmppc_switch_mmu_to_radix(struct kvm *kvm)if (err)return err; +kvmppc_rmap_reset (kvm); +/* Mutual exclusion with kvm_unmap_hva_range etc. */ +spin_lock (&kvm->mmu_lock); + kvm->arch.radix =1 ; +spin_unlock (&kvm->mmu_lock);kvmppc_free_hpt (&kvm->arch.hpt);kvmppc_update_lpcr (kvm,LPCR_UPRT |LPCR_GTSE |LPCR_HR ,LPCR_VPM1 |LPCR_UPRT |LPCR_GTSE |LPCR_HR ); - kvm->arch.radix =1 ;return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 65/190 Btrfs: clean up scrub is_dev_replace parameter
In reply to Greg Kroah-Hartman[ Upstream commit 32934280967d00dc2b5c4d3b63b21a9c8638326e ]
struct scrub_ctx has an ->is_dev_replace member, so there's no point in passing around is_dev_replace where sctx is available.
--- fs/btrfs/scrub.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-)
fs/btrfs/scrub.c +9 -14
@@ -3022,8 +3022,7 @@ out: static noinline_for_stack int scrub_stripe(struct scrub_ctx *sctx,struct map_lookup *map,struct btrfs_device *scrub_dev, -int num,u64 base,u64 length, -int is_dev_replace) +int num,u64 base,u64 length) {struct btrfs_path *path, *ppath;struct btrfs_fs_info *fs_info = sctx->fs_info;
@@ -3299,7 +3298,7 @@ again: extent_physical = extent_logical - logical + physical; extent_dev = scrub_dev; extent_mirror_num = mirror_num; -if (is_dev_replace) +if (sctx->is_dev_replace) scrub_remap_extent(fs_info, extent_logical, extent_len, &extent_physical, &extent_dev,
@@ -3397,8 +3396,7 @@ static noinline_for_stack int scrub_chunk(struct scrub_ctx *sctx,struct btrfs_device *scrub_dev, u64 chunk_offset, u64 length, u64 dev_offset, - struct btrfs_block_group_cache *cache, - int is_dev_replace) + struct btrfs_block_group_cache *cache) { struct btrfs_fs_info *fs_info = sctx->fs_info;struct btrfs_mapping_tree *map_tree = &fs_info->mapping_tree;
@@ -3435,8 +3433,7 @@ static noinline_for_stack int scrub_chunk(struct scrub_ctx *sctx,if (map->stripes[i].dev->bdev == scrub_dev->bdev && map->stripes[i].physical == dev_offset) { ret =scrub_stripe (sctx, map, scrub_dev, i, - chunk_offset, length, - is_dev_replace); + chunk_offset, length);if (ret) goto out; }
@@ -3449,8 +3446,7 @@ out:static noinline_for_stack int scrub_enumerate_chunks(struct scrub_ctx *sctx, -struct btrfs_device *scrub_dev,u64 start,u64 end, -int is_dev_replace) +struct btrfs_device *scrub_dev,u64 start,u64 end) {struct btrfs_dev_extent *dev_extent =NULL ;struct btrfs_path *path;
@@ -3544,7 +3540,7 @@ int scrub_enumerate_chunks(struct scrub_ctx *sctx,*/ scrub_pause_on (fs_info); ret =btrfs_inc_block_group_ro (cache); -if (!ret && is_dev_replace) { +if (!ret && sctx->is_dev_replace) {/* * If we are doing a device replace wait for any tasks * that started dellaloc right before we set the block
@@ -3609,7 +3605,7 @@ int scrub_enumerate_chunks(struct scrub_ctx *sctx, dev_replace->item_needs_writeback =1 ;btrfs_dev_replace_write_unlock (&fs_info->dev_replace); ret =scrub_chunk (sctx, scrub_dev, chunk_offset, length, - found_key.offset, cache, is_dev_replace); + found_key.offset, cache);/* * flush, submit all pending read and write bios, afterwards
@@ -3670,7 +3666,7 @@ int scrub_enumerate_chunks(struct scrub_ctx *sctx,btrfs_put_block_group (cache);if (ret)break ; -if (is_dev_replace && +if (sctx->is_dev_replace &&atomic64_read (&dev_replace->num_write_errors) >0 ) { ret = -EIO ;break ;
@@ -3893,8 +3889,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, }if (!ret) - ret =scrub_enumerate_chunks (sctx, dev, start, end, - is_dev_replace); + ret =scrub_enumerate_chunks (sctx, dev, start, end);wait_event (sctx->list_wait,atomic_read (&sctx->bios_in_flight) ==0 );atomic_dec (&fs_info->scrubs_running);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 66/190 Btrfs: fix deadlock with memory reclaim during scrub
In reply to Greg Kroah-Hartman[ Upstream commit a5fb11429167ee6ddeeacc554efaf5776b36433a ]
When a transaction commit starts, it attempts to pause scrub and it blocks until the scrub is paused. So while the transaction is blocked waiting for scrub to pause, we can not do memory allocation with GFP_KERNEL from scrub, otherwise we risk getting into a deadlock with reclaim.
Checking for scrub pause requests is done early at the beginning of the while loop of scrub_stripe() and later in the loop, scrub_extent() and scrub_raid56_parity() are called, which in turn call scrub_pages() and scrub_pages_for_parity() respectively. These last two functions do memory allocations using GFP_KERNEL. Same problem could happen while scrubbing the super blocks, since it calls scrub_pages().
We also can not have any of the worker tasks, created by the scrub task, doing GFP_KERNEL allocations, because before pausing, the scrub task waits for all the worker tasks to complete (also done at scrub_stripe()).
So make sure GFP_NOFS is used for the memory allocations because at any time a scrub pause request can happen from another task that started to commit a transaction.
--- fs/btrfs/scrub.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)
fs/btrfs/scrub.c +34 -1
@@ -322,6 +322,7 @@ static struct full_stripe_lock *insert_full_stripe_lock(struct rb_node *parent =NULL ;struct full_stripe_lock *entry;struct full_stripe_lock *ret; +unsigned int nofs_flag;lockdep_assert_held (&locks_root->lock);
@@ -339,8 +340,17 @@ static struct full_stripe_lock *insert_full_stripe_lock( } } -/* Insert new lock */ +/* +* Insert new lock. +* +* We must use GFP_NOFS because the scrub task might be waiting for a +* worker task executing this function and in turn a transaction commit +* might be waiting the scrub task to pause (which needs to wait for all +* the worker tasks to complete before pausing). +*/ + nofs_flag =memalloc_nofs_save (); ret =kmalloc (sizeof (*ret),GFP_KERNEL ); +memalloc_nofs_restore (nofs_flag);if (!ret)return ERR_PTR (-ENOMEM ); ret->logical = fstripe_logical;
@@ -1622,8 +1632,19 @@ static int scrub_add_page_to_wr_bio(struct scrub_ctx *sctx,mutex_lock (&sctx->wr_lock); again:if (!sctx->wr_curr_bio) { +unsigned int nofs_flag; + +/* +* We must use GFP_NOFS because the scrub task might be waiting +* for a worker task executing this function and in turn a +* transaction commit might be waiting the scrub task to pause +* (which needs to wait for all the worker tasks to complete +* before pausing). +*/ + nofs_flag =memalloc_nofs_save (); sctx->wr_curr_bio =kzalloc (sizeof (*sctx->wr_curr_bio),GFP_KERNEL ); +memalloc_nofs_restore (nofs_flag);if (!sctx->wr_curr_bio) {mutex_unlock (&sctx->wr_lock);return -ENOMEM ;
@@ -3775,6 +3796,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,struct scrub_ctx *sctx;int ret;struct btrfs_device *dev; +unsigned int nofs_flag;if (btrfs_fs_closing (fs_info))return -EINVAL ;
@@ -3878,6 +3900,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,atomic_inc (&fs_info->scrubs_running);mutex_unlock (&fs_info->scrub_lock); +/* +* In order to avoid deadlock with reclaim when there is a transaction +* trying to pause scrub, make sure we use GFP_NOFS for all the +* allocations done at btrfs_scrub_pages() and scrub_pages_for_parity() +* invoked by our callees. The pausing request is done when the +* transaction commit starts, and it blocks the transaction until scrub +* is paused (done at specific points at scrub_stripe() or right above +* before incrementing fs_info->scrubs_running). +*/ + nofs_flag =memalloc_nofs_save ();if (!is_dev_replace) {/* * by holding device list mutex, we can
@@ -3890,6 +3922,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,if (!ret) ret =scrub_enumerate_chunks (sctx, dev, start, end); +memalloc_nofs_restore (nofs_flag);wait_event (sctx->list_wait,atomic_read (&sctx->bios_in_flight) ==0 );atomic_dec (&fs_info->scrubs_running);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 67/190 btrfs: Remove extent_io_ops::fill_delalloc
In reply to Greg Kroah-Hartman[ Upstream commit 5eaad97af8aeff38debe7d3c69ec3a0d71f8350f ]
This callback is called only from writepage_delalloc which in turn is guaranteed to be called from the data page writeout path. In the end there is no reason to have the call to this function to be indrected via the extent_io_ops structure. This patch removes the callback definition, exports the function and calls it directly. No functional changes.
--- fs/btrfs/ctree.h | 3 +++ fs/btrfs/extent_io.c | 20 +++++++++----------- fs/btrfs/extent_io.h | 5 ----- fs/btrfs/inode.c | 15 +++++++-------- 4 files changed, 19 insertions(+), 24 deletions(-)
fs/btrfs/ctree.h +3 -0
@@ -3200,6 +3200,9 @@ int btrfs_prealloc_file_range_trans(struct inode *inode, struct btrfs_trans_handle *trans, int mode, u64 start, u64 num_bytes, u64 min_size, loff_t actual_len, u64 *alloc_hint); +int btrfs_run_delalloc_range (void *private_data,struct page *locked_page, +u64 start,u64 end,int *page_started,unsigned long *nr_written, +struct writeback_control *wbc);extern const struct dentry_operations btrfs_dentry_operations;#ifdef CONFIG_BTRFS_FS_RUN_SANITY_TESTS void btrfs_test_inode_set_ops (struct inode *inode);
fs/btrfs/extent_io.c +9 -11
@@ -3199,7 +3199,7 @@ static void update_nr_written(struct writeback_control *wbc,/* * helper for __extent_writepage, doing all of the delayed allocation setup. * -* This returns 1 if our fill_delalloc function did all the work required +* This returns 1 if btrfs_run_delalloc_range function did all the work required * to write the page (copy into inline extent). In this case the IO has * been started and the page is already unlocked. *
@@ -3220,7 +3220,7 @@ static noinline_for_stack int writepage_delalloc(struct inode *inode,int ret;int page_started =0 ; -if (epd->extent_locked || !tree->ops || !tree->ops->fill_delalloc) +if (epd->extent_locked)return 0 ;while (delalloc_end < page_end) {
@@ -3233,18 +3233,16 @@ static noinline_for_stack int writepage_delalloc(struct inode *inode, delalloc_start = delalloc_end +1 ;continue ; } - ret = tree->ops->fill_delalloc (inode, page, - delalloc_start, - delalloc_end, - &page_started, - nr_written, wbc); + ret =btrfs_run_delalloc_range (inode, page, delalloc_start, + delalloc_end, &page_started, nr_written, wbc);/* File system has been set read-only */ if (ret) {SetPageError (page); -/* fill_delalloc should be return < 0 for error -* but just in case, we use > 0 here meaning the -* IO is started, so we don't want to return > 0 -* unless things are going well. +/* +* btrfs_run_delalloc_range should return < 0 for error +* but just in case, we use > 0 here meaning the IO is +* started, so we don't want to return > 0 unless +* things are going well. */ ret = ret <0 ? ret : -EIO ; goto done;
fs/btrfs/extent_io.h +0 -5
@@ -106,11 +106,6 @@ struct extent_io_ops {/* * Optional hooks, called if the pointer is not NULL */ -int (*fill_delalloc)(void *private_data,struct page *locked_page, -u64 start,u64 end,int *page_started, -unsigned long *nr_written, -struct writeback_control *wbc); -int (*writepage_start_hook)(struct page *page,u64 start,u64 end);void (*writepage_end_io_hook)(struct page *page,u64 start,u64 end,struct extent_state *state,int uptodate);
fs/btrfs/inode.c +7 -8
@@ -110,8 +110,8 @@ static void __endio_write_update_ordered(struct inode *inode,* extent_clear_unlock_delalloc() to clear both the bits EXTENT_DO_ACCOUNTING * and EXTENT_DELALLOC simultaneously, because that causes the reserved metadata * to be released, which we want to happen only when finishing the ordered -* extent (btrfs_finish_ordered_io()). Also note that the caller of the -* fill_delalloc() callback already does proper cleanup for the first page of +* extent (btrfs_finish_ordered_io()). Also note that the caller of +* btrfs_run_delalloc_range already does proper cleanup for the first page of * the range, that is, it invokes the callback writepage_end_io_hook() for the * range of the first page. */
@@ -1599,12 +1599,12 @@ static inline int need_force_cow(struct inode *inode, u64 start, u64 end) }/* -* extent_io.c call back to do delayed allocation processing +* Function to process delayed allocation (create CoW) for ranges which are +* being touched for the first time. */ -static int run_delalloc_range (void *private_data,struct page *locked_page, -u64 start,u64 end,int *page_started, -unsigned long *nr_written, -struct writeback_control *wbc) +int btrfs_run_delalloc_range (void *private_data,struct page *locked_page, +u64 start,u64 end,int *page_started,unsigned long *nr_written, +struct writeback_control *wbc) {struct inode *inode = private_data;int ret;
@@ -10598,7 +10598,6 @@ static const struct extent_io_ops btrfs_extent_io_ops = { .readpage_io_failed_hook = btrfs_readpage_io_failed_hook,/* optional callbacks */ - .fill_delalloc = run_delalloc_range, .writepage_end_io_hook = btrfs_writepage_end_io_hook, .writepage_start_hook = btrfs_writepage_start_hook, .set_bit_hook = btrfs_set_bit_hook,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 68/190 btrfs: Fix error handling in btrfs_cleanup_ordered_extents
In reply to Greg Kroah-Hartman[ Upstream commit d1051d6ebf8ef3517a5a3cf82bba8436d190f1c2 ]
Running btrfs/124 in a loop hung up on me sporadically with the following call trace:
btrfs D 0 5760 5324 0x00000000 Call Trace: ? __schedule+0x243/0x800 schedule+0x33/0x90 btrfs_start_ordered_extent+0x10c/0x1b0 [btrfs] ? wait_woken+0xa0/0xa0 btrfs_wait_ordered_range+0xbb/0x100 [btrfs] btrfs_relocate_block_group+0x1ff/0x230 [btrfs] btrfs_relocate_chunk+0x49/0x100 [btrfs] btrfs_balance+0xbeb/0x1740 [btrfs] btrfs_ioctl_balance+0x2ee/0x380 [btrfs] btrfs_ioctl+0x1691/0x3110 [btrfs] ? lockdep_hardirqs_on+0xed/0x180 ? __handle_mm_fault+0x8e7/0xfb0 ? _raw_spin_unlock+0x24/0x30 ? __handle_mm_fault+0x8e7/0xfb0 ? do_vfs_ioctl+0xa5/0x6e0 ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] do_vfs_ioctl+0xa5/0x6e0 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ksys_ioctl+0x3a/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe
This happens because during page writeback it's valid for writepage_delalloc to instantiate a delalloc range which doesn't belong to the page currently being written back.
The reason this case is valid is due to find_lock_delalloc_range returning any available range after the passed delalloc_start and ignoring whether the page under writeback is within that range.
In turn ordered extents (OE) are always created for the returned range from find_lock_delalloc_range. If, however, a failure occurs while OE are being created then the clean up code in btrfs_cleanup_ordered_extents will be called.
Unfortunately the code in btrfs_cleanup_ordered_extents doesn't consider the case of such 'foreign' range being processed and instead it always assumes that the range OE are created for belongs to the page. This leads to the first page of such foregin range to not be cleaned up since it's deliberately missed and skipped by the current cleaning up code.
Fix this by correctly checking whether the current page belongs to the range being instantiated and if so adjsut the range parameters passed for cleaning up. If it doesn't, then just clean the whole OE range directly.
--- fs/btrfs/inode.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
fs/btrfs/inode.c +20 -9
@@ -110,17 +110,17 @@ static void __endio_write_update_ordered(struct inode *inode,* extent_clear_unlock_delalloc() to clear both the bits EXTENT_DO_ACCOUNTING * and EXTENT_DELALLOC simultaneously, because that causes the reserved metadata * to be released, which we want to happen only when finishing the ordered -* extent (btrfs_finish_ordered_io()). Also note that the caller of -* btrfs_run_delalloc_range already does proper cleanup for the first page of -* the range, that is, it invokes the callback writepage_end_io_hook() for the -* range of the first page. +* extent (btrfs_finish_ordered_io()). */ static inline void btrfs_cleanup_ordered_extents (struct inode *inode, -const u64 offset, -const u64 bytes) +struct page *locked_page, +u64 offset,u64 bytes) {unsigned long index = offset >>PAGE_SHIFT ;unsigned long end_index = (offset + bytes -1 ) >>PAGE_SHIFT ; +u64 page_start =page_offset (locked_page); +u64 page_end = page_start +PAGE_SIZE -1 ; +struct page *page;while (index <= end_index) {
@@ -131,8 +131,18 @@ static inline void btrfs_cleanup_ordered_extents(struct inode *inode,ClearPagePrivate2 (page);put_page (page); } -return __endio_write_update_ordered (inode, offset +PAGE_SIZE , - bytes -PAGE_SIZE , false); + +/* +* In case this page belongs to the delalloc range being instantiated +* then skip it, since the first page of a range is going to be +* properly cleaned up by the caller of run_delalloc_range +*/ +if (page_start >= offset && page_end <= (offset + bytes -1 )) { + offset +=PAGE_SIZE ; + bytes -=PAGE_SIZE ; + } + +return __endio_write_update_ordered (inode, offset, bytes, false); }static int btrfs_dirty_inode (struct inode *inode);
@@ -1629,7 +1639,8 @@ int btrfs_run_delalloc_range(void *private_data, struct page *locked_page, write_flags); }if (ret) -btrfs_cleanup_ordered_extents (inode, start, end - start +1 ); +btrfs_cleanup_ordered_extents (inode, locked_page, start, + end - start +1 );return ret; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 69/190 scsi: megaraid_sas: Fix combined reply queue mode detection
In reply to Greg Kroah-Hartman[ Upstream commit e29c322133472628c6de85efb99ccd3b3df5571e ]
For Invader series, if FW supports more than 8 MSI-x vectors, driver needs to enable combined reply queue mode. For Ventura series, driver enables combined reply queue mode in case of more than 16 MSI-x vectors.
--- drivers/scsi/megaraid/megaraid_sas_base.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-)
drivers/scsi/megaraid/megaraid_sas_base.c +20 -3
@@ -5325,12 +5325,29 @@ static int megasas_init_fw(struct megasas_instance *instance) instance->msix_vectors = (scratch_pad_2 &MR_MAX_REPLY_QUEUES_OFFSET ) +1 ; fw_msix_count = instance->msix_vectors; - }else {/* Invader series supports more than 8 MSI-x vectors*/ + }else { instance->msix_vectors = ((scratch_pad_2 &MR_MAX_REPLY_QUEUES_EXT_OFFSET ) >>MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT ) +1 ; -if (instance->msix_vectors >16 ) - instance->msix_combined = true; + +/* +* For Invader series, > 8 MSI-x vectors +* supported by FW/HW implies combined +* reply queue mode is enabled. +* For Ventura series, > 16 MSI-x vectors +* supported by FW/HW implies combined +* reply queue mode is enabled. +*/ +switch (instance->adapter_type) { +case INVADER_SERIES : +if (instance->msix_vectors >8 ) + instance->msix_combined = true; +break ; +case VENTURA_SERIES : +if (instance->msix_vectors >16 ) + instance->msix_combined = true; +break ; + }if (rdpq_enable) instance->is_rdpq = (scratch_pad_2 & MR_RDPQ_MODE_OFFSET) ?
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 70/190 scsi: megaraid_sas: Add check for reset adapter bit
In reply to Greg Kroah-Hartman[ Upstream commit de93b40d98ead27ee2f7f7df93fdd4914a6c8d8d ]
For SAS3 and later controllers, FW sets the reset adapter bit indicating the driver to perform a controller reset. Driver needs to check if this bit is set before doing a reset. This reduces the driver probe failure time to 180seconds in case there is a faulty controller connected.
--- drivers/scsi/megaraid/megaraid_sas_base.c | 33 +++++++++++++++-------- 1 file changed, 22 insertions(+), 11 deletions(-)
drivers/scsi/megaraid/megaraid_sas_base.c +22 -11
@@ -5218,7 +5218,7 @@ static int megasas_init_fw(struct megasas_instance *instance) {u32 max_sectors_1;u32 max_sectors_2, tmp_sectors, msix_enable; -u32 scratch_pad_2, scratch_pad_3, scratch_pad_4; +u32 scratch_pad_2, scratch_pad_3, scratch_pad_4, status_reg;resource_size_t base_addr;struct megasas_register_set __iomem *reg_set;struct megasas_ctrl_info *ctrl_info =NULL ;
@@ -5226,6 +5226,7 @@ static int megasas_init_fw(struct megasas_instance *instance)int i, j, loop, fw_msix_count =0 ;struct IOV_111 *iovPtr;struct fusion_context *fusion; +bool do_adp_reset = true; fusion = instance->ctrl_context;
@@ -5274,19 +5275,29 @@ static int megasas_init_fw(struct megasas_instance *instance) }if (megasas_transition_to_ready (instance,0 )) { -atomic_set (&instance->fw_reset_no_pci_access,1 ); - instance->instancet->adp_reset - (instance, instance->reg_set); -atomic_set (&instance->fw_reset_no_pci_access,0 ); -dev_info (&instance->pdev->dev, -"FW restarted successfully from %s!\n" , - __func__); +if (instance->adapter_type >=INVADER_SERIES ) { + status_reg = instance->instancet->read_fw_status_reg ( + instance->reg_set); + do_adp_reset = status_reg &MFI_RESET_ADAPTER ; + } -/*waitting for about 30 second before retry*/ -ssleep (30 ); +if (do_adp_reset) { +atomic_set (&instance->fw_reset_no_pci_access,1 ); + instance->instancet->adp_reset + (instance, instance->reg_set); +atomic_set (&instance->fw_reset_no_pci_access,0 ); +dev_info (&instance->pdev->dev, +"FW restarted successfully from %s!\n" , + __func__); + +/*waiting for about 30 second before retry*/ +ssleep (30 ); -if (megasas_transition_to_ready (instance,0 )) +if (megasas_transition_to_ready (instance,0 )) + goto fail_ready_state; + }else { goto fail_ready_state; + } }megasas_init_ctrl_params (instance);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 71/190 scsi: megaraid_sas: Use 63-bit DMA addressing
In reply to Greg Kroah-Hartman[ Upstream commit 894169db12463cea08d0e2a9e35f42b291340e5a ]
Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault.
Driver will set 63-bit DMA mask to ensure the above address will not be used.
--- drivers/scsi/megaraid/megaraid_sas_base.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/scsi/megaraid/megaraid_sas_base.c +10 -10
@@ -6056,13 +6056,13 @@ static int megasas_io_attach(struct megasas_instance *instance)* @instance: Adapter soft state * Description: * -* For Ventura, driver/FW will operate in 64bit DMA addresses. +* For Ventura, driver/FW will operate in 63bit DMA addresses. * * For invader- * By default, driver/FW will operate in 32bit DMA addresses * for consistent DMA mapping but if 32 bit consistent -* DMA mask fails, driver will try with 64 bit consistent -* mask provided FW is true 64bit DMA capable +* DMA mask fails, driver will try with 63 bit consistent +* mask provided FW is true 63bit DMA capable * * For older controllers(Thunderbolt and MFI based adapters)- * driver/FW will operate in 32 bit consistent DMA addresses.
@@ -6075,15 +6075,15 @@ megasas_set_dma_mask(struct megasas_instance *instance)u32 scratch_pad_2; pdev = instance->pdev; - consistent_mask = (instance->adapter_type ==VENTURA_SERIES ) ? -DMA_BIT_MASK (64 ) :DMA_BIT_MASK (32 ); + consistent_mask = (instance->adapter_type >=VENTURA_SERIES ) ? +DMA_BIT_MASK (63 ) :DMA_BIT_MASK (32 );if (IS_DMA64 ) { -if (dma_set_mask (&pdev->dev,DMA_BIT_MASK (64 )) && +if (dma_set_mask (&pdev->dev,DMA_BIT_MASK (63 )) &&dma_set_mask_and_coherent (&pdev->dev,DMA_BIT_MASK (32 ))) goto fail_set_dma_mask; -if ((*pdev->dev.dma_mask ==DMA_BIT_MASK (64 )) && +if ((*pdev->dev.dma_mask ==DMA_BIT_MASK (63 )) && (dma_set_coherent_mask (&pdev->dev, consistent_mask) &&dma_set_mask_and_coherent (&pdev->dev,DMA_BIT_MASK (32 )))) {/*
@@ -6096,7 +6096,7 @@ megasas_set_dma_mask(struct megasas_instance *instance)if (!(scratch_pad_2 &MR_CAN_HANDLE_64_BIT_DMA_OFFSET )) goto fail_set_dma_mask;else if (dma_set_mask_and_coherent (&pdev->dev, -DMA_BIT_MASK (64 ))) +DMA_BIT_MASK (63 ))) goto fail_set_dma_mask; } }else if (dma_set_mask_and_coherent (&pdev->dev,DMA_BIT_MASK (32 )))
@@ -6108,8 +6108,8 @@ megasas_set_dma_mask(struct megasas_instance *instance) instance->consistent_mask_64bit = true;dev_info (&pdev->dev,"%s bit DMA mask and %s bit consistent mask\n" , - ((*pdev->dev.dma_mask ==DMA_BIT_MASK (64 )) ?"64" :"32" ), - (instance->consistent_mask_64bit ?"64" :"32" )); + ((*pdev->dev.dma_mask ==DMA_BIT_MASK (64 )) ?"63" :"32" ), + (instance->consistent_mask_64bit ?"63" :"32" ));return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 72/190 powerpc/pkeys: Fix handling of pkey state across fork()
In reply to Greg Kroah-Hartman[ Upstream commit 2cd4bd192ee94848695c1c052d87913260e10f36 ]
Protection key tracking information is not copied over to the mm_struct of the child during fork(). This can cause the child to erroneously allocate keys that were already allocated. Any allocated execute-only key is lost aswell.
Add code; called by dup_mmap(), to copy the pkey state from parent to child explicitly.
This problem was originally found by Dave Hansen on x86, which turns out to be a problem on powerpc aswell.
--- arch/powerpc/include/asm/mmu_context.h | 15 +++++++++------ arch/powerpc/mm/pkeys.c | 10 ++++++++++ 2 files changed, 19 insertions(+), 6 deletions(-)
arch/powerpc/include/asm/mmu_context.h +9 -6
@@ -217,12 +217,6 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,#endif } -static inline int arch_dup_mmap (struct mm_struct *oldmm, -struct mm_struct *mm) -{ -return 0 ; -} -#ifndef CONFIG_PPC_BOOK3S_64 static inline void arch_exit_mmap (struct mm_struct *mm) {
@@ -247,6 +241,7 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,#ifdef CONFIG_PPC_MEM_KEYS bool arch_vma_access_permitted (struct vm_area_struct *vma,bool write,bool execute,bool foreign); +void arch_dup_pkeys (struct mm_struct *oldmm,struct mm_struct *mm);#else /* CONFIG_PPC_MEM_KEYS */ static inline bool arch_vma_access_permitted (struct vm_area_struct *vma,bool write,bool execute,bool foreign)
@@ -259,6 +254,7 @@ static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,#define thread_pkey_regs_save (thread)#define thread_pkey_regs_restore (new_thread, old_thread)#define thread_pkey_regs_init (thread) +#define arch_dup_pkeys (oldmm, mm)static inline u64 pte_to_hpte_pkey_bits (u64 pteflags) {
@@ -267,5 +263,12 @@ static inline u64 pte_to_hpte_pkey_bits(u64 pteflags)#endif /* CONFIG_PPC_MEM_KEYS */ +static inline int arch_dup_mmap (struct mm_struct *oldmm, +struct mm_struct *mm) +{ +arch_dup_pkeys (oldmm, mm); +return 0 ; +} +#endif /* __KERNEL__ */ #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
arch/powerpc/mm/pkeys.c +10 -0
@@ -414,3 +414,13 @@ bool arch_vma_access_permitted(struct vm_area_struct *vma, bool write,return pkey_access_permitted (vma_pkey (vma), write, execute); } + +void arch_dup_pkeys (struct mm_struct *oldmm,struct mm_struct *mm) +{ +if (static_branch_likely (&pkey_disabled)) +return ; + +/* Duplicate the oldmm pkey state in mm: */ +mm_pkey_allocation_map (mm) =mm_pkey_allocation_map (oldmm); + mm->context.execute_only_pkey = oldmm->context.execute_only_pkey; +}
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 73/190 btrfs: volumes: Make sure no dev extent is beyond device boundary
In reply to Greg Kroah-Hartman[ Upstream commit 05a37c48604c19b50873fd9663f9140c150469d1 ]
Add extra dev extent end check against device boundary.
--- fs/btrfs/volumes.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
fs/btrfs/volumes.c +17 -0
@@ -7411,6 +7411,7 @@ static int verify_one_dev_extent(struct btrfs_fs_info *fs_info,struct extent_map_tree *em_tree = &fs_info->mapping_tree.map_tree;struct extent_map *em;struct map_lookup *map; +struct btrfs_device *dev;u64 stripe_len;bool found = false;int ret =0 ;
@@ -7460,6 +7461,22 @@ static int verify_one_dev_extent(struct btrfs_fs_info *fs_info, physical_offset, devid); ret = -EUCLEAN ; } + +/* Make sure no dev extent is beyond device bondary */ + dev =btrfs_find_device (fs_info, devid,NULL ,NULL ); +if (!dev) { +btrfs_err (fs_info,"failed to find devid %llu" , devid); + ret = -EUCLEAN ; + goto out; + } +if (physical_offset + physical_len > dev->disk_total_bytes) { +btrfs_err (fs_info, +"dev extent devid %llu physical offset %llu len %llu is beyond device boundary %llu" , + devid, physical_offset, physical_len, + dev->disk_total_bytes); + ret = -EUCLEAN ; + goto out; + } out:free_extent_map (em);return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 74/190 btrfs: Use real device structure to verify dev extent
In reply to Greg Kroah-Hartman[ Upstream commit 1b3922a8bc74231f9a767d1be6d9a061a4d4eeab ]
[BUG]
Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel message:
BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len 8388608 is beyond device boundary 0 BTRFS error (device dm-6): failed to verify dev extents against chunks: -117
BTRFS error (device dm-6): open_ctree failed
[CAUSE]
Commit cf90d884b347 ("btrfs: Introduce mount time chunk <-> dev extent mapping check") introduced strict check on dev extents.
We use btrfs_find_device() with dev uuid and fs uuid set to NULL, and only dependent on @devid to find the real device.
For seed devices, we call clone_fs_devices() in open_seed_devices() to allow us search seed devices directly.
However clone_fs_devices() just populates devices with devid and dev uuid, without populating other essential members, like disk_total_bytes.
This makes any device returned by btrfs_find_device(fs_info, devid, NULL, NULL) is just a dummy, with 0 disk_total_bytes, and any dev extents on the seed device will not pass the device boundary check.
[FIX]
This patch will try to verify the device returned by btrfs_find_device() and if it's a dummy then re-search in seed devices.
--- fs/btrfs/volumes.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
fs/btrfs/volumes.c +12 -0
@@ -7469,6 +7469,18 @@ static int verify_one_dev_extent(struct btrfs_fs_info *fs_info, ret = -EUCLEAN ; goto out; } + +/* It's possible this device is a dummy for seed device */ +if (dev->disk_total_bytes ==0 ) { + dev =find_device (fs_info->fs_devices->seed, devid,NULL ); +if (!dev) { +btrfs_err (fs_info,"failed to find seed devid %llu" , + devid); + ret = -EUCLEAN ; + goto out; + } + } +if (physical_offset + physical_len > dev->disk_total_bytes) { btrfs_err(fs_info, "dev extent devid %llu physical offset %llu len %llu is beyond device boundary %llu",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 75/190 media: vim2m: only cancel work if it is for right context
In reply to Greg Kroah-Hartman[ Upstream commit 240809ef6630a4ce57c273c2d79ffb657cd361eb ]
cancel_delayed_work_sync() was called for any queue, but it should only be called for the queue that is associated with the currently running job.
Otherwise, if two filehandles are streaming at the same time, then closing the first will cancel the work which might still be running for a job from the second filehandle. As a result the second filehandle will never be able to finish the job and an attempt to stop streaming on that second filehandle will stall.
--- drivers/media/platform/vim2m.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/platform/vim2m.c +3 -1
@@ -801,7 +801,9 @@ static void vim2m_stop_streaming(struct vb2_queue *q)struct vb2_v4l2_buffer *vbuf;unsigned long flags; -cancel_delayed_work_sync (&dev->work_run); +if (v4l2_m2m_get_curr_priv (dev->m2m_dev) == ctx) +cancel_delayed_work_sync (&dev->work_run); +for (;;) {if (V4L2_TYPE_IS_OUTPUT (q->type)) vbuf =v4l2_m2m_src_buf_remove (ctx->fh.m2m_ctx);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 76/190 ARC: show_regs: lockdep: re-enable preemption
In reply to Greg Kroah-Hartman[ Upstream commit f731a8e89f8c78985707c626680f3e24c7a60772 ]
signal handling core calls show_regs() with preemption disabled which on ARC takes mmap_sem for mm/vma access, causing lockdep splat.
| [ARCLinux]# ./segv-null-ptr | potentially unexpected fatal signal 11. | BUG: sleeping function called from invalid context at kernel/fork.c:1011 | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr | no locks held by segv-null-ptr/70. | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69 | | Stack Trace: | arc_unwind_core+0xcc/0x100 | ___might_sleep+0x17a/0x190 | mmput+0x16/0xb8 | show_regs+0x52/0x310 | get_signal+0x5ee/0x610 | do_signal+0x2c/0x218 | resume_user_mode_begin+0x90/0xd8
Workaround by re-enabling preemption temporarily.
Note that the preemption disabling in core code around show_regs() was introduced by commit 3a9f84d354ce ("signals, debug: fix BUG: using smp_processor_id() in preemptible code in print_fatal_signal()")
to silence a differnt lockdep seen on x86 bakc in 2009.
--- arch/arc/kernel/troubleshoot.c | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arc/kernel/troubleshoot.c +8 -0
@@ -179,6 +179,12 @@ void show_regs(struct pt_regs *regs)struct task_struct *tsk = current;struct callee_regs *cregs; +/* +* generic code calls us with preemption disabled, but some calls +* here could sleep, so re-enable to avoid lockdep splat +*/ +preempt_enable (); +print_task_path_n_nm (tsk);show_regs_print_info (KERN_INFO );
@@ -221,6 +227,8 @@ void show_regs(struct pt_regs *regs) cregs = (struct callee_regs *)current->thread.callee_reg;if (cregs)show_callee_regs (cregs); + +preempt_disable (); } void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 77/190 ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault
In reply to Greg Kroah-Hartman[ Upstream commit 4d447455e73b47c43dd35fcc38ed823d3182a474 ]
do_page_fault() forgot to relinquish mmap_sem if a signal came while handling handle_mm_fault() - due to say a ctl+c or oom etc. This would later cause a deadlock by acquiring it twice.
This came to light when running libc testsuite tst-tls3-malloc test but is likely also the cause for prior seen LTP failures. Using lockdep clearly showed what the issue was.
| # while true; do ./tst-tls3-malloc ; done
| Didn't expect signal from child: got `Segmentation fault'
| ^C
| ============================================
| WARNING: possible recursive locking detected
| 4.17.0+ #25 Not tainted
| --------------------------------------------
| tst-tls3-malloc/510 is trying to acquire lock:
| 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c
|
|but task is already holding lock:
|606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0
|
| other info that might help us debug this:
| Possible unsafe locking scenario:
|
| CPU0
| ----
| lock(&mm->mmap_sem);
| lock(&mm->mmap_sem);
|
| *** DEADLOCK ***
|------------------------------------------------------------
What the change does is not obvious (note to myself)
prior code was
| do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_ERROR | up_read | if user_mode | return <-- lock still held, this was the BUG
New code
| do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_RETRY | return <-- not same case as above, but still OK since | core mm already relinq lock for FAULT_RETRY | ... | | < Now falls through for bug case above > | | up_read() <-- lock relinquished
--- arch/arc/mm/fault.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
arch/arc/mm/fault.c +9 -4
@@ -143,12 +143,17 @@ good_area:*/ fault =handle_mm_fault (vma, address, flags); -/* If Pagefault was interrupted by SIGKILL, exit page fault "early" */ if (unlikely (fatal_signal_pending (current))) { -if ((fault &VM_FAULT_ERROR ) && !(fault &VM_FAULT_RETRY )) -up_read (&mm->mmap_sem); -if (user_mode (regs)) + +/* +* if fault retry, mmap_sem already relinquished by core mm +* so OK to return to user mode (with signal handled first) +*/ +if (fault &VM_FAULT_RETRY ) { +if (!user_mode (regs)) + goto no_context;return ; + } }perf_sw_event (PERF_COUNT_SW_PAGE_FAULTS ,1 , regs, address);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 78/190 IB/uverbs: Fix OOPs upon device disassociation
In reply to Greg Kroah-Hartman[ Upstream commit 425784aa5b029eeb80498c73a68f62c3ad1d3b3f ]
The async_file might be freed before the disassociation has been ended, causing qp shutdown to use after free on it.
Since uverbs_destroy_ufile_hw is not a fence, it returns if a disassociation is ongoing in another thread. It has to be written this way to avoid deadlock. However this means that the ufile FD close cannot destroy anything that may still be used by an active kref, such as the the async_file.
To fix that move the kref_put() to be in ib_uverbs_release_file().
BUG: unable to handle kernel paging request at ffffffffba682787 PGD bc80e067 P4D bc80e067 PUD bc80f063 PMD 1313df163 PTE 80000000bc682061 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 32410 Comm: bash Tainted: G OE 4.20.0-rc6+ #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_lock_slowpath+0x1b3/0x2a0 Code: 98 83 e2 60 49 89 df 48 8b 04 c5 80 18 72 ba 48 8d ba 80 32 02 00 ba 00 80 00 00 4c 8d 65 14 41 bd 01 00 00 00 48 01 c7 85 d2 <48> 89 2f 48 89 fb 74 14 8b 45 08 85 c0 75 42 84 d2 74 6b f3 90 83 RSP: 0018:ffffc1bbc064fb58 EFLAGS: 00010006 RAX: ffffffffba65f4e7 RBX: ffff9f209c656c00 RCX: 0000000000000001 RDX: 0000000000008000 RSI: 0000000000000000 RDI: ffffffffba682787 RBP: ffff9f217bb23280 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9f209d2c7800 R11: ffffffffffffffe8 R12: ffff9f217bb23294 R13: 0000000000000001 R14: 0000000000000000 R15: ffff9f209c656c00 FS: 00007fac55aad740(0000) GS:ffff9f217bb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffba682787 CR3: 000000012f8e0000 CR4: 00000000000006e0 Call Trace: _raw_spin_lock_irq+0x27/0x30 ib_uverbs_release_uevent+0x1e/0xa0 [ib_uverbs] uverbs_free_qp+0x7e/0x90 [ib_uverbs] destroy_hw_idr_uobject+0x1c/0x50 [ib_uverbs] uverbs_destroy_uobject+0x2e/0x180 [ib_uverbs] __uverbs_cleanup_ufile+0x73/0x90 [ib_uverbs] uverbs_destroy_ufile_hw+0x5d/0x120 [ib_uverbs] ib_uverbs_remove_one+0xea/0x240 [ib_uverbs] ib_unregister_device+0xfb/0x200 [ib_core] mlx5_ib_remove+0x51/0xe0 [mlx5_ib] mlx5_remove_device+0xc1/0xd0 [mlx5_core] mlx5_unregister_device+0x3d/0xb0 [mlx5_core] remove_one+0x2a/0x90 [mlx5_core] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x16d/0x240 unbind_store+0xb2/0x100 kernfs_fop_write+0x102/0x180 __vfs_write+0x36/0x1a0 ? __alloc_fd+0xa9/0x170 ? set_close_on_exec+0x49/0x70 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fac551aac60
--- drivers/infiniband/core/uverbs_main.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/infiniband/core/uverbs_main.c +3 -4
@@ -265,6 +265,9 @@ void ib_uverbs_release_file(struct kref *ref)if (atomic_dec_and_test (&file->device->refcount))ib_uverbs_comp_dev (file->device); +if (file->async_file) +kref_put (&file->async_file->ref, + ib_uverbs_release_async_event_file);kobject_put (&file->device->kobj);kfree (file); }
@@ -915,10 +918,6 @@ static int ib_uverbs_close(struct inode *inode, struct file *filp) }mutex_unlock (&file->device->lists_mutex); -if (file->async_file) -kref_put (&file->async_file->ref, - ib_uverbs_release_async_event_file); -kref_put (&file->ref, ib_uverbs_release_file);return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 79/190 crypto: ccree - fix resume race condition on init
In reply to Greg Kroah-Hartman[ Upstream commit 1358c13a48c43f5e4de0c1835291837a27b9720c ]
We were enabling autosuspend, which is using data set by the hash module, prior to the hash module being inited, casuing a crash on resume as part of the startup sequence if the race was lost.
This was never a real problem because the PM infra was using low res timers so we were always winning the race, until commit 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") changed that :-)
Fix this by seperating the PM setup and enablement and doing the latter only at the end of the init sequence.
--- drivers/crypto/ccree/cc_driver.c | 7 ++++--- drivers/crypto/ccree/cc_pm.c | 13 ++++++------- drivers/crypto/ccree/cc_pm.h | 3 +++ 3 files changed, 13 insertions(+), 10 deletions(-)
drivers/crypto/ccree/cc_driver.c +4 -3
@@ -364,7 +364,7 @@ static int init_cc_resources(struct platform_device *plat_dev) rc =cc_ivgen_init (new_drvdata);if (rc) {dev_err (dev,"cc_ivgen_init failed\n" ); - goto post_power_mgr_err; + goto post_buf_mgr_err; }/* Allocate crypto algs */
@@ -387,6 +387,9 @@ static int init_cc_resources(struct platform_device *plat_dev) goto post_hash_err; } +/* All set, we can allow autosuspend */ +cc_pm_go (new_drvdata); +/* If we got here and FIPS mode is enabled * it means all FIPS test passed, so let TEE * know we're good.
@@ -401,8 +404,6 @@ post_cipher_err:cc_cipher_free (new_drvdata); post_ivgen_err:cc_ivgen_fini (new_drvdata); -post_power_mgr_err: -cc_pm_fini (new_drvdata); post_buf_mgr_err:cc_buffer_mgr_fini (new_drvdata); post_req_mgr_err:
drivers/crypto/ccree/cc_pm.c +6 -7
@@ -103,20 +103,19 @@ int cc_pm_put_suspend(struct device *dev)int cc_pm_init (struct cc_drvdata *drvdata) { -int rc =0 ;struct device *dev =drvdata_to_dev (drvdata);/* must be before the enabling to avoid resdundent suspending */ pm_runtime_set_autosuspend_delay (dev,CC_SUSPEND_TIMEOUT );pm_runtime_use_autosuspend (dev);/* activate the PM module */ - rc =pm_runtime_set_active (dev); -if (rc) -return rc; -/* enable the PM module*/ -pm_runtime_enable (dev); +return pm_runtime_set_active (dev); +} -return rc; +/* enable the PM module*/ +void cc_pm_go (struct cc_drvdata *drvdata) +{ +pm_runtime_enable (drvdata_to_dev (drvdata)); }void cc_pm_fini (struct cc_drvdata *drvdata)
drivers/crypto/ccree/cc_pm.h +3 -0
@@ -16,6 +16,7 @@extern const struct dev_pm_ops ccree_pm;int cc_pm_init (struct cc_drvdata *drvdata); +void cc_pm_go (struct cc_drvdata *drvdata);void cc_pm_fini (struct cc_drvdata *drvdata);int cc_pm_suspend (struct device *dev);int cc_pm_resume (struct device *dev);
@@ -29,6 +30,8 @@ static inline int cc_pm_init(struct cc_drvdata *drvdata)return 0 ; } +static void cc_pm_go (struct cc_drvdata *drvdata) {} +static inline void cc_pm_fini (struct cc_drvdata *drvdata) {}static inline int cc_pm_suspend (struct device *dev)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 80/190 crypto: ccree - add missing inline qualifier
In reply to Greg Kroah-Hartman[ Upstream commit f1071c3e2473ae19a7f5d892a187c4cab1a61f2e ]
Commit 1358c13a48c4 ("crypto: ccree - fix resume race condition on init") was missing a "inline" qualifier for stub function used when CONFIG_PM is not set causing a build warning.
--- drivers/crypto/ccree/cc_pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/ccree/cc_pm.h +1 -1
@@ -30,7 +30,7 @@ static inline int cc_pm_init(struct cc_drvdata *drvdata)return 0 ; } -static void cc_pm_go (struct cc_drvdata *drvdata) {} +static inline void cc_pm_go (struct cc_drvdata *drvdata) {}static inline void cc_pm_fini (struct cc_drvdata *drvdata) {}
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 81/190 drm/vblank: Allow dynamic per-crtc max_vblank_count
In reply to Greg Kroah-Hartman[ Upstream commit ed20151a7699bb2c77eba3610199789a126940c4 ]
On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to configure the per-crtc value before calling drm_vblank_on().
Also looks like there was some discussion about exynos needing similar treatment.
v2: Drop the extra max_vblank_count!=0 check for the
WARN(last!=current), will take care of it in i915 code (Daniel)
WARN_ON(!inmodeset) (Daniel)
WARN_ON(dev->max_vblank_count)
Pimp up the docs (Daniel)--- drivers/gpu/drm/drm_vblank.c | 45 +++++++++++++++++++++++++++++++++--- include/drm/drm_device.h | 8 ++++++- include/drm/drm_vblank.h | 22 ++++++++++++++++++ 3 files changed, 71 insertions(+), 4 deletions(-)
drivers/gpu/drm/drm_vblank.c +42 -3
@@ -105,13 +105,20 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe,write_sequnlock (&vblank->seqlock); } +static u32 drm_max_vblank_count (struct drm_device *dev,unsigned int pipe) +{ +struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; + +return vblank->max_vblank_count ?: dev->max_vblank_count; +} +/* * "No hw counter" fallback implementation of .get_vblank_counter() hook, * if there is no useable hardware frame counter available. */ static u32 drm_vblank_no_hw_counter (struct drm_device *dev,unsigned int pipe) { -WARN_ON_ONCE (dev->max_vblank_count !=0 ); +WARN_ON_ONCE (drm_max_vblank_count (dev, pipe) !=0 );return 0 ; }
@@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,ktime_t t_vblank;int count =DRM_TIMESTAMP_MAXRETRIES ;int framedur_ns = vblank->framedur_ns; +u32 max_vblank_count =drm_max_vblank_count (dev, pipe);/* * Interrupts were disabled prior to this call, so deal with counter
@@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, rc =drm_get_last_vbltimestamp (dev, pipe, &t_vblank, in_vblank_irq); }while (cur_vblank !=__get_vblank_counter (dev, pipe) && --count >0 ); -if (dev->max_vblank_count !=0 ) { +if (max_vblank_count) {/* trust the hw counter when it's around */ - diff = (cur_vblank - vblank->last) & dev->max_vblank_count; + diff = (cur_vblank - vblank->last) & max_vblank_count; }else if (rc && framedur_ns) {u64 diff_ns =ktime_to_ns (ktime_sub (t_vblank, vblank->time));
@@ -1204,6 +1212,37 @@ void drm_crtc_vblank_reset(struct drm_crtc *crtc) }EXPORT_SYMBOL (drm_crtc_vblank_reset); +/** +* drm_crtc_set_max_vblank_count - configure the hw max vblank counter value +* @crtc: CRTC in question +* @max_vblank_count: max hardware vblank counter value +* +* Update the maximum hardware vblank counter value for @crtc +* at runtime. Useful for hardware where the operation of the +* hardware vblank counter depends on the currently active +* display configuration. +* +* For example, if the hardware vblank counter does not work +* when a specific connector is active the maximum can be set +* to zero. And when that specific connector isn't active the +* maximum can again be set to the appropriate non-zero value. +* +* If used, must be called before drm_vblank_on(). +*/ +void drm_crtc_set_max_vblank_count (struct drm_crtc *crtc, +u32 max_vblank_count) +{ +struct drm_device *dev = crtc->dev; +unsigned int pipe =drm_crtc_index (crtc); +struct drm_vblank_crtc *vblank = &dev->vblank[pipe]; + +WARN_ON (dev->max_vblank_count); +WARN_ON (!READ_ONCE (vblank->inmodeset)); + + vblank->max_vblank_count = max_vblank_count; +} +EXPORT_SYMBOL (drm_crtc_set_max_vblank_count); +/** * drm_crtc_vblank_on - enable vblank events on a CRTC * @crtc: CRTC in question
include/drm/drm_device.h +7 -1
@@ -174,7 +174,13 @@ struct drm_device {* races and imprecision over longer time periods, hence exposing a * hardware vblank counter is always recommended. * -* If non-zeor, &drm_crtc_funcs.get_vblank_counter must be set. +* This is the statically configured device wide maximum. The driver +* can instead choose to use a runtime configurable per-crtc value +* &drm_vblank_crtc.max_vblank_count, in which case @max_vblank_count +* must be left at zero. See drm_crtc_set_max_vblank_count() on how +* to use the per-crtc value. +* +* If non-zero, &drm_crtc_funcs.get_vblank_counter must be set. */ u32 max_vblank_count;/**< size of vblank counter register */
include/drm/drm_vblank.h +22 -0
@@ -128,6 +128,26 @@ struct drm_vblank_crtc {* @last: Protected by &drm_device.vbl_lock, used for wraparound handling. */ u32 last; +/** +* @max_vblank_count: +* +* Maximum value of the vblank registers for this crtc. This value +1 +* will result in a wrap-around of the vblank register. It is used +* by the vblank core to handle wrap-arounds. +* +* If set to zero the vblank core will try to guess the elapsed vblanks +* between times when the vblank interrupt is disabled through +* high-precision timestamps. That approach is suffering from small +* races and imprecision over longer time periods, hence exposing a +* hardware vblank counter is always recommended. +* +* This is the runtime configurable per-crtc maximum set through +* drm_crtc_set_max_vblank_count(). If this is used the driver +* must leave the device wide &drm_device.max_vblank_count at zero. +* +* If non-zero, &drm_crtc_funcs.get_vblank_counter must be set. +*/ +u32 max_vblank_count;/** * @inmodeset: Tracks whether the vblank is disabled due to a modeset. * For legacy driver bit 2 additionally tracks whether an additional
@@ -206,4 +226,6 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,void drm_calc_timestamping_constants (struct drm_crtc *crtc,const struct drm_display_mode *mode);wait_queue_head_t *drm_crtc_vblank_waitqueue (struct drm_crtc *crtc); +void drm_crtc_set_max_vblank_count (struct drm_crtc *crtc, +u32 max_vblank_count);#endif
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 82/190 drm/i915/ilk: Fix warning when reading emon_status with no output
In reply to Greg Kroah-Hartman[ Upstream commit cab870b7fdf3c4be747d88de5248b28db7d4055e ]
When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs.
[22.756480] ------------[ cut here ]------------ [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282 [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006 [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57 [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000 [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001 [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188 [22.756651] FS: 00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000 [22.756653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008 [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020 [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0 [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000 [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ]
--- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/i915/i915_debugfs.c +4 -0
@@ -1788,6 +1788,8 @@ static int i915_emon_status(struct seq_file *m, void *unused)if (!IS_GEN5 (dev_priv))return -ENODEV ; +intel_runtime_pm_get (dev_priv); + ret =mutex_lock_interruptible (&dev->struct_mutex);if (ret)return ret;
@@ -1802,6 +1804,8 @@ static int i915_emon_status(struct seq_file *m, void *unused)seq_printf (m,"GFX power: %ld\n" , gfx);seq_printf (m,"Total power: %ld\n" , chipset + gfx); +intel_runtime_pm_put (dev_priv); +return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 83/190 mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies
In reply to Greg Kroah-Hartman[ Upstream commit 09fdc98577120d4f47601c3127efde726a2300c6 ]
INTEL_SOC_PMIC, INTEL_SOC_PMIC_CHTWC and MFD_TPS68470 select the I2C_DESIGNWARE_PLATFORM without its dependencies making it possible to see warning and build error like below:
WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM
Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y]) Selected by [y]:
- MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y
/usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_resume':
i2c-designware-platdrv.c:(.text+0x62): undefined reference to i2c_dw_prepare_clk' /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function dw_i2c_plat_suspend':
i2c-designware-platdrv.c:(.text+0x9a): undefined reference to i2c_dw_prepare_clk' /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function dw_i2c_plat_probe':
i2c-designware-platdrv.c:(.text+0x41c): undefined reference to i2c_dw_prepare_clk' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x438): undefined reference to i2c_dw_read_comp_param' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x545): undefined reference to i2c_dw_probe' /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x727): undefined reference to i2c_dw_probe_slave'
Fix this by making above options to depend on I2C_DESIGNWARE_PLATFORM being built-in. I2C_DESIGNWARE_PLATFORM is a visible symbol with dependencies so in general the select should be avoided.
--- drivers/mfd/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mfd/Kconfig +3 -3
@@ -509,10 +509,10 @@ config INTEL_SOC_PMIC bool "Support for Crystal Cove PMIC" depends on ACPI && HAS_IOMEM && I2C=y && GPIOLIB && COMMON_CLK depends on X86 || COMPILE_TEST + depends on I2C_DESIGNWARE_PLATFORM=y select MFD_CORE select REGMAP_I2C select REGMAP_IRQ - select I2C_DESIGNWARE_PLATFORM help Select this option to enable support for Crystal Cove PMIC on some Intel SoC systems. The PMIC provides ADC, GPIO,
@@ -538,10 +538,10 @@ config INTEL_SOC_PMIC_CHTWC bool "Support for Intel Cherry Trail Whiskey Cove PMIC" depends on ACPI && HAS_IOMEM && I2C=y && COMMON_CLK depends on X86 || COMPILE_TEST + depends on I2C_DESIGNWARE_PLATFORM=y select MFD_CORE select REGMAP_I2C select REGMAP_IRQ - select I2C_DESIGNWARE_PLATFORM help Select this option to enable support for the Intel Cherry Trail Whiskey Cove PMIC found on some Intel Cherry Trail systems.
@@ -1403,9 +1403,9 @@ config MFD_TPS65217 config MFD_TPS68470 bool "TI TPS68470 Power Management / LED chips" depends on ACPI && I2C=y + depends on I2C_DESIGNWARE_PLATFORM=y select MFD_CORE select REGMAP_I2C - select I2C_DESIGNWARE_PLATFORM help If you say yes here you get support for the TPS68470 series of Power Management / LED chips.
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 84/190 tpm: Fix some name collisions with drivers/char/tpm.h
In reply to Greg Kroah-Hartman[ Upstream commit 8ab547a2dcfac6ec184a5e036e1093eb3f7a215c ]
* Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to ST33ZP24_BUFSIZE.
* Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to TPM_I2C_INFINEON_BUFSIZE.
* Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES.
* Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton.
--- drivers/char/tpm/st33zp24/i2c.c | 2 +- drivers/char/tpm/st33zp24/spi.c | 2 +- drivers/char/tpm/st33zp24/st33zp24.h | 4 ++-- drivers/char/tpm/tpm_i2c_infineon.c | 15 ++++++++------- drivers/char/tpm/tpm_i2c_nuvoton.c | 16 +++++++--------- 5 files changed, 19 insertions(+), 20 deletions(-)
drivers/char/tpm/st33zp24/i2c.c +1 -1
@@ -33,7 +33,7 @@struct st33zp24_i2c_phy {struct i2c_client *client; -u8 buf[TPM_BUFSIZE +1 ]; +u8 buf[ST33ZP24_BUFSIZE +1 ];int io_lpcpd; };
drivers/char/tpm/st33zp24/spi.c +1 -1
@@ -63,7 +63,7 @@* some latency byte before the answer is available (max 15). * We have 2048 + 1024 + 15. */ -#define ST33ZP24_SPI_BUFFER_SIZE (TPM_BUFSIZE + (TPM_BUFSIZE / 2) +\ +#define ST33ZP24_SPI_BUFFER_SIZE (ST33ZP24_BUFSIZE + (ST33ZP24_BUFSIZE / 2) +\ MAX_SPI_LATENCY)
drivers/char/tpm/st33zp24/st33zp24.h +2 -2
@@ -18,8 +18,8 @@ #ifndef __LOCAL_ST33ZP24_H__ #define __LOCAL_ST33ZP24_H__ -#define TPM_WRITE_DIRECTION 0x80 -#define TPM_BUFSIZE 2048 +#define TPM_WRITE_DIRECTION 0x80 +#define ST33ZP24_BUFSIZE 2048 struct st33zp24_dev { struct tpm_chip *chip;
drivers/char/tpm/tpm_i2c_infineon.c +8 -7
@@ -26,8 +26,7 @@#include <linux/wait.h> #include "tpm.h" -/* max. buffer size supported by our TPM */ -#define TPM_BUFSIZE 1260 +#define TPM_I2C_INFINEON_BUFSIZE 1260/* max. number of iterations after I2C NAK */ #define MAX_COUNT 3
@@ -63,11 +62,13 @@ enum i2c_chip_type { UNKNOWN, }; -/* Structure to store I2C TPM specific stuff */ struct tpm_inf_dev {struct i2c_client *client;int locality; -u8 buf[TPM_BUFSIZE +sizeof (u8)];/* max. buffer size + addr */ +/* In addition to the data itself, the buffer must fit the 7-bit I2C +* address and the direction bit. +*/ +u8 buf[TPM_I2C_INFINEON_BUFSIZE +1 ];struct tpm_chip *chip;enum i2c_chip_type chip_type;unsigned int adapterlimit;
@@ -219,7 +220,7 @@ static int iic_tpm_write_generic(u8 addr, u8 *buffer, size_t len, .buf = tpm_dev.buf }; -if (len >TPM_BUFSIZE ) +if (len >TPM_I2C_INFINEON_BUFSIZE )return -EINVAL ;if (!tpm_dev.client->adapter->algo->master_xfer)
@@ -527,8 +528,8 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)u8 retries =0 ;u8 sts =TPM_STS_GO ; -if (len >TPM_BUFSIZE ) -return -E2BIG ;/* command is too long for our tpm, sorry */ +if (len >TPM_I2C_INFINEON_BUFSIZE ) +return -E2BIG ;if (request_locality (chip,0 ) <0 )return -EBUSY ;
drivers/char/tpm/tpm_i2c_nuvoton.c +7 -9
@@ -35,14 +35,12 @@#include "tpm.h" /* I2C interface offsets */ -#define TPM_STS 0x00 -#define TPM_BURST_COUNT 0x01 -#define TPM_DATA_FIFO_W 0x20 -#define TPM_DATA_FIFO_R 0x40 -#define TPM_VID_DID_RID 0x60 -/* TPM command header size */ -#define TPM_HEADER_SIZE 10 -#define TPM_RETRY 5 +#define TPM_STS 0x00 +#define TPM_BURST_COUNT 0x01 +#define TPM_DATA_FIFO_W 0x20 +#define TPM_DATA_FIFO_R 0x40 +#define TPM_VID_DID_RID 0x60 +#define TPM_I2C_RETRIES 5/* * I2C bus device maximum buffer size w/o counting I2C address or command * i.e. max size required for I2C write is 34 = addr, command, 32 bytes data
@@ -292,7 +290,7 @@ static int i2c_nuvoton_recv(struct tpm_chip *chip, u8 *buf, size_t count)dev_err (dev,"%s() count < header size\n" , __func__);return -EIO ; } -for (retries =0 ; retries <TPM_RETRY ; retries++) { +for (retries =0 ; retries <TPM_I2C_RETRIES ; retries++) {if (retries >0 ) {/* if this is not the first trial, set responseRetry */ i2c_nuvoton_write_status(client,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 85/190 bcache: replace hard coded number with BUCKET_GC_GEN_MAX
In reply to Greg Kroah-Hartman[ Upstream commit 149d0efada7777ad5a5242b095692af142f533d8 ]
In extents.c:bch_extent_bad(), number 96 is used as parameter to call btree_bug_on(). The purpose is to check whether stale gen value exceeds BUCKET_GC_GEN_MAX, so it is better to use macro BUCKET_GC_GEN_MAX to make the code more understandable.
--- drivers/md/bcache/extents.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/bcache/extents.c +1 -1
@@ -553,7 +553,7 @@ static bool bch_extent_bad(struct btree_keys *bk, const struct bkey *k)for (i =0 ; i <KEY_PTRS (k); i++) { stale =ptr_stale (b->c, k, i); -btree_bug_on (stale >96 , b, +btree_bug_on (stale >BUCKET_GC_GEN_MAX , b,"key too stale: %i, need_gc %u" , stale, b->c->need_gc);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 86/190 bcache: treat stale && dirty keys as bad keys
In reply to Greg Kroah-Hartman[ Upstream commit 58ac323084ebf44f8470eeb8b82660f9d0ee3689 ]
Stale && dirty keys can be produced in the follow way:
After writeback in write_dirty_finish(), dirty keys k1 will replace by clean keys k2
==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key); ==>btree_insert_fn(struct btree_op *b_op, struct btree *b) ==>static int bch_btree_insert_node(struct btree *b,
struct btree_op *op,
struct keylist *insert_keys,
atomic_t *journal_ref,
Then two steps:
A) update k1 to k2 in btree node memory; bch_btree_insert_keys(b, op, insert_keys, replace_key)
B) Write the bset(contains k2) to cache disk by a 30s delay work bch_btree_leaf_dirty(b, journal_ref).
But before the 30s delay work write the bset to cache device, these things happened:
A) GC works, and reclaim the bucket k2 point to;
B) Allocator works, and invalidate the bucket k2 point to, and increase the gen of the bucket, and place it into free_inc fifo;
C) Until now, the 30s delay work still does not finish work, so in the disk, the key still is k1, it is dirty and stale (its gen is smaller than the gen of the bucket). and then the machine power off suddenly happens;
D) When the machine power on again, after the btree reconstruction, the stale dirty key appear.
In bch_extent_bad(), when expensive_debug_checks is off, it would treat the dirty key as good even it is stale keys, and it would cause bellow probelms:
A) In read_dirty() it would cause machine crash:
BUG_ON(ptr_stale(dc->disk.c, &w->key, 0));
B) It could be worse when reads hits stale dirty keys, it would read old incorrect data.
This patch tolerate the existence of these stale && dirty keys, and treat them as bad key in bch_extent_bad().
(Coly Li: fix indent which was modified by sender's email client)
--- drivers/md/bcache/extents.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
drivers/md/bcache/extents.c +7 -6
@@ -538,6 +538,7 @@ static bool bch_extent_bad(struct btree_keys *bk, const struct bkey *k) { struct btree *b = container_of(bk, struct btree, keys);unsigned int i, stale; +char buf[80 ];if (!KEY_PTRS (k) ||bch_extent_invalid (bk, k))
@@ -547,19 +548,19 @@ static bool bch_extent_bad(struct btree_keys *bk, const struct bkey *k)if (!ptr_available (b->c, k, i))return true; -if (!expensive_debug_checks (b->c) &&KEY_DIRTY (k)) -return false; -for (i =0 ; i <KEY_PTRS (k); i++) { stale =ptr_stale (b->c, k, i); +if (stale &&KEY_DIRTY (k)) { +bch_extent_to_text (buf,sizeof (buf), k); +pr_info ("stale dirty pointer, stale %u, key: %s" , + stale, buf); + } +btree_bug_on (stale >BUCKET_GC_GEN_MAX , b,"key too stale: %i, need_gc %u" , stale, b->c->need_gc); -btree_bug_on (stale &&KEY_DIRTY (k) &&KEY_SIZE (k), - b,"stale dirty pointer" ); -if (stale)return true;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 87/190 KVM: VMX: Compare only a single byte for VMCS "launched" in vCPU-run
In reply to Greg Kroah-Hartman[ Upstream commit 61c08aa9606d4e48a8a50639c956448a720174c3 ]
The vCPU-run asm blob does a manual comparison of a VMCS' launched status to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs. VMRESUME. The launched flag is a bool, which is a typedef of _Bool. C99 does not define an exact size for _Bool, stating only that is must be large enough to hold '0' and '1'. Most, if not all, compilers use a single byte for _Bool, including gcc[1].
Originally, 'launched' was of type 'int' and so the asm blob used 'cmpl' to check the launch status. When 'launched' was moved to be stored on a per-VMCS basis, struct vcpu_vmx's "temporary" __launched flag was added in order to avoid having to pass the current VMCS into the asm blob. The new '__launched' was defined as a 'bool' and not an 'int', but the 'cmp' instruction was not updated.
This has not caused any known problems, likely due to compilers aligning variables to 4-byte or 8-byte boundaries and KVM zeroing out struct vcpu_vmx during allocation. I.e. vCPU-run accesses "junk" data, it just happens to always be zero and so doesn't affect the result.
[1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html
--- arch/x86/kvm/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/vmx.c +1 -1
@@ -10808,7 +10808,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)"mov %%" _ASM_AX", %%cr2 \n\t" "3: \n\t" /* Check if vmlaunch of vmresume is needed */ -"cmpl $0, %c[launched](%0) \n\t" +"cmpb $0, %c[launched](%0) \n\t" /* Load guest registers. Don't clobber flags. */ "mov %c[rax](%0), %%" _ASM_AX" \n\t" "mov %c[rbx](%0), %%" _ASM_BX" \n\t"
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 88/190 iio: adc: exynos-adc: Add S5PV210 variant
In reply to Greg Kroah-Hartman[ Upstream commit 882bf52fdeab47dbe991cc0e564b0b51c571d0a3 ]
S5PV210's ADC variant is almost the same as v1 except that it has 10 channels and doesn't require the pmu register
--- drivers/iio/adc/exynos_adc.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/iio/adc/exynos_adc.c +14 -0
@@ -115,6 +115,7 @@#define MAX_ADC_V2_CHANNELS 10#define MAX_ADC_V1_CHANNELS 8#define MAX_EXYNOS3250_ADC_CHANNELS 2 +#define MAX_S5PV210_ADC_CHANNELS 10/* Bit definitions common for ADC_V1 and ADC_V2 */ #define ADC_CON_EN_START (1u << 0)
@@ -282,6 +283,16 @@ static const struct exynos_adc_data exynos_adc_v1_data = { .start_conv = exynos_adc_v1_start_conv, }; +static const struct exynos_adc_data exynos_adc_s5pv210_data = { + .num_channels =MAX_S5PV210_ADC_CHANNELS , + .mask =ADC_DATX_MASK ,/* 12 bit ADC resolution */ + + .init_hw = exynos_adc_v1_init_hw, + .exit_hw = exynos_adc_v1_exit_hw, + .clear_irq = exynos_adc_v1_clear_irq, + .start_conv = exynos_adc_v1_start_conv, +}; +static void exynos_adc_s3c2416_start_conv (struct exynos_adc *info,unsigned long addr) {
@@ -478,6 +489,9 @@ static const struct of_device_id exynos_adc_match[] = { }, { .compatible = "samsung,s3c6410-adc", .data = &exynos_adc_s3c64xx_data, + }, { + .compatible = "samsung,s5pv210-adc", + .data = &exynos_adc_s5pv210_data, }, { .compatible = "samsung,exynos-adc-v1", .data = &exynos_adc_v1_data,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 89/190 dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant
In reply to Greg Kroah-Hartman[ Upstream commit a9b0a2a7c19316588421b94946c8e2e5a84ac14e ]
Add information about new compatible for S5PV210
--- .../devicetree/bindings/iio/adc/samsung,exynos-adc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt +3 -1
@@ -11,7 +11,7 @@ New driver handles the following Required properties: - compatible: Must be "samsung,exynos-adc-v1" - for exynos4412/5250 and s5pv210 controllers. + for exynos4412/5250 controllers. Must be "samsung,exynos-adc-v2" for future controllers. Must be "samsung,exynos3250-adc" for
@@ -28,6 +28,8 @@ Required properties: the ADC in s3c2443 and compatibles Must be "samsung,s3c6410-adc" for the ADC in s3c6410 and compatibles + Must be "samsung,s5pv210-adc" for + the ADC in s5pv210 and compatibles - reg: List of ADC register address range - The base address and range of ADC register - The base address and range of ADC_PHY register (every
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 90/190 iio: adc: exynos-adc: Use proper number of channels for Exynos4x12
In reply to Greg Kroah-Hartman[ Upstream commit 103cda6a3b8d2c10d5f8cd7abad118e9db8f4776 ]
Exynos4212 and Exynos4412 have only four ADC channels so using "samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is wrong. Add a new compatible for Exynos4x12.
--- .../bindings/iio/adc/samsung,exynos-adc.txt | 4 +++- drivers/iio/adc/exynos_adc.c | 17 +++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.txt +3 -1
@@ -11,11 +11,13 @@ New driver handles the following Required properties: - compatible: Must be "samsung,exynos-adc-v1" - for exynos4412/5250 controllers. + for Exynos5250 controllers. Must be "samsung,exynos-adc-v2" for future controllers. Must be "samsung,exynos3250-adc" for controllers compatible with ADC of Exynos3250. + Must be "samsung,exynos4212-adc" for + controllers compatible with ADC of Exynos4212 and Exynos4412. Must be "samsung,exynos7-adc" for the ADC in Exynos7 and compatibles Must be "samsung,s3c2410-adc" for
drivers/iio/adc/exynos_adc.c +17 -0
@@ -115,6 +115,7 @@#define MAX_ADC_V2_CHANNELS 10#define MAX_ADC_V1_CHANNELS 8#define MAX_EXYNOS3250_ADC_CHANNELS 2 +#define MAX_EXYNOS4212_ADC_CHANNELS 4#define MAX_S5PV210_ADC_CHANNELS 10/* Bit definitions common for ADC_V1 and ADC_V2 */
@@ -271,6 +272,19 @@ static void exynos_adc_v1_start_conv(struct exynos_adc *info,writel (con1 |ADC_CON_EN_START ,ADC_V1_CON (info->regs)); } +/* Exynos4212 and 4412 is like ADCv1 but with four channels only */ +static const struct exynos_adc_data exynos4212_adc_data = { + .num_channels =MAX_EXYNOS4212_ADC_CHANNELS , + .mask =ADC_DATX_MASK ,/* 12 bit ADC resolution */ + .needs_adc_phy = true, + .phy_offset =EXYNOS_ADCV1_PHY_OFFSET , + + .init_hw = exynos_adc_v1_init_hw, + .exit_hw = exynos_adc_v1_exit_hw, + .clear_irq = exynos_adc_v1_clear_irq, + .start_conv = exynos_adc_v1_start_conv, +}; +static const struct exynos_adc_data exynos_adc_v1_data = { .num_channels =MAX_ADC_V1_CHANNELS , .mask =ADC_DATX_MASK ,/* 12 bit ADC resolution */
@@ -492,6 +506,9 @@ static const struct of_device_id exynos_adc_match[] = { }, { .compatible = "samsung,s5pv210-adc", .data = &exynos_adc_s5pv210_data, + }, { + .compatible = "samsung,exynos4212-adc", + .data = &exynos4212_adc_data, }, { .compatible = "samsung,exynos-adc-v1", .data = &exynos_adc_v1_data,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 91/190 mt76: fix corrupted software generated tx CCMP PN
In reply to Greg Kroah-Hartman[ Upstream commit 906d2d3f874a54183df5a609fda180adf0462428 ]
Since ccmp_pn is u8 *, the second half needs to start at array index 4 instead of 0. Fixes a connection stall after a certain amount of traffic
--- drivers/net/wireless/mediatek/mt76/mt76x2_mac_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/mediatek/mt76/mt76x2_mac_common.c +1 -1
@@ -402,7 +402,7 @@ void mt76x2_mac_write_txwi(struct mt76x2_dev *dev, struct mt76x2_txwi *txwi, ccmp_pn[6 ] = pn >>32 ; ccmp_pn[7 ] = pn >>40 ; txwi->iv = *((__le32 *)&ccmp_pn[0 ]); - txwi->eiv = *((__le32 *)&ccmp_pn[1 ]); + txwi->eiv = *((__le32 *)&ccmp_pn[4 ]); }spin_lock_bh (&dev->mt76.lock);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 92/190 drm/nouveau: Dont WARN_ON VCPI allocation failures
In reply to Greg Kroah-Hartman[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead.
--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/dispnv50/disp.c +2 -1
@@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots =drm_dp_find_vcpi_slots (&mstm->mgr, mstc->pbn); r =drm_dp_mst_allocate_vcpi (&mstm->mgr, mstc->port, mstc->pbn, slots); -WARN_ON (!r); +if (!r) +DRM_DEBUG_KMS ("Failed to allocate VCPI\n" );if (!mstm->links++)nv50_outp_acquire (mstm->outp);
Signature · 8 lines
2.20.1 _______________________________________________ Nouveau mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
Cheers,
-ilia
Quoted 43 lines · Greg Kroah-Hartman
[ Upstream commit
b513a18cf1d705bd04efd91c417e79e4938be093]This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead.
Signed-off-by Lyude Paul <[email protected]>Fixes f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")Cc Ben Skeggs <[email protected]>Cc <[email protected]> # v4.10+Signed-off-by Ben Skeggs <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)drivers/gpu/drm/nouveau/dispnv50/disp.c +2
-2@@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots =drm_dp_find_vcpi_slots (&mstm->mgr, mstc->pbn); r =drm_dp_mst_allocate_vcpi (&mstm->mgr, mstc->port, mstc->pbn, slots); -WARN_ON (!r); +if (!r) +DRM_DEBUG_KMS ("Failed to allocate VCPI\n" );if (!mstm->links++)nv50_outp_acquire (mstm->outp); --2.20.1
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Sasha Levin
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit bdcc885be68289a37d0d063cd94390da81fd8178
Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100
drm/nouveau: Don't WARN_ON VCPI allocation failures
--
Thanks,
Sasha
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 12 lines · Sasha Levin
Quoted 10 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failures
Quoted 7 lines
Quoted 2 lines
Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
That's right -- the email's From header gets used in the case of no explicit From in the email body. But Greg is sending the emails From:
Greg, so if I were to ingest that email, I would end up with a patch
From: Greg, not From: Lyude as it ought to be.
Cheers,
-ilia
Greg Kroah-Hartman
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
In reply to Sasha LevinQuoted 22 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
Quoted 7 lines
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100drm/nouveau: Don't
WARN_ONVCPI allocation failures
Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
thanks,
greg k-h
Sasha Levin
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 29 lines · Greg Kroah-Hartman
Quoted 28 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100
Quoted 6 lines
Quoted 1 line
drm/nouveau: Don't
WARN_ONVCPI allocation failuresYeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
Heh, didn't think anyone cared about this scenario for the stable-rc patches.
I'll go add it.
But... why do you actually care?
--
Thanks,
Sasha
Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 38 lines · Sasha Levin
Quoted 29 lines · Greg Kroah-Hartman
Quoted 28 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100Quoted 6 lines
Quoted 1 line
drm/nouveau: Don't
WARN_ONVCPI allocation failuresYeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
Quoted 6 lines
Heh, didn't think anyone cared about this scenario for the stable-rc patches.
I'll go add it.
But... why do you actually care?
Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different?
(I was surprised to see Greg contributing to nouveau when I first saw the patch. But then realized it was the stable ingestion notification.)
-ilia
Sasha Levin
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 42 lines · Ilia Mirkin
Quoted 41 lines · Sasha Levin
Quoted 29 lines · Greg Kroah-Hartman
Quoted 28 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100Quoted 6 lines
Quoted 1 line
drm/nouveau: Don't
WARN_ONVCPI allocation failuresYeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
Heh, didn't think anyone cared about this scenario for the stable-rc patches.
Quoted 6 lines
Quoted 3 lines
I'll go add it.
But... why do you actually care?
Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different?
It shouldn't.
It's just a mismatch between our two somewhat seperate workflow.
Technically it's Greg who needs to be adding that line since the patches I have in stable-queue correctly state the author, and it only goes wrong when they're being formatted into mails sent for the -rc cycles.
But yes, thanks for pointing it out, I'll go add it in the scripts.
--
Thanks,
Sasha
Greg Kroah-Hartman
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
In reply to Sasha LevinQuoted 37 lines · Sasha Levin
Quoted 29 lines · Greg Kroah-Hartman
Quoted 28 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100Quoted 6 lines
Quoted 1 line
drm/nouveau: Don't
WARN_ONVCPI allocation failuresYeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
Quoted 6 lines
Heh, didn't think anyone cared about this scenario for the stable-rc patches.
I'll go add it.
But... why do you actually care?
On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch.
thanks,
greg k-h
Sasha Levin
maintainerRe: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Quoted 41 lines · Greg Kroah-Hartman
Quoted 40 lines · Sasha Levin
Quoted 29 lines · Greg Kroah-Hartman
Quoted 28 lines · Sasha Levin
Quoted 4 lines · Ilia Mirkin
Hi Greg,
This feels like it's missing a From: line.
Quoted 8 lines
commit
b513a18cf1d705bd04efd91c417e79e4938be093Author: Lyude Paul <[email protected]> Date: Mon Jan 28 16:03:50 2019 -0500drm/nouveau: Don't
WARN_ONVCPI allocation failuresIs this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly?
It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header.
The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree:
commit
bdcc885be68289a37d0d063cd94390da81fd8178Author: Lyude Paul <[email protected]> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman <[email protected]> CommitDate: Fri Sep 13 14:05:29 2019 +0100Quoted 6 lines
Quoted 1 line
drm/nouveau: Don't
WARN_ONVCPI allocation failuresYeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches.
Heh, didn't think anyone cared about this scenario for the stable-rc patches.
Quoted 7 lines
Quoted 3 lines
I'll go add it.
But... why do you actually care?
On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch.
Right right, I agree this is wrong and I'll fix it. I'm just concerned about what exactly you are doing with the -rc patches to actually care about this :)
--
Thanks,
Sasha
Greg Kroah-Hartman
maintainerPATCH 93/190 iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules
In reply to Greg Kroah-Hartman[ Upstream commit ab27926d9e4ae23df4f4d98e31f067c8b486bb4f ]
The devices with PCI device ID 0x34F0 are part of the SoC and can be combined with some different external RF modules. The configuration for these devices should reflect that, but are currently mixed up. To avoid confusion with discrete devices, add part of the firmware to be used and the official name of the device to the cfg structs.
This is least reorganization possible (without messing things even more) that could be done as a bugfix for this SoC. Further reorganization of this code will be done separately.
--- .../net/wireless/intel/iwlwifi/cfg/22000.c | 65 ++++++++++++++++++- .../net/wireless/intel/iwlwifi/iwl-config.h | 9 ++- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 55 ++++++++-------- 3 files changed, 97 insertions(+), 32 deletions(-)
drivers/net/wireless/intel/iwlwifi/cfg/22000.c +62 -3
@@ -77,10 +77,13 @@#define IWL_22000_HR_FW_PRE "iwlwifi-Qu-a0-hr-a0-"#define IWL_22000_HR_CDB_FW_PRE "iwlwifi-QuIcp-z0-hrcdb-a0-"#define IWL_22000_HR_A_F0_FW_PRE "iwlwifi-QuQnj-f0-hr-a0-" -#define IWL_22000_HR_B_FW_PRE "iwlwifi-Qu-b0-hr-b0-" +#define IWL_22000_HR_B_F0_FW_PRE "iwlwifi-Qu-b0-hr-b0-" +#define IWL_22000_QU_B_HR_B_FW_PRE "iwlwifi-Qu-b0-hr-b0-" +#define IWL_22000_HR_B_FW_PRE "iwlwifi-QuQnj-b0-hr-b0-"#define IWL_22000_JF_B0_FW_PRE "iwlwifi-QuQnj-a0-jf-b0-"#define IWL_22000_HR_A0_FW_PRE "iwlwifi-QuQnj-a0-hr-a0-"#define IWL_22000_SU_Z0_FW_PRE "iwlwifi-su-z0-" +#define IWL_QU_B_JF_B_FW_PRE "iwlwifi-Qu-b0-jf-b0-"#define IWL_22000_HR_MODULE_FIRMWARE (api) \ IWL_22000_HR_FW_PRE __stringify(api) ".ucode"
@@ -88,7 +91,11 @@ IWL_22000_JF_FW_PRE __stringify(api) ".ucode"#define IWL_22000_HR_A_F0_QNJ_MODULE_FIRMWARE (api) \ IWL_22000_HR_A_F0_FW_PRE __stringify(api) ".ucode" -#define IWL_22000_HR_B_QNJ_MODULE_FIRMWARE (api) \ +#define IWL_22000_HR_B_F0_QNJ_MODULE_FIRMWARE (api) \ + IWL_22000_HR_B_F0_FW_PRE __stringify(api) ".ucode" +#define IWL_22000_QU_B_HR_B_MODULE_FIRMWARE (api) \ + IWL_22000_QU_B_HR_B_FW_PRE __stringify(api) ".ucode" +#define IWL_22000_HR_B_QNJ_MODULE_FIRMWARE (api) \ IWL_22000_HR_B_FW_PRE __stringify(api) ".ucode"#define IWL_22000_JF_B0_QNJ_MODULE_FIRMWARE (api) \ IWL_22000_JF_B0_FW_PRE __stringify(api) ".ucode"
@@ -96,6 +103,8 @@ IWL_22000_HR_A0_FW_PRE __stringify(api) ".ucode"#define IWL_22000_SU_Z0_MODULE_FIRMWARE (api) \ IWL_22000_SU_Z0_FW_PRE __stringify(api) ".ucode" +#define IWL_QU_B_JF_B_MODULE_FIRMWARE (api) \ + IWL_QU_B_JF_B_FW_PRE __stringify(api) ".ucode"#define NVM_HW_SECTION_NUM_FAMILY_22000 10
@@ -190,7 +199,54 @@ const struct iwl_cfg iwl22000_2ac_cfg_jf = {const struct iwl_cfg iwl22000_2ax_cfg_hr = { .name ="Intel(R) Dual Band Wireless AX 22000" , - .fw_name_pre =IWL_22000_HR_FW_PRE , + .fw_name_pre =IWL_22000_QU_B_HR_B_FW_PRE , +IWL_DEVICE_22500 , +/* +* This device doesn't support receiving BlockAck with a large bitmap +* so we need to restrict the size of transmitted aggregation to the +* HT size; mac80211 would otherwise pick the HE max (256) by default. +*/ + .max_tx_agg_size =IEEE80211_MAX_AMPDU_BUF_HT , +}; + +/* +* All JF radio modules are part of the 9000 series, but the MAC part +* looks more like 22000. That's why this device is here, but called +* 9560 nevertheless. +*/ +const struct iwl_cfg iwl9461_2ac_cfg_qu_b0_jf_b0 = { + .name ="Intel(R) Wireless-AC 9461" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE , +IWL_DEVICE_22500 , +}; + +const struct iwl_cfg iwl9462_2ac_cfg_qu_b0_jf_b0 = { + .name ="Intel(R) Wireless-AC 9462" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE , +IWL_DEVICE_22500 , +}; + +const struct iwl_cfg iwl9560_2ac_cfg_qu_b0_jf_b0 = { + .name ="Intel(R) Wireless-AC 9560" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE , +IWL_DEVICE_22500 , +}; + +const struct iwl_cfg killer1550i_2ac_cfg_qu_b0_jf_b0 = { + .name ="Killer (R) Wireless-AC 1550i Wireless Network Adapter (9560NGW)" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE , +IWL_DEVICE_22500 , +}; + +const struct iwl_cfg killer1550s_2ac_cfg_qu_b0_jf_b0 = { + .name ="Killer (R) Wireless-AC 1550s Wireless Network Adapter (9560NGW)" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE , +IWL_DEVICE_22500 , +}; + +const struct iwl_cfg iwl22000_2ax_cfg_jf = { + .name ="Intel(R) Dual Band Wireless AX 22000" , + .fw_name_pre =IWL_QU_B_JF_B_FW_PRE ,IWL_DEVICE_22500 ,/* * This device doesn't support receiving BlockAck with a large bitmap
@@ -264,7 +320,10 @@ const struct iwl_cfg iwl22560_2ax_cfg_su_cdb = {MODULE_FIRMWARE (IWL_22000_HR_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_JF_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_HR_A_F0_QNJ_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX )); +MODULE_FIRMWARE (IWL_22000_HR_B_F0_QNJ_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX )); +MODULE_FIRMWARE (IWL_22000_QU_B_HR_B_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_HR_B_QNJ_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_JF_B0_QNJ_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_HR_A0_QNJ_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));MODULE_FIRMWARE (IWL_22000_SU_Z0_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX )); +MODULE_FIRMWARE (IWL_QU_B_JF_B_MODULE_FIRMWARE (IWL_22000_UCODE_API_MAX ));
drivers/net/wireless/intel/iwlwifi/iwl-config.h +8 -1
@@ -574,11 +574,18 @@ extern const struct iwl_cfg iwl22000_2ac_cfg_hr;extern const struct iwl_cfg iwl22000_2ac_cfg_hr_cdb;extern const struct iwl_cfg iwl22000_2ac_cfg_jf;extern const struct iwl_cfg iwl22000_2ax_cfg_hr; +extern const struct iwl_cfg iwl9461_2ac_cfg_qu_b0_jf_b0; +extern const struct iwl_cfg iwl9462_2ac_cfg_qu_b0_jf_b0; +extern const struct iwl_cfg iwl9560_2ac_cfg_qu_b0_jf_b0; +extern const struct iwl_cfg killer1550i_2ac_cfg_qu_b0_jf_b0; +extern const struct iwl_cfg killer1550s_2ac_cfg_qu_b0_jf_b0; +extern const struct iwl_cfg iwl22000_2ax_cfg_jf;extern const struct iwl_cfg iwl22000_2ax_cfg_qnj_hr_a0_f0; +extern const struct iwl_cfg iwl22000_2ax_cfg_qnj_hr_b0_f0;extern const struct iwl_cfg iwl22000_2ax_cfg_qnj_hr_b0;extern const struct iwl_cfg iwl22000_2ax_cfg_qnj_jf_b0;extern const struct iwl_cfg iwl22000_2ax_cfg_qnj_hr_a0;extern const struct iwl_cfg iwl22560_2ax_cfg_su_cdb; -#endif /* CONFIG_IWLMVM */ +#endif /* CPTCFG_IWLMVM || CPTCFG_IWLFMAC */ #endif /* __IWL_CONFIG_H__ */
drivers/net/wireless/intel/iwlwifi/pcie/drv.c +27 -28
61 lines not on this page · raw message
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 94/190 iwlwifi: add new card for 9260 series
In reply to Greg Kroah-Hartman[ Upstream commit 3941310cf665b8a7965424d2a185c80782faa030 ]
Add one PCI ID for 9260 series.
--- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/intel/iwlwifi/pcie/drv.c +1 -0
@@ -601,6 +601,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x2526, 0x2030, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x2034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x4018, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4034, iwl9560_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)},
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 95/190 x86/kvmclock: set offset for kvm unstable clock
In reply to Greg Kroah-Hartman[ Upstream commit b5179ec4187251a751832193693d6e474d3445ac ]
VMs may show incorrect uptime and dmesg printk offsets on hypervisors with unstable clock. The problem is produced when VM is rebooted without exiting from qemu.
The fix is to calculate clock offset not only for stable clock but for unstable clock as well, and use kvm_sched_clock_read() which substracts the offset for both clocks.
This is safe, because pvclock_clocksource_read() does the right thing and makes sure that clock always goes forward, so once offset is calculated with unstable clock, we won't get new reads that are smaller than offset, and thus won't get negative results.
Thank you Jon DeVree for helping to reproduce this issue.
--- arch/x86/kernel/kvmclock.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
arch/x86/kernel/kvmclock.c +1 -5
@@ -117,12 +117,8 @@ static u64 kvm_sched_clock_read(void)static inline void kvm_sched_clock_init (bool stable) { -if (!stable) { - pv_time_ops.sched_clock = kvm_clock_read; +if (!stable)clear_sched_clock_stable (); -return ; - } - kvm_sched_clock_offset =kvm_clock_read (); pv_time_ops.sched_clock = kvm_sched_clock_read;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 96/190 spi: spi-gpio: fix SPI_CS_HIGH capability
In reply to Greg Kroah-Hartman[ Upstream commit b89fefda7d4e3a649129584d855be233c7465264 ]
spi-gpio is capable of dealing with active-high chip-selects. Unfortunately, commit 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") broke this by setting master->mode_bits, which overrides the setting in the spi-bitbang code. Fix this.
[Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie]
--- drivers/spi/spi-gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/spi/spi-gpio.c +1 -2
@@ -410,7 +410,7 @@ static int spi_gpio_probe(struct platform_device *pdev)return status; master->bits_per_word_mask =SPI_BPW_RANGE_MASK (1 ,32 ); - master->mode_bits =SPI_3WIRE |SPI_CPHA |SPI_CPOL ; + master->mode_bits =SPI_3WIRE |SPI_CPHA |SPI_CPOL |SPI_CS_HIGH ; master->flags = master_flags; master->bus_num = pdev->id;/* The master needs to think there is a chipselect even if not connected */
@@ -437,7 +437,6 @@ static int spi_gpio_probe(struct platform_device *pdev) spi_gpio->bitbang.txrx_word[SPI_MODE_3 ] = spi_gpio_spec_txrx_word_mode3; } spi_gpio->bitbang.setup_transfer = spi_bitbang_setup_transfer; - spi_gpio->bitbang.flags =SPI_CS_HIGH ; status =spi_bitbang_start (&spi_gpio->bitbang);if (status)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 97/190 powerpc/kvm: Save and restore host AMR/IAMR/UAMOR
In reply to Greg Kroah-Hartman[ Upstream commit c3c7470c75566a077c8dc71dcf8f1948b8ddfab4 ]
When the hash MMU is active the AMR, IAMR and UAMOR are used for pkeys. The AMR is directly writable by user space, and the UAMOR masks those writes, meaning both registers are effectively user register state. The IAMR is used to create an execute only key.
Also we must maintain the value of at least the AMR when running in process context, so that any memory accesses done by the kernel on behalf of the process are correctly controlled by the AMR.
Although we are correctly switching all registers when going into a guest, on returning to the host we just write 0 into all regs, except on Power9 where we restore the IAMR correctly.
This could be observed by a user process if it writes the AMR, then runs a guest and we then return immediately to it without rescheduling. Because we have written 0 to the AMR that would have the effect of granting read/write permission to pages that the process was trying to protect.
In addition, when using the Radix MMU, the AMR can prevent inadvertent kernel access to userspace data, writing 0 to the AMR disables that protection.
So save and restore AMR, IAMR and UAMOR.
--- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 26 ++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-)
arch/powerpc/kvm/book3s_hv_rmhandlers.S +17 -9
@@ -56,6 +56,8 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300) #define STACK_SLOT_DAWR (SFS-56) #define STACK_SLOT_DAWRX (SFS-64) #define STACK_SLOT_HFSCR (SFS-72) +#define STACK_SLOT_AMR (SFS-80) +#define STACK_SLOT_UAMOR (SFS-88) /* * Call kvmppc_hv_entry in real mode.
@@ -760,11 +762,9 @@ BEGIN_FTR_SECTION mfspr r5, SPRN_TIDR mfspr r6, SPRN_PSSCR mfspr r7, SPRN_PID - mfspr r8, SPRN_IAMR std r5, STACK_SLOT_TID(r1) std r6, STACK_SLOT_PSSCR(r1) std r7, STACK_SLOT_PID(r1) - std r8, STACK_SLOT_IAMR(r1) mfspr r5, SPRN_HFSCR std r5, STACK_SLOT_HFSCR(r1) END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
@@ -772,11 +772,18 @@ BEGIN_FTR_SECTION mfspr r5, SPRN_CIABR mfspr r6, SPRN_DAWR mfspr r7, SPRN_DAWRX + mfspr r8, SPRN_IAMR std r5, STACK_SLOT_CIABR(r1) std r6, STACK_SLOT_DAWR(r1) std r7, STACK_SLOT_DAWRX(r1) + std r8, STACK_SLOT_IAMR(r1) END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S) + mfspr r5, SPRN_AMR + std r5, STACK_SLOT_AMR(r1) + mfspr r6, SPRN_UAMOR + std r6, STACK_SLOT_UAMOR(r1) + BEGIN_FTR_SECTION /* Set partition DABR */ /* Do this before re-enabling PMU to avoid P7 DABR corruption bug */
@@ -1713,22 +1720,25 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_300) mtspr SPRN_PSPB, r0 mtspr SPRN_WORT, r0 BEGIN_FTR_SECTION - mtspr SPRN_IAMR, r0 mtspr SPRN_TCSCR, r0 /* Set MMCRS to 1<<31 to freeze and disable the SPMC counters */ li r0, 1 sldi r0, r0, 31 mtspr SPRN_MMCRS, r0 END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300) -8: - /* Save and reset AMR and UAMOR before turning on the MMU */ + /* Save and restore AMR, IAMR and UAMOR before turning on the MMU */ + ld r8, STACK_SLOT_IAMR(r1) + mtspr SPRN_IAMR, r8 + +8: /* Power7 jumps back in here */ mfspr r5,SPRN_AMR mfspr r6,SPRN_UAMOR std r5,VCPU_AMR(r9) std r6,VCPU_UAMOR(r9) - li r6,0 - mtspr SPRN_AMR,r6 + ld r5,STACK_SLOT_AMR(r1) + ld r6,STACK_SLOT_UAMOR(r1) + mtspr SPRN_AMR, r5 mtspr SPRN_UAMOR, r6 /* Switch DSCR back to host value */
@@ -1897,11 +1907,9 @@ BEGIN_FTR_SECTION ld r5, STACK_SLOT_TID(r1) ld r6, STACK_SLOT_PSSCR(r1) ld r7, STACK_SLOT_PID(r1) - ld r8, STACK_SLOT_IAMR(r1) mtspr SPRN_TIDR, r5 mtspr SPRN_PSSCR, r6 mtspr SPRN_PID, r7 - mtspr SPRN_IAMR, r8 END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300) #ifdef CONFIG_PPC_RADIX_MMU
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 98/190 mmc: renesas_sdhi: Fix card initialization failure in high speed mode
In reply to Greg Kroah-Hartman[ Upstream commit d30ae056adb81e1d2b8b953efa74735a020b8e3b ]
This fixes card initialization failure in high speed mode.
If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux DT does not enable SDR/HS200/HS400 mode, card initialization fails in high speed mode.
It is necessary to initialize SCC registers during card initialization phase. HW reset function is registered only for a port with either of SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties are not present in device tree, SCC registers will not be reset. In SoC that support SCC registers, HW reset function should be registered regardless of the configuration of device tree.
Reproduction procedure:
- Use U-Boot that support MMC HS200/400 mode.
- Delete HS200/HS400 properties in device tree. (Delete mmc-hs200-1_8v and mmc-hs400-1_8v)
- MMC port works high speed mode and all commands fail.
--- drivers/mmc/host/renesas_sdhi_core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/mmc/host/renesas_sdhi_core.c +7 -4
@@ -636,6 +636,13 @@ int renesas_sdhi_probe(struct platform_device *pdev, host->ops.card_busy = renesas_sdhi_card_busy; host->ops.start_signal_voltage_switch = renesas_sdhi_start_signal_voltage_switch; + +/* SDR and HS200/400 registers requires HW reset */ +if (of_data && of_data->scc_offset) { + priv->scc_ctl = host->ctl + of_data->scc_offset; + host->mmc->caps |=MMC_CAP_HW_RESET ; + host->hw_reset = renesas_sdhi_hw_reset; + } }/* Orginally registers were 16 bit apart, could be 32 or 64 nowadays */
@@ -693,8 +700,6 @@ int renesas_sdhi_probe(struct platform_device *pdev,const struct renesas_sdhi_scc *taps = of_data->taps;bool hit = false; - host->mmc->caps |=MMC_CAP_HW_RESET ; -for (i =0 ; i < of_data->taps_num; i++) {if (taps[i].clk_rate ==0 || taps[i].clk_rate == host->mmc->f_max) {
@@ -707,12 +712,10 @@ int renesas_sdhi_probe(struct platform_device *pdev,if (!hit)dev_warn (&host->pdev->dev,"Unknown clock rate for SDR104\n" ); - priv->scc_ctl = host->ctl + of_data->scc_offset; host->init_tuning = renesas_sdhi_init_tuning; host->prepare_tuning = renesas_sdhi_prepare_tuning; host->select_tuning = renesas_sdhi_select_tuning; host->check_scc_error = renesas_sdhi_check_scc_error; - host->hw_reset = renesas_sdhi_hw_reset; host->prepare_hs400_tuning = renesas_sdhi_prepare_hs400_tuning; host->hs400_downgrade = renesas_sdhi_disable_scc;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 99/190 btrfs: scrub: pass fs_info to scrub_setup_ctx
In reply to Greg Kroah-Hartman[ Upstream commit 92f7ba434f51e8e9317f1d166105889aa230abd2 ]
We can pass fs_info directly as this is the only member of btrfs_device that's bing used inside scrub_setup_ctx.
--- fs/btrfs/scrub.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/btrfs/scrub.c +4 -5
@@ -578,12 +578,11 @@ static void scrub_put_ctx(struct scrub_ctx *sctx)scrub_free_ctx (sctx); } -static noinline_for_stack -struct scrub_ctx *scrub_setup_ctx(struct btrfs_device *dev, int is_dev_replace) +static noinline_for_stack struct scrub_ctx *scrub_setup_ctx( +struct btrfs_fs_info *fs_info,int is_dev_replace) {struct scrub_ctx *sctx;int i; -struct btrfs_fs_info *fs_info = dev->fs_info; sctx =kzalloc (sizeof (*sctx),GFP_KERNEL );if (!sctx)
@@ -592,7 +591,7 @@ struct scrub_ctx *scrub_setup_ctx(struct btrfs_device *dev, int is_dev_replace) sctx->is_dev_replace = is_dev_replace; sctx->pages_per_rd_bio =SCRUB_PAGES_PER_RD_BIO ; sctx->curr =-1 ; - sctx->fs_info = dev->fs_info; + sctx->fs_info = fs_info;for (i =0 ; i <SCRUB_BIOS_PER_SCTX ; ++i) {struct scrub_bio *sbio;
@@ -3881,7 +3880,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,return ret; } - sctx =scrub_setup_ctx (dev, is_dev_replace); + sctx =scrub_setup_ctx (fs_info, is_dev_replace);if (IS_ERR (sctx)) {mutex_unlock (&fs_info->scrub_lock);mutex_unlock (&fs_info->fs_devices->device_list_mutex);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 100/190 btrfs: scrub: move scrub_setup_ctx allocation out of device_list_mutex
In reply to Greg Kroah-Hartman[ Upstream commit 0e94c4f45d14cf89d1f40c91b0a8517e791672a7 ]
The scrub context is allocated with GFP_KERNEL and called from btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe regarding reclaim that could try to flush filesystem data in order to get the memory. And the device_list_mutex is held during superblock commit, so this would cause a lockup.
Move the alocation and initialization before any changes that require the mutex.
--- fs/btrfs/scrub.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-)
fs/btrfs/scrub.c +18 -12
@@ -3837,13 +3837,18 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,return -EINVAL ; } +/* Allocate outside of device_list_mutex */ + sctx =scrub_setup_ctx (fs_info, is_dev_replace); +if (IS_ERR (sctx)) +return PTR_ERR (sctx);mutex_lock (&fs_info->fs_devices->device_list_mutex); dev =btrfs_find_device (fs_info, devid,NULL ,NULL );if (!dev || (test_bit (BTRFS_DEV_STATE_MISSING , &dev->dev_state) && !is_dev_replace)) {mutex_unlock (&fs_info->fs_devices->device_list_mutex); -return -ENODEV ; + ret = -ENODEV ; + goto out_free_ctx; } if (!is_dev_replace && !readonly &&
@@ -3851,7 +3856,8 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,mutex_unlock (&fs_info->fs_devices->device_list_mutex);btrfs_err_in_rcu (fs_info,"scrub: device %s is not writable" ,rcu_str_deref (dev->name)); -return -EROFS ; + ret = -EROFS ; + goto out_free_ctx; }mutex_lock (&fs_info->scrub_lock);
@@ -3859,7 +3865,8 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, test_bit(BTRFS_DEV_STATE_REPLACE_TGT, &dev->dev_state)) {mutex_unlock (&fs_info->scrub_lock);mutex_unlock (&fs_info->fs_devices->device_list_mutex); -return -EIO ; + ret = -EIO ; + goto out_free_ctx; }btrfs_dev_replace_read_lock (&fs_info->dev_replace);
@@ -3869,7 +3876,8 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,btrfs_dev_replace_read_unlock (&fs_info->dev_replace);mutex_unlock (&fs_info->scrub_lock);mutex_unlock (&fs_info->fs_devices->device_list_mutex); -return -EINPROGRESS ; + ret = -EINPROGRESS ; + goto out_free_ctx; }btrfs_dev_replace_read_unlock (&fs_info->dev_replace);
@@ -3877,16 +3885,9 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,if (ret) {mutex_unlock (&fs_info->scrub_lock);mutex_unlock (&fs_info->fs_devices->device_list_mutex); -return ret; + goto out_free_ctx; } - sctx =scrub_setup_ctx (fs_info, is_dev_replace); -if (IS_ERR (sctx)) { -mutex_unlock (&fs_info->scrub_lock); -mutex_unlock (&fs_info->fs_devices->device_list_mutex); -scrub_workers_put (fs_info); -return PTR_ERR (sctx); - } sctx->readonly = readonly; dev->scrub_ctx = sctx;mutex_unlock (&fs_info->fs_devices->device_list_mutex);
@@ -3939,6 +3940,11 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,scrub_put_ctx (sctx); +return ret; + +out_free_ctx: +scrub_free_ctx (sctx); +return ret; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 101/190 btrfs: scrub: fix circular locking dependency warning
In reply to Greg Kroah-Hartman[ Upstream commit 1cec3f27168d7835ff3d23ab371cd548440131bb ]
This fixes a longstanding lockdep warning triggered by fstests/btrfs/011.
Circular locking dependency check reports warning[1], that's because the btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock held. The test case leading to this warning:
$ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /btrfs $ btrfs scrub start -B /btrfs
In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy of the scrub workers are needed. So once we have incremented and decremented the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this patch drops the scrub_lock before calling btrfs_destroy_workqueue().
[359.258534] ======================================================
[359.260305] WARNING: possible circular locking dependency detected
[359.261938] 5.0.0-rc6-default #461 Not tainted
[359.263135] ------------------------------------------------------
[359.264672] btrfs/20975 is trying to acquire lock:
[359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540
[359.268416]
[359.268416] but task is already holding lock:
[359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
[359.272418]
[359.272418] which lock already depends on the new lock.
[359.272418]
[359.274692]
[359.274692] the existing dependency chain (in reverse order) is:
[359.276671]
[359.276671] -> #3 (&fs_info->scrub_lock){+.+.}:
[359.278187] __mutex_lock+0x86/0x9c0
[359.279086] btrfs_scrub_pause+0x31/0x100 [btrfs]
[359.280421] btrfs_commit_transaction+0x1e4/0x9e0 [btrfs]
[359.281931] close_ctree+0x30b/0x350 [btrfs]
[359.283208] generic_shutdown_super+0x64/0x100
[359.284516] kill_anon_super+0x14/0x30
[359.285658] btrfs_kill_super+0x12/0xa0 [btrfs]
[359.286964] deactivate_locked_super+0x29/0x60
[359.288242] cleanup_mnt+0x3b/0x70
[359.289310] task_work_run+0x98/0xc0
[359.290428] exit_to_usermode_loop+0x83/0x90
[359.291445] do_syscall_64+0x15b/0x180
[359.292598] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[359.294011]
[359.294011] -> #2 (sb_internal#2){.+.+}:
[359.295432] __sb_start_write+0x113/0x1d0
[359.296394] start_transaction+0x369/0x500 [btrfs]
[359.297471] btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs]
[359.298629] normal_work_helper+0xcd/0x530 [btrfs]
[359.299698] process_one_work+0x246/0x610
[359.300898] worker_thread+0x3c/0x390
[359.302020] kthread+0x116/0x130
[359.303053] ret_from_fork+0x24/0x30
[359.304152]
[359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}:
[359.306100] process_one_work+0x21f/0x610
[359.307302] worker_thread+0x3c/0x390
[359.308465] kthread+0x116/0x130
[359.309357] ret_from_fork+0x24/0x30
[359.310229]
[359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}:
[359.311812] lock_acquire+0x90/0x180
[359.312929] flush_workqueue+0xaa/0x540
[359.313845] drain_workqueue+0xa1/0x180
[359.314761] destroy_workqueue+0x17/0x240
[359.315754] btrfs_destroy_workqueue+0x57/0x200 [btrfs]
[359.317245] scrub_workers_put+0x2c/0x60 [btrfs]
[359.318585] btrfs_scrub_dev+0x336/0x590 [btrfs]
[359.319944] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
[359.321622] btrfs_ioctl+0x28a4/0x2e40 [btrfs]
[359.322908] do_vfs_ioctl+0xa2/0x6d0
[359.324021] ksys_ioctl+0x3a/0x70
[359.325066] __x64_sys_ioctl+0x16/0x20
[359.326236] do_syscall_64+0x54/0x180
[359.327379] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[359.328772]
[359.328772] other info that might help us debug this:
[359.328772]
[359.330990] Chain exists of:
[359.330990] (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock
[359.330990]
[359.334376] Possible unsafe locking scenario:
[359.334376]
[359.336020] CPU0 CPU1
[359.337070] ---- ----
[359.337821] lock(&fs_info->scrub_lock);
[359.338506] lock(sb_internal#2);
[359.339506] lock(&fs_info->scrub_lock);
[359.341461] lock((wq_completion)"%s-%s""btrfs", name);
[359.342437]
[359.342437] *** DEADLOCK ***
[359.342437]
[359.343745] 1 lock held by btrfs/20975:
[359.344788] #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
[359.346778]
[359.346778] stack backtrace:
[359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461
[359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
[359.350501] Call Trace:
[359.350931] dump_stack+0x67/0x90
[359.351676] print_circular_bug.isra.37.cold.56+0x15c/0x195
[359.353569] check_prev_add.constprop.44+0x4f9/0x750
[359.354849] ? check_prev_add.constprop.44+0x286/0x750
[359.356505] __lock_acquire+0xb84/0xf10
[359.357505] lock_acquire+0x90/0x180
[359.358271] ? flush_workqueue+0x87/0x540
[359.359098] flush_workqueue+0xaa/0x540
[359.359912] ? flush_workqueue+0x87/0x540
[359.360740] ? drain_workqueue+0x1e/0x180
[359.361565] ? drain_workqueue+0xa1/0x180
[359.362391] drain_workqueue+0xa1/0x180
[359.363193] destroy_workqueue+0x17/0x240
[359.364539] btrfs_destroy_workqueue+0x57/0x200 [btrfs]
[359.365673] scrub_workers_put+0x2c/0x60 [btrfs]
[359.366618] btrfs_scrub_dev+0x336/0x590 [btrfs]
[359.367594] ? start_transaction+0xa1/0x500 [btrfs]
[359.368679] btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
[359.369545] btrfs_ioctl+0x28a4/0x2e40 [btrfs]
[359.370186] ? __lock_acquire+0x263/0xf10
[359.370777] ? kvm_clock_read+0x14/0x30
[359.371392] ? kvm_sched_clock_read+0x5/0x10
[359.372248] ? sched_clock+0x5/0x10
[359.372786] ? sched_clock_cpu+0xc/0xc0
[359.373662] ? do_vfs_ioctl+0xa2/0x6d0
[359.374552] do_vfs_ioctl+0xa2/0x6d0
[359.375378] ? do_sigaction+0xff/0x250
[359.376233] ksys_ioctl+0x3a/0x70
[359.376954] __x64_sys_ioctl+0x16/0x20
[359.377772] do_syscall_64+0x54/0x180
[359.378841] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[359.380422] RIP: 0033:0x7f5429296a97Backporting to older kernels: scrub_nocow_workers must be freed the same way as the others.
--- fs/btrfs/scrub.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
fs/btrfs/scrub.c +11 -11
@@ -3778,16 +3778,6 @@ fail_scrub_workers:return -ENOMEM ; } -static noinline_for_stack void scrub_workers_put(struct btrfs_fs_info *fs_info) -{ -if (--fs_info->scrub_workers_refcnt ==0 ) { -btrfs_destroy_workqueue (fs_info->scrub_workers); -btrfs_destroy_workqueue (fs_info->scrub_wr_completion_workers); -btrfs_destroy_workqueue (fs_info->scrub_parity_workers); - } -WARN_ON (fs_info->scrub_workers_refcnt <0 ); -} -int btrfs_scrub_dev (struct btrfs_fs_info *fs_info,u64 devid,u64 start,u64 end,struct btrfs_scrub_progress *progress,int readonly,int is_dev_replace)
@@ -3796,6 +3786,9 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,int ret;struct btrfs_device *dev;unsigned int nofs_flag; +struct btrfs_workqueue *scrub_workers =NULL ; +struct btrfs_workqueue *scrub_wr_comp =NULL ; +struct btrfs_workqueue *scrub_parity =NULL ;if (btrfs_fs_closing (fs_info))return -EINVAL ;
@@ -3935,9 +3928,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,mutex_lock (&fs_info->scrub_lock); dev->scrub_ctx =NULL ; -scrub_workers_put (fs_info); +if (--fs_info->scrub_workers_refcnt ==0 ) { + scrub_workers = fs_info->scrub_workers; + scrub_wr_comp = fs_info->scrub_wr_completion_workers; + scrub_parity = fs_info->scrub_parity_workers; + }mutex_unlock (&fs_info->scrub_lock); +btrfs_destroy_workqueue (scrub_workers); +btrfs_destroy_workqueue (scrub_wr_comp); +btrfs_destroy_workqueue (scrub_parity);scrub_put_ctx (sctx);return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 102/190 btrfs: init csum_list before possible free
In reply to Greg Kroah-Hartman[ Upstream commit e49be14b8d80e23bb7c53d78c21717a474ade76b ]
The scrub_ctx csum_list member must be initialized before scrub_free_ctx is called. If the csum_list is not initialized beforehand, the list_empty call in scrub_free_csums will result in a null deref if the allocation fails in the for loop.
--- fs/btrfs/scrub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/scrub.c +1 -1
@@ -592,6 +592,7 @@ static noinline_for_stack struct scrub_ctx *scrub_setup_ctx( sctx->pages_per_rd_bio =SCRUB_PAGES_PER_RD_BIO ; sctx->curr =-1 ; sctx->fs_info = fs_info; +INIT_LIST_HEAD (&sctx->csum_list);for (i =0 ; i <SCRUB_BIOS_PER_SCTX ; ++i) {struct scrub_bio *sbio;
@@ -616,7 +617,6 @@ static noinline_for_stack struct scrub_ctx *scrub_setup_ctx(atomic_set (&sctx->workers_pending,0 );atomic_set (&sctx->cancel_req,0 ); sctx->csum_size =btrfs_super_csum_size (fs_info->super_copy); -INIT_LIST_HEAD (&sctx->csum_list);spin_lock_init (&sctx->list_lock);spin_lock_init (&sctx->stat_lock);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 103/190 PCI: qcom: Fix error handling in runtime PM support
In reply to Greg Kroah-Hartman[ Upstream commit 6e5da6f7d82474e94c2d4a38cf9ca4edbb3e03a0 ]
The driver does not cope with the fact that probe can fail in a number of cases after enabling runtime PM on the device; this results in warnings about "Unbalanced pm_runtime_enable". Furthermore if probe fails after invoking qcom_pcie_host_init() the power-domain will be left referenced.
As it is not possible for the error handling in qcom_pcie_host_init() to handle errors happening after returning from that function the pm_runtime_get_sync() is moved to qcom_pcie_probe() as well.
--- drivers/pci/controller/dwc/pcie-qcom.c | 56 ++++++++++++++++++-------- 1 file changed, 39 insertions(+), 17 deletions(-)
drivers/pci/controller/dwc/pcie-qcom.c +39 -17
@@ -1091,7 +1091,6 @@ static int qcom_pcie_host_init(struct pcie_port *pp)struct qcom_pcie *pcie =to_qcom_pcie (pci);int ret; -pm_runtime_get_sync (pci->dev);qcom_ep_reset_assert (pcie); ret = pcie->ops->init (pcie);
@@ -1128,7 +1127,6 @@ err_disable_phy:phy_power_off (pcie->phy); err_deinit: pcie->ops->deinit (pcie); -pm_runtime_put (pci->dev);return ret; }
@@ -1218,6 +1216,12 @@ static int qcom_pcie_probe(struct platform_device *pdev)return -ENOMEM ;pm_runtime_enable (dev); + ret =pm_runtime_get_sync (dev); +if (ret <0 ) { +pm_runtime_disable (dev); +return ret; + } + pci->dev = dev; pci->ops = &dw_pcie_ops; pp = &pci->pp;
@@ -1227,44 +1231,56 @@ static int qcom_pcie_probe(struct platform_device *pdev) pcie->ops =of_device_get_match_data (dev); pcie->reset =devm_gpiod_get_optional (dev,"perst" ,GPIOD_OUT_LOW ); -if (IS_ERR (pcie->reset)) -return PTR_ERR (pcie->reset); +if (IS_ERR (pcie->reset)) { + ret =PTR_ERR (pcie->reset); + goto err_pm_runtime_put; + } res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"parf" ); pcie->parf =devm_ioremap_resource (dev, res); -if (IS_ERR (pcie->parf)) -return PTR_ERR (pcie->parf); +if (IS_ERR (pcie->parf)) { + ret =PTR_ERR (pcie->parf); + goto err_pm_runtime_put; + } res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"dbi" ); pci->dbi_base =devm_pci_remap_cfg_resource (dev, res); -if (IS_ERR (pci->dbi_base)) -return PTR_ERR (pci->dbi_base); +if (IS_ERR (pci->dbi_base)) { + ret =PTR_ERR (pci->dbi_base); + goto err_pm_runtime_put; + } res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"elbi" ); pcie->elbi =devm_ioremap_resource (dev, res); -if (IS_ERR (pcie->elbi)) -return PTR_ERR (pcie->elbi); +if (IS_ERR (pcie->elbi)) { + ret =PTR_ERR (pcie->elbi); + goto err_pm_runtime_put; + } pcie->phy =devm_phy_optional_get (dev,"pciephy" ); -if (IS_ERR (pcie->phy)) -return PTR_ERR (pcie->phy); +if (IS_ERR (pcie->phy)) { + ret =PTR_ERR (pcie->phy); + goto err_pm_runtime_put; + } ret = pcie->ops->get_resources (pcie);if (ret) -return ret; + goto err_pm_runtime_put; pp->ops = &qcom_pcie_dw_ops;if (IS_ENABLED (CONFIG_PCI_MSI )) { pp->msi_irq =platform_get_irq_byname (pdev,"msi" ); -if (pp->msi_irq <0 ) -return pp->msi_irq; +if (pp->msi_irq <0 ) { + ret = pp->msi_irq; + goto err_pm_runtime_put; + } } ret =phy_init (pcie->phy);if (ret) {pm_runtime_disable (&pdev->dev); -return ret; + goto err_pm_runtime_put; }platform_set_drvdata (pdev, pcie);
@@ -1273,10 +1289,16 @@ static int qcom_pcie_probe(struct platform_device *pdev)if (ret) {dev_err (dev,"cannot initialize host\n" );pm_runtime_disable (&pdev->dev); -return ret; + goto err_pm_runtime_put; }return 0 ; + +err_pm_runtime_put: +pm_runtime_put (dev); +pm_runtime_disable (dev); + +return ret; }static const struct of_device_id qcom_pcie_match[] = {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 104/190 PCI: qcom: Dont deassert reset GPIO during probe
In reply to Greg Kroah-Hartman[ Upstream commit 02b485e31d98265189b91f3e69c43df2ed50610c ]
Acquiring the reset GPIO low means that reset is being deasserted, this is followed almost immediately with qcom_pcie_host_init() asserting it, initializing it and then finally deasserting it again, for the link to come up.
Some PCIe devices requires a minimum time between the initial deassert and subsequent reset cycles. In a platform that boots with the reset GPIO asserted this requirement is being violated by this deassert/assert pulse.
Acquire the reset GPIO high to prevent this situation by matching the state to the subsequent asserted state.
--- drivers/pci/controller/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/controller/dwc/pcie-qcom.c +1 -1
@@ -1230,7 +1230,7 @@ static int qcom_pcie_probe(struct platform_device *pdev) pcie->ops =of_device_get_match_data (dev); - pcie->reset =devm_gpiod_get_optional (dev,"perst" ,GPIOD_OUT_LOW ); + pcie->reset =devm_gpiod_get_optional (dev,"perst" ,GPIOD_OUT_HIGH );if (IS_ERR (pcie->reset)) { ret =PTR_ERR (pcie->reset); goto err_pm_runtime_put;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 105/190 drm: add __user attribute to ptr_to_compat()
In reply to Greg Kroah-Hartman[ Upstream commit e552f0851070fe4975d610a99910be4e9bf5d7bd ]
The ptr_to_compat() call takes a "void __user *", so cast the compat drm calls that use it to avoid the following warnings from sparse:
drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 (different address spaces)drivers/gpu/drm/drm_ioc32.c:188:39: expected void [noderef] <asn:1>*uptrdrivers/gpu/drm/drm_ioc32.c:188:39: got void *[addressable] [assigned] handledrivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 (different address spaces)drivers/gpu/drm/drm_ioc32.c:529:41: expected void [noderef] <asn:1>*uptrdrivers/gpu/drm/drm_ioc32.c:529:41: got void *[addressable] [assigned] handle
--- drivers/gpu/drm/drm_ioc32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_ioc32.c +3 -3
@@ -185,7 +185,7 @@ static int compat_drm_getmap(struct file *file, unsigned int cmd, m32.size = map.size; m32.type = map.type; m32.flags = map.flags; - m32.handle =ptr_to_compat (map.handle); + m32.handle =ptr_to_compat ((void __user *)map.handle); m32.mtrr = map.mtrr;if (copy_to_user (argp, &m32,sizeof (m32)))return -EFAULT ;
@@ -216,7 +216,7 @@ static int compat_drm_addmap(struct file *file, unsigned int cmd, m32.offset = map.offset; m32.mtrr = map.mtrr; - m32.handle =ptr_to_compat (map.handle); + m32.handle =ptr_to_compat ((void __user *)map.handle);if (map.handle !=compat_ptr (m32.handle))pr_err_ratelimited ("compat_drm_addmap truncated handle %p for type %d offset %x\n" , map.handle, m32.type, m32.offset);
@@ -529,7 +529,7 @@ static int compat_drm_getsareactx(struct file *file, unsigned int cmd,if (err)return err; - req32.handle =ptr_to_compat (req.handle); + req32.handle =ptr_to_compat ((void __user *)req.handle);if (copy_to_user (argp, &req32,sizeof (req32)))return -EFAULT ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 106/190 CIFS: Fix error paths in writeback code
In reply to Greg Kroah-Hartman[ Upstream commit 9a66396f1857cc1de06f4f4771797315e1a4ea56 ]
This patch aims to address writeback code problems related to error paths. In particular it respects EINTR and related error codes and stores and returns the first error occurred during writeback.
--- fs/cifs/cifsglob.h | 19 +++++++++++++++++++ fs/cifs/cifssmb.c | 7 ++++--- fs/cifs/file.c | 29 +++++++++++++++++++++++------ fs/cifs/inode.c | 10 ++++++++++ 4 files changed, 56 insertions(+), 9 deletions(-)
fs/cifs/cifsglob.h +19 -0
@@ -1563,6 +1563,25 @@ static inline void free_dfs_info_array(struct dfs_info3_param *param,kfree (param); } +static inline bool is_interrupt_error (int error) +{ +switch (error) { +case -EINTR : +case -ERESTARTSYS : +case -ERESTARTNOHAND : +case -ERESTARTNOINTR : +return true; + } +return false; +} + +static inline bool is_retryable_error (int error) +{ +if (is_interrupt_error (error) || error == -EAGAIN ) +return true; +return false; +} +#define MID_FREE 0#define MID_REQUEST_ALLOCATED 1#define MID_REQUEST_SUBMITTED 2
fs/cifs/cifssmb.c +4 -3
@@ -2042,7 +2042,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata)for (j =0 ; j < nr_pages; j++) {unlock_page (wdata2->pages[j]); -if (rc !=0 && rc != -EAGAIN ) { +if (rc !=0 && !is_retryable_error (rc)) {SetPageError (wdata2->pages[j]);end_page_writeback (wdata2->pages[j]);put_page (wdata2->pages[j]);
@@ -2051,7 +2051,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata)if (rc) {kref_put (&wdata2->refcount, cifs_writedata_release); -if (rc == -EAGAIN ) +if (is_retryable_error (rc))continue ;break ; }
@@ -2060,7 +2060,8 @@ cifs_writev_requeue(struct cifs_writedata *wdata) i += nr_pages; }while (i < wdata->nr_pages); -mapping_set_error (inode->i_mapping, rc); +if (rc !=0 && !is_retryable_error (rc)) +mapping_set_error (inode->i_mapping, rc);kref_put (&wdata->refcount, cifs_writedata_release); }
fs/cifs/file.c +23 -6
@@ -749,7 +749,8 @@ reopen_success:if (can_flush) { rc =filemap_write_and_wait (inode->i_mapping); -mapping_set_error (inode->i_mapping, rc); +if (!is_interrupt_error (rc)) +mapping_set_error (inode->i_mapping, rc);if (tcon->unix_ext) rc = cifs_get_inode_info_unix(&inode, full_path,
@@ -2137,6 +2138,7 @@ static int cifs_writepages(struct address_space *mapping,pgoff_t end, index;struct cifs_writedata *wdata;int rc =0 ; +int saved_rc =0 ;/* * If wsize is smaller than the page cache size, default to writing
@@ -2163,8 +2165,10 @@ retry: rc = server->ops->wait_mtu_credits (server, cifs_sb->wsize, &wsize, &credits); -if (rc) +if (rc !=0 ) { + done = true;break ; + } tofind =min ((wsize /PAGE_SIZE ) -1 , end - index) +1 ;
@@ -2172,6 +2176,7 @@ retry: &found_pages);if (!wdata) { rc = -ENOMEM ; + done = true;add_credits_and_wake_if (server, credits,0 );break ; }
@@ -2200,7 +2205,7 @@ retry:if (rc !=0 ) {add_credits_and_wake_if (server, wdata->credits,0 );for (i =0 ; i < nr_pages; ++i) { -if (rc == -EAGAIN ) +if (is_retryable_error (rc))redirty_page_for_writepage (wbc, wdata->pages[i]);else
@@ -2208,7 +2213,7 @@ retry:end_page_writeback (wdata->pages[i]);put_page (wdata->pages[i]); } -if (rc != -EAGAIN ) +if (!is_retryable_error (rc))mapping_set_error (mapping, rc); }kref_put (&wdata->refcount, cifs_writedata_release);
@@ -2218,6 +2223,15 @@ retry:continue ; } +/* Return immediately if we received a signal during writing */ +if (is_interrupt_error (rc)) { + done = true; +break ; + } + +if (rc !=0 && saved_rc ==0 ) + saved_rc = rc; + wbc->nr_to_write -= nr_pages;if (wbc->nr_to_write <=0 ) done = true;
@@ -2235,6 +2249,9 @@ retry: goto retry; } +if (saved_rc !=0 ) + rc = saved_rc; +if (wbc->range_cyclic || (range_whole && wbc->nr_to_write >0 )) mapping->writeback_index = index;
@@ -2266,8 +2283,8 @@ cifs_writepage_locked(struct page *page, struct writeback_control *wbc)set_page_writeback (page); retry_write: rc =cifs_partialpagewrite (page,0 ,PAGE_SIZE ); -if (rc == -EAGAIN ) { -if (wbc->sync_mode ==WB_SYNC_ALL ) +if (is_retryable_error (rc)) { +if (wbc->sync_mode ==WB_SYNC_ALL && rc == -EAGAIN ) goto retry_write;redirty_page_for_writepage (wbc, page); }else if (rc !=0 ) {
fs/cifs/inode.c +10 -0
@@ -2261,6 +2261,11 @@ cifs_setattr_unix(struct dentry *direntry, struct iattr *attrs)* the flush returns error? */ rc =filemap_write_and_wait (inode->i_mapping); +if (is_interrupt_error (rc)) { + rc = -ERESTARTSYS ; + goto out; + } +mapping_set_error (inode->i_mapping, rc); rc =0 ;
@@ -2404,6 +2409,11 @@ cifs_setattr_nounix(struct dentry *direntry, struct iattr *attrs)* the flush returns error? */ rc =filemap_write_and_wait (inode->i_mapping); +if (is_interrupt_error (rc)) { + rc = -ERESTARTSYS ; + goto cifs_setattr_exit; + } +mapping_set_error (inode->i_mapping, rc); rc =0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 107/190 CIFS: Fix leaking locked VFS cache pages in writeback retry
In reply to Greg Kroah-Hartman[ Upstream commit 165df9a080b6863ae286fa01780c13d87cd81076 ]
If we don't find a writable file handle when retrying writepages we break of the loop and do not unlock and put pages neither from wdata2 nor from the original wdata. Fix this by walking through all the remaining pages and cleanup them properly.
--- fs/cifs/cifssmb.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
fs/cifs/cifssmb.c +13 -4
@@ -2033,12 +2033,13 @@ cifs_writev_requeue(struct cifs_writedata *wdata) wdata2->cfile =find_writable_file (CIFS_I (inode), false);if (!wdata2->cfile) { -cifs_dbg (VFS ,"No writable handles for inode\n" ); +cifs_dbg (VFS ,"No writable handle to retry writepages\n" ); rc = -EBADF ; -break ; + }else { + wdata2->pid = wdata2->cfile->pid; + rc = server->ops->async_writev (wdata2, + cifs_writedata_release); } - wdata2->pid = wdata2->cfile->pid; - rc = server->ops->async_writev (wdata2, cifs_writedata_release);for (j =0 ; j < nr_pages; j++) {unlock_page (wdata2->pages[j]);
@@ -2053,6 +2054,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata)kref_put (&wdata2->refcount, cifs_writedata_release);if (is_retryable_error (rc))continue ; + i += nr_pages;break ; }
@@ -2060,6 +2062,13 @@ cifs_writev_requeue(struct cifs_writedata *wdata) i += nr_pages; }while (i < wdata->nr_pages); +/* cleanup remaining pages from the original wdata */ +for (; i < wdata->nr_pages; i++) { +SetPageError (wdata->pages[i]); +end_page_writeback (wdata->pages[i]); +put_page (wdata->pages[i]); + } +if (rc !=0 && !is_retryable_error (rc))mapping_set_error (inode->i_mapping, rc);kref_put (&wdata->refcount, cifs_writedata_release);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 108/190 drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set
In reply to Greg Kroah-Hartman[ Upstream commit ebfb6977801da521d8d5d752d373a187e2a2b9b3 ]
Add err goto label and use it when VMA can't be established or changes underneath.
v2:
- Dropping Fixes: as it's indeed impossible to race an object to the error address. (Chris)
v3:
- Use IS_ERR_VALUE (Chris)
--- drivers/gpu/drm/i915/i915_gem.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/i915_gem.c +10 -2
@@ -1881,6 +1881,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data, addr =vm_mmap (obj->base.filp,0 , args->size,PROT_READ |PROT_WRITE ,MAP_SHARED , args->offset); +if (IS_ERR_VALUE (addr)) + goto err; +if (args->flags &I915_MMAP_WC ) {struct mm_struct *mm = current->mm;struct vm_area_struct *vma;
@@ -1896,17 +1899,22 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,else addr = -ENOMEM ;up_write (&mm->mmap_sem); +if (IS_ERR_VALUE (addr)) + goto err;/* This may race, but that's ok, it only gets set */ WRITE_ONCE (obj->frontbuffer_ggtt_origin,ORIGIN_CPU ); }i915_gem_object_put (obj); -if (IS_ERR ((void *)addr)) -return addr; args->addr_ptr = (uint64_t ) addr;return 0 ; + +err: +i915_gem_object_put (obj); + +return addr; }static unsigned int tile_row_pages (struct drm_i915_gem_object *obj)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 109/190 drm/i915: Sanity check mmap length against object size
In reply to Greg Kroah-Hartman[ Upstream commit 000c4f90e3f0194eef218ff2c6a8fd8ca1de4313 ]
We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong.
Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access.
Testcase: igt/gem_mmap/bad-size
--- drivers/gpu/drm/i915/i915_gem.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_gem.c +9 -6
@@ -1874,8 +1874,13 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,* pages from. */ if (!obj->base.filp) { -i915_gem_object_put (obj); -return -ENXIO ; + addr = -ENXIO ; + goto err; + } + +if (range_overflows (args->offset, args->size, (u64 )obj->base.size)) { + addr = -EINVAL ; + goto err; } addr = vm_mmap(obj->base.filp, 0, args->size,
@@ -1889,8 +1894,8 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,struct vm_area_struct *vma;if (down_write_killable (&mm->mmap_sem)) { -i915_gem_object_put (obj); -return -EINTR ; + addr = -EINTR ; + goto err; } vma =find_vma (mm, addr);if (vma &&__vma_matches (vma, obj->base.filp, addr, args->size))
@@ -1908,12 +1913,10 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,i915_gem_object_put (obj); args->addr_ptr = (uint64_t ) addr; -return 0 ; err:i915_gem_object_put (obj); -return addr; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 110/190 usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps
In reply to Greg Kroah-Hartman[ Upstream commit 976daf9d1199932df80e7b04546d1a1bd4ed5ece ]
PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and simply ignore any src PDOs which the sink does not understand such as PPS but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message, causing contract negotiation to fail.
This commit fixes such sinks not working by re-trying the contract negotiation with PD-2.0 source-caps messages if we don't have a contract after PD_N_HARD_RESET_COUNT hard-reset attempts.
The problem fixed by this commit was noticed with a Type-C to VGA dongle.
--- drivers/usb/typec/tcpm.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
drivers/usb/typec/tcpm.c +26 -1
@@ -37,6 +37,7 @@S (SRC_ATTACHED ), \S (SRC_STARTUP ), \S (SRC_SEND_CAPABILITIES ), \ +S (SRC_SEND_CAPABILITIES_TIMEOUT ), \S (SRC_NEGOTIATE_CAPABILITIES ), \S (SRC_TRANSITION_SUPPLY ), \ S(SRC_READY), \
@@ -2987,10 +2988,34 @@ static void run_state_machine(struct tcpm_port *port)/* port->hard_reset_count = 0; */ port->caps_count =0 ; port->pd_capable = true; -tcpm_set_state_cond (port,hard_reset_state (port), +tcpm_set_state_cond (port,SRC_SEND_CAPABILITIES_TIMEOUT ,PD_T_SEND_SOURCE_CAP ); }break ; +case SRC_SEND_CAPABILITIES_TIMEOUT : +/* +* Error recovery for a PD_DATA_SOURCE_CAP reply timeout. +* +* PD 2.0 sinks are supposed to accept src-capabilities with a +* 3.0 header and simply ignore any src PDOs which the sink does +* not understand such as PPS but some 2.0 sinks instead ignore +* the entire PD_DATA_SOURCE_CAP message, causing contract +* negotiation to fail. +* +* After PD_N_HARD_RESET_COUNT hard-reset attempts, we try +* sending src-capabilities with a lower PD revision to +* make these broken sinks work. +*/ +if (port->hard_reset_count <PD_N_HARD_RESET_COUNT ) { +tcpm_set_state (port,HARD_RESET_SEND ,0 ); + }else if (port->negotiated_rev >PD_REV20 ) { + port->negotiated_rev--; + port->hard_reset_count =0 ; +tcpm_set_state (port,SRC_SEND_CAPABILITIES ,0 ); + }else { +tcpm_set_state (port,hard_reset_state (port),0 ); + } +break ;case SRC_NEGOTIATE_CAPABILITIES : ret =tcpm_pd_check_request (port);if (ret <0 ) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 111/190 arm64: dts: stratix10: add the sysmgr-syscon property from the gmacs
In reply to Greg Kroah-Hartman[ Upstream commit 8efd6365417a044db03009724ecc1a9521524913 ]
The gmac ethernet driver uses the "altr,sysmgr-syscon" property to configure phy settings for the gmac controller.
Add the "altr,sysmgr-syscon" property to all gmac nodes.
This patch fixes:
[ 0.917530] socfpga-dwmac ff800000.ethernet: No sysmgr-syscon node found [ 0.924209] socfpga-dwmac ff800000.ethernet: Unable to parse OF data
--- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi +3 -0
@@ -140,6 +140,7 @@ tx-fifo-depth = <16384>; rx-fifo-depth = <16384>; snps,multicast-filter-bins = <256>; + altr,sysmgr-syscon = <&sysmgr 0x44 0>; status = "disabled"; };
@@ -156,6 +157,7 @@ tx-fifo-depth = <16384>; rx-fifo-depth = <16384>; snps,multicast-filter-bins = <256>; + altr,sysmgr-syscon = <&sysmgr 0x48 0>; status = "disabled"; };
@@ -172,6 +174,7 @@ tx-fifo-depth = <16384>; rx-fifo-depth = <16384>; snps,multicast-filter-bins = <256>; + altr,sysmgr-syscon = <&sysmgr 0x4c 0>; status = "disabled"; };
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 112/190 IB/mlx5: Reset access mask when looping inside page fault handler
In reply to Greg Kroah-Hartman[ Upstream commit 1abe186ed8a6593069bc122da55fc684383fdc1c ]
If page-fault handler spans multiple MRs then the access mask needs to be reset before each MR handling or otherwise write access will be granted to mapped pages instead of read-only.
--- drivers/infiniband/hw/mlx5/odp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/hw/mlx5/odp.c +2 -1
@@ -497,7 +497,7 @@ void mlx5_ib_free_implicit_mr(struct mlx5_ib_mr *imr)static int pagefault_mr (struct mlx5_ib_dev *dev,struct mlx5_ib_mr *mr,u64 io_virt,size_t bcnt,u32 *bytes_mapped) { -u64 access_mask =ODP_READ_ALLOWED_BIT ; +u64 access_mask;int npages =0 , page_shift, np;u64 start_idx, page_mask;struct ib_umem_odp *odp;
@@ -522,6 +522,7 @@ next_mr: page_shift = mr->umem->page_shift; page_mask = ~(BIT (page_shift) -1 ); start_idx = (io_virt - (mr->mmkey.iova & page_mask)) >> page_shift; + access_mask =ODP_READ_ALLOWED_BIT ;if (mr->umem->writable) access_mask |=ODP_WRITE_ALLOWED_BIT ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 113/190 kvm: mmu: Fix overflow on kvm mmu page limit calculation
In reply to Greg Kroah-Hartman[ Upstream commit bc8a3d8925a8fa09fa550e0da115d95851ce33c6 ]
KVM bases its memory usage limits on the total number of guest pages across all memslots. However, those limits, and the calculations to produce them, use 32 bit unsigned integers. This can result in overflow if a VM has more guest pages that can be represented by a u32. As a result of this overflow, KVM can use a low limit on the number of MMU pages it will allocate. This makes KVM unable to map all of guest memory at once, prompting spurious faults.
Tested: Ran all kvm-unit-tests on an Intel Haswell machine. This patch
introduced no new failures.
--- arch/x86/include/asm/kvm_host.h | 12 ++++++------ arch/x86/kvm/mmu.c | 13 ++++++------- arch/x86/kvm/mmu.h | 2 +- arch/x86/kvm/x86.c | 4 ++-- 4 files changed, 15 insertions(+), 16 deletions(-)
arch/x86/include/asm/kvm_host.h +6 -6
@@ -117,7 +117,7 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, int level) }#define KVM_PERMILLE_MMU_PAGES 20 -#define KVM_MIN_ALLOC_MMU_PAGES 64 +#define KVM_MIN_ALLOC_MMU_PAGES 64UL#define KVM_MMU_HASH_SHIFT 12#define KVM_NUM_MMU_PAGES (1 << KVM_MMU_HASH_SHIFT)#define KVM_MIN_FREE_MMU_PAGES 5
@@ -796,9 +796,9 @@ enum kvm_irqchip_mode { };struct kvm_arch { -unsigned int n_used_mmu_pages; -unsigned int n_requested_mmu_pages; -unsigned int n_max_mmu_pages; +unsigned long n_used_mmu_pages; +unsigned long n_requested_mmu_pages; +unsigned long n_max_mmu_pages;unsigned int indirect_shadow_pages;unsigned long mmu_valid_gen;struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES ];
@@ -1201,8 +1201,8 @@ void kvm_mmu_clear_dirty_pt_masked(struct kvm *kvm, gfn_t gfn_offset, unsigned long mask);void kvm_mmu_zap_all (struct kvm *kvm);void kvm_mmu_invalidate_mmio_sptes (struct kvm *kvm,u64 gen); -unsigned int kvm_mmu_calculate_mmu_pages (struct kvm *kvm); -void kvm_mmu_change_mmu_pages (struct kvm *kvm,unsigned int kvm_nr_mmu_pages); +unsigned long kvm_mmu_calculate_mmu_pages (struct kvm *kvm); +void kvm_mmu_change_mmu_pages (struct kvm *kvm,unsigned long kvm_nr_mmu_pages);int load_pdptrs (struct kvm_vcpu *vcpu,struct kvm_mmu *mmu,unsigned long cr3);bool pdptrs_changed (struct kvm_vcpu *vcpu);
arch/x86/kvm/mmu.c +6 -7
@@ -1954,7 +1954,7 @@ static int is_empty_shadow_page(u64 *spt)* aggregate version in order to make the slab shrinker * faster */ -static inline void kvm_mod_used_mmu_pages (struct kvm *kvm,int nr) +static inline void kvm_mod_used_mmu_pages (struct kvm *kvm,unsigned long nr) { kvm->arch.n_used_mmu_pages += nr;percpu_counter_add (&kvm_total_used_mmu_pages, nr);
@@ -2704,7 +2704,7 @@ static bool prepare_zap_oldest_mmu_page(struct kvm *kvm,* Changing the number of mmu pages allocated to the vm * Note: if goal_nr_mmu_pages is too small, you will get dead lock */ -void kvm_mmu_change_mmu_pages (struct kvm *kvm,unsigned int goal_nr_mmu_pages) +void kvm_mmu_change_mmu_pages (struct kvm *kvm,unsigned long goal_nr_mmu_pages) {LIST_HEAD (invalid_list);
@@ -5926,10 +5926,10 @@ out:/* * Caculate mmu pages needed for kvm. */ -unsigned int kvm_mmu_calculate_mmu_pages (struct kvm *kvm) +unsigned long kvm_mmu_calculate_mmu_pages (struct kvm *kvm) { -unsigned int nr_mmu_pages; -unsigned int nr_pages =0 ; +unsigned long nr_mmu_pages; +unsigned long nr_pages =0 ;struct kvm_memslots *slots;struct kvm_memory_slot *memslot;int i;
@@ -5942,8 +5942,7 @@ unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm) } nr_mmu_pages = nr_pages *KVM_PERMILLE_MMU_PAGES /1000 ; - nr_mmu_pages =max (nr_mmu_pages, - (unsigned int )KVM_MIN_ALLOC_MMU_PAGES ); + nr_mmu_pages =max (nr_mmu_pages,KVM_MIN_ALLOC_MMU_PAGES );return nr_mmu_pages; }
arch/x86/kvm/mmu.h +1 -1
@@ -69,7 +69,7 @@ bool kvm_can_do_async_pf(struct kvm_vcpu *vcpu);int kvm_handle_page_fault (struct kvm_vcpu *vcpu,u64 error_code,u64 fault_address,char *insn,int insn_len); -static inline unsigned int kvm_mmu_available_pages (struct kvm *kvm) +static inline unsigned long kvm_mmu_available_pages (struct kvm *kvm) {if (kvm->arch.n_max_mmu_pages > kvm->arch.n_used_mmu_pages) return kvm->arch.n_max_mmu_pages -
arch/x86/kvm/x86.c +2 -2
@@ -4116,7 +4116,7 @@ static int kvm_vm_ioctl_set_identity_map_addr(struct kvm *kvm, }static int kvm_vm_ioctl_set_nr_mmu_pages (struct kvm *kvm, -u32 kvm_nr_mmu_pages) +unsigned long kvm_nr_mmu_pages) {if (kvm_nr_mmu_pages <KVM_MIN_ALLOC_MMU_PAGES )return -EINVAL ;
@@ -4130,7 +4130,7 @@ static int kvm_vm_ioctl_set_nr_mmu_pages(struct kvm *kvm,return 0 ; } -static int kvm_vm_ioctl_get_nr_mmu_pages (struct kvm *kvm) +static unsigned long kvm_vm_ioctl_get_nr_mmu_pages (struct kvm *kvm) {return kvm->arch.n_max_mmu_pages; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 114/190 x86/kvm: move kvm_load/put_guest_xcr0 into atomic context
In reply to Greg Kroah-Hartman[ Upstream commit 1811d979c71621aafc7b879477202d286f7e863b ]
guest xcr0 could leak into host when MCE happens in guest mode. Because do_machine_check() could schedule out at a few places.
For example:
kvm_load_guest_xcr0
...kvm_x86_ops->run(vcpu) {
vmx_vcpu_run
vmx_complete_atomic_exit
kvm_machine_check
do_machine_check
do_memory_failure
memory_failure
lock_page
In this case, host_xcr0 is 0x2ff, guest vcpu xcr0 is 0xff. After schedule out, host cpu has guest xcr0 loaded (0xff).
In __switch_to {
switch_fpu_finish
copy_kernel_to_fpregs
XRSTORS
If any bit i in XSTATE_BV[i] == 1 and xcr0[i] == 0, XRSTORS will generate #GP (In this case, bit 9). Then ex_handler_fprestore kicks in and tries to reinitialize fpu by restoring init fpu state. Same story as last #GP, except we get DOUBLE FAULT this time.
--- arch/x86/kvm/svm.c | 2 ++ arch/x86/kvm/vmx.c | 4 ++++ arch/x86/kvm/x86.c | 10 ++++------ arch/x86/kvm/x86.h | 2 ++ 4 files changed, 12 insertions(+), 6 deletions(-)
arch/x86/kvm/svm.c +2 -0
@@ -5622,6 +5622,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) svm->vmcb->save.cr2 = vcpu->arch.cr2;clgi (); +kvm_load_guest_xcr0 (vcpu);/* * If this vCPU has touched SPEC_CTRL, restore the guest's value if
@@ -5769,6 +5770,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)if (unlikely (svm->vmcb->control.exit_code ==SVM_EXIT_NMI ))kvm_before_interrupt (&svm->vcpu); +kvm_put_guest_xcr0 (vcpu);stgi ();/* Any pending NMI will happen here */
arch/x86/kvm/vmx.c +4 -0
@@ -10756,6 +10756,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)if (vcpu->guest_debug &KVM_GUESTDBG_SINGLESTEP )vmx_set_interrupt_shadow (vcpu,0 ); +kvm_load_guest_xcr0 (vcpu); +if (static_cpu_has (X86_FEATURE_PKU ) &&kvm_read_cr4_bits (vcpu,X86_CR4_PKE ) && vcpu->arch.pkru != vmx->host_pkru)
@@ -10971,6 +10973,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)__write_pkru (vmx->host_pkru); } +kvm_put_guest_xcr0 (vcpu); + vmx->nested.nested_run_pending =0 ; vmx->idt_vectoring_info =0 ;
arch/x86/kvm/x86.c +4 -6
@@ -713,7 +713,7 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long msw) }EXPORT_SYMBOL_GPL (kvm_lmsw); -static void kvm_load_guest_xcr0 (struct kvm_vcpu *vcpu) +void kvm_load_guest_xcr0 (struct kvm_vcpu *vcpu) {if (kvm_read_cr4_bits (vcpu,X86_CR4_OSXSAVE ) && !vcpu->guest_xcr0_loaded) {
@@ -723,8 +723,9 @@ static void kvm_load_guest_xcr0(struct kvm_vcpu *vcpu) vcpu->guest_xcr0_loaded =1 ; } } +EXPORT_SYMBOL_GPL (kvm_load_guest_xcr0); -static void kvm_put_guest_xcr0 (struct kvm_vcpu *vcpu) +void kvm_put_guest_xcr0 (struct kvm_vcpu *vcpu) {if (vcpu->guest_xcr0_loaded) {if (vcpu->arch.xcr0 != host_xcr0)
@@ -732,6 +733,7 @@ static void kvm_put_guest_xcr0(struct kvm_vcpu *vcpu) vcpu->guest_xcr0_loaded =0 ; } } +EXPORT_SYMBOL_GPL (kvm_put_guest_xcr0);static int __kvm_set_xcr (struct kvm_vcpu *vcpu,u32 index,u64 xcr) {
@@ -7649,8 +7651,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) goto cancel_injection; } -kvm_load_guest_xcr0 (vcpu); -if (req_immediate_exit) {kvm_make_request (KVM_REQ_EVENT , vcpu); kvm_x86_ops->request_immediate_exit (vcpu);
@@ -7703,8 +7703,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) vcpu->mode =OUTSIDE_GUEST_MODE ;smp_wmb (); -kvm_put_guest_xcr0 (vcpu); -kvm_before_interrupt (vcpu); kvm_x86_ops->handle_external_intr (vcpu);kvm_after_interrupt (vcpu);
arch/x86/kvm/x86.h +2 -0
@@ -345,4 +345,6 @@ static inline void kvm_after_interrupt(struct kvm_vcpu *vcpu) __this_cpu_write(current_vcpu, NULL); } +void kvm_load_guest_xcr0 (struct kvm_vcpu *vcpu); +void kvm_put_guest_xcr0 (struct kvm_vcpu *vcpu);#endif
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 115/190 KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels
In reply to Greg Kroah-Hartman[ Upstream commit b68f3cc7d978943fcf85148165b00594c38db776 ]
Invoking the 64-bit variation on a 32-bit kenrel will crash the guest, trigger a WARN, and/or lead to a buffer overrun in the host, e.g. rsm_load_state_64() writes r8-r15 unconditionally, but enum kvm_reg and thus x86_emulate_ctxt._regs only define r8-r15 for CONFIG_X86_64.
KVM allows userspace to report long mode support via CPUID, even though the guest is all but guaranteed to crash if it actually tries to enable long mode. But, a pure 32-bit guest that is ignorant of long mode will happily plod along.
SMM complicates things as 64-bit CPUs use a different SMRAM save state area. KVM handles this correctly for 64-bit kernels, e.g. uses the legacy save state map if userspace has hid long mode from the guest, but doesn't fare well when userspace reports long mode support on a 32-bit host kernel (32-bit KVM doesn't support 64-bit guests).
Since the alternative is to crash the guest, e.g. by not loading state or explicitly requesting shutdown, unconditionally use the legacy SMRAM save state map for 32-bit KVM. If a guest has managed to get far enough to handle SMIs when running under a weird/buggy userspace hypervisor, then don't deliberately crash the guest since there are no downsides (from KVM's perspective) to allow it to continue running.
--- arch/x86/kvm/emulate.c | 10 ++++++++++ arch/x86/kvm/x86.c | 10 ++++++---- 2 files changed, 16 insertions(+), 4 deletions(-)
arch/x86/kvm/emulate.c +10 -0
@@ -2331,12 +2331,16 @@ static int em_lseg(struct x86_emulate_ctxt *ctxt)static int emulator_has_longmode (struct x86_emulate_ctxt *ctxt) { +#ifdef CONFIG_X86_64 u32 eax, ebx, ecx, edx; eax =0x80000001 ; ecx =0 ; ctxt->ops->get_cpuid (ctxt, &eax, &ebx, &ecx, &edx, false);return edx &bit (X86_FEATURE_LM ); +#else +return false; +#endif }#define GET_SMSTATE (type, smbase, offset) \
@@ -2381,6 +2385,7 @@ static int rsm_load_seg_32(struct x86_emulate_ctxt *ctxt, u64 smbase, int n)return X86EMUL_CONTINUE ; } +#ifdef CONFIG_X86_64 static int rsm_load_seg_64 (struct x86_emulate_ctxt *ctxt,u64 smbase,int n) {struct desc_struct desc;
@@ -2399,6 +2404,7 @@ static int rsm_load_seg_64(struct x86_emulate_ctxt *ctxt, u64 smbase, int n) ctxt->ops->set_segment (ctxt, selector, &desc, base3, n); return X86EMUL_CONTINUE; } +#endif static int rsm_enter_protected_mode (struct x86_emulate_ctxt *ctxt,u64 cr0,u64 cr3,u64 cr4)
@@ -2499,6 +2505,7 @@ static int rsm_load_state_32(struct x86_emulate_ctxt *ctxt, u64 smbase)return rsm_enter_protected_mode (ctxt, cr0, cr3, cr4); } +#ifdef CONFIG_X86_64 static int rsm_load_state_64 (struct x86_emulate_ctxt *ctxt,u64 smbase) {struct desc_struct desc;
@@ -2560,6 +2567,7 @@ static int rsm_load_state_64(struct x86_emulate_ctxt *ctxt, u64 smbase) return X86EMUL_CONTINUE; } +#endif static int em_rsm (struct x86_emulate_ctxt *ctxt) {
@@ -2616,9 +2624,11 @@ static int em_rsm(struct x86_emulate_ctxt *ctxt)if (ctxt->ops->pre_leave_smm (ctxt, smbase))return X86EMUL_UNHANDLEABLE ; +#ifdef CONFIG_X86_64 if (emulator_has_longmode (ctxt)) ret =rsm_load_state_64 (ctxt, smbase +0x8000 ); else +#endif ret =rsm_load_state_32 (ctxt, smbase +0x8000 );if (ret !=X86EMUL_CONTINUE ) {
arch/x86/kvm/x86.c +6 -4
@@ -7227,9 +7227,9 @@ static void enter_smm_save_state_32(struct kvm_vcpu *vcpu, char *buf)put_smstate (u32, buf,0x7ef8 , vcpu->arch.smbase); } +#ifdef CONFIG_X86_64 static void enter_smm_save_state_64 (struct kvm_vcpu *vcpu,char *buf) { -#ifdef CONFIG_X86_64 struct desc_ptr dt;struct kvm_segment seg;unsigned long val;
@@ -7279,10 +7279,8 @@ static void enter_smm_save_state_64(struct kvm_vcpu *vcpu, char *buf)for (i =0 ; i <6 ; i++) enter_smm_save_seg_64(vcpu, buf, i); -#else -WARN_ON_ONCE (1 ); -#endif } +#endif static void enter_smm (struct kvm_vcpu *vcpu) {
@@ -7293,9 +7291,11 @@ static void enter_smm(struct kvm_vcpu *vcpu)trace_kvm_enter_smm (vcpu->vcpu_id, vcpu->arch.smbase, true);memset (buf,0 ,512 ); +#ifdef CONFIG_X86_64 if (guest_cpuid_has (vcpu,X86_FEATURE_LM ))enter_smm_save_state_64 (vcpu, buf); else +#endif enter_smm_save_state_32 (vcpu, buf);/*
@@ -7353,8 +7353,10 @@ static void enter_smm(struct kvm_vcpu *vcpu)kvm_set_segment (vcpu, &ds,VCPU_SREG_GS );kvm_set_segment (vcpu, &ds,VCPU_SREG_SS ); +#ifdef CONFIG_X86_64 if (guest_cpuid_has (vcpu,X86_FEATURE_LM )) kvm_x86_ops->set_efer (vcpu,0 ); +#endif kvm_update_cpuid (vcpu);kvm_mmu_reset_context (vcpu);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 116/190 cifs: Fix lease buffer length error
In reply to Greg Kroah-Hartman[ Upstream commit b57a55e2200ede754e4dc9cce4ba9402544b9365 ]
There is a KASAN slab-out-of-bounds:
BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0
Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539
CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
Call Trace:
dump_stack+0xdd/0x12a
print_address_description+0xa7/0x540
kasan_report+0x1ff/0x550
check_memory_region+0x2f1/0x310
memcpy+0x2f/0x80
_copy_from_iter_full+0x783/0xaa0
tcp_sendmsg_locked+0x1840/0x4140
tcp_sendmsg+0x37/0x60
inet_sendmsg+0x18c/0x490
sock_sendmsg+0xae/0x130
smb_send_kvec+0x29c/0x520
__smb_send_rqst+0x3ef/0xc60
smb_send_rqst+0x25a/0x2e0
compound_send_recv+0x9e8/0x2af0
cifs_send_recv+0x24/0x30
SMB2_open+0x35e/0x1620
open_shroot+0x27b/0x490
smb2_open_op_close+0x4e1/0x590
smb2_query_path_info+0x2ac/0x650
cifs_get_inode_info+0x1058/0x28f0
cifs_root_iget+0x3bb/0xf80
cifs_smb3_do_mount+0xe00/0x14c0
cifs_do_mount+0x15/0x20
mount_fs+0x5e/0x290
vfs_kern_mount+0x88/0x460
do_mount+0x398/0x31e0
ksys_mount+0xc6/0x150
__x64_sys_mount+0xea/0x190
do_syscall_64+0x122/0x590
entry_SYSCALL_64_after_hwframe+0x44/0xa9It can be reproduced by the following step:
1. samba configured with: server max protocol = SMB2_10
2. mount -o vers=default
When parse the mount version parameter, the 'ops' and 'vals' was setted to smb30, if negotiate result is smb21, just update the 'ops' to smb21, but the 'vals' is still smb30. When add lease context, the iov_base is allocated with smb21 ops, but the iov_len is initiallited with the smb30. Because the iov_len is longer than iov_base, when send the message, copy array out of bounds.
we need to keep the 'ops' and 'vals' consistent.
--- fs/cifs/smb2pdu.c | 1 + 1 file changed, 1 insertion(+)
fs/cifs/smb2pdu.c +1 -0
@@ -712,6 +712,7 @@ SMB2_negotiate(const unsigned int xid, struct cifs_ses *ses) }else if (rsp->DialectRevision ==cpu_to_le16 (SMB21_PROT_ID )) {/* ops set to 3.0 by default for default so update */ ses->server->ops = &smb21_operations; + ses->server->vals = &smb21_values; } }else if (le16_to_cpu (rsp->DialectRevision) != ses->server->vals->protocol_id) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 117/190 media: i2c: tda1997x: select V4L2_FWNODE
In reply to Greg Kroah-Hartman[ Upstream commit 5f2efda71c09b12012053f457fac7692f268b72c ]
Building tda1997x fails now unless V4L2_FWNODE is selected:
drivers/media/i2c/tda1997x.o: in function tda1997x_parse_dt' undefined reference to v4l2_fwnode_endpoint_parse'
While at it, also sort the selections alphabetically
--- drivers/media/i2c/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/i2c/Kconfig +2 -1
@@ -60,8 +60,9 @@ config VIDEO_TDA1997X tristate "NXP TDA1997x HDMI receiver" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API depends on SND_SOC - select SND_PCM select HDMI + select SND_PCM + select V4L2_FWNODE ---help--- V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 118/190 ext4: protect journal inodes blocks using block_validity
In reply to Greg Kroah-Hartman[ Upstream commit 345c0dbf3a30872d9b204db96b5857cd00808cae ]
Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879
--- fs/ext4/block_validity.c | 48 ++++++++++++++++++++++++++++++++++++++++ fs/ext4/inode.c | 4 ++++ 2 files changed, 52 insertions(+)
fs/ext4/block_validity.c +48 -0
@@ -137,6 +137,48 @@ static void debug_print_tree(struct ext4_sb_info *sbi)printk (KERN_CONT "\n" ); } +static int ext4_protect_reserved_inode (struct super_block *sb,u32 ino) +{ +struct inode *inode; +struct ext4_sb_info *sbi =EXT4_SB (sb); +struct ext4_map_blocks map; +u32 i =0 , err =0 , num, n; + +if ((ino <EXT4_ROOT_INO ) || + (ino >le32_to_cpu (sbi->s_es->s_inodes_count))) +return -EINVAL ; + inode =ext4_iget (sb, ino,EXT4_IGET_SPECIAL ); +if (IS_ERR (inode)) +return PTR_ERR (inode); + num = (inode->i_size + sb->s_blocksize -1 ) >> sb->s_blocksize_bits; +while (i < num) { + map.m_lblk = i; + map.m_len = num - i; + n =ext4_map_blocks (NULL , inode, &map,0 ); +if (n <0 ) { + err = n; +break ; + } +if (n ==0 ) { + i++; + }else { +if (!ext4_data_block_valid (sbi, map.m_pblk, n)) { +ext4_error (sb,"blocks %llu-%llu from inode %u " +"overlap system zone" , map.m_pblk, + map.m_pblk + map.m_len -1 , ino); + err = -EFSCORRUPTED ; +break ; + } + err =add_system_zone (sbi, map.m_pblk, n); +if (err <0 ) +break ; + i += n; + } + } +iput (inode); +return err; +} +int ext4_setup_system_zone (struct super_block *sb) {ext4_group_t ngroups =ext4_get_groups_count (sb);
@@ -171,6 +213,12 @@ int ext4_setup_system_zone(struct super_block *sb)if (ret)return ret; } +if (ext4_has_feature_journal (sb) && sbi->s_es->s_journal_inum) { + ret =ext4_protect_reserved_inode (sb, +le32_to_cpu (sbi->s_es->s_journal_inum)); +if (ret) +return ret; + }if (test_opt (sb,DEBUG ))debug_print_tree (sbi);
fs/ext4/inode.c +4 -0
@@ -399,6 +399,10 @@ static int __check_block_validity(struct inode *inode, const char *func, unsigned int line, struct ext4_map_blocks *map) { + if (ext4_has_feature_journal(inode->i_sb) && + (inode->i_ino == + le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum))) + return 0; if (!ext4_data_block_valid(EXT4_SB(inode->i_sb), map->m_pblk, map->m_len)) { ext4_error_inode(inode, func, line, map->m_pblk,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 119/190 ARM: dts: qcom: ipq4019: fix PCI range
In reply to Greg Kroah-Hartman[ Upstream commit da89f500cb55fb3f19c4b399b46d8add0abbd4d6 ]
The PCI range is invalid and PCI attached devices doen't work.
--- arch/arm/boot/dts/qcom-ipq4019.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/qcom-ipq4019.dtsi +1 -1
@@ -387,7 +387,7 @@ #size-cells = <2>; ranges = <0x81000000 0 0x40200000 0x40200000 0 0x00100000 - 0x82000000 0 0x48000000 0x48000000 0 0x10000000>; + 0x82000000 0 0x40300000 0x40300000 0 0x400000>; interrupts = <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>; interrupt-names = "msi";
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 120/190 ARM: dts: qcom: ipq4019: Fix MSI IRQ type
In reply to Greg Kroah-Hartman[ Upstream commit 97131f85c08e024df49480ed499aae8fb754067f ]
The databook clearly states that the MSI IRQ (msi_ctrl_int) is a level triggered interrupt.
The msi_ctrl_int will be high for as long as any MSI status bit is set, thus the IRQ type should be set to IRQ_TYPE_LEVEL_HIGH, causing the IRQ handler to keep getting called, as long as any MSI status bit is set.
A git grep shows that ipq4019 is the only SoC using snps,dw-pcie that has configured this IRQ incorrectly.
Not having the correct IRQ type defined will cause us to lose interrupts, which in turn causes timeouts in the PCIe endpoint drivers.
--- arch/arm/boot/dts/qcom-ipq4019.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/qcom-ipq4019.dtsi +1 -1
@@ -389,7 +389,7 @@ ranges = <0x81000000 0 0x40200000 0x40200000 0 0x00100000 0x82000000 0 0x40300000 0x40300000 0 0x400000>; - interrupts = <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>; + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 121/190 ARM: dts: qcom: ipq4019: enlarge PCIe BAR range
In reply to Greg Kroah-Hartman[ Upstream commit f3e35357cd460a8aeb48b8113dc4b761a7d5c828 ]
David Bauer reported that the VDSL modem (attached via PCIe) on his AVM Fritz!Box 7530 was complaining about not having enough space in the BAR. A closer inspection of the old qcom-ipq40xx.dtsi pulled from the GL-iNet repository listed:
| qcom,pcie@80000 {
| compatible = "qcom,msm_pcie";
| reg = <0x80000 0x2000>,
| <0x99000 0x800>,
| <0x40000000 0xf1d>,
| <0x40000f20 0xa8>,
| <0x40100000 0x1000>,
| <0x40200000 0x100000>,
| <0x40300000 0xd00000>;
| reg-names = "parf", "phy", "dm_core", "elbi",
| "conf", "io", "bars";Matching the reg-names with the listed reg leads to <0xd00000> as the size for the "bars".
--- arch/arm/boot/dts/qcom-ipq4019.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/qcom-ipq4019.dtsi +2 -2
@@ -386,8 +386,8 @@ #address-cells = <3>; #size-cells = <2>; - ranges = <0x81000000 0 0x40200000 0x40200000 0 0x00100000 - 0x82000000 0 0x40300000 0x40300000 0 0x400000>; + ranges = <0x81000000 0 0x40200000 0x40200000 0 0x00100000>, + <0x82000000 0 0x40300000 0x40300000 0 0x00d00000>; interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "msi";
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 122/190 dt-bindings: mmc: Add supports-cqe property
In reply to Greg Kroah-Hartman[ Upstream commit c7fddbd5db5cffd10ed4d18efa20e36803d1899f ]
Add supports-cqe optional property for MMC hosts.
This property is used to identify the specific host controller supporting command queue.
--- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/mmc/mmc.txt +2 -0
@@ -62,6 +62,8 @@ Optional properties: be referred to mmc-pwrseq-simple.txt. But now it's reused as a tunable delay waiting for I/O signalling and card power supply to be stable, regardless of whether pwrseq-simple is used. Default to 10ms if no available. +- supports-cqe : The presence of this property indicates that the corresponding + MMC host controller supports HW command queue feature. *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted"
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 123/190 dt-bindings: mmc: Add disable-cqe-dcmd property.
In reply to Greg Kroah-Hartman[ Upstream commit 28f22fb755ecf9f933f045bc0afdb8140641b01c ]
Add disable-cqe-dcmd as optional property for MMC hosts. This property allows to disable or not enable the direct command features of the command queue engine.
--- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/mmc/mmc.txt +2 -0
@@ -64,6 +64,8 @@ Optional properties: whether pwrseq-simple is used. Default to 10ms if no available. - supports-cqe : The presence of this property indicates that the corresponding MMC host controller supports HW command queue feature. +- disable-cqe-dcmd: This property indicates that the MMC controller's command + queue engine (CQE) does not support direct commands (DCMDs). *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted"
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 124/190 PCI: Add macro for Switchtec quirk declarations
In reply to Greg Kroah-Hartman[ Upstream commit 01d5d7fa8376c6b5acda86e16fcad22de6bba486 ]
Add SWITCHTEC_QUIRK() to reduce redundancy in declaring devices that use quirk_switchtec_ntb_dma_alias().
By itself, this is no functional change, but a subsequent patch updates SWITCHTEC_QUIRK() to fix ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB").
--- drivers/pci/quirks.c | 90 +++++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 56 deletions(-)
drivers/pci/quirks.c +34 -56
@@ -5082,59 +5082,37 @@ static void quirk_switchtec_ntb_dma_alias(struct pci_dev *pdev)pci_iounmap (pdev, mmio);pci_disable_device (pdev); } -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8531 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8532 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8533 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8534 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8535 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8536 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8543 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8544 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8545 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8546 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8551 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8552 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8553 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8554 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8555 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8556 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8561 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8562 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8563 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8564 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8565 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8566 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8571 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8572 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8573 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8574 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8575 , - quirk_switchtec_ntb_dma_alias); -DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_MICROSEMI ,0x8576 , - quirk_switchtec_ntb_dma_alias); +#define SWITCHTEC_QUIRK (vid) \ + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_MICROSEMI, vid, \ + quirk_switchtec_ntb_dma_alias) + +SWITCHTEC_QUIRK (0x8531 );/* PFX 24xG3 */ +SWITCHTEC_QUIRK (0x8532 );/* PFX 32xG3 */ +SWITCHTEC_QUIRK (0x8533 );/* PFX 48xG3 */ +SWITCHTEC_QUIRK (0x8534 );/* PFX 64xG3 */ +SWITCHTEC_QUIRK (0x8535 );/* PFX 80xG3 */ +SWITCHTEC_QUIRK (0x8536 );/* PFX 96xG3 */ +SWITCHTEC_QUIRK (0x8541 );/* PSX 24xG3 */ +SWITCHTEC_QUIRK (0x8542 );/* PSX 32xG3 */ +SWITCHTEC_QUIRK (0x8543 );/* PSX 48xG3 */ +SWITCHTEC_QUIRK (0x8544 );/* PSX 64xG3 */ +SWITCHTEC_QUIRK (0x8545 );/* PSX 80xG3 */ +SWITCHTEC_QUIRK (0x8546 );/* PSX 96xG3 */ +SWITCHTEC_QUIRK (0x8551 );/* PAX 24XG3 */ +SWITCHTEC_QUIRK (0x8552 );/* PAX 32XG3 */ +SWITCHTEC_QUIRK (0x8553 );/* PAX 48XG3 */ +SWITCHTEC_QUIRK (0x8554 );/* PAX 64XG3 */ +SWITCHTEC_QUIRK (0x8555 );/* PAX 80XG3 */ +SWITCHTEC_QUIRK (0x8556 );/* PAX 96XG3 */ +SWITCHTEC_QUIRK (0x8561 );/* PFXL 24XG3 */ +SWITCHTEC_QUIRK (0x8562 );/* PFXL 32XG3 */ +SWITCHTEC_QUIRK (0x8563 );/* PFXL 48XG3 */ +SWITCHTEC_QUIRK (0x8564 );/* PFXL 64XG3 */ +SWITCHTEC_QUIRK (0x8565 );/* PFXL 80XG3 */ +SWITCHTEC_QUIRK (0x8566 );/* PFXL 96XG3 */ +SWITCHTEC_QUIRK (0x8571 );/* PFXI 24XG3 */ +SWITCHTEC_QUIRK (0x8572 );/* PFXI 32XG3 */ +SWITCHTEC_QUIRK (0x8573 );/* PFXI 48XG3 */ +SWITCHTEC_QUIRK (0x8574 );/* PFXI 64XG3 */ +SWITCHTEC_QUIRK (0x8575 );/* PFXI 80XG3 */ +SWITCHTEC_QUIRK (0x8576 );/* PFXI 96XG3 */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 125/190 PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
In reply to Greg Kroah-Hartman[ Upstream commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 ]
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue:
1. Boot up the laptop normally in Hybrid Graphics mode
2. Make sure nouveau is loaded and that the GPU is awake
3. Allow the Nvidia GPU to runtime suspend itself after being idle
4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help)
5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue
This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything:
nouveau 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002
This causes a timeout trying to bring up the GR ctx:
nouveau 0000:01:00.0: timeout
WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 unknown]
The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel:
irq 16: nobody cared (try booting with the "irqpoll" option)
...
handlers:
[<000000007faa9e99>] i801_isr [i2c_i801]
Disabling IRQ #16
...
serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
i801_smbus 0000:00:1f.4: Timeout waiting for interrupt!
i801_smbus 0000:00:1f.4: Transaction timeout
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus 0000:00:1f.4: Timeout waiting for interrupt!
i801_smbus 0000:00:1f.4: Transaction timeout
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
This causes the touchpad and sometimes other things to get disabled.
Since this happens without nouveau, we can't fix this problem from nouveau itself.
Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state.
--- drivers/pci/quirks.c | 58 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
drivers/pci/quirks.c +58 -0
@@ -5116,3 +5116,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */SWITCHTEC_QUIRK (0x8574 );/* PFXI 64XG3 */ SWITCHTEC_QUIRK (0x8575 );/* PFXI 80XG3 */ SWITCHTEC_QUIRK (0x8576 );/* PFXI 96XG3 */ + +/* +* On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does +* not always reset the secondary Nvidia GPU between reboots if the system +* is configured to use Hybrid Graphics mode. This results in the GPU +* being left in whatever state it was in during the *previous* boot, which +* causes spurious interrupts from the GPU, which in turn causes us to +* disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly, +* this also completely breaks nouveau. +* +* Luckily, it seems a simple reset of the Nvidia GPU brings it back to a +* clean state and fixes all these issues. +* +* When the machine is configured in Dedicated display mode, the issue +* doesn't occur. Fortunately the GPU advertises NoReset+ when in this +* mode, so we can detect that and avoid resetting it. +*/ +static void quirk_reset_lenovo_thinkpad_p50_nvgpu (struct pci_dev *pdev) +{ +void __iomem *map; +int ret; + +if (pdev->subsystem_vendor !=PCI_VENDOR_ID_LENOVO || + pdev->subsystem_device !=0x222e || + !pdev->reset_fn) +return ; + +if (pci_enable_device_mem (pdev)) +return ; + +/* +* Based on nvkm_device_ctor() in +* drivers/gpu/drm/nouveau/nvkm/engine/device/base.c +*/ + map =pci_iomap (pdev,0 ,0x23000 ); +if (!map) { +pci_err (pdev,"Can't map MMIO space\n" ); + goto out_disable; + } + +/* +* Make sure the GPU looks like it's been POSTed before resetting +* it. +*/ +if (ioread32 (map +0x2240c ) &0x2 ) { +pci_info (pdev,FW_BUG "GPU left initialized by EFI, resetting\n" ); + ret =pci_reset_function (pdev); +if (ret <0 ) +pci_err (pdev,"Failed to reset GPU: %d\n" , ret); + } + +iounmap (map); +out_disable: +pci_disable_device (pdev); +} +DECLARE_PCI_FIXUP_CLASS_FINAL (PCI_VENDOR_ID_NVIDIA ,0x13b1 , +PCI_CLASS_DISPLAY_VGA ,8 , + quirk_reset_lenovo_thinkpad_p50_nvgpu);
Signature · 8 lines
2.20.1 _______________________________________________ Nouveau mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/nouveau
Greg Kroah-Hartman
maintainerPATCH 126/190 dm mpath: fix missing call of path selector type->end_io
In reply to Greg Kroah-Hartman[ Upstream commit 5de719e3d01b4abe0de0d7b857148a880ff2a90b ]
After commit 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback"), map_request() will requeue the tio when issued clone request return BLK_STS_RESOURCE or BLK_STS_DEV_RESOURCE.
Thus, if device driver status is error, a tio may be requeued multiple times until the return value is not DM_MAPIO_REQUEUE. That means type->start_io may be called multiple times, while type->end_io is only called when IO complete.
In fact, even without commit 396eaf21ee17, setup_clone() failure can also cause tio requeue and associated missed call to type->end_io.
The service-time path selector selects path based on in_flight_size, which is increased by st_start_io() and decreased by st_end_io(). Missed calls to st_end_io() can lead to in_flight_size count error and will cause the selector to make the wrong choice. In addition, queue-length path selector will also be affected.
To fix the problem, call type->end_io in ->release_clone_rq before tio requeue. map_info is passed to ->release_clone_rq() for map_request() error path that result in requeue.
--- drivers/md/dm-mpath.c | 17 ++++++++++++++++- drivers/md/dm-rq.c | 8 ++++---- drivers/md/dm-target.c | 3 ++- include/linux/device-mapper.h | 3 ++- 4 files changed, 24 insertions(+), 7 deletions(-)
drivers/md/dm-mpath.c +16 -1
@@ -554,8 +554,23 @@ static int multipath_clone_and_map(struct dm_target *ti, struct request *rq,return DM_MAPIO_REMAPPED ; } -static void multipath_release_clone (struct request *clone) +static void multipath_release_clone (struct request *clone, +union map_info *map_context) { +if (unlikely (map_context)) { +/* +* non-NULL map_context means caller is still map +* method; must undo multipath_clone_and_map() +*/ +struct dm_mpath_io *mpio =get_mpio (map_context); +struct pgpath *pgpath = mpio->pgpath; + +if (pgpath && pgpath->pg->ps.type->end_io) + pgpath->pg->ps.type->end_io (&pgpath->pg->ps, + &pgpath->path, + mpio->nr_bytes); + } +blk_put_request (clone); }
drivers/md/dm-rq.c +4 -4
@@ -219,7 +219,7 @@ static void dm_end_request(struct request *clone, blk_status_t error)struct request *rq = tio->orig;blk_rq_unprep_clone (clone); - tio->ti->type->release_clone_rq (clone); + tio->ti->type->release_clone_rq (clone,NULL );rq_end_stats (md, rq);if (!rq->q->mq_ops)
@@ -270,7 +270,7 @@ static void dm_requeue_original_request(struct dm_rq_target_io *tio, bool delay_rq_end_stats (md, rq);if (tio->clone) {blk_rq_unprep_clone (tio->clone); - tio->ti->type->release_clone_rq (tio->clone); + tio->ti->type->release_clone_rq (tio->clone,NULL ); }if (!rq->q->mq_ops)
@@ -495,7 +495,7 @@ check_again:case DM_MAPIO_REMAPPED :if (setup_clone (clone, rq, tio,GFP_ATOMIC )) {/* -ENOMEM */ - ti->type->release_clone_rq (clone); + ti->type->release_clone_rq (clone, &tio->info);return DM_MAPIO_REQUEUE ; }
@@ -505,7 +505,7 @@ check_again: ret =dm_dispatch_clone_request (clone, rq);if (ret ==BLK_STS_RESOURCE || ret ==BLK_STS_DEV_RESOURCE ) {blk_rq_unprep_clone (clone); - tio->ti->type->release_clone_rq (clone); + tio->ti->type->release_clone_rq (clone, &tio->info); tio->clone =NULL ;if (!rq->q->mq_ops) r =DM_MAPIO_DELAY_REQUEUE ;
drivers/md/dm-target.c +2 -1
@@ -136,7 +136,8 @@ static int io_err_clone_and_map_rq(struct dm_target *ti, struct request *rq,return DM_MAPIO_KILL ; } -static void io_err_release_clone_rq (struct request *clone) +static void io_err_release_clone_rq (struct request *clone, +union map_info *map_context) { }
include/linux/device-mapper.h +2 -1
@@ -62,7 +62,8 @@ typedef int (*dm_clone_and_map_request_fn) (struct dm_target *ti,struct request *rq, union map_info *map_context, struct request **clone); -typedef void (*dm_release_clone_request_fn ) (struct request *clone); +typedef void (*dm_release_clone_request_fn ) (struct request *clone, +union map_info *map_context);/* * Returns:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 127/190 blk-mq: free hw queues resource in hctxs release handler
In reply to Greg Kroah-Hartman[ Upstream commit c7e2d94b3d1634988a95ac4d77a72dc7487ece06 ]
Once blk_cleanup_queue() returns, tags shouldn't be used any more, because blk_mq_free_tag_set() may be called. Commit 45a9c9d909b2 ("blk-mq: Fix a use-after-free") fixes this issue exactly.
However, that commit introduces another issue. Before 45a9c9d909b2, we are allowed to run queue during cleaning up queue if the queue's kobj refcount is held. After that commit, queue can't be run during queue cleaning up, otherwise oops can be triggered easily because some fields of hctx are freed by blk_mq_free_queue() in blk_cleanup_queue().
We have invented ways for addressing this kind of issue before, such as:
8dc765d438f1 ("SCSI: fix queue cleanup race before queue initialization is done") c2856ae2f315 ("blk-mq: quiesce queue before freeing queue")
But still can't cover all cases, recently James reports another such kind of issue:
https://marc.info/?l=linux-scsi&m=155389088124782&w=2
This issue can be quite hard to address by previous way, given scsi_run_queue() may run requeues for other LUNs.
Fixes the above issue by freeing hctx's resources in its release handler, and this way is safe becasue tags isn't needed for freeing such hctx resource.
This approach follows typical design pattern wrt. kobject's release handler.
--- block/blk-core.c | 3 ++- block/blk-mq-sysfs.c | 6 ++++++ block/blk-mq.c | 8 ++------ block/blk-mq.h | 2 +- 4 files changed, 11 insertions(+), 8 deletions(-)
block/blk-core.c +2 -1
@@ -816,7 +816,8 @@ void blk_cleanup_queue(struct request_queue *q)blk_exit_queue (q);if (q->mq_ops) -blk_mq_free_queue (q); +blk_mq_exit_queue (q); +percpu_ref_exit (&q->q_usage_counter);spin_lock_irq (lock);
block/blk-mq-sysfs.c +6 -0
@@ -10,6 +10,7 @@#include <linux/smp.h> #include <linux/blk-mq.h> +#include "blk.h" #include "blk-mq.h" #include "blk-mq-tag.h"
@@ -21,6 +22,11 @@ static void blk_mq_hw_sysfs_release(struct kobject *kobj) { struct blk_mq_hw_ctx *hctx = container_of(kobj, struct blk_mq_hw_ctx, kobj); + +if (hctx->flags &BLK_MQ_F_BLOCKING ) +cleanup_srcu_struct (hctx->srcu); +blk_free_flush_queue (hctx->fq); +sbitmap_free (&hctx->ctx_map);free_cpumask_var (hctx->cpumask);kfree (hctx->ctxs);kfree (hctx);
block/blk-mq.c +2 -6
@@ -2157,12 +2157,7 @@ static void blk_mq_exit_hctx(struct request_queue *q,if (set->ops->exit_hctx) set->ops->exit_hctx (hctx, hctx_idx); -if (hctx->flags &BLK_MQ_F_BLOCKING ) -cleanup_srcu_struct (hctx->srcu); -blk_mq_remove_cpuhp (hctx); -blk_free_flush_queue (hctx->fq); -sbitmap_free (&hctx->ctx_map); } static void blk_mq_exit_hw_queues(struct request_queue *q,
@@ -2662,7 +2657,8 @@ err_exit: }EXPORT_SYMBOL (blk_mq_init_allocated_queue); -void blk_mq_free_queue (struct request_queue *q) +/* tags can _not_ be used after returning from blk_mq_exit_queue */ +void blk_mq_exit_queue (struct request_queue *q) {struct blk_mq_tag_set *set = q->tag_set;
block/blk-mq.h +1 -1
@@ -31,7 +31,7 @@ struct blk_mq_ctx { }____cacheline_aligned_in_smp ;void blk_mq_freeze_queue (struct request_queue *q); -void blk_mq_free_queue (struct request_queue *q); +void blk_mq_exit_queue (struct request_queue *q);int blk_mq_update_nr_requests (struct request_queue *q,unsigned int nr);void blk_mq_wake_waiters (struct request_queue *q);bool blk_mq_dispatch_rq_list (struct request_queue *,struct list_head *,bool );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 128/190 mmc: sdhci-pci: Add support for Intel CML
In reply to Greg Kroah-Hartman[ Upstream commit 765c59675ab571caf7ada456bbfd23a73136b535 ]
Add PCI Ids for Intel CML.
--- drivers/mmc/host/sdhci-pci-core.c | 2 ++ drivers/mmc/host/sdhci-pci.h | 2 ++ 2 files changed, 4 insertions(+)
drivers/mmc/host/sdhci-pci-core.c +2 -0
@@ -1577,6 +1577,8 @@ static const struct pci_device_id pci_ids[] = {SDHCI_PCI_DEVICE (INTEL ,CNPH_SD , intel_byt_sd),SDHCI_PCI_DEVICE (INTEL ,ICP_EMMC , intel_glk_emmc),SDHCI_PCI_DEVICE (INTEL ,ICP_SD , intel_byt_sd), +SDHCI_PCI_DEVICE (INTEL ,CML_EMMC , intel_glk_emmc), +SDHCI_PCI_DEVICE (INTEL ,CML_SD , intel_byt_sd),SDHCI_PCI_DEVICE (O2 ,8120 , o2),SDHCI_PCI_DEVICE (O2 ,8220 , o2), SDHCI_PCI_DEVICE(O2, 8221, o2),
drivers/mmc/host/sdhci-pci.h +2 -0
@@ -50,6 +50,8 @@#define PCI_DEVICE_ID_INTEL_CNPH_SD 0xa375#define PCI_DEVICE_ID_INTEL_ICP_EMMC 0x34c4#define PCI_DEVICE_ID_INTEL_ICP_SD 0x34f8 +#define PCI_DEVICE_ID_INTEL_CML_EMMC 0x02c4 +#define PCI_DEVICE_ID_INTEL_CML_SD 0x02f5#define PCI_DEVICE_ID_SYSKONNECT_8000 0x8000#define PCI_DEVICE_ID_VIA_95D0 0x95d0
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 129/190 PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify code
In reply to Greg Kroah-Hartman[ Upstream commit e6fdd3bf5aecd8615f31a5128775b9abcf3e0d86 ]
Use devm_pci_alloc_host_bridge() to simplify the error code path. This also fixes a leak in the dw_pcie_host_init() error path.
--- .../pci/controller/dwc/pcie-designware-host.c | 21 +++++++------------ 1 file changed, 8 insertions(+), 13 deletions(-)
drivers/pci/controller/dwc/pcie-designware-host.c +8 -13
@@ -356,7 +356,7 @@ int dw_pcie_host_init(struct pcie_port *pp)dev_err (dev,"Missing *config* reg space\n" ); } - bridge =pci_alloc_host_bridge (0 ); + bridge =devm_pci_alloc_host_bridge (dev,0 );if (!bridge)return -ENOMEM ;
@@ -367,7 +367,7 @@ int dw_pcie_host_init(struct pcie_port *pp) ret =devm_request_pci_bus_resources (dev, &bridge->windows);if (ret) - goto error; +return ret;/* Get the I/O and memory ranges from DT */ resource_list_for_each_entry_safe (win, tmp, &bridge->windows) {
@@ -411,8 +411,7 @@ int dw_pcie_host_init(struct pcie_port *pp) resource_size(pp->cfg));if (!pci->dbi_base) {dev_err (dev,"Error with ioremap\n" ); - ret = -ENOMEM ; - goto error; +return -ENOMEM ; } }
@@ -423,8 +422,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->cfg0_base, pp->cfg0_size);if (!pp->va_cfg0_base) {dev_err (dev,"Error with ioremap in function\n" ); - ret = -ENOMEM ; - goto error; +return -ENOMEM ; } }
@@ -434,8 +432,7 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->cfg1_size);if (!pp->va_cfg1_base) {dev_err (dev,"Error with ioremap\n" ); - ret = -ENOMEM ; - goto error; +return -ENOMEM ; } }
@@ -458,14 +455,14 @@ int dw_pcie_host_init(struct pcie_port *pp) pp->num_vectors == 0) {dev_err (dev,"Invalid number of vectors\n" ); - goto error; +return -EINVAL ; } }if (!pp->ops->msi_host_init) { ret =dw_pcie_allocate_domains (pp);if (ret) - goto error; +return ret;if (pp->msi_irq) irq_set_chained_handler_and_data(pp->msi_irq,
@@ -474,7 +471,7 @@ int dw_pcie_host_init(struct pcie_port *pp) }else { ret = pp->ops->msi_host_init (pp);if (ret <0 ) - goto error; +return ret; } }
@@ -514,8 +511,6 @@ int dw_pcie_host_init(struct pcie_port *pp) err_free_msi:if (pci_msi_enabled () && !pp->ops->msi_host_init)dw_pcie_free_msi (pp); -error: -pci_free_host_bridge (bridge);return ret; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 130/190 cifs: smbd: take an array of reqeusts when sending upper layer data
In reply to Greg Kroah-Hartman[ Upstream commit 4739f2328661d070f93f9bcc8afb2a82706c826d ]
To support compounding, __smb_send_rqst() now sends an array of requests to the transport layer.
Change smbd_send() to take an array of requests, and send them in as few packets as possible.
--- fs/cifs/smbdirect.c | 55 +++++++++++++++++++++++---------------------- fs/cifs/smbdirect.h | 5 +++-- fs/cifs/transport.c | 2 +- 3 files changed, 32 insertions(+), 30 deletions(-)
fs/cifs/smbdirect.c +28 -27
@@ -2090,7 +2090,8 @@ int smbd_recv(struct smbd_connection *info, struct msghdr *msg)* rqst: the data to write * return value: 0 if successfully write, otherwise error code */ -int smbd_send (struct TCP_Server_Info *server,struct smb_rqst *rqst) +int smbd_send (struct TCP_Server_Info *server, +int num_rqst,struct smb_rqst *rqst_array) {struct smbd_connection *info = server->smbd_conn;struct kvec vec;
@@ -2102,6 +2103,8 @@ int smbd_send(struct TCP_Server_Info *server, struct smb_rqst *rqst) info->max_send_size -sizeof (struct smbd_data_transfer );struct kvec *iov;int rc; +struct smb_rqst *rqst; +int rqst_idx; info->smbd_send_pending++;if (info->transport_status !=SMBD_CONNECTED ) {
@@ -2109,47 +2112,41 @@ int smbd_send(struct TCP_Server_Info *server, struct smb_rqst *rqst) goto done; } -/* -* Skip the RFC1002 length defined in MS-SMB2 section 2.1 -* It is used only for TCP transport in the iov[0] -* In future we may want to add a transport layer under protocol -* layer so this will only be issued to TCP transport -*/ - -if (rqst->rq_iov[0 ].iov_len !=4 ) { -log_write (ERR ,"expected the pdu length in 1st iov, but got %zu\n" , rqst->rq_iov[0 ].iov_len); -return -EINVAL ; - } -/* * Add in the page array if there is one. The caller needs to set * rq_tailsz to PAGE_SIZE when the buffer has multiple pages and * ends at page boundary */ - buflen =smb_rqst_len (server, rqst); + remaining_data_length =0 ; +for (i =0 ; i < num_rqst; i++) + remaining_data_length +=smb_rqst_len (server, &rqst_array[i]); -if (buflen +sizeof (struct smbd_data_transfer ) > +if (remaining_data_length +sizeof (struct smbd_data_transfer ) > info->max_fragmented_send_size) {log_write (ERR ,"payload size %d > max size %d\n" , - buflen, info->max_fragmented_send_size); + remaining_data_length, info->max_fragmented_send_size); rc = -EINVAL ; goto done; } - iov = &rqst->rq_iov[1 ]; + rqst_idx =0 ; + +next_rqst: + rqst = &rqst_array[rqst_idx]; + iov = rqst->rq_iov; -cifs_dbg (FYI ,"Sending smb (RDMA): smb_len=%u\n" , buflen); -for (i =0 ; i < rqst->rq_nvec-1 ; i++) +cifs_dbg (FYI ,"Sending smb (RDMA): idx=%d smb_len=%lu\n" , + rqst_idx,smb_rqst_len (server, rqst)); +for (i =0 ; i < rqst->rq_nvec; i++)dump_smb (iov[i].iov_base, iov[i].iov_len); - remaining_data_length = buflen; -log_write (INFO ,"rqst->rq_nvec=%d rqst->rq_npages=%d rq_pagesz=%d " -"rq_tailsz=%d buflen=%d\n" , - rqst->rq_nvec, rqst->rq_npages, rqst->rq_pagesz, - rqst->rq_tailsz, buflen); +log_write (INFO ,"rqst_idx=%d nvec=%d rqst->rq_npages=%d rq_pagesz=%d " +"rq_tailsz=%d buflen=%lu\n" , + rqst_idx, rqst->rq_nvec, rqst->rq_npages, rqst->rq_pagesz, + rqst->rq_tailsz,smb_rqst_len (server, rqst)); - start = i = iov[0 ].iov_len ?0 :1 ; + start = i =0 ; buflen =0 ;while (true) { buflen += iov[i].iov_len;
@@ -2197,14 +2194,14 @@ int smbd_send(struct TCP_Server_Info *server, struct smb_rqst *rqst) goto done; } i++; -if (i == rqst->rq_nvec-1 ) +if (i == rqst->rq_nvec)break ; } start = i; buflen =0 ; }else { i++; -if (i == rqst->rq_nvec-1 ) { +if (i == rqst->rq_nvec) {/* send out all remaining vecs */ remaining_data_length -= buflen; log_write(INFO,
@@ -2248,6 +2245,10 @@ int smbd_send(struct TCP_Server_Info *server, struct smb_rqst *rqst) } } + rqst_idx++; +if (rqst_idx < num_rqst) + goto next_rqst; + done:/* * As an optimization, we don't wait for individual I/O to finish
fs/cifs/smbdirect.h +3 -2
@@ -292,7 +292,8 @@ void smbd_destroy(struct smbd_connection *info);/* Interface for carrying upper layer I/O through send/recv */ int smbd_recv (struct smbd_connection *info,struct msghdr *msg); -int smbd_send (struct TCP_Server_Info *server,struct smb_rqst *rqst); +int smbd_send (struct TCP_Server_Info *server, +int num_rqst,struct smb_rqst *rqst);enum mr_state {MR_READY ,
@@ -332,7 +333,7 @@ static inline void *smbd_get_connection(static inline int smbd_reconnect (struct TCP_Server_Info *server) {return -1 ; }static inline void smbd_destroy (struct smbd_connection *info) {}static inline int smbd_recv (struct smbd_connection *info,struct msghdr *msg) {return -1 ; } -static inline int smbd_send (struct TCP_Server_Info *server,struct smb_rqst *rqst) {return -1 ; } +static inline int smbd_send (struct TCP_Server_Info *server,int num_rqst,struct smb_rqst *rqst) {return -1 ; }#endif #endif
fs/cifs/transport.c +1 -1
@@ -287,7 +287,7 @@ __smb_send_rqst(struct TCP_Server_Info *server, int num_rqst,__be32 rfc1002_marker;if (cifs_rdma_enabled (server) && server->smbd_conn) { - rc =smbd_send (server, rqst); + rc =smbd_send (server, num_rqst, rqst); goto smbd_done; }if (ssocket ==NULL )
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 131/190 dm crypt: move detailed message into debug level
In reply to Greg Kroah-Hartman[ Upstream commit 7a1cd7238fde6ab367384a4a2998cba48330c398 ]
The information about tag size should not be printed without debug info set. Also print device major:minor in the error message to identify the device instance.
Also use rate limiting and debug level for info about used crypto API implementaton. This is important because during online reencryption the existing message saturates syslog (because we are moving hotzone across the whole device).
--- drivers/md/dm-crypt.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/md/dm-crypt.c +3 -2
@@ -949,6 +949,7 @@ static int crypt_integrity_ctr(struct crypt_config *cc, struct dm_target *ti) {#ifdef CONFIG_BLK_DEV_INTEGRITY struct blk_integrity *bi =blk_get_integrity (cc->dev->bdev->bd_disk); +struct mapped_device *md =dm_table_get_md (ti->table);/* From now we require underlying device with our integrity profile */ if (!bi ||strcasecmp (bi->profile->name,"DM-DIF-EXT-TAG" )) {
@@ -968,7 +969,7 @@ static int crypt_integrity_ctr(struct crypt_config *cc, struct dm_target *ti)if (crypt_integrity_aead (cc)) { cc->integrity_tag_size = cc->on_disk_tag_size - cc->integrity_iv_size; -DMINFO ("Integrity AEAD, tag size %u, IV size %u." , +DMDEBUG ("%s: Integrity AEAD, tag size %u, IV size %u." ,dm_device_name (md), cc->integrity_tag_size, cc->integrity_iv_size);if (crypto_aead_setauthsize (any_tfm_aead (cc), cc->integrity_tag_size)) {
@@ -976,7 +977,7 @@ static int crypt_integrity_ctr(struct crypt_config *cc, struct dm_target *ti)return -EINVAL ; } }else if (cc->integrity_iv_size) -DMINFO ("Additional per-sector space %u bytes for IV." , +DMDEBUG ("%s: Additional per-sector space %u bytes for IV." ,dm_device_name (md), cc->integrity_iv_size);if ((cc->integrity_tag_size + cc->integrity_iv_size) != bi->tag_size) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 132/190 signal/arc: Use force_sig_fault where appropriate
In reply to Greg Kroah-Hartman[ Upstream commit 15773ae938d8d93d982461990bebad6e1d7a1830 ]
--- arch/arc/mm/fault.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-)
arch/arc/mm/fault.c +5 -15
@@ -66,14 +66,12 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)struct vm_area_struct *vma =NULL ;struct task_struct *tsk = current;struct mm_struct *mm = tsk->mm; -siginfo_t info; +int si_code;int ret;vm_fault_t fault;int write = regs->ecr_cause &ECR_C_PROTV_STORE ;/* ST/EX */ unsigned int flags =FAULT_FLAG_ALLOW_RETRY |FAULT_FLAG_KILLABLE ; -clear_siginfo (&info); -/* * We fault-in kernel-space virtual memory on-demand. The * 'reference' page table is init_mm.pgd.
@@ -91,7 +89,7 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)return ; } - info.si_code =SEGV_MAPERR ; + si_code =SEGV_MAPERR ;/* * If we're in an interrupt or have no user
@@ -119,7 +117,7 @@ retry:* we can handle it.. */ good_area: - info.si_code =SEGV_ACCERR ; + si_code =SEGV_ACCERR ;/* Handle protection violation, execute on heap or stack */
@@ -204,11 +202,7 @@ bad_area_nosemaphore:/* User mode accesses just cause a SIGSEGV */ if (user_mode (regs)) { tsk->thread.fault_address = address; - info.si_signo =SIGSEGV ; - info.si_errno =0 ; -/* info.si_code has been set above */ - info.si_addr = (void __user *)address; -force_sig_info (SIGSEGV , &info, tsk); +force_sig_fault (SIGSEGV , si_code, (void __user *)address, tsk);return ; }
@@ -243,9 +237,5 @@ do_sigbus: goto no_context; tsk->thread.fault_address = address; - info.si_signo =SIGBUS ; - info.si_errno =0 ; - info.si_code =BUS_ADRERR ; - info.si_addr = (void __user *)address; -force_sig_info (SIGBUS , &info, tsk); +force_sig_fault (SIGBUS ,BUS_ADRERR , (void __user *)address, tsk); }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 133/190 ARC: mm: fix uninitialised signal code in do_page_fault
In reply to Greg Kroah-Hartman[ Upstream commit 121e38e5acdc8e1e4cdb750fcdcc72f94e420968 ]
Commit 15773ae938d8 ("signal/arc: Use force_sig_fault where appropriate") introduced undefined behaviour by leaving si_code unitiailized and leaking random kernel values to user space.
--- arch/arc/mm/fault.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arc/mm/fault.c +1 -1
@@ -66,7 +66,7 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)struct vm_area_struct *vma =NULL ;struct task_struct *tsk = current;struct mm_struct *mm = tsk->mm; -int si_code; +int si_code =0 ;int ret;vm_fault_t fault;int write = regs->ecr_cause &ECR_C_PROTV_STORE ;/* ST/EX */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 134/190 ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
In reply to Greg Kroah-Hartman[ Upstream commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 ]
As of today if userspace process tries to access a kernel virtual addres (0x7000_0000 to 0x7ffff_ffff) such that a legit kernel mapping already exists, that process hangs instead of being killed with SIGSEGV
Fix that by ensuring that do_page_fault() handles kenrel vaddr only if in kernel mode.
And given this, we can also simplify the code a bit. Now a vmalloc fault implies kernel mode so its failure (for some reason) can reuse the @no_context label and we can remove @bad_area_nosemaphore.
Reproduce user test for original problem:
------------------------>8-----------------
#include <stdlib.h>
#include <stdint.h>
int main(int argc, char *argv[])
{
volatile uint32_t temp;
temp = *(uint32_t *)(0x70000000);
}
------------------------>8-----------------
--- arch/arc/mm/fault.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
arch/arc/mm/fault.c +3 -6
@@ -66,7 +66,7 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)struct vm_area_struct *vma =NULL ;struct task_struct *tsk = current;struct mm_struct *mm = tsk->mm; -int si_code =0 ; +int si_code =SEGV_MAPERR ;int ret;vm_fault_t fault;int write = regs->ecr_cause &ECR_C_PROTV_STORE ;/* ST/EX */
@@ -81,16 +81,14 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)* only copy the information from the master page table, * nothing more. */ -if (address >=VMALLOC_START ) { +if (address >=VMALLOC_START && !user_mode (regs)) { ret =handle_kernel_vaddr_fault (address);if (unlikely (ret)) - goto bad_area_nosemaphore; + goto no_context;else return ; } - si_code =SEGV_MAPERR ; -/* * If we're in an interrupt or have no user * context, we must not take the fault..
@@ -198,7 +196,6 @@ good_area: bad_area:up_read (&mm->mmap_sem); -bad_area_nosemaphore:/* User mode accesses just cause a SIGSEGV */ if (user_mode (regs)) { tsk->thread.fault_address = address;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 135/190 drm/amdkfd: Add missing Polaris10 ID
In reply to Greg Kroah-Hartman[ Upstream commit 0a5a9c276c335870a1cecc4f02b76d6d6f663c8b ]
This was added to amdgpu but was missed in amdkfd
--- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdkfd/kfd_device.c +1 -0
@@ -310,6 +310,7 @@ static const struct kfd_deviceid supported_devices[] = { { 0x67CF, &polaris10_device_info }, /* Polaris10 */ { 0x67D0, &polaris10_vf_device_info }, /* Polaris10 vf*/ { 0x67DF, &polaris10_device_info }, /* Polaris10 */ + { 0x6FDF, &polaris10_device_info }, /* Polaris10 */ { 0x67E0, &polaris11_device_info }, /* Polaris11 */ { 0x67E1, &polaris11_device_info }, /* Polaris11 */ { 0x67E3, &polaris11_device_info }, /* Polaris11 */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 136/190 kvm: Check irqchip mode before assign irqfd
In reply to Greg Kroah-Hartman[ Upstream commit 654f1f13ea56b92bacade8ce2725aea0457f91c0 ]
When assigning kvm irqfd we didn't check the irqchip mode but we allow KVM_IRQFD to succeed with all the irqchip modes. However it does not make much sense to create irqfd even without the kernel chips. Let's provide a arch-dependent helper to check whether a specific irqfd is allowed by the arch. At least for x86, it should make sense to check:
- when irqchip mode is NONE, all irqfds should be disallowed, and,
- when irqchip mode is SPLIT, irqfds that are with resamplefd should be disallowed.
For either of the case, previously we'll silently ignore the irq or the irq ack event if the irqchip mode is incorrect. However that can cause misterious guest behaviors and it can be hard to triage. Let's fail KVM_IRQFD even earlier to detect these incorrect configurations.
--- arch/x86/kvm/irq.c | 7 +++++++ arch/x86/kvm/irq.h | 1 + virt/kvm/eventfd.c | 9 +++++++++ 3 files changed, 17 insertions(+)
arch/x86/kvm/irq.c +7 -0
@@ -172,3 +172,10 @@ void __kvm_migrate_timers(struct kvm_vcpu *vcpu)__kvm_migrate_apic_timer (vcpu);__kvm_migrate_pit_timer (vcpu); } + +bool kvm_arch_irqfd_allowed (struct kvm *kvm,struct kvm_irqfd *args) +{ +bool resample = args->flags &KVM_IRQFD_FLAG_RESAMPLE ; + +return resample ?irqchip_kernel (kvm) :irqchip_in_kernel (kvm); +}
arch/x86/kvm/irq.h +1 -0
@@ -114,6 +114,7 @@ static inline int irqchip_in_kernel(struct kvm *kvm)return mode !=KVM_IRQCHIP_NONE ; } +bool kvm_arch_irqfd_allowed (struct kvm *kvm,struct kvm_irqfd *args);void kvm_inject_pending_timer_irqs (struct kvm_vcpu *vcpu);void kvm_inject_apic_timer_irqs (struct kvm_vcpu *vcpu);void kvm_apic_nmi_wd_deliver (struct kvm_vcpu *vcpu);
virt/kvm/eventfd.c +9 -0
@@ -44,6 +44,12 @@static struct workqueue_struct *irqfd_cleanup_wq; +bool __attribute__((weak)) +kvm_arch_irqfd_allowed (struct kvm *kvm,struct kvm_irqfd *args) +{ +return true; +} +static void irqfd_inject (struct work_struct *work) {
@@ -297,6 +303,9 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)if (!kvm_arch_intc_initialized (kvm))return -EAGAIN ; +if (!kvm_arch_irqfd_allowed (kvm, args)) +return -EINVAL ; + irqfd =kzalloc (sizeof (*irqfd),GFP_KERNEL );if (!irqfd)return -ENOMEM ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 137/190 drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)
In reply to Greg Kroah-Hartman[ Upstream commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d ]
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110).
[How]
fetch rptr appropriately, meaning move its read location further down in the code flow.
With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent.
V2: remove reduntant fetch of rptr
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c +4 -1
@@ -1070,7 +1070,7 @@ void amdgpu_vce_ring_emit_fence(struct amdgpu_ring *ring, u64 addr, u64 seq,int amdgpu_vce_ring_test_ring (struct amdgpu_ring *ring) {struct amdgpu_device *adev = ring->adev; -uint32_t rptr =amdgpu_ring_get_rptr (ring); +uint32_t rptr;unsigned i;int r, timeout = adev->usec_timeout;
@@ -1084,6 +1084,9 @@ int amdgpu_vce_ring_test_ring(struct amdgpu_ring *ring) ring->idx, r);return r; } + + rptr =amdgpu_ring_get_rptr (ring); +amdgpu_ring_write (ring,VCE_CMD_END );amdgpu_ring_commit (ring);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 138/190 drm/amdgpu/{uvd,vcn}: fetch rings read_ptr after alloc
In reply to Greg Kroah-Hartman[ Upstream commit 517b91f4cde3043d77b2178548473e8545ef07cb ]
[What]
readptr read always returns zero, since most likely these blocks are either power or clock gated.
[How]
fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 5 ++++- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 5 ++++- drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c +4 -1
@@ -431,7 +431,7 @@ error:int amdgpu_vcn_enc_ring_test_ring (struct amdgpu_ring *ring) {struct amdgpu_device *adev = ring->adev; -uint32_t rptr =amdgpu_ring_get_rptr (ring); +uint32_t rptr;unsigned i;int r;
@@ -441,6 +441,9 @@ int amdgpu_vcn_enc_ring_test_ring(struct amdgpu_ring *ring) ring->idx, r);return r; } + + rptr =amdgpu_ring_get_rptr (ring); +amdgpu_ring_write (ring,VCN_ENC_CMD_END );amdgpu_ring_commit (ring);
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c +4 -1
@@ -170,7 +170,7 @@ static void uvd_v6_0_enc_ring_set_wptr(struct amdgpu_ring *ring)static int uvd_v6_0_enc_ring_test_ring (struct amdgpu_ring *ring) {struct amdgpu_device *adev = ring->adev; -uint32_t rptr =amdgpu_ring_get_rptr (ring); +uint32_t rptr;unsigned i;int r;
@@ -180,6 +180,9 @@ static int uvd_v6_0_enc_ring_test_ring(struct amdgpu_ring *ring) ring->idx, r);return r; } + + rptr =amdgpu_ring_get_rptr (ring); +amdgpu_ring_write (ring,HEVC_ENC_CMD_END );amdgpu_ring_commit (ring);
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c +4 -1
@@ -175,7 +175,7 @@ static void uvd_v7_0_enc_ring_set_wptr(struct amdgpu_ring *ring)static int uvd_v7_0_enc_ring_test_ring (struct amdgpu_ring *ring) {struct amdgpu_device *adev = ring->adev; -uint32_t rptr =amdgpu_ring_get_rptr (ring); +uint32_t rptr;unsigned i;int r;
@@ -188,6 +188,9 @@ static int uvd_v7_0_enc_ring_test_ring(struct amdgpu_ring *ring) ring->me, ring->idx, r);return r; } + + rptr =amdgpu_ring_get_rptr (ring); +amdgpu_ring_write (ring,HEVC_ENC_CMD_END );amdgpu_ring_commit (ring);
Signature · 1 line
2.20.1