2020-04-16 16:09:58

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 000/146] 4.19.116-rc1 review

This is the start of the stable review cycle for the 4.19.116 release.
There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
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.116-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.116-rc1

Christian Gmeiner <[email protected]>
etnaviv: perfmon: fix total and idle HI cyleces readout

Nathan Chancellor <[email protected]>
misc: echo: Remove unnecessary parentheses and simplify check for zero

Laurentiu Tudor <[email protected]>
powerpc/fsl_booke: Avoid creating duplicate tlb1 entry

Masami Hiramatsu <[email protected]>
ftrace/kprobe: Show the maxactive number on kprobe_events

Chris Wilson <[email protected]>
drm: Remove PageReserved manipulation from drm_pci_alloc

Lyude Paul <[email protected]>
drm/dp_mst: Fix clearing payload state on topology disable

Sasha Levin <[email protected]>
Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"

Gilad Ben-Yossef <[email protected]>
crypto: ccree - only try to map auth tag if needed

Gilad Ben-Yossef <[email protected]>
crypto: ccree - dec auth tag size from cryptlen map

Gilad Ben-Yossef <[email protected]>
crypto: ccree - don't mangle the request assoclen

Gilad Ben-Yossef <[email protected]>
crypto: ccree - zero out internal struct before use

Hadar Gat <[email protected]>
crypto: ccree - improve error handling

Andrei Botila <[email protected]>
crypto: caam - update xts sector size for large input length

Bob Liu <[email protected]>
dm zoned: remove duplicate nr_rnd_zones increase in dmz_init_zone()

Josef Bacik <[email protected]>
btrfs: use nofs allocations for running delayed items

Clement Courbet <[email protected]>
powerpc: Make setjmp/longjmp signature standard

Segher Boessenkool <[email protected]>
powerpc: Add attributes for setjmp/longjmp

Sreekanth Reddy <[email protected]>
scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug

Christophe Leroy <[email protected]>
powerpc/kprobes: Ignore traps that happened in real mode

Cédric Le Goater <[email protected]>
powerpc/xive: Use XIVE_BAD_IRQ instead of zero to catch non configured IPIs

Aneesh Kumar K.V <[email protected]>
powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap PTE entries

Michael Ellerman <[email protected]>
powerpc/64/tm: Don't let userspace set regs->trap via sigreturn

Michael Ellerman <[email protected]>
powerpc/powernv/idle: Restore AMR/UAMOR/AMOR after idle

Juergen Gross <[email protected]>
xen/blkfront: fix memory allocation flags in blkfront_setup_indirect()

Wen Yang <[email protected]>
ipmi: fix hung processes in __get_guid()

Kai-Heng Feng <[email protected]>
libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set

Simon Gander <[email protected]>
hfsplus: fix crash and filesystem corruption when deleting files

Oliver O'Halloran <[email protected]>
cpufreq: powernv: Fix use-after-free

Eric Biggers <[email protected]>
kmod: make request_module() return an error when autoloading is disabled

Paul Cercueil <[email protected]>
clk: ingenic/jz4770: Exit with error if CGU init failed

Hans de Goede <[email protected]>
Input: i8042 - add Acer Aspire 5738z to nomux list

Michael Mueller <[email protected]>
s390/diag: fix display of diagnose call statistics

Sam Lunt <[email protected]>
perf tools: Support Python 3.8+ in Makefile

Changwei Ge <[email protected]>
ocfs2: no need try to truncate file beyond i_size

Eric Biggers <[email protected]>
fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()

Qian Cai <[email protected]>
ext4: fix a data race at inode->i_blocks

Trond Myklebust <[email protected]>
NFS: Fix a page leak in nfs_destroy_unlinked_subrequests()

Libor Pechacek <[email protected]>
powerpc/pseries: Avoid NULL pointer dereference when drmem is unavailable

Christian Gmeiner <[email protected]>
drm/etnaviv: rework perfmon query infrastructure

Nathan Chancellor <[email protected]>
rtc: omap: Use define directive for PIN_CONFIG_ACTIVE_HIGH

Michal Hocko <[email protected]>
selftests: vm: drop dependencies on page flags from mlock2 tests

Fredrik Strupe <[email protected]>
arm64: armv8_deprecated: Fix undef_hook mask for thumb setend

Steffen Maier <[email protected]>
scsi: zfcp: fix missing erp_lock in port recovery trigger for point-to-point

Shetty, Harshini X (EXT-Sony Mobile) <[email protected]>
dm verity fec: fix memory leak in verity_fec_dtr

Mikulas Patocka <[email protected]>
dm writecache: add cond_resched to avoid CPU hangs

Maxime Ripard <[email protected]>
arm64: dts: allwinner: h6: Fix PMU compatible

Subash Abhinov Kasiviswanathan <[email protected]>
net: qualcomm: rmnet: Allow configuration updates to existing devices

Alexander Duyck <[email protected]>
mm: Use fixed constant in page_frag_alloc instead of size + 1

Anssi Hannula <[email protected]>
tools: gpio: Fix out-of-tree build regression

Zhenzhong Duan <[email protected]>
x86/speculation: Remove redundant arch_smt_update() invocation

YueHaibing <[email protected]>
powerpc/pseries: Drop pointless static qualifier in vpa_debugfs_init()

Gao Xiang <[email protected]>
erofs: correct the remaining shrink objects

Rosioru Dragos <[email protected]>
crypto: mxs-dcp - fix scatterlist linearization for hash

Robbie Ko <[email protected]>
btrfs: fix missing semaphore unlock in btrfs_sync_file

Filipe Manana <[email protected]>
btrfs: fix missing file extent item for hole after ranged fsync

Josef Bacik <[email protected]>
btrfs: drop block from cache on error in relocation

Josef Bacik <[email protected]>
btrfs: set update the uuid generation as soon as possible

Filipe Manana <[email protected]>
Btrfs: fix crash during unmount due to race with delayed inode workers

Frieder Schrempf <[email protected]>
mtd: spinand: Do not erase the block before writing a bad block marker

Frieder Schrempf <[email protected]>
mtd: spinand: Stop using spinand->oobbuf for buffering bad block markers

Yilu Lin <[email protected]>
CIFS: Fix bug which the return value by asynchronous read is error

Vitaly Kuznetsov <[email protected]>
KVM: VMX: fix crash cleanup when KVM wasn't used

Sean Christopherson <[email protected]>
KVM: x86: Gracefully handle __vmalloc() failure during VM allocation

Sean Christopherson <[email protected]>
KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support

Sean Christopherson <[email protected]>
KVM: x86: Allocate new rmap and large page tracking when moving memslot

David Hildenbrand <[email protected]>
KVM: s390: vsie: Fix delivery of addressing exceptions

David Hildenbrand <[email protected]>
KVM: s390: vsie: Fix region 1 ASCE sanity shadow address checks

Sean Christopherson <[email protected]>
KVM: nVMX: Properly handle userspace interrupt window request

Thomas Gleixner <[email protected]>
x86/entry/32: Add missing ASM_CLAC to general_protection entry

Eric W. Biederman <[email protected]>
signal: Extend exec_id to 64bits

Remi Pommarel <[email protected]>
ath9k: Handle txpower changes even when TPC is disabled

Gustavo A. R. Silva <[email protected]>
MIPS: OCTEON: irq: Fix potential NULL pointer dereference

Huacai Chen <[email protected]>
MIPS/tlbex: Fix LDDIR usage in setup_pw() for Loongson-3

Vasily Averin <[email protected]>
pstore: pstore_ftrace_seq_next should increase position index

Sungbo Eo <[email protected]>
irqchip/versatile-fpga: Apply clear-mask earlier

Yang Xu <[email protected]>
KEYS: reaching the keys quotas correctly

Vasily Averin <[email protected]>
tpm: tpm2_bios_measurements_next should increase position index

Vasily Averin <[email protected]>
tpm: tpm1_bios_measurements_next should increase position index

Matthew Garrett <[email protected]>
tpm: Don't make log failures fatal

Kishon Vijay Abraham I <[email protected]>
PCI: endpoint: Fix for concurrent memory allocation in OB address region

Sean V Kelley <[email protected]>
PCI: Add boot interrupt quirk mechanism for Xeon chipsets

Yicong Yang <[email protected]>
PCI/ASPM: Clear the correct bits when enabling L1 substates

Lukas Wunner <[email protected]>
PCI: pciehp: Fix indefinite wait on sysfs requests

James Smart <[email protected]>
nvme: Treat discovery subsystems as unique subsystems

James Smart <[email protected]>
nvme-fc: Revert "add module to ops template to allow module references"

Martin Blumenstingl <[email protected]>
thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n

Jan Engelhardt <[email protected]>
acpi/x86: ignore unspecified bit positions in the ACPI global lock field

Benoit Parrot <[email protected]>
media: ti-vpe: cal: fix disable_irqs to only the intended target

Takashi Iwai <[email protected]>
ALSA: hda/realtek - Add quirk for MSI GL63

Thomas Hebb <[email protected]>
ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups

Thomas Hebb <[email protected]>
ALSA: hda/realtek - Set principled PC Beep configuration for ALC256

Thomas Hebb <[email protected]>
ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256

Takashi Iwai <[email protected]>
ALSA: pcm: oss: Fix regression by buffer overflow fix

Takashi Iwai <[email protected]>
ALSA: ice1724: Fix invalid access for enumerated ctl items

Takashi Iwai <[email protected]>
ALSA: hda: Fix potential access overflow in beep helper

Takashi Iwai <[email protected]>
ALSA: hda: Add driver blacklist

Takashi Iwai <[email protected]>
ALSA: usb-audio: Add mixer workaround for TRX40 and co

Thinh Nguyen <[email protected]>
usb: gadget: composite: Inform controller driver of self-powered

Sriharsha Allenki <[email protected]>
usb: gadget: f_fs: Fix use after free issue as part of queue failure

이경택 <[email protected]>
ASoC: topology: use name_prefix for new kcontrol

이경택 <[email protected]>
ASoC: dpcm: allow start or stop during pause for backend

이경택 <[email protected]>
ASoC: dapm: connect virtual mux with default value

이경택 <[email protected]>
ASoC: fix regwmask

Kees Cook <[email protected]>
slub: improve bit diffusion for freelist ptr obfuscation

Yury Norov <[email protected]>
uapi: rename ext2_swab() to swab() and share globally in swab.h

Alex Vesker <[email protected]>
IB/mlx5: Replace tunnel mpls capability bits for tunnel_offloads

Josef Bacik <[email protected]>
btrfs: track reloc roots based on their commit root bytenr

Josef Bacik <[email protected]>
btrfs: remove a BUG_ON() from merge_reloc_roots()

Qu Wenruo <[email protected]>
btrfs: qgroup: ensure qgroup_rescan_running is only set when the worker is at least queued

Zhiqiang Liu <[email protected]>
block, bfq: fix use-after-free in bfq_idle_slice_timer_body

Boqun Feng <[email protected]>
locking/lockdep: Avoid recursion in lockdep_count_{for,back}ward_deps()

Junyong Sun <[email protected]>
firmware: fix a double abort case with fw_load_sysfs_fallback

Guoqing Jiang <[email protected]>
md: check arrays is suspended in mddev_detach before call quiesce operations

Marc Zyngier <[email protected]>
irqchip/gic-v4: Provide irq_retrigger to avoid circular locking dependency

Neil Armstrong <[email protected]>
usb: dwc3: core: add support for disabling SS instances in park mode

Dongchun Zhu <[email protected]>
media: i2c: ov5695: Fix power on and off sequences

Sahitya Tummala <[email protected]>
block: Fix use-after-free issue accessing struct io_cq

Alexander Sverdlin <[email protected]>
genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy()

Ard Biesheuvel <[email protected]>
efi/x86: Ignore the memory attributes table on i386

Arvind Sankar <[email protected]>
x86/boot: Use unsigned comparison for addresses

Bob Peterson <[email protected]>
gfs2: Don't demote a glock until its revokes are written

chenqiwu <[email protected]>
pstore/platform: fix potential mem leak if pstore_init_fs failed

John Garry <[email protected]>
libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()

Matt Ranostay <[email protected]>
media: i2c: video-i2c: fix build errors due to 'imply hwmon'

Logan Gunthorpe <[email protected]>
PCI/switchtec: Fix init_completion race condition with poll_wait()

Andy Lutomirski <[email protected]>
selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault

Michael Wang <[email protected]>
sched: Avoid scale real weight down to zero

Sungbo Eo <[email protected]>
irqchip/versatile-fpga: Handle chained IRQs properly

Konstantin Khlebnikov <[email protected]>
block: keep bdi->io_pages in sync with max_sectors_kb for stacked devices

Thomas Hellstrom <[email protected]>
x86: Don't let pgprot_modify() change the page encryption bit

Mathias Nyman <[email protected]>
xhci: bail out early if driver can't accress host in resume

Alexey Dobriyan <[email protected]>
null_blk: fix spurious IO errors after failed past-wp access

Bart Van Assche <[email protected]>
null_blk: Handle null_add_dev() failures properly

Bart Van Assche <[email protected]>
null_blk: Fix the null_add_dev() error path

James Morse <[email protected]>
firmware: arm_sdei: fix double-lock on hibernate with shared events

Stephan Gerhold <[email protected]>
media: venus: hfi_parser: Ignore HEVC encoding for V1

Christoph Niedermaier <[email protected]>
cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL

Alain Volmat <[email protected]>
i2c: st: fix missing struct parameter description

Xu Wang <[email protected]>
qlcnic: Fix bad kzalloc null test

Raju Rangoju <[email protected]>
cxgb4/ptp: pass the sign of offset delta in FW CMD

Luo bin <[email protected]>
hinic: fix wrong para of wait_for_completion_timeout

Luo bin <[email protected]>
hinic: fix a bug of waitting for IO stopped

Zheng Wei <[email protected]>
net: vxge: fix wrong __VA_ARGS__ usage

David Howells <[email protected]>
rxrpc: Abstract out the calculation of whether there's Tx space

Ondrej Jirman <[email protected]>
bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads

Ondrej Jirman <[email protected]>
ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesn't like such a high voltage


-------------

Diffstat:

Documentation/sound/hd-audio/index.rst | 1 +
Documentation/sound/hd-audio/models.rst | 2 -
Documentation/sound/hd-audio/realtek-pc-beep.rst | 129 ++++++++++++
Makefile | 4 +-
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 +-
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 3 +-
arch/arm64/kernel/armv8_deprecated.c | 2 +-
arch/mips/cavium-octeon/octeon-irq.c | 3 +
arch/mips/mm/tlbex.c | 5 +-
arch/powerpc/include/asm/book3s/64/hash-4k.h | 6 +
arch/powerpc/include/asm/book3s/64/hash-64k.h | 8 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
arch/powerpc/include/asm/book3s/64/radix.h | 5 +
arch/powerpc/include/asm/drmem.h | 4 +-
arch/powerpc/include/asm/setjmp.h | 6 +-
arch/powerpc/kernel/Makefile | 3 -
arch/powerpc/kernel/idle_book3s.S | 27 ++-
arch/powerpc/kernel/kprobes.c | 3 +
arch/powerpc/kernel/signal_64.c | 4 +-
arch/powerpc/mm/tlb_nohash_low.S | 12 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 8 +-
arch/powerpc/platforms/pseries/lpar.c | 2 +-
arch/powerpc/sysdev/xive/common.c | 12 +-
arch/powerpc/sysdev/xive/native.c | 4 +-
arch/powerpc/sysdev/xive/spapr.c | 4 +-
arch/powerpc/sysdev/xive/xive-internal.h | 7 +
arch/powerpc/xmon/Makefile | 3 -
arch/s390/kernel/diag.c | 2 +-
arch/s390/kvm/vsie.c | 1 +
arch/s390/mm/gmap.c | 6 +-
arch/x86/boot/compressed/head_32.S | 2 +-
arch/x86/boot/compressed/head_64.S | 4 +-
arch/x86/entry/entry_32.S | 1 +
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/include/asm/pgtable.h | 7 +-
arch/x86/include/asm/pgtable_types.h | 2 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kvm/svm.c | 4 +
arch/x86/kvm/vmx.c | 110 ++++------
arch/x86/kvm/x86.c | 21 +-
block/bfq-iosched.c | 16 +-
block/blk-ioc.c | 7 +
block/blk-settings.c | 3 +
drivers/ata/libata-pmp.c | 1 +
drivers/ata/libata-scsi.c | 9 +-
drivers/base/firmware_loader/fallback.c | 2 +-
drivers/block/null_blk_main.c | 10 +-
drivers/block/xen-blkfront.c | 17 +-
drivers/bus/sunxi-rsb.c | 2 +-
drivers/char/ipmi/ipmi_msghandler.c | 4 +-
drivers/char/tpm/eventlog/common.c | 12 +-
drivers/char/tpm/eventlog/tpm1.c | 2 +-
drivers/char/tpm/eventlog/tpm2.c | 2 +-
drivers/char/tpm/tpm-chip.c | 4 +-
drivers/char/tpm/tpm.h | 2 +-
drivers/clk/ingenic/jz4770-cgu.c | 4 +-
drivers/cpufreq/imx6q-cpufreq.c | 3 +
drivers/cpufreq/powernv-cpufreq.c | 6 +
drivers/crypto/caam/caamalg_desc.c | 16 +-
drivers/crypto/ccree/cc_aead.c | 56 +++--
drivers/crypto/ccree/cc_aead.h | 1 +
drivers/crypto/ccree/cc_buffer_mgr.c | 108 +++++-----
drivers/crypto/mxs-dcp.c | 58 +++--
drivers/firmware/arm_sdei.c | 32 ++-
drivers/firmware/efi/efi.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 19 +-
drivers/gpu/drm/drm_pci.c | 25 +--
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 103 +++++++--
drivers/i2c/busses/i2c-st.c | 1 +
drivers/infiniband/hw/mlx5/main.c | 6 +-
drivers/input/serio/i8042-x86ia64io.h | 11 +
drivers/irqchip/irq-gic-v3-its.c | 6 +
drivers/irqchip/irq-versatile-fpga.c | 18 +-
drivers/md/dm-verity-fec.c | 1 +
drivers/md/dm-writecache.c | 6 +-
drivers/md/dm-zoned-metadata.c | 1 -
drivers/md/md.c | 2 +-
drivers/media/i2c/ov5695.c | 49 +++--
drivers/media/i2c/video-i2c.c | 2 +-
drivers/media/platform/qcom/venus/hfi_parser.c | 1 +
drivers/media/platform/ti-vpe/cal.c | 16 +-
drivers/misc/echo/echo.c | 2 +-
drivers/mtd/nand/spi/core.c | 17 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c | 3 +
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 3 +-
drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c | 51 +----
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 5 +-
drivers/net/ethernet/neterion/vxge/vxge-config.h | 2 +-
drivers/net/ethernet/neterion/vxge/vxge-main.h | 14 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 31 +--
drivers/net/wireless/ath/ath9k/main.c | 3 +
drivers/nvme/host/core.c | 11 +
drivers/nvme/host/fc.c | 14 +-
drivers/nvme/target/fcloop.c | 1 -
drivers/pci/endpoint/pci-epc-mem.c | 10 +-
drivers/pci/hotplug/pciehp_hpc.c | 14 +-
drivers/pci/pcie/aspm.c | 4 +-
drivers/pci/quirks.c | 80 ++++++-
drivers/pci/switch/switchtec.c | 2 +-
drivers/rtc/rtc-omap.c | 4 +-
drivers/s390/scsi/zfcp_erp.c | 2 +-
drivers/scsi/lpfc/lpfc_nvme.c | 2 -
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 8 +-
drivers/scsi/qla2xxx/qla_nvme.c | 1 -
drivers/staging/erofs/utils.c | 2 +-
drivers/usb/dwc3/core.c | 5 +
drivers/usb/dwc3/core.h | 4 +
drivers/usb/gadget/composite.c | 9 +
drivers/usb/gadget/function/f_fs.c | 1 +
drivers/usb/host/xhci.c | 4 +-
fs/btrfs/async-thread.c | 8 +
fs/btrfs/async-thread.h | 1 +
fs/btrfs/delayed-inode.c | 13 ++
fs/btrfs/disk-io.c | 27 ++-
fs/btrfs/file.c | 11 +
fs/btrfs/qgroup.c | 11 +-
fs/btrfs/relocation.c | 35 ++--
fs/cifs/file.c | 2 +-
fs/exec.c | 2 +-
fs/ext4/inode.c | 2 +-
fs/filesystems.c | 4 +-
fs/gfs2/glock.c | 3 +
fs/hfsplus/attributes.c | 4 +
fs/nfs/write.c | 1 +
fs/ocfs2/alloc.c | 4 +
fs/pstore/inode.c | 5 +-
fs/pstore/platform.c | 4 +-
include/linux/devfreq_cooling.h | 2 +-
include/linux/iocontext.h | 1 +
include/linux/mlx5/mlx5_ifc.h | 9 +-
include/linux/nvme-fc-driver.h | 4 -
include/linux/pci-epc.h | 3 +
include/linux/sched.h | 4 +-
include/linux/swab.h | 1 +
include/uapi/linux/swab.h | 10 +
kernel/cpu.c | 5 +-
kernel/irq/irqdomain.c | 10 +-
kernel/kmod.c | 4 +-
kernel/locking/lockdep.c | 4 +
kernel/sched/sched.h | 8 +-
kernel/signal.c | 2 +-
kernel/trace/trace_kprobe.c | 2 +
lib/find_bit.c | 16 +-
mm/page_alloc.c | 8 +-
mm/slub.c | 2 +-
net/rxrpc/sendmsg.c | 27 ++-
security/keys/key.c | 2 +-
security/keys/keyctl.c | 4 +-
sound/core/oss/pcm_plugin.c | 32 ++-
sound/pci/hda/hda_beep.c | 6 +-
sound/pci/hda/hda_intel.c | 16 ++
sound/pci/hda/patch_realtek.c | 50 +----
sound/pci/ice1712/prodigy_hifi.c | 4 +-
sound/soc/soc-dapm.c | 8 +-
sound/soc/soc-ops.c | 4 +-
sound/soc/soc-pcm.c | 6 +-
sound/soc/soc-topology.c | 2 +-
sound/usb/mixer_maps.c | 28 +++
tools/gpio/Makefile | 2 +-
tools/perf/Makefile.config | 11 +-
tools/testing/selftests/vm/mlock2-tests.c | 233 ++++-----------------
tools/testing/selftests/x86/ptrace_syscall.c | 8 +-
163 files changed, 1231 insertions(+), 840 deletions(-)



2020-04-16 17:49:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 001/146] ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesnt like such a high voltage

From: Ondrej Jirman <[email protected]>

[ Upstream commit a40550952c000667b20082d58077bc647da6c890 ]

Lowering the voltage solves the quick image degradation over time
(minutes), that was probably caused by overheating.

Signed-off-by: Ondrej Jirman <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index 49547a43cc90a..54cbdaf7ffdcc 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -318,8 +318,8 @@
};

&reg_dldo3 {
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
regulator-name = "vdd-csi";
};

--
2.20.1



2020-04-16 17:49:37

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 015/146] null_blk: fix spurious IO errors after failed past-wp access

From: Alexey Dobriyan <[email protected]>

[ Upstream commit ff77042296d0a54535ddf74412c5ae92cb4ec76a ]

Steps to reproduce:

BLKRESETZONE zone 0

// force EIO
pwrite(fd, buf, 4096, 4096);

[issue more IO including zone ioctls]

It will start failing randomly including IO to unrelated zones because of
->error "reuse". Trigger can be partition detection as well if test is not
run immediately which is even more entertaining.

The fix is of course to clear ->error where necessary.

Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Alexey Dobriyan (SK hynix) <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/block/null_blk_main.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
index 78355a0e61db6..d2d7dc9cd58d2 100644
--- a/drivers/block/null_blk_main.c
+++ b/drivers/block/null_blk_main.c
@@ -571,6 +571,7 @@ static struct nullb_cmd *__alloc_cmd(struct nullb_queue *nq)
if (tag != -1U) {
cmd = &nq->cmds[tag];
cmd->tag = tag;
+ cmd->error = BLK_STS_OK;
cmd->nq = nq;
if (nq->dev->irqmode == NULL_IRQ_TIMER) {
hrtimer_init(&cmd->timer, CLOCK_MONOTONIC,
@@ -1433,6 +1434,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx *hctx,
cmd->timer.function = null_cmd_timer_expired;
}
cmd->rq = bd->rq;
+ cmd->error = BLK_STS_OK;
cmd->nq = nq;

blk_mq_start_request(bd->rq);
--
2.20.1



2020-04-16 17:50:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 006/146] hinic: fix wrong para of wait_for_completion_timeout

From: Luo bin <[email protected]>

[ Upstream commit 0da7c322f116210ebfdda59c7da663a6fc5e9cc8 ]

the second input parameter of wait_for_completion_timeout should
be jiffies instead of millisecond

Signed-off-by: Luo bin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 3 ++-
drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
index 4d09ea786b35f..ee715bf785adf 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
@@ -398,7 +398,8 @@ static int cmdq_sync_cmd_direct_resp(struct hinic_cmdq *cmdq,

spin_unlock_bh(&cmdq->cmdq_lock);

- if (!wait_for_completion_timeout(&done, CMDQ_TIMEOUT)) {
+ if (!wait_for_completion_timeout(&done,
+ msecs_to_jiffies(CMDQ_TIMEOUT))) {
spin_lock_bh(&cmdq->cmdq_lock);

if (cmdq->errcode[curr_prod_idx] == &errcode)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
index 278dc13f3dae8..9fcf2e5e00039 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_mgmt.c
@@ -52,7 +52,7 @@

#define MSG_NOT_RESP 0xFFFF

-#define MGMT_MSG_TIMEOUT 1000
+#define MGMT_MSG_TIMEOUT 5000

#define mgmt_to_pfhwdev(pf_mgmt) \
container_of(pf_mgmt, struct hinic_pfhwdev, pf_to_mgmt)
@@ -276,7 +276,8 @@ static int msg_to_mgmt_sync(struct hinic_pf_to_mgmt *pf_to_mgmt,
goto unlock_sync_msg;
}

- if (!wait_for_completion_timeout(recv_done, MGMT_MSG_TIMEOUT)) {
+ if (!wait_for_completion_timeout(recv_done,
+ msecs_to_jiffies(MGMT_MSG_TIMEOUT))) {
dev_err(&pdev->dev, "MGMT timeout, MSG id = %d\n", msg_id);
err = -ETIMEDOUT;
goto unlock_sync_msg;
--
2.20.1



2020-04-16 17:50:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 007/146] cxgb4/ptp: pass the sign of offset delta in FW CMD

From: Raju Rangoju <[email protected]>

[ Upstream commit 50e0d28d3808146cc19b0d5564ef4ba9e5bf3846 ]

cxgb4_ptp_fineadjtime() doesn't pass the signedness of offset delta
in FW_PTP_CMD. Fix it by passing correct sign.

Signed-off-by: Raju Rangoju <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
index 9f9d6cae39d55..758f2b8363282 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
@@ -246,6 +246,9 @@ static int cxgb4_ptp_fineadjtime(struct adapter *adapter, s64 delta)
FW_PTP_CMD_PORTID_V(0));
c.retval_len16 = cpu_to_be32(FW_CMD_LEN16_V(sizeof(c) / 16));
c.u.ts.sc = FW_PTP_SC_ADJ_FTIME;
+ c.u.ts.sign = (delta < 0) ? 1 : 0;
+ if (delta < 0)
+ delta = -delta;
c.u.ts.tm = cpu_to_be64(delta);

err = t4_wr_mbox(adapter, adapter->mbox, &c, sizeof(c), NULL);
--
2.20.1



2020-04-16 17:51:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 047/146] ASoC: topology: use name_prefix for new kcontrol

From: 이경택 <[email protected]>

commit abca9e4a04fbe9c6df4d48ca7517e1611812af25 upstream.

Current topology doesn't add prefix of component to new kcontrol.

Signed-off-by: Gyeongtaek Lee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/soc-topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -364,7 +364,7 @@ static int soc_tplg_add_kcontrol(struct
struct snd_soc_component *comp = tplg->comp;

return soc_tplg_add_dcontrol(comp->card->snd_card,
- comp->dev, k, NULL, comp, kcontrol);
+ comp->dev, k, comp->name_prefix, comp, kcontrol);
}

/* remove a mixer kcontrol */


2020-04-16 17:51:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 049/146] usb: gadget: composite: Inform controller driver of self-powered

From: Thinh Nguyen <[email protected]>

commit 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c upstream.

Different configuration/condition may draw different power. Inform the
controller driver of the change so it can respond properly (e.g.
GET_STATUS request). This fixes an issue with setting MaxPower from
configfs. The composite driver doesn't check this value when setting
self-powered.

Cc: [email protected]
Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
Signed-off-by: Thinh Nguyen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/composite.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -847,6 +847,11 @@ static int set_config(struct usb_composi
else
power = min(power, 900U);
done:
+ if (power <= USB_SELF_POWER_VBUS_MAX_DRAW)
+ usb_gadget_set_selfpowered(gadget);
+ else
+ usb_gadget_clear_selfpowered(gadget);
+
usb_gadget_vbus_draw(gadget, power);
if (result >= 0 && cdev->delayed_status)
result = USB_GADGET_DELAYED_STATUS;
@@ -2265,6 +2270,7 @@ void composite_suspend(struct usb_gadget

cdev->suspended = 1;

+ usb_gadget_set_selfpowered(gadget);
usb_gadget_vbus_draw(gadget, 2);
}

@@ -2293,6 +2299,9 @@ void composite_resume(struct usb_gadget
else
maxpower = min(maxpower, 900U);

+ if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW)
+ usb_gadget_clear_selfpowered(gadget);
+
usb_gadget_vbus_draw(gadget, maxpower);
}



2020-04-16 17:51:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 050/146] ALSA: usb-audio: Add mixer workaround for TRX40 and co

From: Takashi Iwai <[email protected]>

commit 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 upstream.

Some recent boards (supposedly with a new AMD platform) contain the
USB audio class 2 device that is often tied with HD-audio. The device
exposes an Input Gain Pad control (id=19, control=12) but this node
doesn't behave correctly, returning an error for each inquiry of
GET_MIN and GET_MAX that should have been mandatory.

As a workaround, simply ignore this node by adding a usbmix_name_map
table entry. The currently known devices are:
* 0414:a002 - Gigabyte TRX40 Aorus Pro WiFi
* 0b05:1916 - ASUS ROG Zenith II
* 0b05:1917 - ASUS ROG Strix
* 0db0:0d64 - MSI TRX40 Creator
* 0db0:543d - MSI TRX40

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/usb/mixer_maps.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

--- a/sound/usb/mixer_maps.c
+++ b/sound/usb/mixer_maps.c
@@ -363,6 +363,14 @@ static const struct usbmix_name_map dell
{ 0 }
};

+/* Some mobos shipped with a dummy HD-audio show the invalid GET_MIN/GET_MAX
+ * response for Input Gain Pad (id=19, control=12). Skip it.
+ */
+static const struct usbmix_name_map asus_rog_map[] = {
+ { 19, NULL, 12 }, /* FU, Input Gain Pad */
+ {}
+};
+
/*
* Control map entries
*/
@@ -482,6 +490,26 @@ static struct usbmix_ctl_map usbmix_ctl_
.id = USB_ID(0x05a7, 0x1020),
.map = bose_companion5_map,
},
+ { /* Gigabyte TRX40 Aorus Pro WiFi */
+ .id = USB_ID(0x0414, 0xa002),
+ .map = asus_rog_map,
+ },
+ { /* ASUS ROG Zenith II */
+ .id = USB_ID(0x0b05, 0x1916),
+ .map = asus_rog_map,
+ },
+ { /* ASUS ROG Strix */
+ .id = USB_ID(0x0b05, 0x1917),
+ .map = asus_rog_map,
+ },
+ { /* MSI TRX40 Creator */
+ .id = USB_ID(0x0db0, 0x0d64),
+ .map = asus_rog_map,
+ },
+ { /* MSI TRX40 */
+ .id = USB_ID(0x0db0, 0x543d),
+ .map = asus_rog_map,
+ },
{ 0 } /* terminator */
};



2020-04-16 17:54:00

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 067/146] PCI: endpoint: Fix for concurrent memory allocation in OB address region

From: Kishon Vijay Abraham I <[email protected]>

commit 04e046ca57ebed3943422dee10eec9e73aec081e upstream.

pci-epc-mem uses a bitmap to manage the Endpoint outbound (OB) address
region. This address region will be shared by multiple endpoint
functions (in the case of multi function endpoint) and it has to be
protected from concurrent access to avoid updating an inconsistent state.

Use a mutex to protect bitmap updates to prevent the memory
allocation API from returning incorrect addresses.

Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: [email protected] # v4.14+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/endpoint/pci-epc-mem.c | 10 ++++++++--
include/linux/pci-epc.h | 3 +++
2 files changed, 11 insertions(+), 2 deletions(-)

--- a/drivers/pci/endpoint/pci-epc-mem.c
+++ b/drivers/pci/endpoint/pci-epc-mem.c
@@ -79,6 +79,7 @@ int __pci_epc_mem_init(struct pci_epc *e
mem->page_size = page_size;
mem->pages = pages;
mem->size = size;
+ mutex_init(&mem->lock);

epc->mem = mem;

@@ -122,7 +123,7 @@ void __iomem *pci_epc_mem_alloc_addr(str
phys_addr_t *phys_addr, size_t size)
{
int pageno;
- void __iomem *virt_addr;
+ void __iomem *virt_addr = NULL;
struct pci_epc_mem *mem = epc->mem;
unsigned int page_shift = ilog2(mem->page_size);
int order;
@@ -130,15 +131,18 @@ void __iomem *pci_epc_mem_alloc_addr(str
size = ALIGN(size, mem->page_size);
order = pci_epc_mem_get_order(mem, size);

+ mutex_lock(&mem->lock);
pageno = bitmap_find_free_region(mem->bitmap, mem->pages, order);
if (pageno < 0)
- return NULL;
+ goto ret;

*phys_addr = mem->phys_base + (pageno << page_shift);
virt_addr = ioremap(*phys_addr, size);
if (!virt_addr)
bitmap_release_region(mem->bitmap, pageno, order);

+ret:
+ mutex_unlock(&mem->lock);
return virt_addr;
}
EXPORT_SYMBOL_GPL(pci_epc_mem_alloc_addr);
@@ -164,7 +168,9 @@ void pci_epc_mem_free_addr(struct pci_ep
pageno = (phys_addr - mem->phys_base) >> page_shift;
size = ALIGN(size, mem->page_size);
order = pci_epc_mem_get_order(mem, size);
+ mutex_lock(&mem->lock);
bitmap_release_region(mem->bitmap, pageno, order);
+ mutex_unlock(&mem->lock);
}
EXPORT_SYMBOL_GPL(pci_epc_mem_free_addr);

--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -69,6 +69,7 @@ struct pci_epc_ops {
* @bitmap: bitmap to manage the PCI address space
* @pages: number of bits representing the address region
* @page_size: size of each page
+ * @lock: mutex to protect bitmap
*/
struct pci_epc_mem {
phys_addr_t phys_base;
@@ -76,6 +77,8 @@ struct pci_epc_mem {
unsigned long *bitmap;
size_t page_size;
int pages;
+ /* mutex to protect against concurrent access for memory allocation*/
+ struct mutex lock;
};

/**


2020-04-16 17:54:35

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 061/146] thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n

From: Martin Blumenstingl <[email protected]>

commit 3f5b9959041e0db6dacbea80bb833bff5900999f upstream.

When CONFIG_DEVFREQ_THERMAL is disabled all functions except
of_devfreq_cooling_register_power() were already inlined. Also inline
the last function to avoid compile errors when multiple drivers call
of_devfreq_cooling_register_power() when CONFIG_DEVFREQ_THERMAL is not
set. Compilation failed with the following message:
multiple definition of `of_devfreq_cooling_register_power'
(which then lists all usages of of_devfreq_cooling_register_power())

Thomas Zimmermann reported this problem [0] on a kernel config with
CONFIG_DRM_LIMA={m,y}, CONFIG_DRM_PANFROST={m,y} and
CONFIG_DEVFREQ_THERMAL=n after both, the lima and panfrost drivers
gained devfreq cooling support.

[0] https://www.spinics.net/lists/dri-devel/msg252825.html

Fixes: a76caf55e5b356 ("thermal: Add devfreq cooling")
Cc: [email protected]
Reported-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Tested-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/devfreq_cooling.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/linux/devfreq_cooling.h
+++ b/include/linux/devfreq_cooling.h
@@ -75,7 +75,7 @@ void devfreq_cooling_unregister(struct t

#else /* !CONFIG_DEVFREQ_THERMAL */

-struct thermal_cooling_device *
+static inline struct thermal_cooling_device *
of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
struct devfreq_cooling_power *dfc_power)
{


2020-04-16 17:59:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 112/146] fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()

From: Eric Biggers <[email protected]>

commit 26c5d78c976ca298e59a56f6101a97b618ba3539 upstream.

After request_module(), nothing is stopping the module from being
unloaded until someone takes a reference to it via try_get_module().

The WARN_ONCE() in get_fs_type() is thus user-reachable, via userspace
running 'rmmod' concurrently.

Since WARN_ONCE() is for kernel bugs only, not for user-reachable
situations, downgrade this warning to pr_warn_once().

Keep it printed once only, since the intent of this warning is to detect
a bug in modprobe at boot time. Printing the warning more than once
wouldn't really provide any useful extra information.

Fixes: 41124db869b7 ("fs: warn in case userspace lied about modprobe return")
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Reviewed-by: Jessica Yu <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jeff Vander Stoep <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: NeilBrown <[email protected]>
Cc: <[email protected]> [4.13+]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/filesystems.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -267,7 +267,9 @@ struct file_system_type *get_fs_type(con
fs = __get_fs_type(name, len);
if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
fs = __get_fs_type(name, len);
- WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
+ if (!fs)
+ pr_warn_once("request_module fs-%.*s succeeded, but still no fs?\n",
+ len, name);
}

if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {


2020-04-16 18:00:09

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 099/146] mm: Use fixed constant in page_frag_alloc instead of size + 1

From: Alexander Duyck <[email protected]>

commit 8644772637deb121f7ac2df690cbf83fa63d3b70 upstream.

This patch replaces the size + 1 value introduced with the recent fix for 1
byte allocs with a constant value.

The idea here is to reduce code overhead as the previous logic would have
to read size into a register, then increment it, and write it back to
whatever field was being used. By using a constant we can avoid those
memory reads and arithmetic operations in favor of just encoding the
maximum value into the operation itself.

Fixes: 2c2ade81741c ("mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs")
Signed-off-by: Alexander Duyck <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/page_alloc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4537,11 +4537,11 @@ refill:
/* Even if we own the page, we do not use atomic_set().
* This would break get_page_unless_zero() users.
*/
- page_ref_add(page, size);
+ page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);

/* reset page count bias and offset to start of new frag */
nc->pfmemalloc = page_is_pfmemalloc(page);
- nc->pagecnt_bias = size + 1;
+ nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
nc->offset = size;
}

@@ -4557,10 +4557,10 @@ refill:
size = nc->size;
#endif
/* OK, page count is 0, we can safely set it */
- set_page_count(page, size + 1);
+ set_page_count(page, PAGE_FRAG_CACHE_MAX_SIZE + 1);

/* reset page count bias and offset to start of new frag */
- nc->pagecnt_bias = size + 1;
+ nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
offset = size - fragsz;
}



2020-04-16 18:01:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 082/146] KVM: x86: Allocate new rmap and large page tracking when moving memslot

From: Sean Christopherson <[email protected]>

commit edd4fa37baa6ee8e44dc65523b27bd6fe44c94de upstream.

Reallocate a rmap array and recalcuate large page compatibility when
moving an existing memslot to correctly handle the alignment properties
of the new memslot. The number of rmap entries required at each level
is dependent on the alignment of the memslot's base gfn with respect to
that level, e.g. moving a large-page aligned memslot so that it becomes
unaligned will increase the number of rmap entries needed at the now
unaligned level.

Not updating the rmap array is the most obvious bug, as KVM accesses
garbage data beyond the end of the rmap. KVM interprets the bad data as
pointers, leading to non-canonical #GPs, unexpected #PFs, etc...

general protection fault: 0000 [#1] SMP
CPU: 0 PID: 1909 Comm: move_memory_reg Not tainted 5.4.0-rc7+ #139
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:rmap_get_first+0x37/0x50 [kvm]
Code: <48> 8b 3b 48 85 ff 74 ec e8 6c f4 ff ff 85 c0 74 e3 48 89 d8 5b c3
RSP: 0018:ffffc9000021bbc8 EFLAGS: 00010246
RAX: ffff00617461642e RBX: ffff00617461642e RCX: 0000000000000012
RDX: ffff88827400f568 RSI: ffffc9000021bbe0 RDI: ffff88827400f570
RBP: 0010000000000000 R08: ffffc9000021bd00 R09: ffffc9000021bda8
R10: ffffc9000021bc48 R11: 0000000000000000 R12: 0030000000000000
R13: 0000000000000000 R14: ffff88827427d700 R15: ffffc9000021bce8
FS: 00007f7eda014700(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7ed9216ff8 CR3: 0000000274391003 CR4: 0000000000162eb0
Call Trace:
kvm_mmu_slot_set_dirty+0xa1/0x150 [kvm]
__kvm_set_memory_region.part.64+0x559/0x960 [kvm]
kvm_set_memory_region+0x45/0x60 [kvm]
kvm_vm_ioctl+0x30f/0x920 [kvm]
do_vfs_ioctl+0xa1/0x620
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x4c/0x170
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f7ed9911f47
Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 21 6f 2c 00 f7 d8 64 89 01 48
RSP: 002b:00007ffc00937498 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000001ab0010 RCX: 00007f7ed9911f47
RDX: 0000000001ab1350 RSI: 000000004020ae46 RDI: 0000000000000004
RBP: 000000000000000a R08: 0000000000000000 R09: 00007f7ed9214700
R10: 00007f7ed92149d0 R11: 0000000000000246 R12: 00000000bffff000
R13: 0000000000000003 R14: 00007f7ed9215000 R15: 0000000000000000
Modules linked in: kvm_intel kvm irqbypass
---[ end trace 0c5f570b3358ca89 ]---

The disallow_lpage tracking is more subtle. Failure to update results
in KVM creating large pages when it shouldn't, either due to stale data
or again due to indexing beyond the end of the metadata arrays, which
can lead to memory corruption and/or leaking data to guest/userspace.

Note, the arrays for the old memslot are freed by the unconditional call
to kvm_free_memslot() in __kvm_set_memory_region().

Fixes: 05da45583de9b ("KVM: MMU: large page support")
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9229,6 +9229,13 @@ int kvm_arch_create_memslot(struct kvm *
{
int i;

+ /*
+ * Clear out the previous array pointers for the KVM_MR_MOVE case. The
+ * old arrays will be freed by __kvm_set_memory_region() if installing
+ * the new memslot is successful.
+ */
+ memset(&slot->arch, 0, sizeof(slot->arch));
+
for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) {
struct kvm_lpage_info *linfo;
unsigned long ugfn;
@@ -9303,6 +9310,10 @@ int kvm_arch_prepare_memory_region(struc
const struct kvm_userspace_memory_region *mem,
enum kvm_mr_change change)
{
+ if (change == KVM_MR_MOVE)
+ return kvm_arch_create_memslot(kvm, memslot,
+ mem->memory_size >> PAGE_SHIFT);
+
return 0;
}



2020-04-16 19:37:46

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 023/146] media: i2c: video-i2c: fix build errors due to imply hwmon

From: Matt Ranostay <[email protected]>

[ Upstream commit 64d4fc9926f09861a35d8f0f7d81f056e6d5af7b ]

Fix build fault when CONFIG_HWMON is a module, and CONFIG_VIDEO_I2C
as builtin. This is due to 'imply hwmon' in the respective Kconfig.

Issue build log:

ld: drivers/media/i2c/video-i2c.o: in function `amg88xx_hwmon_init':
video-i2c.c:(.text+0x2e1): undefined reference to `devm_hwmon_device_register_with_info

Cc: [email protected]
Fixes: acbea6798955 (media: video-i2c: add hwmon support for amg88xx)
Signed-off-by: Matt Ranostay <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/media/i2c/video-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
index f27d294dcbef5..dd50acc085d89 100644
--- a/drivers/media/i2c/video-i2c.c
+++ b/drivers/media/i2c/video-i2c.c
@@ -105,7 +105,7 @@ static int amg88xx_xfer(struct video_i2c_data *data, char *buf)
return (ret == 2) ? 0 : -EIO;
}

-#if IS_ENABLED(CONFIG_HWMON)
+#if IS_REACHABLE(CONFIG_HWMON)

static const u32 amg88xx_temp_config[] = {
HWMON_T_INPUT,
--
2.20.1



2020-04-16 19:38:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 044/146] ASoC: fix regwmask

From: 이경택 <[email protected]>

commit 0ab070917afdc93670c2d0ea02ab6defb6246a7c upstream.

If regwshift is 32 and the selected architecture compiles '<<' operator
for signed int literal into rotating shift, '1<<regwshift' became 1 and
it makes regwmask to 0x0.
The literal is set to unsigned long to get intended regwmask.

Signed-off-by: Gyeongtaek Lee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/soc-ops.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -832,7 +832,7 @@ int snd_soc_get_xr_sx(struct snd_kcontro
unsigned int regbase = mc->regbase;
unsigned int regcount = mc->regcount;
unsigned int regwshift = component->val_bytes * BITS_PER_BYTE;
- unsigned int regwmask = (1<<regwshift)-1;
+ unsigned int regwmask = (1UL<<regwshift)-1;
unsigned int invert = mc->invert;
unsigned long mask = (1UL<<mc->nbits)-1;
long min = mc->min;
@@ -881,7 +881,7 @@ int snd_soc_put_xr_sx(struct snd_kcontro
unsigned int regbase = mc->regbase;
unsigned int regcount = mc->regcount;
unsigned int regwshift = component->val_bytes * BITS_PER_BYTE;
- unsigned int regwmask = (1<<regwshift)-1;
+ unsigned int regwmask = (1UL<<regwshift)-1;
unsigned int invert = mc->invert;
unsigned long mask = (1UL<<mc->nbits)-1;
long max = mc->max;


2020-04-16 19:39:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 052/146] ALSA: hda: Fix potential access overflow in beep helper

From: Takashi Iwai <[email protected]>

commit 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a upstream.

The beep control helper function blindly stores the values in two
stereo channels no matter whether the actual control is mono or
stereo. This is practically harmless, but it annoys the recently
introduced sanity check, resulting in an error when the checker is
enabled.

This patch corrects the behavior to store only on the defined array
member.

Fixes: 0401e8548eac ("ALSA: hda - Move beep helper functions to hda_beep.c")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
Reviewed-by: Jaroslav Kysela <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/hda_beep.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/hda_beep.c
+++ b/sound/pci/hda/hda_beep.c
@@ -297,8 +297,12 @@ int snd_hda_mixer_amp_switch_get_beep(st
{
struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
struct hda_beep *beep = codec->beep;
+ int chs = get_amp_channels(kcontrol);
+
if (beep && (!beep->enabled || !ctl_has_mute(kcontrol))) {
- ucontrol->value.integer.value[0] =
+ if (chs & 1)
+ ucontrol->value.integer.value[0] = beep->enabled;
+ if (chs & 2)
ucontrol->value.integer.value[1] = beep->enabled;
return 0;
}


2020-04-16 19:39:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 056/146] ALSA: hda/realtek - Set principled PC Beep configuration for ALC256

From: Thomas Hebb <[email protected]>

commit c44737449468a0bdc50e09ec75e530f208391561 upstream.

The Realtek PC Beep Hidden Register[1] is currently set by
patch_realtek.c in two different places:

In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to
non-beep input on 1Ah and no 1Ah loopback to either headphones or
speakers. (Although, curiously, the loopback amp is still enabled.) This
write was added fairly recently by commit e3743f431143 ("ALSA:
hda/realtek - Dell headphone has noise on unmute for ALC236") and is a
safe default. However, it happens in the wrong place:
alc_fill_eapd_coef() runs on module load and cold boot but not on S3
resume, meaning the register loses its value after suspend.

Conversely, in alc256_init(), the register is updated to unset bit 13
(disable speaker loopback) and set bit 5 (set non-beep input on 1Ah).
Although this write does run on S3 resume, it's not quite enough to fix
up the register's default value of 0x3717. What's missing is a set of
bit 14 to disable headphone loopback. Without that, we end up with a
feedback loop where the headphone jack is being driven by amplified
samples of itself[2].

This change eliminates the update in alc256_init() and replaces it with
the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is
supposed to be the codec's default value, so using it will make
debugging easier for Realtek.

Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs.

[1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst

[2] Setting the "Headphone Mic Boost" control from userspace changes
this feedback loop and has been a widely-shared workaround for headphone
noise on laptops like the Dell XPS 13 9350. This commit eliminates the
feedback loop and makes the workaround unnecessary.

Fixes: e1e8c1fdce8b ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236")
Cc: [email protected]
Signed-off-by: Thomas Hebb <[email protected]>
Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.com
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -379,7 +379,9 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0215:
case 0x10ec0233:
case 0x10ec0235:
+ case 0x10ec0236:
case 0x10ec0255:
+ case 0x10ec0256:
case 0x10ec0257:
case 0x10ec0282:
case 0x10ec0283:
@@ -391,11 +393,6 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0300:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
- case 0x10ec0236:
- case 0x10ec0256:
- alc_write_coef_idx(codec, 0x36, 0x5757);
- alc_update_coef_idx(codec, 0x10, 1<<9, 0);
- break;
case 0x10ec0275:
alc_update_coef_idx(codec, 0xe, 0, 1<<0);
break;
@@ -3249,7 +3246,13 @@ static void alc256_init(struct hda_codec
alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
- alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/
+ /*
+ * Expose headphone mic (or possibly Line In on some machines) instead
+ * of PC Beep on 1Ah, and disable 1Ah loopback for all outputs. See
+ * Documentation/sound/hd-audio/realtek-pc-beep.rst for details of
+ * this register.
+ */
+ alc_write_coef_idx(codec, 0x36, 0x5757);
}

static void alc256_shutup(struct hda_codec *codec)


2020-04-16 19:39:30

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 069/146] tpm: tpm1_bios_measurements_next should increase position index

From: Vasily Averin <[email protected]>

commit d7a47b96ed1102551eb7325f97937e276fb91045 upstream.

If .next function does not change position index,
following .show function will repeat output related
to current position index.

In case of /sys/kernel/security/tpm0/ascii_bios_measurements
and binary_bios_measurements:
1) read after lseek beyound end of file generates whole last line.
2) read after lseek to middle of last line generates
expected end of last line and unexpected whole last line once again.

Cc: [email protected] # 4.19.x
Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/tpm/eventlog/tpm1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/tpm/eventlog/tpm1.c
+++ b/drivers/char/tpm/eventlog/tpm1.c
@@ -129,6 +129,7 @@ static void *tpm1_bios_measurements_next
u32 converted_event_size;
u32 converted_event_type;

+ (*pos)++;
converted_event_size = do_endian_conversion(event->event_size);

v += sizeof(struct tcpa_event) + converted_event_size;
@@ -146,7 +147,6 @@ static void *tpm1_bios_measurements_next
((v + sizeof(struct tcpa_event) + converted_event_size) >= limit))
return NULL;

- (*pos)++;
return v;
}



2020-04-16 19:39:59

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 068/146] tpm: Dont make log failures fatal

From: Matthew Garrett <[email protected]>

commit 805fa88e0780b7ce1cc9b649dd91a0a7164c6eb4 upstream.

If a TPM is in disabled state, it's reasonable for it to have an empty
log. Bailing out of probe in this case means that the PPI interface
isn't available, so there's no way to then enable the TPM from the OS.
In general it seems reasonable to ignore log errors - they shouldn't
interfere with any other TPM functionality.

Signed-off-by: Matthew Garrett <[email protected]>
Cc: [email protected] # 4.19.x
Reviewed-by: Jerry Snitselaar <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/tpm/eventlog/common.c | 12 ++++--------
drivers/char/tpm/tpm-chip.c | 4 +---
drivers/char/tpm/tpm.h | 2 +-
3 files changed, 6 insertions(+), 12 deletions(-)

--- a/drivers/char/tpm/eventlog/common.c
+++ b/drivers/char/tpm/eventlog/common.c
@@ -104,11 +104,8 @@ static int tpm_read_log(struct tpm_chip
*
* If an event log is found then the securityfs files are setup to
* export it to userspace, otherwise nothing is done.
- *
- * Returns -ENODEV if the firmware has no event log or securityfs is not
- * supported.
*/
-int tpm_bios_log_setup(struct tpm_chip *chip)
+void tpm_bios_log_setup(struct tpm_chip *chip)
{
const char *name = dev_name(&chip->dev);
unsigned int cnt;
@@ -117,7 +114,7 @@ int tpm_bios_log_setup(struct tpm_chip *

rc = tpm_read_log(chip);
if (rc < 0)
- return rc;
+ return;
log_version = rc;

cnt = 0;
@@ -163,13 +160,12 @@ int tpm_bios_log_setup(struct tpm_chip *
cnt++;
}

- return 0;
+ return;

err:
- rc = PTR_ERR(chip->bios_dir[cnt]);
chip->bios_dir[cnt] = NULL;
tpm_bios_log_teardown(chip);
- return rc;
+ return;
}

void tpm_bios_log_teardown(struct tpm_chip *chip)
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -463,9 +463,7 @@ int tpm_chip_register(struct tpm_chip *c

tpm_sysfs_add_device(chip);

- rc = tpm_bios_log_setup(chip);
- if (rc != 0 && rc != -ENODEV)
- return rc;
+ tpm_bios_log_setup(chip);

tpm_add_ppi(chip);

--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -602,6 +602,6 @@ int tpm2_prepare_space(struct tpm_chip *
int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
u32 cc, u8 *buf, size_t *bufsiz);

-int tpm_bios_log_setup(struct tpm_chip *chip);
+void tpm_bios_log_setup(struct tpm_chip *chip);
void tpm_bios_log_teardown(struct tpm_chip *chip);
#endif


2020-04-16 19:40:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 072/146] irqchip/versatile-fpga: Apply clear-mask earlier

From: Sungbo Eo <[email protected]>

commit 6a214a28132f19ace3d835a6d8f6422ec80ad200 upstream.

Clear its own IRQs before the parent IRQ get enabled, so that the
remaining IRQs do not accidentally interrupt the parent IRQ controller.

This patch also fixes a reboot bug on OX820 SoC, where the remaining
rps-timer IRQ raises a GIC interrupt that is left pending. After that,
the rps-timer IRQ is cleared during driver initialization, and there's
no IRQ left in rps-irq when local_irq_enable() is called, which evokes
an error message "unexpected IRQ trap".

Fixes: bdd272cbb97a ("irqchip: versatile FPGA: support cascaded interrupts from DT")
Signed-off-by: Sungbo Eo <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/irqchip/irq-versatile-fpga.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -212,6 +212,9 @@ int __init fpga_irq_of_init(struct devic
if (of_property_read_u32(node, "valid-mask", &valid_mask))
valid_mask = 0;

+ writel(clear_mask, base + IRQ_ENABLE_CLEAR);
+ writel(clear_mask, base + FIQ_ENABLE_CLEAR);
+
/* Some chips are cascaded from a parent IRQ */
parent_irq = irq_of_parse_and_map(node, 0);
if (!parent_irq) {
@@ -221,9 +224,6 @@ int __init fpga_irq_of_init(struct devic

fpga_irq_init(base, node->name, 0, parent_irq, valid_mask, node);

- writel(clear_mask, base + IRQ_ENABLE_CLEAR);
- writel(clear_mask, base + FIQ_ENABLE_CLEAR);
-
/*
* On Versatile AB/PB, some secondary interrupts have a direct
* pass-thru to the primary controller for IRQs 20 and 22-31 which need


2020-04-16 19:40:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 037/146] block, bfq: fix use-after-free in bfq_idle_slice_timer_body

From: Zhiqiang Liu <[email protected]>

[ Upstream commit 2f95fa5c955d0a9987ffdc3a095e2f4e62c5f2a9 ]

In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is
not in bfqd-lock critical section. The bfqq, which is not
equal to NULL in bfq_idle_slice_timer, may be freed after passing
to bfq_idle_slice_timer_body. So we will access the freed memory.

In addition, considering the bfqq may be in race, we should
firstly check whether bfqq is in service before doing something
on it in bfq_idle_slice_timer_body func. If the bfqq in race is
not in service, it means the bfqq has been expired through
__bfq_bfqq_expire func, and wait_request flags has been cleared in
__bfq_bfqd_reset_in_service func. So we do not need to re-clear the
wait_request of bfqq which is not in service.

KASAN log is given as follows:
[13058.354613] ==================================================================
[13058.354640] BUG: KASAN: use-after-free in bfq_idle_slice_timer+0xac/0x290
[13058.354644] Read of size 8 at addr ffffa02cf3e63f78 by task fork13/19767
[13058.354646]
[13058.354655] CPU: 96 PID: 19767 Comm: fork13
[13058.354661] Call trace:
[13058.354667] dump_backtrace+0x0/0x310
[13058.354672] show_stack+0x28/0x38
[13058.354681] dump_stack+0xd8/0x108
[13058.354687] print_address_description+0x68/0x2d0
[13058.354690] kasan_report+0x124/0x2e0
[13058.354697] __asan_load8+0x88/0xb0
[13058.354702] bfq_idle_slice_timer+0xac/0x290
[13058.354707] __hrtimer_run_queues+0x298/0x8b8
[13058.354710] hrtimer_interrupt+0x1b8/0x678
[13058.354716] arch_timer_handler_phys+0x4c/0x78
[13058.354722] handle_percpu_devid_irq+0xf0/0x558
[13058.354731] generic_handle_irq+0x50/0x70
[13058.354735] __handle_domain_irq+0x94/0x110
[13058.354739] gic_handle_irq+0x8c/0x1b0
[13058.354742] el1_irq+0xb8/0x140
[13058.354748] do_wp_page+0x260/0xe28
[13058.354752] __handle_mm_fault+0x8ec/0x9b0
[13058.354756] handle_mm_fault+0x280/0x460
[13058.354762] do_page_fault+0x3ec/0x890
[13058.354765] do_mem_abort+0xc0/0x1b0
[13058.354768] el0_da+0x24/0x28
[13058.354770]
[13058.354773] Allocated by task 19731:
[13058.354780] kasan_kmalloc+0xe0/0x190
[13058.354784] kasan_slab_alloc+0x14/0x20
[13058.354788] kmem_cache_alloc_node+0x130/0x440
[13058.354793] bfq_get_queue+0x138/0x858
[13058.354797] bfq_get_bfqq_handle_split+0xd4/0x328
[13058.354801] bfq_init_rq+0x1f4/0x1180
[13058.354806] bfq_insert_requests+0x264/0x1c98
[13058.354811] blk_mq_sched_insert_requests+0x1c4/0x488
[13058.354818] blk_mq_flush_plug_list+0x2d4/0x6e0
[13058.354826] blk_flush_plug_list+0x230/0x548
[13058.354830] blk_finish_plug+0x60/0x80
[13058.354838] read_pages+0xec/0x2c0
[13058.354842] __do_page_cache_readahead+0x374/0x438
[13058.354846] ondemand_readahead+0x24c/0x6b0
[13058.354851] page_cache_sync_readahead+0x17c/0x2f8
[13058.354858] generic_file_buffered_read+0x588/0xc58
[13058.354862] generic_file_read_iter+0x1b4/0x278
[13058.354965] ext4_file_read_iter+0xa8/0x1d8 [ext4]
[13058.354972] __vfs_read+0x238/0x320
[13058.354976] vfs_read+0xbc/0x1c0
[13058.354980] ksys_read+0xdc/0x1b8
[13058.354984] __arm64_sys_read+0x50/0x60
[13058.354990] el0_svc_common+0xb4/0x1d8
[13058.354994] el0_svc_handler+0x50/0xa8
[13058.354998] el0_svc+0x8/0xc
[13058.354999]
[13058.355001] Freed by task 19731:
[13058.355007] __kasan_slab_free+0x120/0x228
[13058.355010] kasan_slab_free+0x10/0x18
[13058.355014] kmem_cache_free+0x288/0x3f0
[13058.355018] bfq_put_queue+0x134/0x208
[13058.355022] bfq_exit_icq_bfqq+0x164/0x348
[13058.355026] bfq_exit_icq+0x28/0x40
[13058.355030] ioc_exit_icq+0xa0/0x150
[13058.355035] put_io_context_active+0x250/0x438
[13058.355038] exit_io_context+0xd0/0x138
[13058.355045] do_exit+0x734/0xc58
[13058.355050] do_group_exit+0x78/0x220
[13058.355054] __wake_up_parent+0x0/0x50
[13058.355058] el0_svc_common+0xb4/0x1d8
[13058.355062] el0_svc_handler+0x50/0xa8
[13058.355066] el0_svc+0x8/0xc
[13058.355067]
[13058.355071] The buggy address belongs to the object at ffffa02cf3e63e70#012 which belongs to the cache bfq_queue of size 464
[13058.355075] The buggy address is located 264 bytes inside of#012 464-byte region [ffffa02cf3e63e70, ffffa02cf3e64040)
[13058.355077] The buggy address belongs to the page:
[13058.355083] page:ffff7e80b3cf9800 count:1 mapcount:0 mapping:ffff802db5c90780 index:0xffffa02cf3e606f0 compound_mapcount: 0
[13058.366175] flags: 0x2ffffe0000008100(slab|head)
[13058.370781] raw: 2ffffe0000008100 ffff7e80b53b1408 ffffa02d730c1c90 ffff802db5c90780
[13058.370787] raw: ffffa02cf3e606f0 0000000000370023 00000001ffffffff 0000000000000000
[13058.370789] page dumped because: kasan: bad access detected
[13058.370791]
[13058.370792] Memory state around the buggy address:
[13058.370797] ffffa02cf3e63e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb
[13058.370801] ffffa02cf3e63e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370805] >ffffa02cf3e63f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370808] ^
[13058.370811] ffffa02cf3e63f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[13058.370815] ffffa02cf3e64000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[13058.370817] ==================================================================
[13058.370820] Disabling lock debugging due to kernel taint

Here, we directly pass the bfqd to bfq_idle_slice_timer_body func.
--
V2->V3: rewrite the comment as suggested by Paolo Valente
V1->V2: add one comment, and add Fixes and Reported-by tag.

Fixes: aee69d78d ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler")
Acked-by: Paolo Valente <[email protected]>
Reported-by: Wang Wang <[email protected]>
Signed-off-by: Zhiqiang Liu <[email protected]>
Signed-off-by: Feilong Lin <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
block/bfq-iosched.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 66b1ebc21ce4f..5198ed1b36690 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5156,20 +5156,28 @@ static struct bfq_queue *bfq_init_rq(struct request *rq)
return bfqq;
}

-static void bfq_idle_slice_timer_body(struct bfq_queue *bfqq)
+static void
+bfq_idle_slice_timer_body(struct bfq_data *bfqd, struct bfq_queue *bfqq)
{
- struct bfq_data *bfqd = bfqq->bfqd;
enum bfqq_expiration reason;
unsigned long flags;

spin_lock_irqsave(&bfqd->lock, flags);
- bfq_clear_bfqq_wait_request(bfqq);

+ /*
+ * Considering that bfqq may be in race, we should firstly check
+ * whether bfqq is in service before doing something on it. If
+ * the bfqq in race is not in service, it has already been expired
+ * through __bfq_bfqq_expire func and its wait_request flags has
+ * been cleared in __bfq_bfqd_reset_in_service func.
+ */
if (bfqq != bfqd->in_service_queue) {
spin_unlock_irqrestore(&bfqd->lock, flags);
return;
}

+ bfq_clear_bfqq_wait_request(bfqq);
+
if (bfq_bfqq_budget_timeout(bfqq))
/*
* Also here the queue can be safely expired
@@ -5214,7 +5222,7 @@ static enum hrtimer_restart bfq_idle_slice_timer(struct hrtimer *timer)
* early.
*/
if (bfqq)
- bfq_idle_slice_timer_body(bfqq);
+ bfq_idle_slice_timer_body(bfqd, bfqq);

return HRTIMER_NORESTART;
}
--
2.20.1



2020-04-16 19:47:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 085/146] KVM: VMX: fix crash cleanup when KVM wasnt used

From: Vitaly Kuznetsov <[email protected]>

commit dbef2808af6c594922fe32833b30f55f35e9da6d upstream.

If KVM wasn't used at all before we crash the cleanup procedure fails with
BUG: unable to handle page fault for address: ffffffffffffffc8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 23215067 P4D 23215067 PUD 23217067 PMD 0
Oops: 0000 [#8] SMP PTI
CPU: 0 PID: 3542 Comm: bash Kdump: loaded Tainted: G D 5.6.0-rc2+ #823
RIP: 0010:crash_vmclear_local_loaded_vmcss.cold+0x19/0x51 [kvm_intel]

The root cause is that loaded_vmcss_on_cpu list is not yet initialized,
we initialize it in hardware_enable() but this only happens when we start
a VM.

Previously, we used to have a bitmap with enabled CPUs and that was
preventing [masking] the issue.

Initialized loaded_vmcss_on_cpu list earlier, right before we assign
crash_vmclear_loaded_vmcss pointer. blocked_vcpu_on_cpu list and
blocked_vcpu_on_cpu_lock are moved altogether for consistency.

Fixes: 31603d4fc2bb ("KVM: VMX: Always VMCLEAR in-use VMCSes during crash with kexec support")
Signed-off-by: Vitaly Kuznetsov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Sean Christopherson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/vmx.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4398,10 +4398,6 @@ static int hardware_enable(void)
!hv_get_vp_assist_page(cpu))
return -EFAULT;

- INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
- INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
- spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
-
rdmsrl(MSR_IA32_FEATURE_CONTROL, old);

test_bits = FEATURE_CONTROL_LOCKED;
@@ -14554,7 +14550,7 @@ module_exit(vmx_exit);

static int __init vmx_init(void)
{
- int r;
+ int r, cpu;

#if IS_ENABLED(CONFIG_HYPERV)
/*
@@ -14605,6 +14601,12 @@ static int __init vmx_init(void)
}
}

+ for_each_possible_cpu(cpu) {
+ INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
+ INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
+ spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
+ }
+
#ifdef CONFIG_KEXEC_CORE
rcu_assign_pointer(crash_vmclear_loaded_vmcss,
crash_vmclear_local_loaded_vmcss);


2020-04-16 19:47:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 076/146] ath9k: Handle txpower changes even when TPC is disabled

From: Remi Pommarel <[email protected]>

commit 968ae2caad0782db5dbbabb560d3cdefd2945d38 upstream.

When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to
reconfigure HW's maximum txpower.

This fixes 0dBm txpower setting when user attaches to an interface for
the first time with the following scenario:

ieee80211_do_open()
ath9k_add_interface()
ath9k_set_txpower() /* Set TX power with not yet initialized
sc->hw->conf.power_level */

ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and
raise IEEE80211_CONF_CHANGE_POWER */

ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */

This issue can be reproduced with the following:

$ modprobe -r ath9k
$ modprobe ath9k
$ wpa_supplicant -i wlan0 -c /tmp/wpa.conf &
$ iw dev /* Here TX power is either 0 or 3 depending on RF chain */
$ killall wpa_supplicant
$ iw dev /* TX power goes back to calibrated value and subsequent
calls will be fine */

Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability")
Cc: [email protected]
Signed-off-by: Remi Pommarel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/main.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1457,6 +1457,9 @@ static int ath9k_config(struct ieee80211
ath_chanctx_set_channel(sc, ctx, &hw->conf.chandef);
}

+ if (changed & IEEE80211_CONF_CHANGE_POWER)
+ ath9k_set_txpower(sc, NULL);
+
mutex_unlock(&sc->mutex);
ath9k_ps_restore(sc);



2020-04-16 19:48:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 095/146] erofs: correct the remaining shrink objects

From: Gao Xiang <[email protected]>

commit 9d5a09c6f3b5fb85af20e3a34827b5d27d152b34 upstream.

The remaining count should not include successful
shrink attempts.

Fixes: e7e9a307be9d ("staging: erofs: introduce workstation for decompression")
Cc: <[email protected]> # 4.19+
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Chao Yu <[email protected]>
Signed-off-by: Gao Xiang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/staging/erofs/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -309,7 +309,7 @@ unsigned long erofs_shrink_scan(struct s
sbi->shrinker_run_no = run_no;

#ifdef CONFIG_EROFS_FS_ZIP
- freed += erofs_shrink_workstation(sbi, nr, false);
+ freed += erofs_shrink_workstation(sbi, nr - freed, false);
#endif

spin_lock(&erofs_sb_list_lock);


2020-04-16 19:48:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 098/146] tools: gpio: Fix out-of-tree build regression

From: Anssi Hannula <[email protected]>

commit 82f04bfe2aff428b063eefd234679b2d693228ed upstream.

Commit 0161a94e2d1c7 ("tools: gpio: Correctly add make dependencies for
gpio_utils") added a make rule for gpio-utils-in.o but used $(output)
instead of the correct $(OUTPUT) for the output directory, breaking
out-of-tree build (O=xx) with the following error:

No rule to make target 'out/tools/gpio/gpio-utils-in.o', needed by 'out/tools/gpio/lsgpio-in.o'. Stop.

Fix that.

Fixes: 0161a94e2d1c ("tools: gpio: Correctly add make dependencies for gpio_utils")
Cc: <[email protected]>
Cc: Laura Abbott <[email protected]>
Signed-off-by: Anssi Hannula <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/gpio/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/gpio/Makefile
+++ b/tools/gpio/Makefile
@@ -35,7 +35,7 @@ $(OUTPUT)include/linux/gpio.h: ../../inc

prepare: $(OUTPUT)include/linux/gpio.h

-GPIO_UTILS_IN := $(output)gpio-utils-in.o
+GPIO_UTILS_IN := $(OUTPUT)gpio-utils-in.o
$(GPIO_UTILS_IN): prepare FORCE
$(Q)$(MAKE) $(build)=gpio-utils



2020-04-16 19:48:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 087/146] mtd: spinand: Stop using spinand->oobbuf for buffering bad block markers

From: Frieder Schrempf <[email protected]>

commit 2148937501ee3d663e0010e519a553fea67ad103 upstream.

For reading and writing the bad block markers, spinand->oobbuf is
currently used as a buffer for the marker bytes. During the
underlying read and write operations to actually get/set the content
of the OOB area, the content of spinand->oobbuf is reused and changed
by accessing it through spinand->oobbuf and/or spinand->databuf.

This is a flaw in the original design of the SPI NAND core and at the
latest from 13c15e07eedf ("mtd: spinand: Handle the case where
PROGRAM LOAD does not reset the cache") on, it results in not having
the bad block marker written at all, as the spinand->oobbuf is
cleared to 0xff after setting the marker bytes to zero.

To fix it, we now just store the two bytes for the marker on the
stack and let the read/write operations copy it from/to the page
buffer later.

Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Cc: [email protected]
Signed-off-by: Frieder Schrempf <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mtd/nand/spi/core.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -629,18 +629,18 @@ static int spinand_mtd_write(struct mtd_
static bool spinand_isbad(struct nand_device *nand, const struct nand_pos *pos)
{
struct spinand_device *spinand = nand_to_spinand(nand);
+ u8 marker[2] = { };
struct nand_page_io_req req = {
.pos = *pos,
- .ooblen = 2,
+ .ooblen = sizeof(marker),
.ooboffs = 0,
- .oobbuf.in = spinand->oobbuf,
+ .oobbuf.in = marker,
.mode = MTD_OPS_RAW,
};

- memset(spinand->oobbuf, 0, 2);
spinand_select_target(spinand, pos->target);
spinand_read_page(spinand, &req, false);
- if (spinand->oobbuf[0] != 0xff || spinand->oobbuf[1] != 0xff)
+ if (marker[0] != 0xff || marker[1] != 0xff)
return true;

return false;
@@ -664,11 +664,12 @@ static int spinand_mtd_block_isbad(struc
static int spinand_markbad(struct nand_device *nand, const struct nand_pos *pos)
{
struct spinand_device *spinand = nand_to_spinand(nand);
+ u8 marker[2] = { };
struct nand_page_io_req req = {
.pos = *pos,
.ooboffs = 0,
- .ooblen = 2,
- .oobbuf.out = spinand->oobbuf,
+ .ooblen = sizeof(marker),
+ .oobbuf.out = marker,
};
int ret;

@@ -683,7 +684,6 @@ static int spinand_markbad(struct nand_d

spinand_erase_op(spinand, pos);

- memset(spinand->oobbuf, 0, 2);
return spinand_write_page(spinand, &req);
}



2020-04-16 19:50:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 103/146] dm verity fec: fix memory leak in verity_fec_dtr

From: Shetty, Harshini X (EXT-Sony Mobile) <[email protected]>

commit 75fa601934fda23d2f15bf44b09c2401942d8e15 upstream.

Fix below kmemleak detected in verity_fec_ctr. output_pool is
allocated for each dm-verity-fec device. But it is not freed when
dm-table for the verity target is removed. Hence free the output
mempool in destructor function verity_fec_dtr.

unreferenced object 0xffffffffa574d000 (size 4096):
comm "init", pid 1667, jiffies 4294894890 (age 307.168s)
hex dump (first 32 bytes):
8e 36 00 98 66 a8 0b 9b 00 00 00 00 00 00 00 00 .6..f...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000060e82407>] __kmalloc+0x2b4/0x340
[<00000000dd99488f>] mempool_kmalloc+0x18/0x20
[<000000002560172b>] mempool_init_node+0x98/0x118
[<000000006c3574d2>] mempool_init+0x14/0x20
[<0000000008cb266e>] verity_fec_ctr+0x388/0x3b0
[<000000000887261b>] verity_ctr+0x87c/0x8d0
[<000000002b1e1c62>] dm_table_add_target+0x174/0x348
[<000000002ad89eda>] table_load+0xe4/0x328
[<000000001f06f5e9>] dm_ctl_ioctl+0x3b4/0x5a0
[<00000000bee5fbb7>] do_vfs_ioctl+0x5dc/0x928
[<00000000b475b8f5>] __arm64_sys_ioctl+0x70/0x98
[<000000005361e2e8>] el0_svc_common+0xa0/0x158
[<000000001374818f>] el0_svc_handler+0x6c/0x88
[<000000003364e9f4>] el0_svc+0x8/0xc
[<000000009d84cec9>] 0xffffffffffffffff

Fixes: a739ff3f543af ("dm verity: add support for forward error correction")
Depends-on: 6f1c819c219f7 ("dm: convert to bioset_init()/mempool_init()")
Cc: [email protected]
Signed-off-by: Harshini Shetty <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/dm-verity-fec.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -552,6 +552,7 @@ void verity_fec_dtr(struct dm_verity *v)
mempool_exit(&f->rs_pool);
mempool_exit(&f->prealloc_pool);
mempool_exit(&f->extra_pool);
+ mempool_exit(&f->output_pool);
kmem_cache_destroy(f->cache);

if (f->data_bufio)


2020-04-16 19:57:07

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 078/146] x86/entry/32: Add missing ASM_CLAC to general_protection entry

From: Thomas Gleixner <[email protected]>

commit 3d51507f29f2153a658df4a0674ec5b592b62085 upstream.

All exception entry points must have ASM_CLAC right at the
beginning. The general_protection entry is missing one.

Fixes: e59d1b0a2419 ("x86-32, smap: Add STAC/CLAC instructions to 32-bit kernel entry")
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Frederic Weisbecker <[email protected]>
Reviewed-by: Alexandre Chartre <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/entry/entry_32.S | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1489,6 +1489,7 @@ ENTRY(int3)
END(int3)

ENTRY(general_protection)
+ ASM_CLAC
pushl $do_general_protection
jmp common_exception
END(general_protection)


2020-04-16 19:57:46

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 111/146] ext4: fix a data race at inode->i_blocks

From: Qian Cai <[email protected]>

commit 28936b62e71e41600bab319f262ea9f9b1027629 upstream.

inode->i_blocks could be accessed concurrently as noticed by KCSAN,

BUG: KCSAN: data-race in ext4_do_update_inode [ext4] / inode_add_bytes

write to 0xffff9a00d4b982d0 of 8 bytes by task 22100 on cpu 118:
inode_add_bytes+0x65/0xf0
__inode_add_bytes at fs/stat.c:689
(inlined by) inode_add_bytes at fs/stat.c:702
ext4_mb_new_blocks+0x418/0xca0 [ext4]
ext4_ext_map_blocks+0x1a6b/0x27b0 [ext4]
ext4_map_blocks+0x1a9/0x950 [ext4]
_ext4_get_block+0xfc/0x270 [ext4]
ext4_get_block_unwritten+0x33/0x50 [ext4]
__block_write_begin_int+0x22e/0xae0
__block_write_begin+0x39/0x50
ext4_write_begin+0x388/0xb50 [ext4]
ext4_da_write_begin+0x35f/0x8f0 [ext4]
generic_perform_write+0x15d/0x290
ext4_buffered_write_iter+0x11f/0x210 [ext4]
ext4_file_write_iter+0xce/0x9e0 [ext4]
new_sync_write+0x29c/0x3b0
__vfs_write+0x92/0xa0
vfs_write+0x103/0x260
ksys_write+0x9d/0x130
__x64_sys_write+0x4c/0x60
do_syscall_64+0x91/0xb05
entry_SYSCALL_64_after_hwframe+0x49/0xbe

read to 0xffff9a00d4b982d0 of 8 bytes by task 8 on cpu 65:
ext4_do_update_inode+0x4a0/0xf60 [ext4]
ext4_inode_blocks_set at fs/ext4/inode.c:4815
ext4_mark_iloc_dirty+0xaf/0x160 [ext4]
ext4_mark_inode_dirty+0x129/0x3e0 [ext4]
ext4_convert_unwritten_extents+0x253/0x2d0 [ext4]
ext4_convert_unwritten_io_end_vec+0xc5/0x150 [ext4]
ext4_end_io_rsv_work+0x22c/0x350 [ext4]
process_one_work+0x54f/0xb90
worker_thread+0x80/0x5f0
kthread+0x1cd/0x1f0
ret_from_fork+0x27/0x50

4 locks held by kworker/u256:0/8:
#0: ffff9a025abc4328 ((wq_completion)ext4-rsv-conversion){+.+.}, at: process_one_work+0x443/0xb90
#1: ffffab5a862dbe20 ((work_completion)(&ei->i_rsv_conversion_work)){+.+.}, at: process_one_work+0x443/0xb90
#2: ffff9a025a9d0f58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
#3: ffff9a00d4b985d8 (&(&ei->i_raw_lock)->rlock){+.+.}, at: ext4_do_update_inode+0xaa/0xf60 [ext4]
irq event stamp: 3009267
hardirqs last enabled at (3009267): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
hardirqs last disabled at (3009266): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
softirqs last enabled at (3009230): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
softirqs last disabled at (3009223): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0

Reported by Kernel Concurrency Sanitizer on:
CPU: 65 PID: 8 Comm: kworker/u256:0 Tainted: G L 5.6.0-rc2-next-20200221+ #7
Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work [ext4]

The plain read is outside of inode->i_lock critical section which
results in a data race. Fix it by adding READ_ONCE() there.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Qian Cai <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5140,7 +5140,7 @@ static int ext4_inode_blocks_set(handle_
struct ext4_inode_info *ei)
{
struct inode *inode = &(ei->vfs_inode);
- u64 i_blocks = inode->i_blocks;
+ u64 i_blocks = READ_ONCE(inode->i_blocks);
struct super_block *sb = inode->i_sb;

if (i_blocks <= ~0U) {


2020-04-16 19:58:45

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 084/146] KVM: x86: Gracefully handle __vmalloc() failure during VM allocation

From: Sean Christopherson <[email protected]>

commit d18b2f43b9147c8005ae0844fb445d8cc6a87e31 upstream.

Check the result of __vmalloc() to avoid dereferencing a NULL pointer in
the event that allocation failres.

Fixes: d1e5b0e98ea27 ("kvm: Make VM ioctl do valloc for some archs")
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Reviewed-by: Vitaly Kuznetsov <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/svm.c | 4 ++++
arch/x86/kvm/vmx.c | 4 ++++
2 files changed, 8 insertions(+)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1917,6 +1917,10 @@ static void __unregister_enc_region_lock
static struct kvm *svm_vm_alloc(void)
{
struct kvm_svm *kvm_svm = vzalloc(sizeof(struct kvm_svm));
+
+ if (!kvm_svm)
+ return NULL;
+
return &kvm_svm->kvm;
}

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10986,6 +10986,10 @@ STACK_FRAME_NON_STANDARD(vmx_vcpu_run);
static struct kvm *vmx_vm_alloc(void)
{
struct kvm_vmx *kvm_vmx = vzalloc(sizeof(struct kvm_vmx));
+
+ if (!kvm_vmx)
+ return NULL;
+
return &kvm_vmx->kvm;
}



2020-04-16 19:58:47

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 131/146] powerpc: Make setjmp/longjmp signature standard

From: Clement Courbet <[email protected]>

commit c17eb4dca5a353a9dbbb8ad6934fe57af7165e91 upstream.

Declaring setjmp()/longjmp() as taking longs makes the signature
non-standard, and makes clang complain. In the past, this has been
worked around by adding -ffreestanding to the compile flags.

The implementation looks like it only ever propagates the value
(in longjmp) or sets it to 1 (in setjmp), and we only call longjmp
with integer parameters.

This allows removing -ffreestanding from the compilation flags.

Fixes: c9029ef9c957 ("powerpc: Avoid clang warnings around setjmp and longjmp")
Cc: [email protected] # v4.14+
Signed-off-by: Clement Courbet <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/include/asm/setjmp.h | 6 ++++--
arch/powerpc/kernel/Makefile | 3 ---
arch/powerpc/xmon/Makefile | 3 ---
3 files changed, 4 insertions(+), 8 deletions(-)

--- a/arch/powerpc/include/asm/setjmp.h
+++ b/arch/powerpc/include/asm/setjmp.h
@@ -12,7 +12,9 @@

#define JMP_BUF_LEN 23

-extern long setjmp(long *) __attribute__((returns_twice));
-extern void longjmp(long *, long) __attribute__((noreturn));
+typedef long jmp_buf[JMP_BUF_LEN];
+
+extern int setjmp(jmp_buf env) __attribute__((returns_twice));
+extern void longjmp(jmp_buf env, int val) __attribute__((noreturn));

#endif /* _ASM_POWERPC_SETJMP_H */
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -5,9 +5,6 @@

CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'

-# Avoid clang warnings around longjmp/setjmp declarations
-CFLAGS_crash.o += -ffreestanding
-
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror

ifdef CONFIG_PPC64
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -1,9 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for xmon

-# Avoid clang warnings around longjmp/setjmp declarations
-subdir-ccflags-y := -ffreestanding
-
subdir-ccflags-$(CONFIG_PPC_WERROR) += -Werror

GCOV_PROFILE := n


2020-04-16 19:59:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 075/146] MIPS: OCTEON: irq: Fix potential NULL pointer dereference

From: Gustavo A. R. Silva <[email protected]>

commit 792a402c2840054533ef56279c212ef6da87d811 upstream.

There is a potential NULL pointer dereference in case kzalloc()
fails and returns NULL.

Fix this by adding a NULL check on *cd*

This bug was detected with the help of Coccinelle.

Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Cc: [email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Thomas Bogendoerfer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/mips/cavium-octeon/octeon-irq.c | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -2199,6 +2199,9 @@ static int octeon_irq_cib_map(struct irq
}

cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+ if (!cd)
+ return -ENOMEM;
+
cd->host_data = host_data;
cd->bit = hw;



2020-04-16 19:59:53

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 144/146] powerpc/fsl_booke: Avoid creating duplicate tlb1 entry

From: Laurentiu Tudor <[email protected]>

[ Upstream commit aa4113340ae6c2811e046f08c2bc21011d20a072 ]

In the current implementation, the call to loadcam_multi() is wrapped
between switch_to_as1() and restore_to_as0() calls so, when it tries
to create its own temporary AS=1 TLB1 entry, it ends up duplicating
the existing one created by switch_to_as1(). Add a check to skip
creating the temporary entry if already running in AS=1.

Fixes: d9e1831a4202 ("powerpc/85xx: Load all early TLB entries at once")
Cc: [email protected] # v4.4+
Signed-off-by: Laurentiu Tudor <[email protected]>
Acked-by: Scott Wood <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/powerpc/mm/tlb_nohash_low.S | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index e066a658acac6..56f58a362ea56 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -402,7 +402,7 @@ _GLOBAL(set_context)
* extern void loadcam_entry(unsigned int index)
*
* Load TLBCAM[index] entry in to the L2 CAM MMU
- * Must preserve r7, r8, r9, and r10
+ * Must preserve r7, r8, r9, r10 and r11
*/
_GLOBAL(loadcam_entry)
mflr r5
@@ -438,6 +438,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
*/
_GLOBAL(loadcam_multi)
mflr r8
+ /* Don't switch to AS=1 if already there */
+ mfmsr r11
+ andi. r11,r11,MSR_IS
+ bne 10f

/*
* Set up temporary TLB entry that is the same as what we're
@@ -463,6 +467,7 @@ _GLOBAL(loadcam_multi)
mtmsr r6
isync

+10:
mr r9,r3
add r10,r3,r4
2: bl loadcam_entry
@@ -471,6 +476,10 @@ _GLOBAL(loadcam_multi)
mr r3,r9
blt 2b

+ /* Don't return to AS=0 if we were in AS=1 at function start */
+ andi. r11,r11,MSR_IS
+ bne 3f
+
/* Return to AS=0 and clear the temporary entry */
mfmsr r6
rlwinm. r6,r6,0,~(MSR_IS|MSR_DS)
@@ -486,6 +495,7 @@ _GLOBAL(loadcam_multi)
tlbwe
isync

+3:
mtlr r8
blr
#endif
--
2.20.1



2020-04-16 19:59:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 145/146] misc: echo: Remove unnecessary parentheses and simplify check for zero

From: Nathan Chancellor <[email protected]>

[ Upstream commit 85dc2c65e6c975baaf36ea30f2ccc0a36a8c8add ]

Clang warns when multiple pairs of parentheses are used for a single
conditional statement.

drivers/misc/echo/echo.c:384:27: warning: equality comparison with
extraneous parentheses [-Wparentheses-equality]
if ((ec->nonupdate_dwell == 0)) {
~~~~~~~~~~~~~~~~~~~~^~~~
drivers/misc/echo/echo.c:384:27: note: remove extraneous parentheses
around the comparison to silence this warning
if ((ec->nonupdate_dwell == 0)) {
~ ^ ~
drivers/misc/echo/echo.c:384:27: note: use '=' to turn this equality
comparison into an assignment
if ((ec->nonupdate_dwell == 0)) {
^~
=
1 warning generated.

Remove them and while we're at it, simplify the zero check as '!var' is
used more than 'var == 0'.

Reported-by: Nick Desaulniers <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/misc/echo/echo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/echo/echo.c b/drivers/misc/echo/echo.c
index 8a5adc0d2e887..3ebe5d75ad6a2 100644
--- a/drivers/misc/echo/echo.c
+++ b/drivers/misc/echo/echo.c
@@ -381,7 +381,7 @@ int16_t oslec_update(struct oslec_state *ec, int16_t tx, int16_t rx)
*/
ec->factor = 0;
ec->shift = 0;
- if ((ec->nonupdate_dwell == 0)) {
+ if (!ec->nonupdate_dwell) {
int p, logp, shift;

/* Determine:
--
2.20.1



2020-04-16 20:37:53

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 121/146] libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set

From: Kai-Heng Feng <[email protected]>

commit 8305f72f952cff21ce8109dc1ea4b321c8efc5af upstream.

During system resume from suspend, this can be observed on ASM1062 PMP
controller:

ata10.01: SATA link down (SStatus 0 SControl 330)
ata10.02: hard resetting link
ata10.02: SATA link down (SStatus 0 SControl 330)
ata10.00: configured for UDMA/133
Kernel panic - not syncing: stack-protector: Kernel
in: sata_pmp_eh_recover+0xa2b/0xa40

CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE
#49-Ubuntu
Hardware name: System manufacturer System Product
1001 12/10/2017
Call Trace:
dump_stack+0x63/0x8b
panic+0xe4/0x244
? sata_pmp_eh_recover+0xa2b/0xa40
__stack_chk_fail+0x19/0x20
sata_pmp_eh_recover+0xa2b/0xa40
? ahci_do_softreset+0x260/0x260 [libahci]
? ahci_do_hardreset+0x140/0x140 [libahci]
? ata_phys_link_offline+0x60/0x60
? ahci_stop_engine+0xc0/0xc0 [libahci]
sata_pmp_error_handler+0x22/0x30
ahci_error_handler+0x45/0x80 [libahci]
ata_scsi_port_error_handler+0x29b/0x770
? ata_scsi_cmd_error_handler+0x101/0x140
ata_scsi_error+0x95/0xd0
? scsi_try_target_reset+0x90/0x90
scsi_error_handler+0xd0/0x5b0
kthread+0x121/0x140
? scsi_eh_get_sense+0x200/0x200
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x22/0x40
Kernel Offset: 0xcc00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is
set, sata_pmp_eh_recover() continues to run. During retry it triggers
the stack protector.

Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover()
jump to pmp_fail directly.

BugLink: https://bugs.launchpad.net/bugs/1821434
Cc: [email protected]
Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libata-pmp.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -764,6 +764,7 @@ static int sata_pmp_eh_recover_pmp(struc

if (dev->flags & ATA_DFLAG_DETACH) {
detach = 1;
+ rc = -ENODEV;
goto fail;
}



2020-04-16 20:38:15

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 138/146] crypto: ccree - dec auth tag size from cryptlen map

From: Gilad Ben-Yossef <[email protected]>

[ Upstream commit 8962c6d2c2b8ca51b0f188109015b15fc5f4da44 ]

Remove the auth tag size from cryptlen before mapping the destination
in out-of-place AEAD decryption thus resolving a crash with
extended testmgr tests.

Signed-off-by: Gilad Ben-Yossef <[email protected]>
Reported-by: Geert Uytterhoeven <[email protected]>
Cc: [email protected] # v4.19+
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/crypto/ccree/cc_buffer_mgr.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c b/drivers/crypto/ccree/cc_buffer_mgr.c
index 6681d113c0d67..77e31191e408a 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -1021,8 +1021,12 @@ static int cc_aead_chain_data(struct cc_drvdata *drvdata,

if (req->src != req->dst) {
size_for_map = areq_ctx->assoclen + req->cryptlen;
- size_for_map += (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ?
- authsize : 0;
+
+ if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT)
+ size_for_map += authsize;
+ else
+ size_for_map -= authsize;
+
if (is_gcm4543)
size_for_map += crypto_aead_ivsize(tfm);

--
2.20.1



2020-04-16 20:38:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 117/146] clk: ingenic/jz4770: Exit with error if CGU init failed

From: Paul Cercueil <[email protected]>

commit c067b46d731a764fc46ecc466c2967088c97089e upstream.

Exit jz4770_cgu_init() if the 'cgu' pointer we get is NULL, since the
pointer is passed as argument to functions later on.

Fixes: 7a01c19007ad ("clk: Add Ingenic jz4770 CGU driver")
Cc: [email protected]
Signed-off-by: Paul Cercueil <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/clk/ingenic/jz4770-cgu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/clk/ingenic/jz4770-cgu.c
+++ b/drivers/clk/ingenic/jz4770-cgu.c
@@ -436,8 +436,10 @@ static void __init jz4770_cgu_init(struc

cgu = ingenic_cgu_new(jz4770_cgu_clocks,
ARRAY_SIZE(jz4770_cgu_clocks), np);
- if (!cgu)
+ if (!cgu) {
pr_err("%s: failed to initialise CGU\n", __func__);
+ return;
+ }

retval = ingenic_cgu_register_clocks(cgu);
if (retval)


2020-04-16 20:38:17

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 137/146] crypto: ccree - dont mangle the request assoclen

From: Gilad Ben-Yossef <[email protected]>

[ Upstream commit da3cf67f1bcf25b069a54ff70fd108860242c8f7 ]

We were mangling the request struct assoclen field.
Fix it by keeping an internal version and working on it.

Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/crypto/ccree/cc_aead.c | 40 +++++++++++++++++-----------
drivers/crypto/ccree/cc_aead.h | 1 +
drivers/crypto/ccree/cc_buffer_mgr.c | 22 +++++++--------
3 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
index c9233420fe421..57aac15a335f5 100644
--- a/drivers/crypto/ccree/cc_aead.c
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -731,7 +731,7 @@ static void cc_set_assoc_desc(struct aead_request *areq, unsigned int flow_mode,
dev_dbg(dev, "ASSOC buffer type DLLI\n");
hw_desc_init(&desc[idx]);
set_din_type(&desc[idx], DMA_DLLI, sg_dma_address(areq->src),
- areq->assoclen, NS_BIT);
+ areq_ctx->assoclen, NS_BIT);
set_flow_mode(&desc[idx], flow_mode);
if (ctx->auth_mode == DRV_HASH_XCBC_MAC &&
areq_ctx->cryptlen > 0)
@@ -1080,9 +1080,11 @@ static void cc_proc_header_desc(struct aead_request *req,
struct cc_hw_desc desc[],
unsigned int *seq_size)
{
+ struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
unsigned int idx = *seq_size;
+
/* Hash associated data */
- if (req->assoclen > 0)
+ if (areq_ctx->assoclen > 0)
cc_set_assoc_desc(req, DIN_HASH, desc, &idx);

/* Hash IV */
@@ -1310,7 +1312,7 @@ static int validate_data_size(struct cc_aead_ctx *ctx,
{
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
struct device *dev = drvdata_to_dev(ctx->drvdata);
- unsigned int assoclen = req->assoclen;
+ unsigned int assoclen = areq_ctx->assoclen;
unsigned int cipherlen = (direct == DRV_CRYPTO_DIRECTION_DECRYPT) ?
(req->cryptlen - ctx->authsize) : req->cryptlen;

@@ -1469,7 +1471,7 @@ static int cc_ccm(struct aead_request *req, struct cc_hw_desc desc[],
idx++;

/* process assoc data */
- if (req->assoclen > 0) {
+ if (req_ctx->assoclen > 0) {
cc_set_assoc_desc(req, DIN_HASH, desc, &idx);
} else {
hw_desc_init(&desc[idx]);
@@ -1561,7 +1563,7 @@ static int config_ccm_adata(struct aead_request *req)
* NIST Special Publication 800-38C
*/
*b0 |= (8 * ((m - 2) / 2));
- if (req->assoclen > 0)
+ if (req_ctx->assoclen > 0)
*b0 |= 64; /* Enable bit 6 if Adata exists. */

rc = set_msg_len(b0 + 16 - l, cryptlen, l); /* Write L'. */
@@ -1572,7 +1574,7 @@ static int config_ccm_adata(struct aead_request *req)
/* END of "taken from crypto/ccm.c" */

/* l(a) - size of associated data. */
- req_ctx->ccm_hdr_size = format_ccm_a0(a0, req->assoclen);
+ req_ctx->ccm_hdr_size = format_ccm_a0(a0, req_ctx->assoclen);

memset(req->iv + 15 - req->iv[0], 0, req->iv[0] + 1);
req->iv[15] = 1;
@@ -1604,7 +1606,7 @@ static void cc_proc_rfc4309_ccm(struct aead_request *req)
memcpy(areq_ctx->ctr_iv + CCM_BLOCK_IV_OFFSET, req->iv,
CCM_BLOCK_IV_SIZE);
req->iv = areq_ctx->ctr_iv;
- req->assoclen -= CCM_BLOCK_IV_SIZE;
+ areq_ctx->assoclen -= CCM_BLOCK_IV_SIZE;
}

static void cc_set_ghash_desc(struct aead_request *req,
@@ -1812,7 +1814,7 @@ static int cc_gcm(struct aead_request *req, struct cc_hw_desc desc[],
// for gcm and rfc4106.
cc_set_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
- if (req->assoclen > 0)
+ if (req_ctx->assoclen > 0)
cc_set_assoc_desc(req, DIN_HASH, desc, seq_size);
cc_set_gctr_desc(req, desc, seq_size);
/* process(gctr+ghash) */
@@ -1836,8 +1838,8 @@ static int config_gcm_context(struct aead_request *req)
(req->cryptlen - ctx->authsize);
__be32 counter = cpu_to_be32(2);

- dev_dbg(dev, "%s() cryptlen = %d, req->assoclen = %d ctx->authsize = %d\n",
- __func__, cryptlen, req->assoclen, ctx->authsize);
+ dev_dbg(dev, "%s() cryptlen = %d, req_ctx->assoclen = %d ctx->authsize = %d\n",
+ __func__, cryptlen, req_ctx->assoclen, ctx->authsize);

memset(req_ctx->hkey, 0, AES_BLOCK_SIZE);

@@ -1853,7 +1855,7 @@ static int config_gcm_context(struct aead_request *req)
if (!req_ctx->plaintext_authenticate_only) {
__be64 temp64;

- temp64 = cpu_to_be64(req->assoclen * 8);
+ temp64 = cpu_to_be64(req_ctx->assoclen * 8);
memcpy(&req_ctx->gcm_len_block.len_a, &temp64, sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
memcpy(&req_ctx->gcm_len_block.len_c, &temp64, 8);
@@ -1863,8 +1865,8 @@ static int config_gcm_context(struct aead_request *req)
*/
__be64 temp64;

- temp64 = cpu_to_be64((req->assoclen + GCM_BLOCK_RFC4_IV_SIZE +
- cryptlen) * 8);
+ temp64 = cpu_to_be64((req_ctx->assoclen +
+ GCM_BLOCK_RFC4_IV_SIZE + cryptlen) * 8);
memcpy(&req_ctx->gcm_len_block.len_a, &temp64, sizeof(temp64));
temp64 = 0;
memcpy(&req_ctx->gcm_len_block.len_c, &temp64, 8);
@@ -1884,7 +1886,7 @@ static void cc_proc_rfc4_gcm(struct aead_request *req)
memcpy(areq_ctx->ctr_iv + GCM_BLOCK_RFC4_IV_OFFSET, req->iv,
GCM_BLOCK_RFC4_IV_SIZE);
req->iv = areq_ctx->ctr_iv;
- req->assoclen -= GCM_BLOCK_RFC4_IV_SIZE;
+ areq_ctx->assoclen -= GCM_BLOCK_RFC4_IV_SIZE;
}

static int cc_proc_aead(struct aead_request *req,
@@ -1909,7 +1911,7 @@ static int cc_proc_aead(struct aead_request *req,
/* Check data length according to mode */
if (validate_data_size(ctx, direct, req)) {
dev_err(dev, "Unsupported crypt/assoc len %d/%d.\n",
- req->cryptlen, req->assoclen);
+ req->cryptlen, areq_ctx->assoclen);
crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_BLOCK_LEN);
return -EINVAL;
}
@@ -2062,6 +2064,7 @@ static int cc_aead_encrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;
areq_ctx->is_gcm4543 = false;

@@ -2093,6 +2096,7 @@ static int cc_rfc4309_ccm_encrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;
areq_ctx->is_gcm4543 = true;

@@ -2114,6 +2118,7 @@ static int cc_aead_decrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;
areq_ctx->is_gcm4543 = false;

@@ -2143,6 +2148,7 @@ static int cc_rfc4309_ccm_decrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;

areq_ctx->is_gcm4543 = true;
@@ -2262,6 +2268,7 @@ static int cc_rfc4106_gcm_encrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;

areq_ctx->plaintext_authenticate_only = false;
@@ -2290,6 +2297,7 @@ static int cc_rfc4543_gcm_encrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;

cc_proc_rfc4_gcm(req);
@@ -2321,6 +2329,7 @@ static int cc_rfc4106_gcm_decrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;

areq_ctx->plaintext_authenticate_only = false;
@@ -2349,6 +2358,7 @@ static int cc_rfc4543_gcm_decrypt(struct aead_request *req)

/* No generated IV required */
areq_ctx->backup_iv = req->iv;
+ areq_ctx->assoclen = req->assoclen;
areq_ctx->backup_giv = NULL;

cc_proc_rfc4_gcm(req);
diff --git a/drivers/crypto/ccree/cc_aead.h b/drivers/crypto/ccree/cc_aead.h
index 5edf3b351fa44..74bc99067f180 100644
--- a/drivers/crypto/ccree/cc_aead.h
+++ b/drivers/crypto/ccree/cc_aead.h
@@ -67,6 +67,7 @@ struct aead_req_ctx {
u8 backup_mac[MAX_MAC_SIZE];
u8 *backup_iv; /*store iv for generated IV flow*/
u8 *backup_giv; /*store iv for rfc3686(ctr) flow*/
+ u32 assoclen; /* internal assoclen */
dma_addr_t mac_buf_dma_addr; /* internal ICV DMA buffer */
/* buffer for internal ccm configurations */
dma_addr_t ccm_iv0_dma_addr;
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c b/drivers/crypto/ccree/cc_buffer_mgr.c
index 7489887cc7802..6681d113c0d67 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -65,7 +65,7 @@ static void cc_copy_mac(struct device *dev, struct aead_request *req,
{
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
- u32 skip = req->assoclen + req->cryptlen;
+ u32 skip = areq_ctx->assoclen + req->cryptlen;

if (areq_ctx->is_gcm4543)
skip += crypto_aead_ivsize(tfm);
@@ -574,8 +574,8 @@ void cc_unmap_aead_request(struct device *dev, struct aead_request *req)

dev_dbg(dev, "Unmapping src sgl: req->src=%pK areq_ctx->src.nents=%u areq_ctx->assoc.nents=%u assoclen:%u cryptlen=%u\n",
sg_virt(req->src), areq_ctx->src.nents, areq_ctx->assoc.nents,
- req->assoclen, req->cryptlen);
- size_to_unmap = req->assoclen + req->cryptlen;
+ areq_ctx->assoclen, req->cryptlen);
+ size_to_unmap = areq_ctx->assoclen + req->cryptlen;
if (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_ENCRYPT)
size_to_unmap += areq_ctx->req_authsize;
if (areq_ctx->is_gcm4543)
@@ -717,7 +717,7 @@ static int cc_aead_chain_assoc(struct cc_drvdata *drvdata,
struct scatterlist *current_sg = req->src;
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
unsigned int sg_index = 0;
- u32 size_of_assoc = req->assoclen;
+ u32 size_of_assoc = areq_ctx->assoclen;
struct device *dev = drvdata_to_dev(drvdata);

if (areq_ctx->is_gcm4543)
@@ -728,7 +728,7 @@ static int cc_aead_chain_assoc(struct cc_drvdata *drvdata,
goto chain_assoc_exit;
}

- if (req->assoclen == 0) {
+ if (areq_ctx->assoclen == 0) {
areq_ctx->assoc_buff_type = CC_DMA_BUF_NULL;
areq_ctx->assoc.nents = 0;
areq_ctx->assoc.mlli_nents = 0;
@@ -788,7 +788,7 @@ static int cc_aead_chain_assoc(struct cc_drvdata *drvdata,
cc_dma_buf_type(areq_ctx->assoc_buff_type),
areq_ctx->assoc.nents);
cc_add_sg_entry(dev, sg_data, areq_ctx->assoc.nents, req->src,
- req->assoclen, 0, is_last,
+ areq_ctx->assoclen, 0, is_last,
&areq_ctx->assoc.mlli_nents);
areq_ctx->assoc_buff_type = CC_DMA_BUF_MLLI;
}
@@ -972,11 +972,11 @@ static int cc_aead_chain_data(struct cc_drvdata *drvdata,
u32 src_mapped_nents = 0, dst_mapped_nents = 0;
u32 offset = 0;
/* non-inplace mode */
- unsigned int size_for_map = req->assoclen + req->cryptlen;
+ unsigned int size_for_map = areq_ctx->assoclen + req->cryptlen;
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
u32 sg_index = 0;
bool is_gcm4543 = areq_ctx->is_gcm4543;
- u32 size_to_skip = req->assoclen;
+ u32 size_to_skip = areq_ctx->assoclen;

if (is_gcm4543)
size_to_skip += crypto_aead_ivsize(tfm);
@@ -1020,7 +1020,7 @@ static int cc_aead_chain_data(struct cc_drvdata *drvdata,
areq_ctx->src_offset = offset;

if (req->src != req->dst) {
- size_for_map = req->assoclen + req->cryptlen;
+ size_for_map = areq_ctx->assoclen + req->cryptlen;
size_for_map += (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ?
authsize : 0;
if (is_gcm4543)
@@ -1186,7 +1186,7 @@ int cc_map_aead_request(struct cc_drvdata *drvdata, struct aead_request *req)
areq_ctx->ccm_iv0_dma_addr = dma_addr;

rc = cc_set_aead_conf_buf(dev, areq_ctx, areq_ctx->ccm_config,
- &sg_data, req->assoclen);
+ &sg_data, areq_ctx->assoclen);
if (rc)
goto aead_map_failure;
}
@@ -1237,7 +1237,7 @@ int cc_map_aead_request(struct cc_drvdata *drvdata, struct aead_request *req)
areq_ctx->gcm_iv_inc2_dma_addr = dma_addr;
}

- size_to_map = req->cryptlen + req->assoclen;
+ size_to_map = req->cryptlen + areq_ctx->assoclen;
if (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_ENCRYPT)
size_to_map += authsize;

--
2.20.1



2020-04-16 20:38:22

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 122/146] ipmi: fix hung processes in __get_guid()

From: Wen Yang <[email protected]>

commit 32830a0534700f86366f371b150b17f0f0d140d7 upstream.

The wait_event() function is used to detect command completion.
When send_guid_cmd() returns an error, smi_send() has not been
called to send data. Therefore, wait_event() should not be used
on the error path, otherwise it will cause the following warning:

[ 1361.588808] systemd-udevd D 0 1501 1436 0x00000004
[ 1361.588813] ffff883f4b1298c0 0000000000000000 ffff883f4b188000 ffff887f7e3d9f40
[ 1361.677952] ffff887f64bd4280 ffffc90037297a68 ffffffff8173ca3b ffffc90000000010
[ 1361.767077] 00ffc90037297ad0 ffff887f7e3d9f40 0000000000000286 ffff883f4b188000
[ 1361.856199] Call Trace:
[ 1361.885578] [<ffffffff8173ca3b>] ? __schedule+0x23b/0x780
[ 1361.951406] [<ffffffff8173cfb6>] schedule+0x36/0x80
[ 1362.010979] [<ffffffffa071f178>] get_guid+0x118/0x150 [ipmi_msghandler]
[ 1362.091281] [<ffffffff810d5350>] ? prepare_to_wait_event+0x100/0x100
[ 1362.168533] [<ffffffffa071f755>] ipmi_register_smi+0x405/0x940 [ipmi_msghandler]
[ 1362.258337] [<ffffffffa0230ae9>] try_smi_init+0x529/0x950 [ipmi_si]
[ 1362.334521] [<ffffffffa022f350>] ? std_irq_setup+0xd0/0xd0 [ipmi_si]
[ 1362.411701] [<ffffffffa0232bd2>] init_ipmi_si+0x492/0x9e0 [ipmi_si]
[ 1362.487917] [<ffffffffa0232740>] ? ipmi_pci_probe+0x280/0x280 [ipmi_si]
[ 1362.568219] [<ffffffff810021a0>] do_one_initcall+0x50/0x180
[ 1362.636109] [<ffffffff812231b2>] ? kmem_cache_alloc_trace+0x142/0x190
[ 1362.714330] [<ffffffff811b2ae1>] do_init_module+0x5f/0x200
[ 1362.781208] [<ffffffff81123ca8>] load_module+0x1898/0x1de0
[ 1362.848069] [<ffffffff811202e0>] ? __symbol_put+0x60/0x60
[ 1362.913886] [<ffffffff8130696b>] ? security_kernel_post_read_file+0x6b/0x80
[ 1362.998514] [<ffffffff81124465>] SYSC_finit_module+0xe5/0x120
[ 1363.068463] [<ffffffff81124465>] ? SYSC_finit_module+0xe5/0x120
[ 1363.140513] [<ffffffff811244be>] SyS_finit_module+0xe/0x10
[ 1363.207364] [<ffffffff81003c04>] do_syscall_64+0x74/0x180

Fixes: 50c812b2b951 ("[PATCH] ipmi: add full sysfs support")
Signed-off-by: Wen Yang <[email protected]>
Cc: Corey Minyard <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected] # 2.6.17-
Message-Id: <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -3134,8 +3134,8 @@ static void __get_guid(struct ipmi_smi *
if (rv)
/* Send failed, no GUID available. */
bmc->dyn_guid_set = 0;
-
- wait_event(intf->waitq, bmc->dyn_guid_set != 2);
+ else
+ wait_event(intf->waitq, bmc->dyn_guid_set != 2);

/* dyn_guid_set makes the guid data available. */
smp_rmb();


2020-04-16 20:38:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 093/146] btrfs: fix missing semaphore unlock in btrfs_sync_file

From: Robbie Ko <[email protected]>

commit 6ff06729c22ec0b7498d900d79cc88cfb8aceaeb upstream.

Ordered ops are started twice in sync file, once outside of inode mutex
and once inside, taking the dio semaphore. There was one error path
missing the semaphore unlock.

Fixes: aab15e8ec2576 ("Btrfs: fix rare chances for data loss when doing a fast fsync")
CC: [email protected] # 4.19+
Signed-off-by: Robbie Ko <[email protected]>
Reviewed-by: Filipe Manana <[email protected]>
[ add changelog ]
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/file.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2137,6 +2137,7 @@ int btrfs_sync_file(struct file *file, l
*/
ret = start_ordered_ops(inode, start, end);
if (ret) {
+ up_write(&BTRFS_I(inode)->dio_sem);
inode_unlock(inode);
goto out;
}


2020-04-16 20:38:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 089/146] Btrfs: fix crash during unmount due to race with delayed inode workers

From: Filipe Manana <[email protected]>

commit f0cc2cd70164efe8f75c5d99560f0f69969c72e4 upstream.

During unmount we can have a job from the delayed inode items work queue
still running, that can lead to at least two bad things:

1) A crash, because the worker can try to create a transaction just
after the fs roots were freed;

2) A transaction leak, because the worker can create a transaction
before the fs roots are freed and just after we committed the last
transaction and after we stopped the transaction kthread.

A stack trace example of the crash:

[79011.691214] kernel BUG at lib/radix-tree.c:982!
[79011.692056] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[79011.693180] CPU: 3 PID: 1394 Comm: kworker/u8:2 Tainted: G W 5.6.0-rc2-btrfs-next-54 #2
(...)
[79011.696789] Workqueue: btrfs-delayed-meta btrfs_work_helper [btrfs]
[79011.697904] RIP: 0010:radix_tree_tag_set+0xe7/0x170
(...)
[79011.702014] RSP: 0018:ffffb3c84a317ca0 EFLAGS: 00010293
[79011.702949] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[79011.704202] RDX: ffffb3c84a317cb0 RSI: ffffb3c84a317ca8 RDI: ffff8db3931340a0
[79011.705463] RBP: 0000000000000005 R08: 0000000000000005 R09: ffffffff974629d0
[79011.706756] R10: ffffb3c84a317bc0 R11: 0000000000000001 R12: ffff8db393134000
[79011.708010] R13: ffff8db3931340a0 R14: ffff8db393134068 R15: 0000000000000001
[79011.709270] FS: 0000000000000000(0000) GS:ffff8db3b6a00000(0000) knlGS:0000000000000000
[79011.710699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[79011.711710] CR2: 00007f22c2a0a000 CR3: 0000000232ad4005 CR4: 00000000003606e0
[79011.712958] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[79011.714205] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[79011.715448] Call Trace:
[79011.715925] record_root_in_trans+0x72/0xf0 [btrfs]
[79011.716819] btrfs_record_root_in_trans+0x4b/0x70 [btrfs]
[79011.717925] start_transaction+0xdd/0x5c0 [btrfs]
[79011.718829] btrfs_async_run_delayed_root+0x17e/0x2b0 [btrfs]
[79011.719915] btrfs_work_helper+0xaa/0x720 [btrfs]
[79011.720773] process_one_work+0x26d/0x6a0
[79011.721497] worker_thread+0x4f/0x3e0
[79011.722153] ? process_one_work+0x6a0/0x6a0
[79011.722901] kthread+0x103/0x140
[79011.723481] ? kthread_create_worker_on_cpu+0x70/0x70
[79011.724379] ret_from_fork+0x3a/0x50
(...)

The following diagram shows a sequence of steps that lead to the crash
during ummount of the filesystem:

CPU 1 CPU 2 CPU 3

btrfs_punch_hole()
btrfs_btree_balance_dirty()
btrfs_balance_delayed_items()
--> sees
fs_info->delayed_root->items
with value 200, which is greater
than
BTRFS_DELAYED_BACKGROUND (128)
and smaller than
BTRFS_DELAYED_WRITEBACK (512)
btrfs_wq_run_delayed_node()
--> queues a job for
fs_info->delayed_workers to run
btrfs_async_run_delayed_root()

btrfs_async_run_delayed_root()
--> job queued by CPU 1

--> starts picking and running
delayed nodes from the
prepare_list list

close_ctree()

btrfs_delete_unused_bgs()

btrfs_commit_super()

btrfs_join_transaction()
--> gets transaction N

btrfs_commit_transaction(N)
--> set transaction state
to TRANTS_STATE_COMMIT_START

btrfs_first_prepared_delayed_node()
--> picks delayed node X through
the prepared_list list

btrfs_run_delayed_items()

btrfs_first_delayed_node()
--> also picks delayed node X
but through the node_list
list

__btrfs_commit_inode_delayed_items()
--> runs all delayed items from
this node and drops the
node's item count to 0
through call to
btrfs_release_delayed_inode()

--> finishes running any remaining
delayed nodes

--> finishes transaction commit

--> stops cleaner and transaction threads

btrfs_free_fs_roots()
--> frees all roots and removes them
from the radix tree
fs_info->fs_roots_radix

btrfs_join_transaction()
start_transaction()
btrfs_record_root_in_trans()
record_root_in_trans()
radix_tree_tag_set()
--> crashes because
the root is not in
the radix tree
anymore

If the worker is able to call btrfs_join_transaction() before the unmount
task frees the fs roots, we end up leaking a transaction and all its
resources, since after the call to btrfs_commit_super() and stopping the
transaction kthread, we don't expect to have any transaction open anymore.

When this situation happens the worker has a delayed node that has no
more items to run, since the task calling btrfs_run_delayed_items(),
which is doing a transaction commit, picks the same node and runs all
its items first.

We can not wait for the worker to complete when running delayed items
through btrfs_run_delayed_items(), because we call that function in
several phases of a transaction commit, and that could cause a deadlock
because the worker calls btrfs_join_transaction() and the task doing the
transaction commit may have already set the transaction state to
TRANS_STATE_COMMIT_DOING.

Also it's not possible to get into a situation where only some of the
items of a delayed node are added to the fs/subvolume tree in the current
transaction and the remaining ones in the next transaction, because when
running the items of a delayed inode we lock its mutex, effectively
waiting for the worker if the worker is running the items of the delayed
node already.

Since this can only cause issues when unmounting a filesystem, fix it in
a simple way by waiting for any jobs on the delayed workers queue before
calling btrfs_commit_supper() at close_ctree(). This works because at this
point no one can call btrfs_btree_balance_dirty() or
btrfs_balance_delayed_items(), and if we end up waiting for any worker to
complete, btrfs_commit_super() will commit the transaction created by the
worker.

CC: [email protected] # 4.4+
Signed-off-by: Filipe Manana <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/async-thread.c | 8 ++++++++
fs/btrfs/async-thread.h | 1 +
fs/btrfs/disk-io.c | 13 +++++++++++++
3 files changed, 22 insertions(+)

--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -434,3 +434,11 @@ void btrfs_set_work_high_priority(struct
{
set_bit(WORK_HIGH_PRIO_BIT, &work->flags);
}
+
+void btrfs_flush_workqueue(struct btrfs_workqueue *wq)
+{
+ if (wq->high)
+ flush_workqueue(wq->high->normal_wq);
+
+ flush_workqueue(wq->normal->normal_wq);
+}
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -73,5 +73,6 @@ void btrfs_set_work_high_priority(struct
struct btrfs_fs_info *btrfs_work_owner(const struct btrfs_work *work);
struct btrfs_fs_info *btrfs_workqueue_owner(const struct __btrfs_workqueue *wq);
bool btrfs_workqueue_normal_congested(const struct btrfs_workqueue *wq);
+void btrfs_flush_workqueue(struct btrfs_workqueue *wq);

#endif
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3949,6 +3949,19 @@ void close_ctree(struct btrfs_fs_info *f
*/
btrfs_delete_unused_bgs(fs_info);

+ /*
+ * There might be existing delayed inode workers still running
+ * and holding an empty delayed inode item. We must wait for
+ * them to complete first because they can create a transaction.
+ * This happens when someone calls btrfs_balance_delayed_items()
+ * and then a transaction commit runs the same delayed nodes
+ * before any delayed worker has done something with the nodes.
+ * We must wait for any worker here and not at transaction
+ * commit time since that could cause a deadlock.
+ * This is a very rare case.
+ */
+ btrfs_flush_workqueue(fs_info->delayed_workers);
+
ret = btrfs_commit_super(fs_info);
if (ret)
btrfs_err(fs_info, "commit super ret %d", ret);


2020-04-16 20:38:31

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 074/146] MIPS/tlbex: Fix LDDIR usage in setup_pw() for Loongson-3

From: Huacai Chen <[email protected]>

commit d191aaffe3687d1e73e644c185f5f0550ec242b5 upstream.

LDDIR/LDPTE is Loongson-3's acceleration for Page Table Walking. If BD
(Base Directory, the 4th page directory) is not enabled, then GDOffset
is biased by BadVAddr[63:62]. So, if GDOffset (aka. BadVAddr[47:36] for
Loongson-3) is big enough, "0b11(BadVAddr[63:62])|BadVAddr[47:36]|...."
can far beyond pg_swapper_dir. This means the pg_swapper_dir may NOT be
accessed by LDDIR correctly, so fix it by set PWDirExt in CP0_PWCtl.

Cc: <[email protected]>
Signed-off-by: Pei Huang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
Signed-off-by: Thomas Bogendoerfer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/mips/mm/tlbex.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -1479,6 +1479,7 @@ static void build_r4000_tlb_refill_handl

static void setup_pw(void)
{
+ unsigned int pwctl;
unsigned long pgd_i, pgd_w;
#ifndef __PAGETABLE_PMD_FOLDED
unsigned long pmd_i, pmd_w;
@@ -1505,6 +1506,7 @@ static void setup_pw(void)

pte_i = ilog2(_PAGE_GLOBAL);
pte_w = 0;
+ pwctl = 1 << 30; /* Set PWDirExt */

#ifndef __PAGETABLE_PMD_FOLDED
write_c0_pwfield(pgd_i << 24 | pmd_i << 12 | pt_i << 6 | pte_i);
@@ -1515,8 +1517,9 @@ static void setup_pw(void)
#endif

#ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
- write_c0_pwctl(1 << 6 | psn);
+ pwctl |= (1 << 6 | psn);
#endif
+ write_c0_pwctl(pwctl);
write_c0_kpgd((long)swapper_pg_dir);
kscratch_used_mask |= (1 << 7); /* KScratch6 is used for KPGD */
}


2020-04-16 20:38:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 073/146] pstore: pstore_ftrace_seq_next should increase position index

From: Vasily Averin <[email protected]>

commit 6c871b7314dde9ab64f20de8f5aa3d01be4518e8 upstream.

In Aug 2018 NeilBrown noticed
commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
"Some ->next functions do not increment *pos when they return NULL...
Note that such ->next functions are buggy and should be fixed.
A simple demonstration is

dd if=/proc/swaps bs=1000 skip=1

Choose any block size larger than the size of /proc/swaps. This will
always show the whole last line of /proc/swaps"

/proc/swaps output was fixed recently, however there are lot of other
affected files, and one of them is related to pstore subsystem.

If .next function does not change position index, following .show function
will repeat output related to current position index.

There are at least 2 related problems:
- read after lseek beyond end of file, described above by NeilBrown
"dd if=<AFFECTED_FILE> bs=1000 skip=1" will generate whole last list
- read after lseek on in middle of last line will output expected rest of
last line but then repeat whole last line once again.

If .show() function generates multy-line output (like
pstore_ftrace_seq_show() does ?) following bash script cycles endlessly

$ q=;while read -r r;do echo "$((++q)) $r";done < AFFECTED_FILE

Unfortunately I'm not familiar enough to pstore subsystem and was unable
to find affected pstore-related file on my test node.

If .next function does not change position index, following .show function
will repeat output related to current position index.

Cc: [email protected]
Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[kees: with robustness tweak from Joel Fernandes <[email protected]>]
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/pstore/inode.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -99,11 +99,11 @@ static void *pstore_ftrace_seq_next(stru
struct pstore_private *ps = s->private;
struct pstore_ftrace_seq_data *data = v;

+ (*pos)++;
data->off += REC_SIZE;
if (data->off + REC_SIZE > ps->total_size)
return NULL;

- (*pos)++;
return data;
}

@@ -113,6 +113,9 @@ static int pstore_ftrace_seq_show(struct
struct pstore_ftrace_seq_data *data = v;
struct pstore_ftrace_record *rec;

+ if (!data)
+ return 0;
+
rec = (struct pstore_ftrace_record *)(ps->record->buf + data->off);

seq_printf(s, "CPU:%d ts:%llu %08lx %08lx %pf <- %pF\n",


2020-04-16 20:38:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 064/146] PCI: pciehp: Fix indefinite wait on sysfs requests

From: Lukas Wunner <[email protected]>

commit 3e487d2e4aa466decd226353755c9d423e8fbacc upstream.

David Hoyer reports that powering pciehp slots up or down via sysfs may
hang: The call to wait_event() in pciehp_sysfs_enable_slot() and
_disable_slot() does not return because ctrl->ist_running remains true.

This flag, which was introduced by commit 157c1062fcd8 ("PCI: pciehp: Avoid
returning prematurely from sysfs requests"), signifies that the IRQ thread
pciehp_ist() is running. It is set to true at the top of pciehp_ist() and
reset to false at the end. However there are two additional return
statements in pciehp_ist() before which the commit neglected to reset the
flag to false and wake up waiters for the flag.

That omission opens up the following race when powering up the slot:

* pciehp_ist() runs because a PCI_EXP_SLTSTA_PDC event was requested
by pciehp_sysfs_enable_slot()

* pciehp_ist() turns on slot power via the following call stack:
pciehp_handle_presence_or_link_change() -> pciehp_enable_slot() ->
__pciehp_enable_slot() -> board_added() -> pciehp_power_on_slot()

* after slot power is turned on, the link comes up, resulting in a
PCI_EXP_SLTSTA_DLLSC event

* the IRQ handler pciehp_isr() stores the event in ctrl->pending_events
and returns IRQ_WAKE_THREAD

* the IRQ thread is already woken (it's bringing up the slot), but the
genirq code remembers to re-run the IRQ thread after it has finished
(such that it can deal with the new event) by setting IRQTF_RUNTHREAD
via __handle_irq_event_percpu() -> __irq_wake_thread()

* the IRQ thread removes PCI_EXP_SLTSTA_DLLSC from ctrl->pending_events
via board_added() -> pciehp_check_link_status() in order to deal with
presence and link flaps per commit 6c35a1ac3da6 ("PCI: pciehp:
Tolerate initially unstable link")

* after pciehp_ist() has successfully brought up the slot, it resets
ctrl->ist_running to false and wakes up the sysfs requester

* the genirq code re-runs pciehp_ist(), which sets ctrl->ist_running
to true but then returns with IRQ_NONE because ctrl->pending_events
is empty

* pciehp_sysfs_enable_slot() is finally woken but notices that
ctrl->ist_running is true, hence continues waiting

The only way to get the hung task going again is to trigger a hotplug
event which brings down the slot, e.g. by yanking out the card.

The same race exists when powering down the slot because remove_board()
likewise clears link or presence changes in ctrl->pending_events per commit
3943af9d01e9 ("PCI: pciehp: Ignore Link State Changes after powering off a
slot") and thereby may cause a re-run of pciehp_ist() which returns with
IRQ_NONE without resetting ctrl->ist_running to false.

Fix by adding a goto label before the teardown steps at the end of
pciehp_ist() and jumping to that label from the two return statements which
currently neglect to reset the ctrl->ist_running flag.

Fixes: 157c1062fcd8 ("PCI: pciehp: Avoid returning prematurely from sysfs requests")
Link: https://lore.kernel.org/r/cca1effa488065cb055120aa01b65719094bdcb5.1584530321.git.lukas@wunner.de
Reported-by: David Hoyer <[email protected]>
Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Keith Busch <[email protected]>
Cc: [email protected] # v4.19+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/hotplug/pciehp_hpc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -627,17 +627,15 @@ static irqreturn_t pciehp_ist(int irq, v
if (atomic_fetch_and(~RERUN_ISR, &ctrl->pending_events) & RERUN_ISR) {
ret = pciehp_isr(irq, dev_id);
enable_irq(irq);
- if (ret != IRQ_WAKE_THREAD) {
- pci_config_pm_runtime_put(pdev);
- return ret;
- }
+ if (ret != IRQ_WAKE_THREAD)
+ goto out;
}

synchronize_hardirq(irq);
events = atomic_xchg(&ctrl->pending_events, 0);
if (!events) {
- pci_config_pm_runtime_put(pdev);
- return IRQ_NONE;
+ ret = IRQ_NONE;
+ goto out;
}

/* Check Attention Button Pressed */
@@ -666,10 +664,12 @@ static irqreturn_t pciehp_ist(int irq, v
pciehp_handle_presence_or_link_change(slot, events);
up_read(&ctrl->reset_lock);

+ ret = IRQ_HANDLED;
+out:
pci_config_pm_runtime_put(pdev);
ctrl->ist_running = false;
wake_up(&ctrl->requester);
- return IRQ_HANDLED;
+ return ret;
}

static int pciehp_poll(void *data)


2020-04-16 20:38:40

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 141/146] drm/dp_mst: Fix clearing payload state on topology disable

From: Lyude Paul <[email protected]>

[ Upstream commit 8732fe46b20c951493bfc4dba0ad08efdf41de81 ]

The issues caused by:

commit 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology
mgr")

Prompted me to take a closer look at how we clear the payload state in
general when disabling the topology, and it turns out there's actually
two subtle issues here.

The first is that we're not grabbing &mgr.payload_lock when clearing the
payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical
lock order is &mgr.payload_lock -> &mgr.lock (because we always want
&mgr.lock to be the inner-most lock so topology validation always
works), this makes perfect sense. It also means that -technically- there
could be racing between someone calling
drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a
modeset occurring that's modifying the payload state at the same time.

The second is the more obvious issue that Wayne Lin discovered, that
we're not clearing proposed_payloads when disabling the topology.

I actually can't see any obvious places where the racing caused by the
first issue would break something, and it could be that some of our
higher-level locks already prevent this by happenstance, but better safe
then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst()
first grabs &mgr.payload_lock followed by &mgr.lock so that we never
race when modifying the payload state. Then, we also clear
proposed_payloads to fix the original issue of enabling a new topology
with a dirty payload state. This doesn't clear any of the drm_dp_vcpi
structures, but those are getting destroyed along with the ports anyway.

Changes since v1:
* Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead -
vsyrjala

Cc: Sean Paul <[email protected]>
Cc: Wayne Lin <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: [email protected] # v4.4+
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index b4fd20062bb80..5f508ec321fef 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2117,6 +2117,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
int ret = 0;
struct drm_dp_mst_branch *mstb = NULL;

+ mutex_lock(&mgr->payload_lock);
mutex_lock(&mgr->lock);
if (mst_state == mgr->mst_state)
goto out_unlock;
@@ -2175,7 +2176,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
- memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payload));
+ memset(mgr->payloads, 0,
+ mgr->max_payloads * sizeof(mgr->payloads[0]));
+ memset(mgr->proposed_vcpis, 0,
+ mgr->max_payloads * sizeof(mgr->proposed_vcpis[0]));
mgr->payload_mask = 0;
set_bit(0, &mgr->payload_mask);
mgr->vcpi_mask = 0;
@@ -2183,6 +2187,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms

out_unlock:
mutex_unlock(&mgr->lock);
+ mutex_unlock(&mgr->payload_lock);
if (mstb)
drm_dp_put_mst_branch_device(mstb);
return ret;
--
2.20.1



2020-04-16 20:38:51

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 005/146] hinic: fix a bug of waitting for IO stopped

From: Luo bin <[email protected]>

[ Upstream commit 96758117dc528e6d84bd23d205e8cf7f31eda029 ]

it's unreliable for fw to check whether IO is stopped, so driver
wait for enough time to ensure IO process is done in hw before
freeing resources

Signed-off-by: Luo bin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 51 +------------------
1 file changed, 2 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
index 9deec13d98e93..4c91c8ceac5f9 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
@@ -370,50 +370,6 @@ static int wait_for_db_state(struct hinic_hwdev *hwdev)
return -EFAULT;
}

-static int wait_for_io_stopped(struct hinic_hwdev *hwdev)
-{
- struct hinic_cmd_io_status cmd_io_status;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
- struct hinic_pfhwdev *pfhwdev;
- unsigned long end;
- u16 out_size;
- int err;
-
- if (!HINIC_IS_PF(hwif) && !HINIC_IS_PPF(hwif)) {
- dev_err(&pdev->dev, "Unsupported PCI Function type\n");
- return -EINVAL;
- }
-
- pfhwdev = container_of(hwdev, struct hinic_pfhwdev, hwdev);
-
- cmd_io_status.func_idx = HINIC_HWIF_FUNC_IDX(hwif);
-
- end = jiffies + msecs_to_jiffies(IO_STATUS_TIMEOUT);
- do {
- err = hinic_msg_to_mgmt(&pfhwdev->pf_to_mgmt, HINIC_MOD_COMM,
- HINIC_COMM_CMD_IO_STATUS_GET,
- &cmd_io_status, sizeof(cmd_io_status),
- &cmd_io_status, &out_size,
- HINIC_MGMT_MSG_SYNC);
- if ((err) || (out_size != sizeof(cmd_io_status))) {
- dev_err(&pdev->dev, "Failed to get IO status, ret = %d\n",
- err);
- return err;
- }
-
- if (cmd_io_status.status == IO_STOPPED) {
- dev_info(&pdev->dev, "IO stopped\n");
- return 0;
- }
-
- msleep(20);
- } while (time_before(jiffies, end));
-
- dev_err(&pdev->dev, "Wait for IO stopped - Timeout\n");
- return -ETIMEDOUT;
-}
-
/**
* clear_io_resource - set the IO resources as not active in the NIC
* @hwdev: the NIC HW device
@@ -433,11 +389,8 @@ static int clear_io_resources(struct hinic_hwdev *hwdev)
return -EINVAL;
}

- err = wait_for_io_stopped(hwdev);
- if (err) {
- dev_err(&pdev->dev, "IO has not stopped yet\n");
- return err;
- }
+ /* sleep 100ms to wait for firmware stopping I/O */
+ msleep(100);

cmd_clear_io_res.func_idx = HINIC_HWIF_FUNC_IDX(hwif);

--
2.20.1



2020-04-16 20:39:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 026/146] gfs2: Dont demote a glock until its revokes are written

From: Bob Peterson <[email protected]>

[ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ]

Before this patch, run_queue would demote glocks based on whether
there are any more holders. But if the glock has pending revokes that
haven't been written to the media, giving up the glock might end in
file system corruption if the revokes never get written due to
io errors, node crashes and fences, etc. In that case, another node
will replay the metadata blocks associated with the glock, but
because the revoke was never written, it could replay that block
even though the glock had since been granted to another node who
might have made changes.

This patch changes the logic in run_queue so that it never demotes
a glock until its count of pending revokes reaches zero.

Signed-off-by: Bob Peterson <[email protected]>
Reviewed-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/gfs2/glock.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index ccdd8c821abd7..f8a5eef3d014b 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -636,6 +636,9 @@ __acquires(&gl->gl_lockref.lock)
goto out_unlock;
if (nonblock)
goto out_sched;
+ smp_mb();
+ if (atomic_read(&gl->gl_revokes) != 0)
+ goto out_sched;
set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags);
GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE);
gl->gl_target = gl->gl_demote_state;
--
2.20.1



2020-04-16 20:39:02

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 016/146] xhci: bail out early if driver cant accress host in resume

From: Mathias Nyman <[email protected]>

[ Upstream commit 72ae194704da212e2ec312ab182a96799d070755 ]

Bail out early if the xHC host needs to be reset at resume
but driver can't access xHC PCI registers.

If xhci driver already fails to reset the controller then there
is no point in attempting to free, re-initialize, re-allocate and
re-start the host. If failure to access the host is detected later,
failing the resume, xhci interrupts will be double freed
when remove is called.

Signed-off-by: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/usb/host/xhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 65cc362717fcb..b4177287d7d0f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1147,8 +1147,10 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
xhci_dbg(xhci, "Stop HCD\n");
xhci_halt(xhci);
xhci_zero_64b_regs(xhci);
- xhci_reset(xhci);
+ retval = xhci_reset(xhci);
spin_unlock_irq(&xhci->lock);
+ if (retval)
+ return retval;
xhci_cleanup_msix(xhci);

xhci_dbg(xhci, "// Disabling event ring interrupts\n");
--
2.20.1



2020-04-16 20:39:47

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 140/146] Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"

[ Upstream commit a86675968e2300fb567994459da3dbc4cd1b322a ]

This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a.

This commit ends up causing some lockdep splats due to trying to grab the
payload lock while holding the mgr's lock:

[ 54.010099]
[ 54.011765] ======================================================
[ 54.018670] WARNING: possible circular locking dependency detected
[ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
[ 54.031610] ------------------------------------------------------
[ 54.038516] kworker/1:6/1040 is trying to acquire lock:
[ 54.044354] ffff888272af3228 (&mgr->payload_lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.054957]
[ 54.054957] but task is already holding lock:
[ 54.061473] ffff888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.071193]
[ 54.071193] which lock already depends on the new lock.
[ 54.071193]
[ 54.080334]
[ 54.080334] the existing dependency chain (in reverse order) is:
[ 54.088697]
[ 54.088697] -> #1 (&mgr->lock){+.+.}:
[ 54.094440] __mutex_lock+0xc3/0x498
[ 54.099015] drm_dp_mst_topology_get_port_validated+0x25/0x80
[ 54.106018] drm_dp_update_payload_part1+0xa2/0x2e2
[ 54.112051] intel_mst_pre_enable_dp+0x144/0x18f
[ 54.117791] intel_encoders_pre_enable+0x63/0x70
[ 54.123532] hsw_crtc_enable+0xa1/0x722
[ 54.128396] intel_update_crtc+0x50/0x194
[ 54.133455] skl_commit_modeset_enables+0x40c/0x540
[ 54.139485] intel_atomic_commit_tail+0x5f7/0x130d
[ 54.145418] intel_atomic_commit+0x2c8/0x2d8
[ 54.150770] drm_atomic_helper_set_config+0x5a/0x70
[ 54.156801] drm_mode_setcrtc+0x2ab/0x833
[ 54.161862] drm_ioctl+0x2e5/0x424
[ 54.166242] vfs_ioctl+0x21/0x2f
[ 54.170426] do_vfs_ioctl+0x5fb/0x61e
[ 54.175096] ksys_ioctl+0x55/0x75
[ 54.179377] __x64_sys_ioctl+0x1a/0x1e
[ 54.184146] do_syscall_64+0x5c/0x6d
[ 54.188721] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 54.194946]
[ 54.194946] -> #0 (&mgr->payload_lock){+.+.}:
[ 54.201463]
[ 54.201463] other info that might help us debug this:
[ 54.201463]
[ 54.210410] Possible unsafe locking scenario:
[ 54.210410]
[ 54.217025] CPU0 CPU1
[ 54.222082] ---- ----
[ 54.227138] lock(&mgr->lock);
[ 54.230643] lock(&mgr->payload_lock);
[ 54.237742] lock(&mgr->lock);
[ 54.244062] lock(&mgr->payload_lock);
[ 54.248346]
[ 54.248346] *** DEADLOCK ***
[ 54.248346]
[ 54.254959] 7 locks held by kworker/1:6/1040:
[ 54.259822] #0: ffff888275c4f528 ((wq_completion)events){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.269451] #1: ffffc9000119beb0
((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.},
at: worker_thread+0x455/0x6e2
[ 54.282768] #2: ffff888272a403f0 (&dev->mode_config.mutex){+.+.},
at: i915_hotplug_work_func+0x4b/0x2be
[ 54.293368] #3: ffffffff824fc6c0 (drm_connector_list_iter){.+.+},
at: i915_hotplug_work_func+0x17e/0x2be
[ 54.304061] #4: ffffc9000119bc58 (crtc_ww_class_acquire){+.+.},
at: drm_helper_probe_detect_ctx+0x40/0xfd
[ 54.314855] #5: ffff888272a40470 (crtc_ww_class_mutex){+.+.}, at:
drm_modeset_lock+0x74/0xe2
[ 54.324385] #6: ffff888272af3060 (&mgr->lock){+.+.}, at:
drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
[ 54.334597]
[ 54.334597] stack backtrace:
[ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
5.5.0-rc6-02274-g77381c23ee63 #47
[ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
Google_Fizz.10139.39.0 01/04/2018
[ 54.357451] Workqueue: events i915_hotplug_work_func
[ 54.362995] Call Trace:
[ 54.365724] dump_stack+0x71/0x9c
[ 54.369427] check_noncircular+0x91/0xbc
[ 54.373809] ? __lock_acquire+0xc9e/0xf66
[ 54.378286] ? __lock_acquire+0xc9e/0xf66
[ 54.382763] ? lock_acquire+0x175/0x1ac
[ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.393177] ? __mutex_lock+0xc3/0x498
[ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
[ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
[ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
[ 54.432482] ? intel_dp_detect+0x227/0x44e
[ 54.437056] ? ww_mutex_lock+0x49/0x9a
[ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd
[ 54.446789] ? intel_encoder_hotplug+0x4b/0x97
[ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0
[ 54.456423] ? mark_held_locks+0x53/0x68
[ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51
[ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4
[ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a
[ 54.476953] ? i915_hotplug_work_func+0x206/0x2be
[ 54.482208] ? worker_thread+0x4d5/0x6e2
[ 54.486587] ? worker_thread+0x455/0x6e2
[ 54.490966] ? queue_work_on+0x64/0x64
[ 54.495151] ? kthread+0x1e9/0x1f1
[ 54.498946] ? queue_work_on+0x64/0x64
[ 54.503130] ? kthread_unpark+0x5e/0x5e
[ 54.507413] ? ret_from_fork+0x3a/0x50

The proper fix for this is probably cleanup the VCPI allocations when we're
enabling the topology, or on the first payload allocation. For now though,
let's just revert.

Signed-off-by: Lyude Paul <[email protected]>
Fixes: 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
Cc: Sean Paul <[email protected]>
Cc: Wayne Lin <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12 ------------
1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7c3c323773d3d..b4fd20062bb80 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2115,7 +2115,6 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool mst_state)
{
int ret = 0;
- int i = 0;
struct drm_dp_mst_branch *mstb = NULL;

mutex_lock(&mgr->lock);
@@ -2176,21 +2175,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
- mutex_lock(&mgr->payload_lock);
memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payload));
mgr->payload_mask = 0;
set_bit(0, &mgr->payload_mask);
- for (i = 0; i < mgr->max_payloads; i++) {
- struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
-
- if (vcpi) {
- vcpi->vcpi = 0;
- vcpi->num_slots = 0;
- }
- mgr->proposed_vcpis[i] = NULL;
- }
mgr->vcpi_mask = 0;
- mutex_unlock(&mgr->payload_lock);
}

out_unlock:
--
2.20.1



2020-04-16 20:40:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 057/146] ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups

From: Thomas Hebb <[email protected]>

commit f36938aa7440f46a0a365f1cfde5f5985af2bef3 upstream.

patch_realtek.c has historically failed to properly configure the PC
Beep Hidden Register for the ALC256 codec (among others). Depending on
your kernel version, symptoms of this misconfiguration can range from
chassis noise, picked up by a poorly-shielded PCBEEP trace, getting
amplified and played on your internal speaker and/or headphones to loud
feedback, which responds to the "Headphone Mic Boost" ALSA control,
getting played through your headphones. For details of the problem, see
the patch in this series titled "ALSA: hda/realtek - Set principled PC
Beep configuration for ALC256", which fixes the configuration.

These symptoms have been most noticed on the Dell XPS 13 9350 and 9360,
popular laptops that use the ALC256. As a result, several model-specific
fixups have been introduced to try and fix the problem, the most
egregious of which locks the "Headphone Mic Boost" control as a hack to
minimize noise from a feedback loop that shouldn't have been there in
the first place.

Now that the underlying issue has been fixed, remove all these fixups.
Remaining fixups needed by the XPS 13 are all picked up by existing pin
quirks.

This change should, for the XPS 13 9350/9360

- Significantly increase volume and audio quality on headphones
- Eliminate headphone popping on suspend/resume
- Allow "Headphone Mic Boost" to be set again, making the headphone
jack fully usable as a microphone jack too.

Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3")
Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360")
Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant")
Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360")
Cc: [email protected]
Signed-off-by: Thomas Hebb <[email protected]>
Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
Documentation/sound/hd-audio/models.rst | 2 -
sound/pci/hda/patch_realtek.c | 34 --------------------------------
2 files changed, 36 deletions(-)

--- a/Documentation/sound/hd-audio/models.rst
+++ b/Documentation/sound/hd-audio/models.rst
@@ -216,8 +216,6 @@ alc298-dell-aio
ALC298 fixups on Dell AIO machines
alc275-dell-xps
ALC275 fixups on Dell XPS models
-alc256-dell-xps13
- ALC256 fixups on Dell XPS13
lenovo-spk-noise
Workaround for speaker noise on Lenovo machines
lenovo-hotkey
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5272,17 +5272,6 @@ static void alc271_hp_gate_mic_jack(stru
}
}

-static void alc256_fixup_dell_xps_13_headphone_noise2(struct hda_codec *codec,
- const struct hda_fixup *fix,
- int action)
-{
- if (action != HDA_FIXUP_ACT_PRE_PROBE)
- return;
-
- snd_hda_codec_amp_stereo(codec, 0x1a, HDA_INPUT, 0, HDA_AMP_VOLMASK, 1);
- snd_hda_override_wcaps(codec, 0x1a, get_wcaps(codec, 0x1a) & ~AC_WCAP_IN_AMP);
-}
-
static void alc269_fixup_limit_int_mic_boost(struct hda_codec *codec,
const struct hda_fixup *fix,
int action)
@@ -5674,8 +5663,6 @@ enum {
ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE,
ALC275_FIXUP_DELL_XPS,
- ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE,
- ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2,
ALC293_FIXUP_LENOVO_SPK_NOISE,
ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
ALC255_FIXUP_DELL_SPK_NOISE,
@@ -6387,23 +6374,6 @@ static const struct hda_fixup alc269_fix
{}
}
},
- [ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE] = {
- .type = HDA_FIXUP_VERBS,
- .v.verbs = (const struct hda_verb[]) {
- /* Disable pass-through path for FRONT 14h */
- {0x20, AC_VERB_SET_COEF_INDEX, 0x36},
- {0x20, AC_VERB_SET_PROC_COEF, 0x1737},
- {}
- },
- .chained = true,
- .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
- },
- [ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2] = {
- .type = HDA_FIXUP_FUNC,
- .v.func = alc256_fixup_dell_xps_13_headphone_noise2,
- .chained = true,
- .chain_id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE
- },
[ALC293_FIXUP_LENOVO_SPK_NOISE] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_disable_aamix,
@@ -6871,17 +6841,14 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x06de, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06df, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
- SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x0738, "Dell Precision 5820", ALC269_FIXUP_NO_SHUTUP),
- SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
SND_PCI_QUIRK(0x1028, 0x075c, "Dell XPS 27 7760", ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x07b0, "Dell Precision 7520", ALC295_FIXUP_DISABLE_DAC3),
SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x080c, "Dell WYSE", ALC225_FIXUP_DELL_WYSE_MIC_NO_PRESENCE),
- SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
@@ -7232,7 +7199,6 @@ static const struct hda_model_fixup alc2
{.id = ALC298_FIXUP_DELL1_MIC_NO_PRESENCE, .name = "alc298-dell1"},
{.id = ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE, .name = "alc298-dell-aio"},
{.id = ALC275_FIXUP_DELL_XPS, .name = "alc275-dell-xps"},
- {.id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE, .name = "alc256-dell-xps13"},
{.id = ALC293_FIXUP_LENOVO_SPK_NOISE, .name = "lenovo-spk-noise"},
{.id = ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY, .name = "lenovo-hotkey"},
{.id = ALC255_FIXUP_DELL_SPK_NOISE, .name = "dell-spk-noise"},


2020-04-16 20:40:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 055/146] ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256

From: Thomas Hebb <[email protected]>

commit f128090491c3f5aacef91a863f8c52abf869c436 upstream.

This codec (among others) has a hidden set of audio routes, apparently
designed to allow PC Beep output without a mixer widget on the output
path, which are controlled by an undocumented Realtek vendor register.
The default configuration of these routes means that certain inputs
aren't accessible, necessitating driver control of the register.
However, Realtek has provided no documentation of the register, instead
opting to fix issues by providing magic numbers, most of which have been
at least somewhat erroneous. These magic numbers then get copied by
others into model-specific fixups, leading to a fragmented and buggy set
of configurations.

To get out of this situation, I've reverse engineered the register by
flipping bits and observing how the codec's behavior changes. This
commit documents my findings. It does not change any code.

Cc: [email protected]
Signed-off-by: Thomas Hebb <[email protected]>
Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
Documentation/sound/hd-audio/index.rst | 1
Documentation/sound/hd-audio/realtek-pc-beep.rst | 129 +++++++++++++++++++++++
2 files changed, 130 insertions(+)

--- a/Documentation/sound/hd-audio/index.rst
+++ b/Documentation/sound/hd-audio/index.rst
@@ -8,3 +8,4 @@ HD-Audio
models
controls
dp-mst
+ realtek-pc-beep
--- /dev/null
+++ b/Documentation/sound/hd-audio/realtek-pc-beep.rst
@@ -0,0 +1,129 @@
+===============================
+Realtek PC Beep Hidden Register
+===============================
+
+This file documents the "PC Beep Hidden Register", which is present in certain
+Realtek HDA codecs and controls a muxer and pair of passthrough mixers that can
+route audio between pins but aren't themselves exposed as HDA widgets. As far
+as I can tell, these hidden routes are designed to allow flexible PC Beep output
+for codecs that don't have mixer widgets in their output paths. Why it's easier
+to hide a mixer behind an undocumented vendor register than to just expose it
+as a widget, I have no idea.
+
+Register Description
+====================
+
+The register is accessed via processing coefficient 0x36 on NID 20h. Bits not
+identified below have no discernible effect on my machine, a Dell XPS 13 9350::
+
+ MSB LSB
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |h|S|L| | B |R| | Known bits
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ |0|0|1|1| 0x7 |0|0x0|1| 0x7 | Reset value
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+1Ah input select (B): 2 bits
+ When zero, expose the PC Beep line (from the internal beep generator, when
+ enabled with the Set Beep Generation verb on NID 01h, or else from the
+ external PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphone
+ jack (or possibly Line In on some machines) input instead. If PC Beep is
+ selected, the 1Ah boost control has no effect.
+
+Amplify 1Ah loopback, left (L): 1 bit
+ Amplify the left channel of 1Ah before mixing it into outputs as specified
+ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
+
+Amplify 1Ah loopback, right (R): 1 bit
+ Amplify the right channel of 1Ah before mixing it into outputs as specified
+ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
+
+Loopback 1Ah to 21h [active low] (h): 1 bit
+ When zero, mix 1Ah (possibly with amplification, depending on L and R bits)
+ into 21h (headphone jack on my machine). Mixed signal respects the mute
+ setting on 21h.
+
+Loopback 1Ah to 14h (S): 1 bit
+ When one, mix 1Ah (possibly with amplification, depending on L and R bits)
+ into 14h (internal speaker on my machine). Mixed signal **ignores** the mute
+ setting on 14h and is present whenever 14h is configured as an output.
+
+Path diagrams
+=============
+
+1Ah input selection (DIV is the PC Beep divider set on NID 01h)::
+
+ <Beep generator> <PCBEEP pin> <Headphone jack>
+ | | |
+ +--DIV--+--!DIV--+ {1Ah boost control}
+ | |
+ +--(b == 0)--+--(b != 0)--+
+ |
+ >1Ah (Beep/Headphone Mic/Line In)<
+
+Loopback of 1Ah to 21h/14h::
+
+ <1Ah (Beep/Headphone Mic/Line In)>
+ |
+ {amplify if L/R}
+ |
+ +-----!h-----+-----S-----+
+ | |
+ {21h mute control} |
+ | |
+ >21h (Headphone)< >14h (Internal Speaker)<
+
+Background
+==========
+
+All Realtek HDA codecs have a vendor-defined widget with node ID 20h which
+provides access to a bank of registers that control various codec functions.
+Registers are read and written via the standard HDA processing coefficient
+verbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node is
+named "Realtek Vendor Registers" in public datasheets' verb listings and,
+apart from that, is entirely undocumented.
+
+This particular register, exposed at coefficient 0x36 and named in commits from
+Realtek, is of note: unlike most registers, which seem to control detailed
+amplifier parameters not in scope of the HDA specification, it controls audio
+routing which could just as easily have been defined using standard HDA mixer
+and selector widgets.
+
+Specifically, it selects between two sources for the input pin widget with Node
+ID (NID) 1Ah: the widget's signal can come either from an audio jack (on my
+laptop, a Dell XPS 13 9350, it's the headphone jack, but comments in Realtek
+commits indicate that it might be a Line In on some machines) or from the PC
+Beep line (which is itself multiplexed between the codec's internal beep
+generator and external PCBEEP pin, depending on if the beep generator is
+enabled via verbs on NID 01h). Additionally, it can mix (with optional
+amplification) that signal onto the 21h and/or 14h output pins.
+
+The register's reset value is 0x3717, corresponding to PC Beep on 1Ah that is
+then amplified and mixed into both the headphones and the speakers. Not only
+does this violate the HDA specification, which says that "[a vendor defined
+beep input pin] connection may be maintained *only* while the Link reset
+(**RST#**) is asserted", it means that we cannot ignore the register if we care
+about the input that 1Ah would otherwise expose or if the PCBEEP trace is
+poorly shielded and picks up chassis noise (both of which are the case on my
+machine).
+
+Unfortunately, there are lots of ways to get this register configuration wrong.
+Linux, it seems, has gone through most of them. For one, the register resets
+after S3 suspend: judging by existing code, this isn't the case for all vendor
+registers, and it's led to some fixes that improve behavior on cold boot but
+don't last after suspend. Other fixes have successfully switched the 1Ah input
+away from PC Beep but have failed to disable both loopback paths. On my
+machine, this means that the headphone input is amplified and looped back to
+the headphone output, which uses the exact same pins! As you might expect, this
+causes terrible headphone noise, the character of which is controlled by the
+1Ah boost control. (If you've seen instructions online to fix XPS 13 headphone
+noise by changing "Headphone Mic Boost" in ALSA, now you know why.)
+
+The information here has been obtained through black-box reverse engineering of
+the ALC256 codec's behavior and is not guaranteed to be correct. It likely
+also applies for the ALC255, ALC257, ALC235, and ALC236, since those codecs
+seem to be close relatives of the ALC256. (They all share one initialization
+function.) Additionally, other codecs like the ALC225 and ALC285 also have this
+register, judging by existing fixups in ``patch_realtek.c``, but specific
+data (e.g. node IDs, bit positions, pin mappings) for those codecs may differ
+from what I've described here.


2020-04-16 20:40:24

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 032/146] usb: dwc3: core: add support for disabling SS instances in park mode

From: Neil Armstrong <[email protected]>

[ Upstream commit 7ba6b09fda5e0cb741ee56f3264665e0edc64822 ]

In certain circumstances, the XHCI SuperSpeed instance in park mode
can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
load on the single XHCI SuperSpeed instance, the controller can crash like:
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
usb 2-1.1-port1: cannot reset (err = -22)

Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
the issue. The bit is described as :
"When this bit is set to '1' all SS bus instances in park mode are disabled"

Synopsys explains:
The GUCTL1.PARKMODE_DISABLE_SS is only available in
dwc_usb3 controller running in host mode.
This should not be set for other IPs.
This can be disabled by default based on IP, but I recommend to have a
property to enable this feature for devices that need this.

CC: Dongjin Kim <[email protected]>
Cc: Jianxin Pan <[email protected]>
Cc: Thinh Nguyen <[email protected]>
Cc: Jun Li <[email protected]>
Reported-by: Tim <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/usb/dwc3/core.c | 5 +++++
drivers/usb/dwc3/core.h | 4 ++++
2 files changed, 9 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6666d2a52bf56..60d08269ad9a0 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -981,6 +981,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (dwc->dis_tx_ipgap_linecheck_quirk)
reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;

+ if (dwc->parkmode_disable_ss_quirk)
+ reg |= DWC3_GUCTL1_PARKMODE_DISABLE_SS;
+
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}

@@ -1287,6 +1290,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-del-phy-power-chg-quirk");
dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
"snps,dis-tx-ipgap-linecheck-quirk");
+ dwc->parkmode_disable_ss_quirk = device_property_read_bool(dev,
+ "snps,parkmode-disable-ss-quirk");

dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 131028501752b..e34308d64619e 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -242,6 +242,7 @@
#define DWC3_GUCTL_HSTINAUTORETRY BIT(14)

/* Global User Control 1 Register */
+#define DWC3_GUCTL1_PARKMODE_DISABLE_SS BIT(17)
#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)

@@ -992,6 +993,8 @@ struct dwc3_scratchpad_array {
* change quirk.
* @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
* check during HS transmit.
+ * @parkmode_disable_ss_quirk: set if we need to disable all SuperSpeed
+ * instances in park mode.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -1163,6 +1166,7 @@ struct dwc3 {
unsigned dis_u2_freeclk_exists_quirk:1;
unsigned dis_del_phy_power_chg_quirk:1;
unsigned dis_tx_ipgap_linecheck_quirk:1;
+ unsigned parkmode_disable_ss_quirk:1;

unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
--
2.20.1



2020-04-16 20:40:27

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 002/146] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads

From: Ondrej Jirman <[email protected]>

[ Upstream commit a43ab30dcd4a1abcdd0d2461bf1cf7c0817f6cd3 ]

When doing a 16-bit read that returns data in the MSB byte, the
RSB_DATA register will keep the MSB byte unchanged when doing
the following 8-bit read. sunxi_rsb_read() will then return
a result that contains high byte from 16-bit read mixed with
the 8-bit result.

The consequence is that after this happens the PMIC's regmap will
look like this: (0x33 is the high byte from the 16-bit read)

% cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
00: 33
01: 33
02: 33
03: 33
04: 33
05: 33
06: 33
07: 33
08: 33
09: 33
0a: 33
0b: 33
0c: 33
0d: 33
0e: 33
[snip]

Fix this by masking the result of the read with the correct mask
based on the size of the read. There are no 16-bit users in the
mainline kernel, so this doesn't need to get into the stable tree.

Signed-off-by: Ondrej Jirman <[email protected]>
Acked-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/bus/sunxi-rsb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 1b76d95859027..2ca2cc56bcef6 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -345,7 +345,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
if (ret)
goto unlock;

- *buf = readl(rsb->regs + RSB_DATA);
+ *buf = readl(rsb->regs + RSB_DATA) & GENMASK(len * 8 - 1, 0);

unlock:
mutex_unlock(&rsb->lock);
--
2.20.1



2020-04-16 20:40:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 4.19 027/146] x86/boot: Use unsigned comparison for addresses

From: Arvind Sankar <[email protected]>

[ Upstream commit 81a34892c2c7c809f9c4e22c5ac936ae673fb9a2 ]

The load address is compared with LOAD_PHYSICAL_ADDR using a signed
comparison currently (using jge instruction).

When loading a 64-bit kernel using the new efi32_pe_entry() point added by:

97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section")

using Qemu with -m 3072, the firmware actually loads us above 2Gb,
resulting in a very early crash.

Use the JAE instruction to perform a unsigned comparison instead, as physical
addresses should be considered unsigned.

Signed-off-by: Arvind Sankar <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/boot/compressed/head_32.S | 2 +-
arch/x86/boot/compressed/head_64.S | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index 37380c0d59996..01d628ea34024 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -106,7 +106,7 @@ ENTRY(startup_32)
notl %eax
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
- jge 1f
+ jae 1f
#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 4eaa724afce34..9fa644c62839f 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -106,7 +106,7 @@ ENTRY(startup_32)
notl %eax
andl %eax, %ebx
cmpl $LOAD_PHYSICAL_ADDR, %ebx
- jge 1f
+ jae 1f
#endif
movl $LOAD_PHYSICAL_ADDR, %ebx
1:
@@ -297,7 +297,7 @@ ENTRY(startup_64)
notq %rax
andq %rax, %rbp
cmpq $LOAD_PHYSICAL_ADDR, %rbp
- jge 1f
+ jae 1f
#endif
movq $LOAD_PHYSICAL_ADDR, %rbp
1:
--
2.20.1



2020-04-16 21:17:11

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review

On 4/16/20 6:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.116 release.
> There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 418 pass: 418 fail: 0

Guenter

2020-04-16 22:11:30

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review

On 4/16/20 7:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.116 release.
> There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> 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.116-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
>

Compiled and booted on my test system. No dmesg regressions.
This one is clean and reboot and poweroff worked just fine.

thanks,
-- Shuah

2020-04-17 06:16:36

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review

On Thu, 16 Apr 2020 at 18:56, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.116 release.
> There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> 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.116-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
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.19.116-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 287f80e07bbc28d3a2a25d2b53674c912d515376
git describe: v4.19.115-147-g287f80e07bbc
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.115-147-g287f80e07bbc


No regressions (compared to build v4.19.114-55-g3b903e5affcf)

No fixes (compared to build v4.19.114-55-g3b903e5affcf)

Ran 31564 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* linux-log-parser
* ltp-cve-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* perf
* kselftest
* kvm-unit-tests
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* ltp-fs-tests
* ltp-open-posix-tests
* v4l2-compliance
* spectre-meltdown-checker-test
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

2020-04-17 09:45:50

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review


On 16/04/2020 14:22, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.116 release.
> There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> 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.116-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


All tests are passing for Tegra ...

Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 fail

Linux version: 4.19.116-rc1-g287f80e07bbc
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-04-17 12:37:40

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.19.116 release.
> There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> 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.116-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.

CIP project ran tests on this one, and we have de0-nano failure:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/136707029

Detailed results should be at:

https://lava.ciplatform.org/scheduler/job/14716
https://lava.ciplatform.org/scheduler/job/14717

..but those results do not load for me (?).

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (1.16 kB)
signature.asc (201.00 B)
Download all attachments

2020-04-17 13:39:49

by Daniel Díaz

[permalink] [raw]
Subject: Re: [PATCH 4.19 000/146] 4.19.116-rc1 review

Hello!

On Fri, 17 Apr 2020 at 07:35, Pavel Machek <[email protected]> wrote:
>
> Hi!
>
> > This is the start of the stable review cycle for the 4.19.116 release.
> > There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> > 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.116-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.
>
> CIP project ran tests on this one, and we have de0-nano failure:
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/136707029
>
> Detailed results should be at:
>
> https://lava.ciplatform.org/scheduler/job/14716
> https://lava.ciplatform.org/scheduler/job/14717
>
> ..but those results do not load for me (?).

Looks like the device failed its health job and went into bad state.
Jobs submitted for that device are still queued, hence the time out.

Greetings!

Daniel Díaz
[email protected]

2020-04-17 14:54:24

by Chris Paterson

[permalink] [raw]
Subject: RE: [PATCH 4.19 000/146] 4.19.116-rc1 review

Hello Pavel,

> From: Daniel Díaz <[email protected]>
> Sent: 17 April 2020 14:38
>
> Hello!
>
> On Fri, 17 Apr 2020 at 07:35, Pavel Machek <[email protected]> wrote:
> >
> > Hi!
> >
> > > This is the start of the stable review cycle for the 4.19.116 release.
> > > There are 146 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 Sat, 18 Apr 2020 13:11:20 +0000.
> > > 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.116-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.
> >
> > CIP project ran tests on this one, and we have de0-nano failure:
> >
> > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-
> ci/pipelines/136707029
> >
> > Detailed results should be at:
> >
> > https://lava.ciplatform.org/scheduler/job/14716
> > https://lava.ciplatform.org/scheduler/job/14717
> >
> > ..but those results do not load for me (?).
>
> Looks like the device failed its health job and went into bad state.
> Jobs submitted for that device are still queued, hence the time out.

Exactly that (thanks Daniel).

The board is now back online and the submitted jobs have passed.

Kind regards, Chris

>
> Greetings!
>
> Daniel Díaz
> [email protected]